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