From: pete@puffin.uucp (Pete Carah)
Subject: Re: integer'image versus integer_io
Organization: Pete's Unix
Date: Wed, 15 Apr 1992 17:56:41 GMT

In article <1992Apr13.113149.20126@hellgate.utah.edu> Kevin Simonson writes:
>     If I want to output an integer to standard output, or to a file, I can
>do it either by instantiating the generic package "integer_io", or by using
>the "integer'image" attribute.  Therefore the following code gives me iden-
>tical results:

>     The only difference I get from my compiler is that with the "'image"
>version there's an extra space in front of the integer for a sign value.

>     My question is, if you want to output integers mixed with text, and if
>you don't mind about that first position for the sign, is there really any
>reason to use an "integer_io" instantiation over just using
>"integer'image"?
Well, with Meridian (and probably most other ada systems), if you use 'image
for ANY type too long you will run out of memory.  The return value of 'image
is a dynamic string, which is NEVER DEALLOCATED.  I'm not sure if
unchecked_deallocation would be safe on this string, since it may be part of
a larger data structure that was allocated.  That would be implementation-
dependent.  I *have* seen this attack us in a production program whose writer
thought 'image was a fine way of doing I/O, and it worked for ALL of his
test cases, then failed (in front of the customer) when the input data set
was a little longer than expected...  We had great fun fixing it, 'image
was buried all over the place.

>     It seems like the "'image" version would be more effective, too, since
>in the other version I'd have to use three I/O calls, versus the one I/O
>call for the concatentated string.
What do you mean by effective?  "efficient?"  Maybe not; the malloc calls
add up too.

For sufficiently small programs/output sets, or on a 32-bit virtual memory
system with no process-size limit, yes it will work, and MAY be more
efficient.  On any program whose output size depends on its input size, and
which will be used by those other than the authors, avoid it like the plague.

Lest you think this is unique, see the problems the C shell had when it was
first ported to non-virtual memory systems; it ran out of memory doing aliases
with fairly small numbers of them.  The fact that it was written on/for a vax
hid the memory leaks from the authors.  (or they may have deliberately ignored
them thinking the shell would never be used on a "small" machine).  Assumptions
like this tend to come back and bite you IN ANY LANGUAGE.  ADA actually hides
this stuff from the user better than C, and thus encourages memory waste.

>     If anybody knows any reason why concatenating "integer'image" might
>cause me any grief, please let me know.
See above.  BTW - text_io CAN also suffer from the same problem; a decent
implementation won't.

In my ("embedded") system (runs on a PC but acts embedded), we don't even
use text_io since it is rather a pig (and I thought C stdio was big...),
and I couldn't use the OS output calls anyhow since it messes up the
graphics.  I just wrote specific conversion routines for the number types
I needed.  Yes, I know, text_io does provide string conversion calls.  That
still brings in the whole 130+ K package.

-- Pete (pete@puffin.uucp)
Newsgroups: comp.lang.ada