Talk:c/string/byte/strncpy

UB of strncpy_s

Writing beyond the end of array dest is buffer overflow:

                                                        count
        -------------------------------------------------
 src:   |                    | \0 |                     |
        ------------------------------------------------- 
        |                         |
        |                         | 
        V                         V              destsz
        -------------.............................
dest:   |           |                            .
        -------------.............................

Reading beyond the end of array src is buffer overflow:

                                      count
        ---------------................
 src:   |             |               .
        ---------------................
        |                             |
        |                             | 
        V                             V                destsz
        ------------------------------------------------
dest:   |                             | \0 |           |
        ------------------------------------------------

Newatthis (talk) 03:49, 18 September 2015 (PDT)

could you please sign your posts to Talk pages? See the instructions above this edit box. (also, are you asking a question?) --Cubbi (talk) 19:16, 17 September 2015 (PDT)

With the diagrams, I am attempting to prompt a discussion about the cases leftover after the *_s functions finish testing for runtime constraint violations since case 2 in the essays lacked any mention of UB. Newatthis (talk) 03:49, 18 September 2015 (PDT)

Of course there will be ways to trigger undefined behavior, the _s functions were never intended to have wide contracts. Why so much attention on strncpy_s and not the more common strncpy? --Cubbi (talk) 06:05, 18 September 2015 (PDT)

I lack the experience to know which string.h functions are more commonly used in the real world. I do understand that strncpy has been a part of the library forever while strncpy_s is an optional newcomer. I suppose that I can infer that the older strncpy appears in more programs than the optional strncpy_s. If my efforts appear to exhibit more attention on strncpy_s, it is only because I struggled to master the cases of UB of this function. My larger goal is to see the big UB picture of string.h and how *_s functions partially address the issue. Also, I noticed that the pages offered some sentences about UB for the unsecure versions but none for the secure versions. I wanted to learn enough to provide some explanation for the *_s versions. Newatthis (talk) 06:06, 20 September 2015 (PDT)

UB statements

The statement regarding the UB of strncpy() was clearly in error. C99 clearly states (in footnote 260): "...if there is no null character in the first `n` characters of the array pointed to by s2, the result will not be null-terminated." The target buffer not being null-terminated is well-defined behaviour. Just continuing to use it as a C string is UB.

I cannot judge the corresponding statements regarding strncpy_s(), since I do not have the C11 document at hand and find the statement itself rather confusing, but I urge editors to have a close look at it as the edits were made close to each other, and by the same user. --DevSolar (talk) 08:46, 8 February 2016 (PST)

the note didn't say "target buffer is not null-terminated", it said "the behavior is undefined if the dest array is not large enough." - that's a simple buffer overrun:

char src[] = "abcde";
char dest[2]; // dest is not large enough
strncpy(dest, src, 6);

--Cubbi (talk) 10:57, 8 February 2016 (PST)

You are correct that it was correct. My mistake; somehow I got the whole thing backwards (n being the size available in dest assumed a given, and n being less than the size in src resulting in UB). Yes I know. More sleeping, less caffeine-induced raging. My apologies. --DevSolar (talk) 13:12, 9 February 2016 (PST)