kanze@gabi-soft.de wrote:
>
> The sprintf function is, of course, broken in the same way that gets is
> broken, and cannot be used in a correct program.

Could you justify this claim please? gets() is broken because there's no
way to tell how many characters will be read, so there's no way to
reliably prevent buffer overrun. I see nothing anlogous in sprintf();
the output data is known before the call so it's trivial to calculate a
hard upper limit on the string length.

Granted there are odd cases like %p where the output format is
implementation defined and the length can't be checked portably, but you
can simply avoid using those particular formats rather than throwing out
sprintf() in general. (And even the difficult cases can be made reliable
in practice, e.g. I think it can safely be guaranteed that %p will
always fit into, say, 100 characters on any implementation in the real
world.)

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
"C++ is to programming as sex is to reproduction. Better ways might
technically exist but they're not nearly as much fun." -- Nikolai Irgens

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

[cc'd to author for speed; please follow up in newsgroup.]

Philippe Blouin <philippe.blouin@sabre.com> wrote in comp.std.c++:
>    Just a simple inquiry, and I figured that comp.std.c++ would be the
>place to ask: why isn't itoa(int, char*) a part of the standard library???
>
>    I understand it's C and not C++,

"C and not C++" is a very very small set. Almost the entire C89
standard library became a part of C++. So to a first approximation,
the C++ standard library is a superset of the C standard library,
and therefore nearly everything that was in the C89 standard library
is on topic here, at least in a C++ context.

But itoa() is not part of the C standard library either. I can't
speak for either standards committee, but I suspect the C++
committee felt no need to add a pure-C function to the C++ standard
library that was not in the C library, and the C committee felt no
need to add it because you could always use sprintf().

Additionally, in C++ you have stringstreams in <sstream>, which are
better because you have no need to worry about allocating or
overflowing a char[ ].

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
                                  http://oakroadsystems.com
C++ FAQ Lite: http://www.parashift.com/c++-faq-lite/
the C++ standard: http://webstore.ansi.org/
reserved C++ identifiers: http://oakroadsystems.com/tech/cppredef.htm
more FAQs: http://oakroadsystems.com/tech/faqget.htm

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Philippe Blouin wrote:

>     Just a simple inquiry, and I figured that comp.std.c++ would be the
> place to ask:
> why isn't itoa(int, char*) a part of the standard library???

I fear I understand how this function is supposed to be used.

What about typing

  os << i;

where os is an output stream, probably a ostringstream (or
ostrstream if you love C strings) instead ?

This is cleaner, much more generic, tastes more like C++...
and of course is way safer.

--

Valentin Bonnard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

On Sun, 22 Oct 2000 07:49:58 CST, Philippe Blouin
<philippe.blouin@sabre.com> wrote in comp.std.c++:

> Hi!
>
>     Just a simple inquiry, and I figured that comp.std.c++ would be the
> place to ask:
> why isn't itoa(int, char*) a part of the standard library???
>
>     I understand it's C and not C++, but somewhere, somehow, it is
> related and I though you guys would be the best to explain me why I have
> to add it to each of my project while its counterpart (atoi()) is
> standard.
>
> Thanks,
>
> Blou
>
> PS I really hope I'm not too out of place...

atoi() is one of the original "hacker" functions that had to be
included in the original C standard because it was used in too many
existing applications to leave it out.  Note that the C standard
(specifically part of the C++ standard by reference) states that
atoi(), atol(), and atof() have undefined behavior if the text string
being processed represents a value outside the range of the variable
type.  They are almost as bad as gets(), in that they can invoke
undefined behavior if passed inappropriate data.  They are not quite
as bad because you can examine the contents of the string before
calling them, to make sure it will not overflow, but that greatly
reduces their usefulness.

In the days before the C had the strto...() functions, that do have
defined behavior for any input, people writing robust programs had to
either examine the text string first, before calling ato...(), or
write their own conversion functions since they had already done more
than half the work in validating the input.

For all practical purposes, the ato...() functions are useless in a
robust real world program.

As for the reverse, C has always provided the sprintf() function for
converting numeric values back into C strings.  C++ has this, and
string stream operations as well.

Jack Klein
--
Home: http://jackklein.home.att.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Jack Klein wrote:

> atoi() is one of the original "hacker" functions that had to be
> included in the original C standard because it was used in too many
> existing applications to leave it out.  Note that the C standard
> (specifically part of the C++ standard by reference) states that
> atoi(), atol(), and atof() have undefined behavior if the text string
> being processed represents a value outside the range of the variable
> type.  They are almost as bad as gets(), in that they can invoke
> undefined behavior if passed inappropriate data.

And almost as bad as istream, for the same reason (value outside range).

> For all practical purposes, the ato...() functions are useless in a
> robust real world program.

So is istream.

> As for the reverse, C has always provided the sprintf() function for
> converting numeric values back into C strings.

A safe function, for sure.

--

Valentin Bonnard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Well,

In 2 points:

1) I'm a C++ fan who has to work in a C+ (C++ programmed by C programmers)
environment.  And sometime, like that one, my file needs to be compiled also
in some C project.  And my compiler version does not support a lot of feature
(STL...).
2) That being said, my question was more theorical:  is there a technical
reason why itoa() does not exist.  I often read comments about the STL
(return values, arguments, performance) on why this and not that.  I'm just
looking for something like that.

