On Wed, Jun 4, 2014 at 7:07 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > On 2014-06-04 12:55, Chris Johns wrote: >> >> On 4/06/2014 4:28 pm, Sebastian Huber wrote: >>> >>> On 2014-05-29 07:10, Chris Johns wrote: >>>> >>>> Remove rtems_current_shell_env as this is dangerous because >>>> the env can be NULL if used outside of a valid shell with the >>>> POSIX key to an env set up. >>>> >>>> Clean up the usage of rtems_current_shell_env. >>> >>> >>> The cleanup looks good, but we should keep the rtems_global_shell_env. >>> I underestimated its widespread use, so it was an error that we removed >>> it. Now it is a constant, so you can use it only for the initialization >>> with default values. >>> >> >> I would rather this API cleaned up and only a single way for applications >> to do >> this. It is a simple and clean change. >> >> The change I have uses the environment of a caller if the caller has a >> specific >> environment in the key else the base it used, ie inherits the environment >> if >> present. > > > This is definitely better and we should add this > rtems_shell_dup_current_env(), but I would nonetheless keep the > rtems_global_shell_env for backward compatibility. > Is it feasible to provide a macro for rtems_global_shell_env that provides the compatibility?
We should definitely put it on the list to eliminate at least after 4.11 (*prod*) -Gedare > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > _______________________________________________ > rtems-devel mailing list > rtems-devel@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
