atoi is a standard function. But itoa is not. Why?

Question

Why this distinction? I've landed up with terrible problems, assuming itoa to be in stdlib.h and finally ending up with linking a custom version of itoa with a different prototype and thus producing some crazy errors.

So, why isn't itoa not a standard function? What's wrong with it? And why is the standard partial towards its twin brother atoi?

Sherrisherrie

atoi is historical, itoa isn't. You shouldn't really use atoi anyway, strto(u)l(l) is what you should use. For the other direction, s(n)printf. – Ikeda

As itoa isn't a standard function can you include what the interface contract for the itoa function that you want to discuss should be? (Doing this may answer your question.) – Masjid

@CharlesBailey I am just curious in general as to why the standard included atoi and not itoa – Sherrisherrie

@Stacker: Do you have a particular itoa in mind? – Masjid

@CharlesBailey Something like this – Sherrisherrie

@stacker- given that the function you linked has no mechanism to detect if it's writing past the end of the buffer, I doubt we'll ever see something like that in C. – Unblessed

itoa() is a posix function, not a standard C function. – Prefix

@Unblessed similar problems exist with a lot of other standard functions like strcpy but they are all in the standard bus! – Sherrisherrie

@HansPassant I dint find it in the POSIX spec here pubs.opengroup.org – Sherrisherrie

@Stacker- true, however they each have safe a variation in the standard as well. There are unsafe functions left over from the original C standard, but they've added save variations for all of them. No new functions are considered for addition to the spec if they have known vulnerabilities. – Unblessed

Answer 1

No itoa has ever been standardised so to add it to the standard you would need a compelling reason and a good interface to add it.

Most itoa interfaces that I have seen either use a static buffer which has re-entrancy and lifetime issues, allocate a dynamic buffer that the caller needs to free or require the user to supply a buffer which makes the interface no better than sprintf.

Masjid

itoa() with a passed in buffer can be a huge win over s(n)printf() when nothing else from that particular part of the library (nothing in the printf() family) is used. That's not a reason to put itoa() in the standard C library, but it is a reason to prefer it over something much heavier. – Mercantilism

@JulieinAustin: Why is it a huge win? True, you don't have to parse the two character format string but I wouldn't consider that a huge win. – Masjid

All of the other parsing functions that come along for the ride with the printf() family can also be avoided. Remember -- there are other things in this life besides parsing format strings. Like, memory footprint. – Mercantilism

@JulieinAustin: What exactly do you mean by "come along for the ride"? There's no reason that an implementation shouldn't link only the functions that are used for from the standard library. sprintf might be more heavyweight than is needed from an int-only formatter but I still wouldn't rate the difference as "a huge win". Perhaps I don't fully understand the situation that you have in mind. – Masjid

I imagine @JulieinAustin is coding for a tightly constrained target environment, such as device firmware. It isn't the usual FOSS use, but it's a vital application area for C. Sometimes in those environments you aren't allowed to link to ANY *printf functions. – Fernyak

@Fernyak guessed correctly - I do a lot of coding where 64K is still considered "huge". The last piece of C I wrote compiles to 15K and uses less than 2K of RAM. Which is a good thing since the part has 28K of I-space and 2K of D-space. – Mercantilism

Answer 2

An "itoa" function would have to return a string. Since strings aren't first-class objects, the caller would have to pass a buffer + length and the function would have to have some way to indicate whether it ran out of room or not. By the time you get that far, you've created something similar enough to sprintf that it's not worth duplicating the code/functionality. The "atoi" function exists because it's less complicated (and arguably safer) than a full "scanf" call. An "itoa" function wouldn't be different enough to be worth it.

Unblessed

Not really. Many developers included itoa()-like routines in code over the years. The maximum buffer size was well-bounded - 6 bytes and a spare for the NUL for 16-bit boxen, and 11 plus a spare for 32-bit boxen. I use an itoa() function in a piece of data acquisition firmware to format a text string containing version and status information. In that implementation I do pass in a pointer, but I've seen others the buffer is static. The best explanation is that just like standards, there are so many different itoa() implementations to choose from!!! – Mercantilism

@JulieinAustin - I'm not saying they don't exist, just that they're not standardized. Your description helps show why. The buffer size differs based on the register size of the machine. The C standards committee stays away from hardware-specific details like this. A standardized function would have to have a consistent interface and work the same on any platform, and the only practical way to do that is to reinvent most of printf(). – Unblessed

I was replying to your assertion that the function would =have= to do all sorts of things. It really doesn't, and the implementation could easily be specified using suitable numbers of weasel-words to get around differences in word size. I mean, for any given word size, there is a well-understood, finite number of characters of storage which are required to represent all possible integer values for that word size. TL;DR - it can be, and has been, implemented far easier and more consistently than you suggest. – Mercantilism

Answer 3

The itoa function isn't standard probably for the reason is that there is no consistent definition of it. Different compiler and library vendors have introduced subtly different versions of it, possibly as an invention to serve as a complement to atoi.

If some non-standard function is widely provided by vendors, the standard's job is to codify it: basically add a description of the existing function to the standard. This is possible if the function has more or less consistent argument conventions and behavior.

Because multiple flavors of itoa are already out there, such a function cannot be added into ISO C. Whatever behavior is described would be at odds with some implementations.

itoa has existed in forms such as:

void itoa(int n, char *s); /* Given in _The C Programming Language_, 1st ed. (K&R1) */

void itoa(int input, void (*subr)(char)); /* Ancient Unix library */

void itoa(int n, char *buf, int radix);
char *itoa(int in, char *buf, int radix);

Microsoft provides it in their Visual C Run Time Library under the altered name: _itoa.

Not only have C implementations historically provided it under differing definitions, C programs also provide a function named itoa function for themselves, which is another source for possible clashes.

Basically, the itoa identifier is "radioactive" with regard to standardization as an external name or macro. If such a function is standardized, it will have to be under a different name.

Carolanncarole