The C library is very good at having functions that do not check their
arguments, so what problem would a itoa(int, char*) add?

Thanks,

Blou



Valentin Bonnard wrote:

> Philippe Blouin wrote:
>
> >     Just a simple inquiry, and I figured that comp.std.c++ would be the
> > place to ask:
> > why isn't itoa(int, char*) a part of the standard library???
>
> I fear I understand how this function is supposed to be used.
>
> What about typing
>
>   os << i;
>
> where os is an output stream, probably a ostringstream (or
> ostrstream if you love C strings) instead ?
>
> This is cleaner, much more generic, tastes more like C++...
> and of course is way safer.
>
> --
>
> Valentin Bonnard
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
> [ Note that the FAQ URL has changed!  Please update your bookmarks.     ]


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <39F5D588.ED53036A@sabre.com>, Philippe Blouin
<philippe.blouin@sabre.com> writes
>The C library is very good at having functions that do not check their
>arguments, so what problem would a itoa(int, char*) add?

But, IIRC, that is not the prototype of the versions of itoa() that are
provided as extensions. In addition the something to something else
functions conventionally take 'something' as a parameter and return
'something else' as a return value. This does not work sanely for itoa
and the user can easily write itoa(int, char *) by forwarding to
sprintf().



Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message
news:mNFMfqBmle95EwwF@ntlworld.com...

>This does not work sanely for itoa
> and the user can easily write itoa(int, char *) by forwarding to
> sprintf().

They can indeed.

The only merit I can see in itoa() is that if executable size really
mattered, itoa() will be smaller in size compared to all the baggage that
sprintf() brings in for its % processing.

Stephen Howe


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <39F5D588.ED53036A@sabre.com>,
Philippe Blouin  <philippe.blouin@sabre.com> wrote:
>The C library is very good at having functions that do not check their
>arguments, so what problem would a itoa(int, char*) add?

I think this is only true of functions that predated ANSI/ISO
standardization, and were retained for historical compatibility.  They
didn't add new ones, and that's what itoa() would have been.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <39F5D588.ED53036A@sabre.com>,
Philippe Blouin  <philippe.blouin@sabre.com> wrote:
>Valentin Bonnard wrote:
>> Philippe Blouin wrote:
>>
>> >     Just a simple inquiry, and I figured that comp.std.c++ would be the
>> > place to ask:
>> > why isn't itoa(int, char*) a part of the standard library???
>>
>> I fear I understand how this function is supposed to be used.
>>
>> What about typing
>>
>>   os << i;
>>
>> where os is an output stream, probably a ostringstream (or
>> ostrstream if you love C strings) instead ?
>>
>> This is cleaner, much more generic, tastes more like C++...
>> and of course is way safer.
>
>In 2 points:
>
>1) I'm a C++ fan who has to work in a C+ (C++ programmed by C programmers)
>environment.  And sometime, like that one, my file needs to be compiled also
>in some C project.  And my compiler version does not support a lot of feature
>(STL...).

I've never heard of a C++ compiler that didn't support some flavor
of iostreams.

>2) That being said, my question was more theorical:  is there a technical
>reason why itoa() does not exist.  I often read comments about the STL
>(return values, arguments, performance) on why this and not that.  I'm just
>looking for something like that.
>
>The C library is very good at having functions that do not check their
>arguments, so what problem would a itoa(int, char*) add?

