Hacker News Reader

Comment by yalue | Hacker News Reader

I am actually happy that gcc doesn't find it important to support a library that prevents its users from using functions that are clearly defined in the specification of the language it supports.

View on HN

I don't understand why functions like gets and sprintf weren't removed from the standard and headers a long time ago. It can't be for legacy reasons, because removing them from the headers has no effect on binaries and when you compile source it should easy to replace gets with fgets and sprintf with snprintfe etc.

These functions have no right to exist.

gets has no right to exist. But sprintf does. It's a workaround for some old embedded C compilers that lack the safe string copy functions (strcpy_s, strlcpy.)

    char dst[5];
    sprintf(dst, "%.*s", (int)sizeof(dst)-1, "Hello!");

Copies a null-terminated string to dst, truncating if necessary to avoid overflow.

Just don't forget the "." or the "-1".

That code is just as easily converted to use snprintf, and then you don't need to worry about the . Or -1.

snprintf is C99 IIRC. Which means legacy C89 compilers (or worse!) don't have it.

Which brings it back again to my initial comment: "I don't understand why functions like gets and sprintf weren't removed from the standard and headers a long time ago."

And by a long time I mean before 1989 (certainly before 1999).

Why should I not be allowed to allocate a buffer that has like 10 or 20 extra characters of space and use a format string with %d in it? Why does sprintf have to be banned?

But banning gets is obvious because it is by definition facing external input

it should always be optional, just like the ms implementation, also this is part of a standard too...

Reply on news.ycombinator.com