Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No strcpy either

daniel.haxx.se

Post reply on HN
Print view View original

21–30 of 151 posts

Re: No strcpy either

#21

Post by p2detar »

stabbles wrote: post #13

Apart from Daniel Sternberg's frequent complaints about AI slop, he also writes [1] > A new breed of AI-powered high quality code analyzers, primarily ZeroPath and Aisle Research, started pouring in bug reports to us with potential defects. We have fixed several hundred bugs as a direct result of those reports – so far. [1] https://daniel.haxx.se/blog/2025/12/23/a-curl-2025-review/

So? Those are automated analysis tools and by "slop" he seems to refer to careless reports crafted using AI, solely for collecting bounties:

https://gist.github.com/bagder/07f7581f6e3d78ef37dfbfc81fd1d...

Re: No strcpy either

#22

Post by molf »

stabbles wrote: post #13

Apart from Daniel Sternberg's frequent complaints about AI slop, he also writes [1] > A new breed of AI-powered high quality code analyzers, primarily ZeroPath and Aisle Research, started pouring in bug reports to us with potential defects. We have fixed several hundred bugs as a direct result of those reports – so far. [1] https://daniel.haxx.se/blog/2025/12/23/a-curl-2025-review/

That's very interesting! It links to:

https://daniel.haxx.se/blog/2025/10/10/a-new-breed-of-analyz...

and its HN discussion:

https://news.ycombinator.com/item?id=45449348

Re: No strcpy either

#23

Post by formerly_proven »

t43562 wrote: post #18

I've always wondered at the motivatons of the various string routines in C - every one of them seems to have some huge caveat which makes them useless. After years I now think it's essential to have a library which records at least how much memory is allocated to a string along with the pointer. Something like this: https://github.com/msteinert/bstring

strncpy is fairly easy, that's a special-purpose function for copying a C string into a fixed-width string, like typically used in old C applications for on-disk formats. E.g. you might have a char username[20] field which can contain up to 20 characters, with unused characters filled with NULs. That's what strncpy is for. The destination argument should always be a fixed-size char array.

A couple years ago we got a new manual page courtesy of Alejandro Colomar just about this: https://man.archlinux.org/man/string_copying.7.en

Re: No strcpy either

#25

Post by ufo »

formerly_proven wrote: post #23
t43562 wrote: post #18

I've always wondered at the motivatons of the various string routines in C - every one of them seems to have some huge caveat which makes them useless. After years I now think it's essential to have a library which records at least how much memory is allocated to a string along with the pointer. Something like this: https://github.com/msteinert/bstring

strncpy is fairly easy, that's a special-purpose function for copying a C string into a fixed-width string, like typically used in old C applications for on-disk formats. E.g. you might have a char username[20] field which can contain up to 20 characters, with unused characters filled with NULs. That's what strncpy is for. The destination argument should always be a fixed-size char array. A couple years ago we got a…

A big footgun with strncpy is that the output string may not be null terminated.

Re: No strcpy either

#26

Post by kccqzy »

ufo wrote: post #25
formerly_proven wrote: post #23

Earlier quoted context omitted.

strncpy is fairly easy, that's a special-purpose function for copying a C string into a fixed-width string, like typically used in old C applications for on-disk formats. E.g. you might have a char username[20] field which can contain up to 20 characters, with unused characters filled with NULs. That's what strncpy is for. The destination argument should always be a fixed-size char array. A couple years ago we got a…

A big footgun with strncpy is that the output string may not be null terminated.

Yeah but fixed width strings don’t need null termination. You know exactly how long the string is. No need to find that null byte.

Re: No strcpy either

#27

Post by jutter »

swinglock wrote: post #14

I'm surprised curlx_strcopy doesn't return success. Sure you could check if dest[0] != '/0' if you care to, but that's not only clumsy to write but also error prone, and so checking for success is not encouraged.

This is especially bizarre given that he explains above that "it is rare that copying a partial string is the right choice" and that the previous solution returned an error...

So now it silently fails and sets dest to an empty string without even partially copying anything!?

Re: No strcpy either

#28

Post by Cyph0n »

formerly_proven wrote: post #23
t43562 wrote: post #18

I've always wondered at the motivatons of the various string routines in C - every one of them seems to have some huge caveat which makes them useless. After years I now think it's essential to have a library which records at least how much memory is allocated to a string along with the pointer. Something like this: https://github.com/msteinert/bstring

strncpy is fairly easy, that's a special-purpose function for copying a C string into a fixed-width string, like typically used in old C applications for on-disk formats. E.g. you might have a char username[20] field which can contain up to 20 characters, with unused characters filled with NULs. That's what strncpy is for. The destination argument should always be a fixed-size char array. A couple years ago we got a…

strncpy doesn’t handle overlapping buffers (undefined behavior). Better to use strncpy_s (if you can) as it is safer overall. See: https://en.cppreference.com/w/c/string/byte/strncpy.html.

As an aside, this is part of the reason why there are so many C successor languages: you can end up with undefined behavior if you don’t always carefully read the docs.

Re: No strcpy either

#29

Post by ninkendo »

kccqzy wrote: post #26
ufo wrote: post #25

Earlier quoted context omitted.

A big footgun with strncpy is that the output string may not be null terminated.

Yeah but fixed width strings don’t need null termination. You know exactly how long the string is. No need to find that null byte.

Until you pass them as a `char *` by accident and it eventually makes its way to some code that does expect null termination.

There’s languages where you can be quite confident your string will never need null termination… but C is not one of them.

Re: No strcpy either

#30

Post by Sharlin »

kccqzy wrote: post #26
ufo wrote: post #25

Earlier quoted context omitted.

A big footgun with strncpy is that the output string may not be null terminated.

Yeah but fixed width strings don’t need null termination. You know exactly how long the string is. No need to find that null byte.

Good luck though remembering not to pass one to any function that does expect to find a null terminator.
Post reply on HN