Talk:c/string/byte/strncpy

[edit] 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)

[edit] 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);

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)

[edit] Is count == 0 a constraint violation for strncpy_s() ?

At least in C11 draft n1570, it does not say that it is a constraint violation if the last argument (count) of strncpy_s() is zero. I am not sure what the official spec says, but it makes sense to me that it should not be a constraint violation for 'count' to be zero. I'm also working with the Dinkum C libraries where it is implemented so that count == 0 is OK (not a violation). Does anyone here know what the official spec says about this?

Leastupperbound (talk) 08:30, 1 July 2020 (PDT)

looks like it was a bug in this page, dropped count == 0 --Cubbi (talk) 09:35, 1 July 2020 (PDT)

Thanks! --Leastupperbound (talk) 18:52, 1 July 2020 (PDT)