Octal interpretation

Octal interpretation

[Peter William Stephenson]

I am heartily sick of being told my stack is unbalanced because the
time happens to be 12:08.  Based on the following two facts,

1) No valid octal number ever starts 08 or 09

2) 08 and 09 are the only two digit numbers evaluated incorrectly

I would like to propose that zstrtol explicitly checks for an 8 or a 9
following the 0 and if there is one evaluates it in decimal.  This
will mean times can be handled properly --- what I mainly use
arithmetic in zsh for anyway --- while real octal numbers won't be
affected.

Anybody writing scripts for users where this may matter should in any
case be stripping leading 0's as a matter of course.  If that's a big
problem, we should simply remove octal handling.  (What's wrong with
8#77 etc. anyway?  Isn't this just why ksh introduced that syntax?)

*** Src/utils.c.oct	Wed Nov  1 11:12:11 1995
--- Src/utils.c	Fri Nov  3 09:45:49 1995
***************
*** 1104,1112 ****
  	    base = 10;
  	else if (*++s == 'x' || *s == 'X')
  	    base = 16, s++;
  	else
  	    base = 8;
!  
      if (base <= 10)
  	for (; *s >= '0' && *s < ('0' + base); s++)
  	    ret = ret * base + *s - '0';
--- 1104,1114 ----
  	    base = 10;
  	else if (*++s == 'x' || *s == 'X')
  	    base = 16, s++;
+ 	else if (*s == '8' || *s == '9')
+ 	    base = 10;
  	else
  	    base = 8;
! 
      if (base <= 10)
  	for (; *s >= '0' && *s < ('0' + base); s++)
  	    ret = ret * base + *s - '0';
*** Doc/zshmisc.1.oct	Sun Oct 29 11:52:06 1995
--- Doc/zshmisc.1	Fri Nov  3 09:46:30 1995
***************
*** 732,739 ****
  .BR let .
  Evaluations are performed using
  .I long
! arithmetic. Constants with a leading 0 are interpreted as octal numbers.
! A leading \fI0x\fP or \fI0X\fP denotes hexadecimal.
  Otherwise, numbers are of the form
  [\fIbase\fB#\^\fR]\fIn\^\fP
  where
--- 732,741 ----
  .BR let .
  Evaluations are performed using
  .I long
! arithmetic. Constants with a leading 0 are interpreted as octal
! numbers, except in the special case that the 0 is immediately followed
! by an 8 or 9 (this allows processing of sections of time strings such
! as "12:08").  A leading \fI0x\fP or \fI0X\fP denotes hexadecimal.
  Otherwise, numbers are of the form
  [\fIbase\fB#\^\fR]\fIn\^\fP
  where

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77330
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: Octal interpretation

[Richard Coleman]

> I am heartily sick of being told my stack is unbalanced because the
> time happens to be 12:08.  Based on the following two facts,
> 
> 1) No valid octal number ever starts 08 or 09
> 
> 2) 08 and 09 are the only two digit numbers evaluated incorrectly
> 
> I would like to propose that zstrtol explicitly checks for an 8 or a 9
> following the 0 and if there is one evaluates it in decimal.  This
> will mean times can be handled properly --- what I mainly use
> arithmetic in zsh for anyway --- while real octal numbers won't be
> affected.
> 
> Anybody writing scripts for users where this may matter should in any
> case be stripping leading 0's as a matter of course.  If that's a big
> problem, we should simply remove octal handling.  (What's wrong with
> 8#77 etc. anyway?  Isn't this just why ksh introduced that syntax?)

I've been planning on getting back to this.  My first thoughts are to
just reverted back to decimail as the default.

rc

Re: Octal interpretation

[Zoltan Hidvegi]

> I've been planning on getting back to this.  My first thoughts are to
> just reverted back to decimail as the default.

I think 0xff hexadecimal notation can be kept but the octal notation should be
removed.  My releases do this.  It would not be difficult to implement it in
the baseline.  My patch only works together with the other bugfixes and
cleanups I made in math.c.  Richard, is there any reason you do not add my
fixes to the baseline?  I try to keep them uptodate.  I provide RCS file which
contains all of the patches separately.  I have tools which makes merging the
patches easier.  Several people complaind recently about bugs which I fixed
long ago.  I completely cleaned up the lexer and the substitution code.
Without the substitution fixes zsh cannot be installed as /bin/sh (e.g. the
common ${1+"$@"} sh idiom does not work with more than one arguments).  Some
developers also expressed interest in rewriting the lexer to achieve 8bit
compilance.  I think the baseline lexer is a wrong starting point.  The
modified lexer supports completion which makes get_comp_string() in
zle_tricky.c much simpler (that was the most horrible zle function in
zle_tricky).  I do not really care about the new features I added.  All of
them are very minor (but they are well tested by now, since many people used
my releases for more than a half year now).  I do not like this state.  Now a
significant amount of my time is spent on kepeng the patches up-to-date.  And
by now there are many patches from other people which did not find their way
to the baseline but are very essential.

Cheers,

  Zoltan

Re: Octal interpretation

[Richard Coleman]

> I think 0xff hexadecimal notation can be kept but the octal notation should be
> removed.  My releases do this.  It would not be difficult to implement it in
> the baseline.  My patch only works together with the other bugfixes and
> cleanups I made in math.c.  Richard, is there any reason you do not add my
> fixes to the baseline?  I try to keep them uptodate.  I provide RCS file which
> contains all of the patches separately.  I have tools which makes merging the
> patches easier.  Several people complaind recently about bugs which I fixed
> long ago.  I completely cleaned up the lexer and the substitution code.
> Without the substitution fixes zsh cannot be installed as /bin/sh (e.g. the
> common ${1+"$@"} sh idiom does not work with more than one arguments).  Some
> developers also expressed interest in rewriting the lexer to achieve 8bit
> compilance.  I think the baseline lexer is a wrong starting point.  The
> modified lexer supports completion which makes get_comp_string() in
> zle_tricky.c much simpler (that was the most horrible zle function in
> zle_tricky).  I do not really care about the new features I added.  All of
> them are very minor (but they are well tested by now, since many people used
> my releases for more than a half year now).  I do not like this state.  Now a
> significant amount of my time is spent on kepeng the patches up-to-date.  And
> by now there are many patches from other people which did not find their way
> to the baseline but are very essential.

It's just an artifact of the way I do things.  I have a one track
mind and tend to do things serially.  First I worked on configure
and the Makefiles.  This lead me to start working on the signals code
(for portability).  This lead me to start working on the hashtable.c.
>From there is was builtin.c (which I actually rewrote a substantial part
of) and then exec.c.  The work on exec.c has started me thinking about
subst.c, so I will probably begin integrating some of these patches.

I realize I'm slow at this, but I try to be very meticulous when I
integrate changes into the baseline.  I usually check over every patch
line by line.  I had to start doing this, because people were sending
in patches without understanding all the implications of the changes
they were making.  This is understandable since parts of zsh are very
complicated.  This way of doing things has slowed down progress somewhat,
but will ultimately produce a much better zsh.

Also, it is time consuming for me to go through the RCS files from your
distribution.  It would be a big help if you started e-mailing me some
of the pieces you think are the most essential.

rc