glob [a-z]## bug in beta18

glob [a-z]## bug in beta18

[Roderick Schertler]

I've been on an old version of zsh (beta7) for a long time, I don't
know when this bug came up.  Here's what I'm seeing:

  j:1% ls
  bug.1  ok
  j:1% print -l 'setopt extended_glob' 'print -c [a-z]#' | zsh-2.6-beta7 -f
  ok
  j:1% print -l 'setopt extended_glob' 'print -c [a-z]#' | zsh-2.6-beta18 -f
  bug.1  ok
  j:1% _

I ended up with this while trying to track down another globbing
strangeness (I get no matches from

    autoload $_dir/[a-zA-Z_][a-zA-Z0-9_---.]#(-.:t)

), I don't know if it's somehow the same bug or not.

-- 
Roderick Schertler
roderick@gate.net

Re: glob [a-z]## bug in beta18

[Zoltan Hidvegi]

> I've been on an old version of zsh (beta7) for a long time, I don't
> know when this bug came up.  Here's what I'm seeing:
> 
>   j:1% ls
>   bug.1  ok
>   j:1% print -l 'setopt extended_glob' 'print -c [a-z]#' | zsh-2.6-beta7 -f
>   ok
>   j:1% print -l 'setopt extended_glob' 'print -c [a-z]#' | zsh-2.6-beta18 -f
>   bug.1  ok
>   j:1% _

I cannot reproduce this.  What OS and which C compiler do you use?

Zoltan

Re: glob [a-z]## bug in beta18

[Roderick Schertler]

On 22 May 1996 14:44:55 -0400, Zoltan Hidvegi <hzoli@cs.elte.hu> said:
> 
>> j:1% print -l 'setopt extended_glob' 'print -c [a-z]#' | zsh-2.6-beta18 -f
>> bug.1  ok
> 
> I cannot reproduce this.  What OS and which C compiler do you use?

I should have realized that this bug was too severe to be universal.
Sorry about that.  I saw that behavior on dgux 5.4.3.10 with gcc 2.5.8
(the standard system compiler).  When I recompiled with debugging rather
than optimization the problem disappeared, so by definition it must be a
bug in the compiler.

-- 
Roderick Schertler
roderick@gate.net

Re: glob [a-z]## bug in beta18

[ead]

Roderick,

Roderick Schertler <roderick@gate.net>:
] Zoltan Hidvegi <hzoli@cs.elte.hu>:
] >> j:1% print -l 'setopt extended_glob' 'print -c [a-z]#' | zsh-2.6-beta18 -f
] >> bug.1  ok
] > 
] > I cannot reproduce this.  What OS and which C compiler do you use?
] 
] I should have realized that this bug was too severe to be universal.
] Sorry about that.  I saw that behavior on dgux 5.4.3.10 with gcc 2.5.8
] (the standard system compiler).  When I recompiled with debugging rather
] than optimization the problem disappeared, so by definition it must be a
] bug in the compiler.

I cannot speak to the problem at hand, and have not looked at the zsh
code in question, but ceteris paribus, this line of reasoning is faulty.

When a "problem disappears", that does not mean that another one,
elsewhere, doesn't move to take it's place. Example: heap corruption due
to bad pointer management with optimization on, but valid memory getting
trashed with optimization off/debugging on.

Eric De Mund <ead@ixian.com>
http://www.ixian.com/ixian/ead/

"It's harder to solve people's problems than it is to design really neat
products." --Stewart Alsop