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

11–20 of 151 posts

Re: No strcpy either

#11

Post by saagarjha »

pama wrote: post #3

Congrats on the completion of this effort! C/C++ can be memory safe but take some effort. IMHO the timeline figure could benefit in mobile from using larger fonts. Most plotting libraries have horrible font size defaults. I wonder why no library picked the other extreme end: I have never seen too large an axis label yet.

Removing strcpy from your code does not make it memory safe.

Re: No strcpy either

#12

Post by CGamesPlay »

Scubabear68 wrote: post #7

From the article: > It has been proven numerous times already that strcpy in source code is like a honey pot for generating hallucinated vulnerability claims This closing thought in the article really stood out to me. Why even bother to run AI checking on C code if the AI flags strcpy() as a problem without caveat?

It's not quite as black and white as the article implies. The hallucinated vulnerability reports don't flag it "without caveat", they invent a convoluted proof of vulnerability with a logical error somewhere along the way, and then this is what gets submitted as the vulnerability report. That's why it's so agitating for the maintainers: it requires reading a "proof" and finding the contradiction.

Re: No strcpy either

#13

Post by stabbles »

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/

Re: No strcpy either

#14

Post by swinglock »

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.

Re: No strcpy either

#15

Post by Tempest1981 »

saagarjha wrote: post #10
Scubabear68 wrote: post #7

From the article: > It has been proven numerous times already that strcpy in source code is like a honey pot for generating hallucinated vulnerability claims This closing thought in the article really stood out to me. Why even bother to run AI checking on C code if the AI flags strcpy() as a problem without caveat?

Because people are stupid and use AI for things it is not good at.

> people are stupid

people overestimate AI

Re: No strcpy either

#16

Post by loeg »

A weird Annex-K like API. The destination buffer size includes space for the trailing nul, but the source size only includes non-nul string bytes.

I don't really think this adds anything over forcing callers to use memcpy directly, instead of strcpy.

Re: No strcpy either

#17

Post by AlexeyBrin »

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.

I guess the idea is that if the code does not crash at this line:

    DEBUGASSERT(slen
it means it succeeded. Although some compilers will remove the assertions in release builds.

I would have preferred an explicit error code though.

Re: No strcpy either

#18

Post by t43562 »

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

Re: No strcpy either

#19

Post by Tempest1981 »

pama wrote: post #3

Congrats on the completion of this effort! C/C++ can be memory safe but take some effort. IMHO the timeline figure could benefit in mobile from using larger fonts. Most plotting libraries have horrible font size defaults. I wonder why no library picked the other extreme end: I have never seen too large an axis label yet.

Yes, the graph font-sizes seem intended for printing them on a single sheet of paper, vs squeezed into a single column in a blog.

Re: No strcpy either

#20

Post by 1f60c »

Snild wrote: post #6
senthil_rajasek wrote: post #2

Title is : No strcpy either @dang

I don't see a problem with that, but for the record, the title on the site is lower-case for me (both browser tab title, and the header when in reader mode).

I think the submission originally had a typo ("strpy", with no C)
Post reply on HN