bubach wrote:If you did find that time&space wormhole and did have a chance of changing the standard, wouldn't you change anything?
Ahhh... now it makes more sense.
Well, most of the "bad" functions in there have been included in the standard for reasons of downward compatibility / prior art, so I would need a wormhole for
everyone who wrote a C lib prior to the standard.
I don't agree with Ztane, for one. I think it is neat to have size-checking and not-size-checking versions of the string functions. If you
know a string fits the buffer (e.g., because you have checked its size before), doing a copy without checking speeds things up. strncpy() is a piece of BS, however.
I also don't agree with Yayyak about the "weird" names of the printf() / scanf() variants. "v" means you pass va_arg instead of ..., "s" means you are working on a string instead of a stream, "f" means you define the stream instead of using stdin / stdout defaults, "n" means you do buffer-checking. That is consistent throughout the library.
I would probably try to get locale and wide-char support into the mainstream headers (<stdio.h> and <string.h>) so that US coders get to realize that the whole world isn't ASCII-7, right from the beginning, so the rest of the world doesn't have to retro-fit all that.
I would add all the stuff that was introduced with C99 and the TR's into the first standard, so we'd have <stdint.h> and <iohw.h> etc. for 18 years already... as a byproduct, we'd have <stdint.h> and long long in C++, too...
And if that wormhole would reach even
further back, I'd force system engineers to make text == binary on all systems, at gunpoint if necessary because it's a bloody nuisance to implement a lib that differentiates between the two, believe me.
But all in all, I think the standard lib - especially since C99 - is a pretty decent job and doesn't require much changing. Now, if only the Java / .NET people would stop comparing it to
their "standard" libraries...
