Mail Archives: djgpp-workers/2001/06/13/12:42:56
> Thanks! I have a few minor comments, but other than that, it can go
> in.
Which reminds me: DJ can I have write access, so I can check this in
along with the a64l/l64a stuff?
> Please update the docs and the source, but I don't think we need to
> move the file to another directory. The structure of the directories
> in djlsr does not convey any information about standard compliance, it
> is simply a convenient way of organizing the source tree. We already
> have non-standard functions in standard directories, e.g. _rename in
> ansi/stdio.
Okelidokeli.
> OTOH, if setenv is now Posix, we need to move its prototype in
> stdlib.h to the Posix section.
Will do.
> > /* Let putenv() do the work */
> > name_with_assign = malloc (strlen (name) + 2);
>
> Perhaps alloca is better here, since environment variables tend to be
> relatively short.
Right.
> You could also avoid this altogether, since `putenv' will remove the
> variable if passed a name without a value. I think it is okay to rely
> on this feature of our implementation of `putenv', provided that you
> say so in a comment.
Oh ok - I only briefly glanced at putenv, so I didn't know it would accept
values without a '='.
In fact, I'll need to update putenv() as well (POSIX also mentions it); for
one thing, the prototype was changed to a non-const char* in Issue 5 of the
draft standard.
> > putenv (name_with_assign);
>
> You cannot use `putenv' in a Posix function without including
> <libc/stubs.h>.
Is this still true now that putenv() is Posix?
> > If @var{name} is @code{NULL}, points to an empty string, or points to
> > a string containing a @samp{=}, this function returns -1 and sets
> > @var{errno} to @code{EINVAL}; otherwise it returns 0.
>
> `errno' is not a formal argument, therefore it should have the @code
> markup, not @var.
Okidoki.
> Finally, please add something in wc204.txi about these changes.
Will do.
- Raw text -