Re: zsh-3.0.2 repacked

Re: zsh-3.0.2 repacked

[Wolfgang Hukriede]

Hi Zoltan!

> It also contains a little fix which is included below to work around a bug
> in the NeXTStep libc which causes slow refresh.  You only need to apply
> this patch if you find zle slow when it refreshes the screen (but first
> try to unset BAUD and see if that helps).

I'm sorry, but definitely there's no such alleged bug in the NeXTStep libc.
Setting BAUD to zero fixes the jumping movement of the cursor, nothing else,
the screen output is as fast/slow as without setting BAUD.

Then, after:

        setvbuf(shout, NULL, _IOFBF, 0);

shout->_bufsiz gives ZERO, as well as shout->_base still is ZERO, in other
words, shout is unbuffered. I cannot imagine this should be different with
other libc's. Have you actually checked this?

Also, to fix that all,

        setvbuf(shout, NULL, _IOFBF, BUFSIZ);

is totally sufficient, and has the advantage, that the buffer only is
allocated if shout is actually used. (Further: imo there's really no need for
conditional compilation here.).

Cheers, till then, Wolfgang.

Re: zsh-3.0.2 repacked

[Zoltan Hidvegi]

Wolfgang Hukriede wrote:
> I'm sorry, but definitely there's no such alleged bug in the NeXTStep libc.
[...]
> Then, after:
> 
>         setvbuf(shout, NULL, _IOFBF, 0);
> 
> shout->_bufsiz gives ZERO, as well as shout->_base still is ZERO, in other
> words, shout is unbuffered. I cannot imagine this should be different with
> other libc's. Have you actually checked this?

Yes of course.  On all other systems I know (and I tesed zsh on 8 different
Unix systems) setvbuf ignores the last argument of setvbuf if the second
argument is NULL.  And conditional compilation is probably has been put
there because there were some systems without setvbuf or _IOFBF.  And only
NeXTStep people complained about slow refresh so I'm pretty sure that
NeXTStep is the only system with this behaviour.

And I used static buffer instead of passing NULL to make sure that it will
really work.  I can imagine that some other system's buggy libc would
interpret non-zero last argument as if you had given it a buffer at address
NULL.

Zoltan

Re: zsh-3.0.2 repacked

[Richard Coleman]

> I'm sorry, but definitely there's no such alleged bug in the NeXTStep libc.
> Setting BAUD to zero fixes the jumping movement of the cursor, nothing else,
> the screen output is as fast/slow as without setting BAUD.
> 
> Then, after:
> 
>         setvbuf(shout, NULL, _IOFBF, 0);
> 
> shout->_bufsiz gives ZERO, as well as shout->_base still is ZERO, in other
> words, shout is unbuffered. I cannot imagine this should be different with
> other libc's. Have you actually checked this?
> 
> Also, to fix that all,
> 
>         setvbuf(shout, NULL, _IOFBF, BUFSIZ);
> 
> is totally sufficient, and has the advantage, that the buffer only is
> allocated if shout is actually used. (Further: imo there's really no need for
> conditional compilation here.).

This is definitely a bug.  If second argument is NULL, and the mode is
either _IOFBF (fully buffered) or _IOLBF (line buffered), then the libc
should ignore the fourth argument and allocate a buffer of the appropriate
length.  This is according to Steven's "Advanced Programming in the Unix
Environment".

rc

Re: zsh-3.0.2 repacked

[Wolfgang Hukriede]

Hi again,

> > other libc's. Have you actually checked this?

> Yes of course.  On all other systems I know (and I tesed zsh on 8 different
> Unix systems) setvbuf ignores the last argument of setvbuf if the second
> argument is NULL.  And conditional compilation is probably has been put
> there because there were some systems without setvbuf or _IOFBF.

Ok, well yes, sorry.

> And I used static buffer instead of passing NULL to make sure that it will
> really work. I can imagine that some other system's buggy libc would
> interpret non-zero last argument as if you had given it a buffer at address
> NULL.

Hm... that's *very* defensive.  :-)

Wolfgang.