Why doesn't GNU add famous non-standard functions to glibc?

I recently found out that certain non-standard C functions, such as itoa() and strrev() are not available in gcc but are available on other compilers such as MSVC and Turbo C/C++. This made me wonder, why doesn't GNU add them? Granted they aren't in the standard, but it seems like it can't hurt. If the concern is people writing non-portable code, why wouldn't a warning suffice?
What about "non-standard" is so hard to understand?

A compiler's developers are not required to add functionality if it isn't mandated by the standard. Especially since there are language standard alternatives available.

https://stackoverflow.com/questions/190229/where-is-the-itoa-function-in-linux

Hint, hint....use sprintf snprintf to convert a number to a C string.

If we were talking about the C++ stdlib std::iota has been mandated since C++11. With C++, though, iota has entirely different functionality.

https://en.cppreference.com/w/cpp/algorithm/iota
Last edited on
It's not the idea of "non-standard" that is hard to understand. It's the idea of not including functions, that although they aren't obligated to include, would seem to only make people's lives easier (since code can be ported more easily from other compilers). I know they don't "have" to do it. I still ask why they don't. You say they aren't "required", but "required" is the wrong word here. If something cannot do harm and only do good, why not put it in?
The harm is perpetuating the existence of the non-standard functions.

If they exist, the lazy will continue to use them.

If it really annoys you, just make your own little library to include in your own projects.
Then no-one but you has to carry your baggage.

When was the last time you used strrev() for something that wasn't homework?
Check out the manual for glibc
https://www.gnu.org/software/libc/manual/html_node/index.html
It's already full of library extensions.
If all software that followed the same standard added all non-standard features from each other they would end up with a lot of extra stuff. It would add to the size and maintenance burden of the software.

Being compatible with your competitors means people using your competitors' software can more easily move to your software, but it also makes it easier for your users to move away. That means if you're new to the game you will probably benefit from staying compatible, but if you're already established with a large userbase you might not want to unconditionally copy everything from a competitor because it essentially means it's your competitor that dictates (why use anything non-standard from you when they can use something non-standard from your competitor knowing you will also support it?).
Last edited on
Hint, hint....use sprintf to convert a number to a C string.


Use snprintf()
https://en.cppreference.com/w/c/io/fprintf

MSVC doesn't have itoa() or strrev() either. It's versions are _itoa() and _strrev(). In general common but non-standard functions in MSVC begin with a _
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/itoa-itow?view=msvc-170
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strrev-wcsrev-mbsrev-mbsrev-l?view=msvc-170

Turbo C/C++


That's a blast from the past...
Last edited on
Personally I'd use C++ for any string manipulation long before I'd use C, but point taken about snprintf, corrected.

Oh, if someone is going to use C string functions why not use the C11 versions? fprintf_s, sprintf_s, snprintf_s

They were something MS non-standardly shoe-horned in before the functions were added to the C stdlib.

In general common but non-standard functions in MSVC begin with a _

That was a change from what I remember how MSVC did things in VC6. I used getch() from <conio.h> then. Fast-forward to VS2015 (and later) and now its _getch().
Last edited on
George P wrote:
Oh, if someone is going to use C string functions why not use the C11 versions? fprintf_s, sprintf_s, snprintf_s

Because those are essentially optional? GCC does not support them

cppreference wrote:
As with all bounds-checked functions, printf_s , fprintf_s, sprintf_s, and snprintf_s are only guaranteed to be available if __STDC_LIB_EXT1__ is defined by the implementation and if the user defines __STDC_WANT_LIB_EXT1__ to the integer constant 1 before including <stdio.h>.
https://en.cppreference.com/w/c/io/fprintf

Microsoft's implementation supports them but doesn't seem to define __STDC_LIB_EXT1__ for some reason.
Last edited on
Ah, the C standard has something in it that is optional, though I can't seem to find any definitive and explicit reference of the functions' optional status other than that long-winded note about the define.

I do know GCC and MSVC are two very different eco-systems for what is available, each has a plethora of non-standard functions the other doesn't have. So I guess the 'safe' functions are non-standard standard functions. ::annoyed grunt::
Last edited on
Microsoft's implementation supports them but doesn't seem to define __STDC_LIB_EXT1__ for some reason.


Probably because there is no requirement to. Having this defined guarantees that the _s versions are available (if __STDC_WANT_LIB_EXT1__ is also set to 1), but not having this defined doesn't mean they are not available. They may or may not...
Microsoft's implementation supports them but doesn't seem to define __STDC_LIB_EXT1__ for some reason.

Likely reason, though it's just a SWAG, as MSVC/C++ had those functions before the C standard committee added them to the C11 standard. Why add something they didn't need to get previously available functionality.
a few things that can't be replicated by existing tools like getch seem like long overdue additions to me. Can that even be done using only standard c++?

that said, compilers already support too many ancient, messy things like non-int main, union hack (I personally think they should have standardized this one instead of banning), and more. This stuff should go away to libraries, not proliferated, or lobby to add to the language. I do recall once having a double main executable that used its return value in the caller/spawner, long long ago. It worked, but many ugly things did back then.
Last edited on
Well, kind of a half-arsed approach to do something similar to getch, waiting for the enter key, has already been done multiple times and should be OS independent. One C++ version:

https://github.com/GeorgePimpleton/misc_files/tree/main/Program%20Pauser%20Toolkit

A C implementation might use getchar().

The "wait for any key-press" feature of getch is a bit more OS dependent.

I've read that using the ncurses library might be a less than exact idea for a getch replacement. PDCurses for Win.
George P wrote:
I've read that using the ncurses library might be a less than exact idea for a getch replacement.

It was a while since I used ncurses but if I remember correctly it had quite a few different functions that affected the behaviour of getch. Whether it should wait for input or return immediately, whether it should show the input as you type or not, whether you want to read characters or key codes, etc.

George P wrote:
PDCurses for Win.

ncurses and pdcurses seems very similar. I think the idea is that you should be able to write code that is compatible with both ncurses and pdcurses and have the code work "everywhere". I haven't tried it though.
Last edited on
a change from what I remember how MSVC did things in VC6


back in the day MS didn't exactly follow standards. There was VC and 'the others' - mainly Borland. MS were more interested in market share over Borland than making sure they were fully standard compliant. Providing 'extra' was one way. It wasn't until much later that MS moved towards being much-more standard compliance.

MS has MFC, Borland had OWL (now VCL). Even the 'standard' controls looked different between Borland and MS generated program. You could usually tell which one the programmer had used to produce the program...

Last edited on
visual provides it anyway, both getch(e) & kbhit (and probably newer ones in .net) type things.
but doing it 100% (I get partial answers) without assembly in standard c++ without libraries (which may be using asm to do it) ... is challenging. I still think that one should be adopted in.
Topic archived. No new replies allowed.