Talk:c/string/byte/strncpy

UB of strncpy_s
Writing beyond the end of array is buffer overflow: count - src:   |                    | \0 |                     | -         |                         |         |                         |          V                         V              destsz -............................. dest:  |           |. -.............................

Reading beyond the end of array 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 array is not large enough." - that's a simple buffer overrun:

--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)

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)