Jerry Milner wrote:
> I'm using Codesourcery, and noticed that something called
>
> ...arm-none-eabi/lib/thumb2\libc.a(lib_a-impure.o)
>
> is using 0xF4 bytes of RAM.  I have no idea what this is, why it's using
> RAM, and haven't found anything with web searches either.  Does anyone
> know what this is, and if I can get rid of it, how?  I could put that
> memory to better use if I can free it.

It is part of libc.a (the Newlib C library). Newlib is open source, so
you could see for yourself. This is the content of impure.c (from which
impure.o is compiled).

```
#include <reent.h>

/* Note that there is a copy of this in sys/reent.h.  */
#ifndef _ATTRIBUTE_IMPURE_PTR_
#define _ATTRIBUTE_IMPURE_PTR_
#endif

#ifndef _ATTRIBUTE_IMPURE_DATA_
#define _ATTRIBUTE_IMPURE_DATA_
#endif

static struct reent __ATTRIBUTE_IMPURE_DATA_ impure_data = _REENT_INIT
(impure_data);
struct _reent *__ATTRIBUTE_IMPURE_PTR__ _impure_ptr = &impure_data;
```

As you can see it comprises a structure and a pointer to that structure.
The structure itself is large and defined in reent.h. I would suggest
that you mess with it at your peril, but if you do you will have to
rebuild the library in any case.

The question of how to remove reentrancy support from Newlib was asked
here:
http://www.codesourcery.com/archives/coldfire-gnu-discuss/msg00179.html,
the answer was that it could not be done (easily).

Clifford

Clifford Slocombe wrote:
>
> It is part of libc.a (the Newlib C library). Newlib is open source, so
> you could see for yourself. This is the content of impure.c (from which
> impure.o is compiled).

> -----------------------------
>
> As you can see it comprises a structure and a pointer to that structure.
> The structure itself is large and defined in reent.h. I would suggest
> that you mess with it at your peril, but if you do you will have to
> rebuild the library in any case.
>
> The question of how to remove reentrancy support from Newlib was asked
> here:
> http://www.codesourcery.com/archives/coldfire-gnu-discuss/msg00179.html,
> the answer was that it could not be done (easily).
>
> Clifford

I tried commenting out my one use of atoi() and I got back 0xF8 bytes
RAM!  I had intended on commenting out that, in addition to memcpy,
strcmp, memset, etc, but atoi was the first one I tried.

> I tried commenting out my one use of atoi() and I got back 0xF8 bytes
> RAM!  I had intended on commenting out that, in addition to memcpy,
> strcmp, memset, etc, but atoi was the first one I tried.

atoi() is not defined as setting errno, but neither is it guaranteed
that it does not. It is likely that it is defined in terms of strtol() -
as it is equivalent to (int)strtol(s, 0, 10) - because strtol()
explicitly sets errno, then so may atoi().

You will loose that 0xF8 bytes as soon as you use anything that uses
errno directly or indirectly.

Clifford