Mail Archives: djgpp/1997/08/07/14:19:46
Esa Peuha <Esa DOT Peuha AT helsinki DOT fi> writes:
>
> In article <33d7e79d DOT 10682519 AT news-win DOT inp DOT nsk DOT su>,
> bukinm AT inp DOT nsk DOT su wrote:
> > There is a bug in putenv (when allocating bigger chunk for
> > environ, one element is not counted).
> > This bug can explain magic number 21.
>
> [patch snipped]
>
> > The line with `putenv_bss_count = __bss_count;' was commented,
> > because later there is a test for `putenv_bss_count != __bss_count'.
> > (This can be left as it was, but it should be changed somehow).
>
> Are you sure that this change won't cause another latent bug?
Code in question:
if ((putenv_bss_count != __bss_count) || (prev_environ != environ))
{
putenv_bss_count = __bss_count;
...
if (putenv_bss_count != __bss_count)
{
prev_environ = environ;
putenv_bss_count = __bss_count;
}
}
If first assignment in the block is deleted, then initial environ
will be free'd. And this can cause troubles if environ was not malloc'ed.
If left as is, there is no need in second if, values are always equal.
The question is, what to delete, `if' or assignment?
(Or, maybe, leave it alone? :)
>
> > Emacs compiled with patched putenv does not crash,
> > but emacs compiled without it does.
>
> The call to malloc your patch corrects is very likely the cause of this
> bug. Apparently it doesn't hurt djgpp's normal malloc routine, but Emacs'
> malloc seems to be more sensitive. If this is true, distributed emacs.exe
> should crash with 6, 22, 54, 118,... environment variables (ie power of 2
> minus 10). I'll test this ASAP.
It may depend on the number of variables in djgpp.env.
Also, emacs adds SHELL=... (maybe only when SHELL is not defined).
- Raw text -