C странное поведение массива

Question

Узнав, что и strncmp не то, что кажется, и strlcpy не доступно в моей операционной системе (Linux), я подумал, что могу попытаться написать его сам.

Я нашел цитату из Ульриха Дреппера, поддерживающего libc, который разместил альтернативу strlcpy, используя mempcpy. У меня тоже нет mempcpy, но это поведение было легко реплицироваться. Во-первых, это TestCase меня

#include <stdio.h> 
#include <string.h> 

#define BSIZE 10 

void insp(const char* s, int n) 
{ 
    int i; 

    for (i = 0; i < n; i++) 
     printf("%c ", s[i]); 

    printf("\n"); 

    for (i = 0; i < n; i++) 
     printf("%02X ", s[i]); 

    printf("\n"); 

    return; 
} 

int copy_string(char *dest, const char *src, int n) 
{ 
    int r = strlen(memcpy(dest, src, n-1)); 
    dest[r] = 0; 

    return r; 
} 

int main() 
{ 
    char b[BSIZE]; 
    memset(b, 0, BSIZE); 

    printf("Buffer size is %d", BSIZE); 

    insp(b, BSIZE); 

    printf("\nFirst copy:\n"); 
    copy_string(b, "First", BSIZE); 
    insp(b, BSIZE); 
    printf("b = '%s'\n", b); 

    printf("\nSecond copy:\n"); 
    copy_string(b, "Second", BSIZE); 
    insp(b, BSIZE); 

    printf("b = '%s'\n", b); 

    return 0; 
} 

И это его результат:

Buffer size is 10      
00 00 00 00 00 00 00 00 00 00 

First copy: 
F i r s t  b  =  
46 69 72 73 74 00 62 20 3D 00 
b = 'First' 

Second copy: 
S e c o n d   
53 65 63 6F 6E 64 00 00 01 00 
b = 'Second' 

Вы можете увидеть во внутреннем представлении (линии insp() создан), что есть некоторый шум смешан в, как строка формата printf() при проверке после первой копии и внешняя 0x01 во второй копии.

Строки копируются неповрежденными и корректно обрабатывают слишком длинные строки источника (давайте проигнорируем возможную проблему с передачей 0 как длины до copy_string, теперь я исправлю это позже).

Но почему здесь находится содержимое внешнего массива (из строки формата) внутри моего адресата? Это как если бы пункт назначения был НАЗНАЧЕН, чтобы соответствовать новой длине.

Answer 1

Конец строки отмечен символом \ 0, после чего может быть что угодно, если только ваша ОС не намеренно затушевывает его, тогда это просто какой-то случайный хлам.

Обратите внимание, что в этом случае «проблема» отсутствует в copy_string, вы точно копируете 10chars, но память «first» в вашем основном коде просто случайна.

Answer 2

Поскольку вы не останавливаетесь на исходном размере, вы останавливаетесь на размер судьбы, который, случается, больше, чем источник, поэтому вы копируете исходную строку и немного мусора.

Вы можете легко видеть, что вы копируете свою исходную строку с ее нулевым терминатором. Но так как вы memcopying 10 байт, и обе строки «Первый» и «Второй» короче 10 байт, вы также копируете лишние байты мимо них.

Answer 3

Применение memcpy(dest, src, n-1) вызывает неопределенное поведение, если dest и src не в длину по меньшей мере, как n-1.

Например, First\0 имеет длину шесть символов, но вы читаете n-1 (9) символов; содержимое памяти за конец строкового литерала не определено, как и поведение вашей программы при чтении этой памяти.

Answer 4

Дополнительный «материал» есть, потому что вы прошли размер буфера до memcpy. Он собирается копировать много символов, даже если источник короче.

Я хотел бы сделать вещи немного по-другому:

void copy_string(char *dest, char const *src, size_t n) { 
    *dest = '\0'; 
    strncat(dest, src, n); 
} 

В отличие от strncpy, strncat определяется работать как большинство людей разумно ожидать.