Another way to look at this (in addition to the other comments
in this thread) is: Is there a (compelling) technical reason why
it must exist?  Granted, it is a common enough sought thing,
and so then perhaps it should be "given a name", but it seems
we have other equivalent idioms in which to spell the same request.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <39F0A7A1.F1123DD3@sabre.com>,
Philippe Blouin  <philippe.blouin@sabre.com> wrote:
>    Just a simple inquiry, and I figured that comp.std.c++ would be the
>place to ask:
>why isn't itoa(int, char*) a part of the standard library???

(1) Because it was no part of C.
(2) Many argue there is a better way to do it
(3) What about the return value, if any?

>    I understand it's C

It's not C.  At least, Standard C doesn't know anything about it
in particular (atoi() is part of Standard C, but itoa is not).

>and not C++, but somewhere, somehow, it is
>related and I though you guys would be the best to explain me why I have
>to add it to each of my project while its counterpart (atoi()) is
>standard.

Well, atoi() isn't too hot itself to be honest, although I guess
the need for the _idea_ of it is more needed than in the other direction.

Anyway, check out http://www.comeaucomputing.com/techtalk/#noitoa

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

brahms@mindspring.com (Stan Brown) writes:

|>  But itoa() is not part of the C standard library either. I can't
|>  speak for either standards committee, but I suspect the C++
|>  committee felt no need to add a pure-C function to the C++ standard
|>  library that was not in the C library, and the C committee felt no
|>  need to add it because you could always use sprintf().

The sprintf function is, of course, broken in the same way that gets is
broken, and cannot be used in a correct program.  However, the C
committee decided to fix it (with snprintf), rather than add additional
broken functions.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Valentin Bonnard <Valentin.Bonnard@free.fr> writes:

|>  Jack Klein wrote:

|>  > atoi() is one of the original "hacker" functions that had to be
|>  > included in the original C standard because it was used in too
|>  > many existing applications to leave it out.  Note that the C
|>  > standard (specifically part of the C++ standard by reference)
|>  > states that atoi(), atol(), and atof() have undefined behavior if
|>  > the text string being processed represents a value outside the
|>  > range of the variable type.  They are almost as bad as gets(), in
|>  > that they can invoke undefined behavior if passed inappropriate
|>  > data.

|>  And almost as bad as istream, for the same reason (value outside
|>  range).

Almost?

Seriously, there is an enormous difference with regards to gets.
Although the standards don't require it, it is not particularly
difficult for an implementation to do them right.  For gets, not only
does the standard allow undefined behavior, it makes it almost
impossible for a conscientious implementation to protect you.

|>  > For all practical purposes, the ato...() functions are useless in
|>  > a robust real world program.

|>  So is istream.

I wouldn't say that.  I use it with getline all the time.  And for
someone with a Pascal background like myself (including IO), I find the
get() and peek() functions invaluable.

Obviously, operator>> is worthless in all but special cases.  But so was
scanf, so the situation hasn't gotten any worse.

|>  > As for the reverse, C has always provided the sprintf() function fo=
r
|>  > converting numeric values back into C strings.=20

|>  A safe function, for sure.

Do I detect a touch of irony:-)?

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

kanze@gabi-soft.de wrote:
>
> brahms@mindspring.com (Stan Brown) writes:
>
> |>  But itoa() is not part of the C standard library either. I can't
> |>  speak for either standards committee, but I suspect the C++
> |>  committee felt no need to add a pure-C function to the C++ standard
> |>  library that was not in the C library, and the C committee felt no
> |>  need to add it because you could always use sprintf().
>
> The sprintf function is, of course, broken in the same way that gets is
> broken, and cannot be used in a correct program.  However, the C
> committee decided to fix it (with snprintf), rather than add additional
> broken functions.

It's only more convenient to avoid overflow with snprintf(); it was
quite possible to avoid it with sprintf(). You can, with only a few
exceptions, pre-calculate a reasonable upper limit to the output size.
In contrast, gets() is far more strongly broken, because there's nothing
you can do from within your program to avoid the overflow.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hi!

    Just a simple inquiry, and I figured that comp.std.c++ would be the
place to ask:
why isn't itoa(int, char*) a part of the standard library???

    I understand it's C and not C++, but somewhere, somehow, it is
related and I though you guys would be the best to explain me why I have
to add it to each of my project while its counterpart (atoi()) is
standard.

Thanks,

Blou

PS I really hope I'm not too out of place...


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]