Skip to main content


Everything has an end. strncpy usage in #curl code is now at zero calls.
#curl
in reply to zephred

@zephred mostly a check that returns error if the source is too long, otherwise a plain strcpy/memcpy. strncpy is just rarely the right choice
in reply to daniel:// stenberg://

as I have mentioned elsewhere I have worked fiercely on reducing memory calls and memory copies in curl code over the last few years, and I have come to realize that strncpy is often a marker for questionable code decisions, so I have worked on removing those questionable code paths.

As I have reduced the amount already before, the remaining few uses were not hard to just fix with better conditions and improved logic

in reply to daniel:// stenberg://

the graph for *all* allocs and copies in libcurl looks like this. It is now really hard to remove more.
in reply to daniel:// stenberg://

This can only end in you writing your own memory allocator to replace the OS allocator, and then this will just be number of times calling sbrk().
in reply to daniel:// stenberg://

yeah I have a fondness for K&R C but looking back many of its standard lib functions were a Bad Idea that at best only made sense for some brief "Garden of Eden" period in the world's software ecosystem

before any user could be a determined (and well-resourced) adversary or a mind bogglingly careless idiot. haha

This entry was edited (1 month ago)
in reply to daniel:// stenberg://

while I understand that C was always ever meant as a relatively light abstraction, I still don't understand why native string handling was never incorporated. Dealing with strings is relevant in _so_ many use cases, that not having a sane and safe abstraction for it is just asking for trouble.

I think that's one of the first things Borland improved on in their derivates of Pascal.