RE: [Dev-C++] itoa - atoi : another implementation

[Per W. <pw...@ia...>]

See below.

/Per W

On Thu, 3 Apr 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...]
> > Sent: Thursday, April 03, 2003 1:34 AM
> > To: Ioannis Vranos
> > Cc: 'Dev-C++'
> > Subject: RE: [Dev-C++] itoa - atoi : another implementation
> >
> > In a lot of embedded environments, itoa() is king, because of that. If
> > a microcontroller have 8kB program area, itoa() consumes 100 byte and
> > sprintf() consumes 2kB, the choice is quite easy.
>
>
> My itoa() was not intended for a microcontroler.
>
>
>
> > > The above is not thread safe (since as I saw you try to
> > embarrass me). :)
> > > You must place a locking mechanism.
> >
> > That's why most implementations of itoa takes a buffer as second
> > parameter.
>
>
> But you said:

I just tried to say that a itoa() with memory allocation is not of
much value. It consumes a lot of CPU-time in allocation/release, it
requires extra clean-up code, and a failure to clean will result in memory
leaks.

A itoa(int,char*[,int]) may even be used in a ISR with a deterministic
behaviour, i.e. the answer will always be available in a fixed maximum
time (with a fixed maximum stack use), and there is no way any running
task may have locked a mutex. Code using malloc()/free() are extremely
vulnerable for mutex locks. Good implementations of sprintf() is
mutex-free, but most of the time the supplier doesn't specify it in the
documentation, so you don't know.

>
> > > It isn't even a good optimization of number of source code
> > > characters, since each call MUST be either:
> > >     free(itoa(i1));
> > > which is an expensive NOP instruction, or:
>
>
> Decide if you consider the free store usage expensive or not. In any case
> there wan't any requirement for microcontrollers. In any case you try
> intentionally to embarrass me. :)

Never any intention of embarrassing anyone. To make you really happy, I
just noticed something really embarrasing. The ltoa() implementation for
the RTOS I'm using will fail for a radix < 10 because the guy implementing
it forgot that a smaller radix requires a bigger buffer. The code assumes
wort-case buffer use for radix 10...

I always consider dynamic heap usage as expensive. It's (almost) always ok
in bread-and-butter programs but in drivers, servers, embedded
environments and where the cude must support very long uptime with high
memory utilization (constantly being close to the limit of available
memory where heap fragmentation gets extra dangerous) great care is
needed.

A NIC driver that allocates all packets when they arrive might easily get
half transfer speed compared to a driver using a packet pool. This is a
bit of problem with object-oriented languages, since extra allocations are
so easily hidden somewhere in a base class constructor/destructor etc, and
if you don't know what speed you should expect from your code, you don't
notice the hidden slowdown.

>
>
> > www.uclibc.org (Small open clib for embedded systems)
> > char *itoa(int i);
> > note: uses static buffer
>
>
> That's nice, mine uses the free store, is thread safe and is intended for
> systems which can afford 8 kbs space cost.
>

It isn't uncommon that sprintf() uses a itoa(int,char*,int) (or ltoa) to
implement the %d support.

I just checked on a RTOS I'm using and noticed that their ltoa() would
fail for a radix < 10 because of too small

>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL: http://run.to/noicys
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>