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.
Why is this even a thing and isn't opt-in?
I dread the idea of starting to get notifications from them in my own projects.
void nobody_calls_me(const char *stuff) {
char *a, *b;
const size_t c = 1024;
a = calloc(c);
if (!a) return;
b = malloc(c);
if (!b) {
free(a);
return;
}
strncpy(a, stuff, c - 1);
strcpy(b, a);
strcpy(a, b);
free(a);
free(b);
}
> 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?
people overestimate AI
So like why doesn't the person iterate with the AI until they understand the bug (and then ultimately discover it doesn't exist)? Like have any of this bug reports actually paid out? It seems like quickly people should just give up from a lack of rewards.
Not helped, I imagine, that once you realise it doesn't work, an easy pivot is to start convincing new people that it'll work if they pay you money for a course on it.
> 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/
https://gist.github.com/bagder/07f7581f6e3d78ef37dfbfc81fd1d...
https://daniel.haxx.se/blog/2025/10/10/a-new-breed-of-analyz...
and its HN discussion:
DEBUGASSERT(slen < dsize);
I would have preferred an explicit error code though.
But regardless of whether the assert is compiled or not, its presence strongly signals that "in a C program strcpy should only be used when we have full control of both" is true for this new function as well.
So now it silently fails and sets dest to an empty string without even partially copying anything!?
I don't really think this adds anything over forcing callers to use memcpy directly, instead of strcpy.
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
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
There’s languages where you can be quite confident your string will never need null termination… but C is not one of them.
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.
Also I'm not sure what you mean with C successor languages not having undefined behaviour, as both Rust and Zig inherit it wholesale from LLVM. At least last I checked that was the case, correct me if I am wrong. Go, Java and C# all have sane behaviour, but those are much higher level.
You would think char symbol[20] would be inefficient for such performance sensitive software, but for the vast majority of exchanges, their technical competencies were not there to properly replace these readable symbol/IDs with a compact/opaque integer ID like a u32. Several exchanges tried and they had numerous issues with IDs not being "properly" unique across symbol types, or time (intra-day or shortly before the open restarts were a common nightmare), etc. A char symbol[20] and strncpy was a dream by comparison.
But also all of this book-keeping takes up extra time and space which is a trade-off easily made nowadays.
Viruses did exist, and these were considered users' fault too.
After all this time the initial AI Slop report was right:
Nonce and websockets don't appear at all in the blog post. The only thing the ai slop got right is that by removing strcpy curl will get less issues [submitted about it].
senthil_rajasek•2h ago
No strcpy either
@dang
Snild•2h ago
1f60c•1h ago
Snild•44m ago