CCS/TM4C1294NCPDT: Cannot use setenv()

In a hosted system like Windows or Linux, the operating system maintains, or holds, the environment variables.  In your case, when things worked, what part of the system maintains the environment variables?

Thanks and regards,

-George

Hello George,

I am not quite sure which part of memory the environment variables are stored in. I'm using setenv() from the GNU GCC stdlib. According to https://www.gnu.org/software/libc/manual/html_node/Environment-Access.html 

Function: int setenv (const char *name, const char *value, int replace)

Preliminary: | MT-Unsafe const:env | AS-Unsafe heap lock | AC-Unsafe corrupt lock mem | See POSIX Safety Concepts.

The setenv function can be used to add a new definition to the environment. The entry with the name name is replaced by the value ‘name=value’. Please note that this is also true if value is the empty string. To do this a new string is created and the strings name and value are copied. A null pointer for the value parameter is illegal. If the environment already contains an entry with key name the replace parameter controls the action. If replace is zero, nothing happens. Otherwise the old entry is replaced by the new one.

Please note that you cannot remove an entry completely using this function.

If the function is successful it returns 0. Otherwise the environment is unchanged and the return value is -1 and errno is set.

This function was originally part of the BSD library but is now part of the Unix standard.

I do not understand how setenv ever worked.  If it worked, that means there is some entity similar to an operating system which, among other things, keeps all the environment variables.  The setenv function is part of the interface to this entity.  To know why it worked, I need to know the details about that entity.

Thanks and regards,

-George

Best I could find was this... https://code.woboq.org/userspace/glibc/stdlib/setenv.c.html

That appears to be an implementation of setenv for Linux, or some other variant of Unix.  Is Linux running on your TM4C1294NCPDT system?

Thanks and regards,

-George

George Mock said:

Is Linux running on your TM4C1294NCPDT system?

George Mock said:

If it worked, that means there is some entity similar to an operating system which, among other things, keeps all the environment variables.  The setenv function is part of the interface to this entity.  To know why it worked, I need to know the details about that entity.

The newlib implementation of setenv() can be seen in the source code downloads on GNU Arm Embedded Toolchain Downloads in the setenv.c and setenv_r.c source files under src/newlib.tar.bz2/newlib/newlib/libc/stdlib. The newlib implementation uses malloc and realloc functions to manage storing environment variables in the heap.

I.e. if the heap is not configured correctly that might explain the setenv failure with GCC v9.2.1.

I haven't yet attempted to test setenv with the GCC ARM compiler.

I hate to admit this topic is beyond my expertise.  That will probably different some day.  But not right now.

TI obtains this ARM GCC compiler from this ARM Ltd web site.  I searched it for issues related to setenv, and found nothing.  You are welcome to visit it and post your question.

Did you look into the possibility that the malloc calls in the setenv implementation failed to allocate memory?

Thanks and regards,

-George