Re: Make expr(1) 64-bit capable and radix-aware

2011-01-16 Thread Paul de Weerd
On Sat, Jan 15, 2011 at 03:35:43PM -0500, Ted Unangst wrote:
| On Sat, Jan 15, 2011 at 3:30 PM, Otto Moerbeek  wrote:
| >> >Additionally, i very much prefer to have as little as possible
| >> >differecnes between expr(1) and the ksh builtin.
| >>
| >> Ehum, running the risk of looking like a complete fool I've got to
| >> ask, is there actually a ksh builtin version of expr?
| >>
| >> I did actually double check that prior to digging into this, with
| >> "whence expr", and now after reading your comment I've skimmed the
| >> man page for ksh as well without finding any reference to a builtin
| >> expr. What am I missing?
| >
| > You are right, I was confused.
| 
| although making $(()) handle 64-bit may also be a nice addition.

64-bit archs already support 64-bit $(()).  32-bit archs do not.
Well, at least the common examples for these platforms:

[weerd@impreza] $ machine
amd64
[weerd@impreza] $ echo $((1024*1024*1024*5))
5368709120

[weerd@tuna] $ machine
i386
[weerd@tuna] $ echo $((1024*1024*1024*5))
1073741824

Paul 'WEiRD' de Weerd

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 



Re: Make expr(1) 64-bit capable and radix-aware

2011-01-15 Thread Matthias Kilian
On Sat, Jan 15, 2011 at 03:35:43PM -0500, Ted Unangst wrote:
> On Sat, Jan 15, 2011 at 3:30 PM, Otto Moerbeek  wrote:
> >> Ehum, running the risk of looking like a complete fool I've got to
> >> ask, is there actually a ksh builtin version of expr?
> >>
> >> I did actually double check that prior to digging into this, with
> >> "whence expr", and now after reading your comment I've skimmed the
> >> man page for ksh as well without finding any reference to a builtin
> >> expr. What am I missing?
> >
> > You are right, I was confused.

x=$(expr $a + $b)

should give the same result as

x=$((a + b))

So it's perfectly ok to demand expr(1) and ksh(1) compatibility.

> although making $(()) handle 64-bit may also be a nice addition.

I've an old diff (from december 2008) around, but IIRC i wasn't
happy with it, because it could break existing shell scripts
(MAILCHECK and TMOUT come into mind).

Ciao,
Kili



Re: Make expr(1) 64-bit capable and radix-aware

2011-01-15 Thread Ted Unangst
On Sat, Jan 15, 2011 at 3:30 PM, Otto Moerbeek  wrote:
>> >Additionally, i very much prefer to have as little as possible
>> >differecnes between expr(1) and the ksh builtin.
>>
>> Ehum, running the risk of looking like a complete fool I've got to
>> ask, is there actually a ksh builtin version of expr?
>>
>> I did actually double check that prior to digging into this, with
>> "whence expr", and now after reading your comment I've skimmed the
>> man page for ksh as well without finding any reference to a builtin
>> expr. What am I missing?
>
> You are right, I was confused.

although making $(()) handle 64-bit may also be a nice addition.



Re: Make expr(1) 64-bit capable and radix-aware

2011-01-15 Thread Otto Moerbeek
On Sat, Jan 15, 2011 at 01:00:04PM +0100, Benny Lofgren wrote:

> On 2011-01-15 07.43, Otto Moerbeek wrote:
> >On Fri, Jan 14, 2011 at 08:22:25PM -0700, Theo de Raadt wrote:
> >>>+ Makes it 64-bit capable on 64-bit architectures by changing relevant
> >>>int:s to long:s.
> >>I think this is a problem.
> >>I would expect a unix utility of this importance to work exactly the
> >>same on all our platforms.
> >
> >Additionally, i very much prefer to have as little as possible
> >differecnes between expr(1) and the ksh builtin.
> 
> Ehum, running the risk of looking like a complete fool I've got to
> ask, is there actually a ksh builtin version of expr?
> 
> I did actually double check that prior to digging into this, with
> "whence expr", and now after reading your comment I've skimmed the
> man page for ksh as well without finding any reference to a builtin
> expr. What am I missing?

You are right, I was confused.

-Otto

> 
> Thanks for the input!
> 
> 
> /Benny
> 
> -- 
> internetlabbet.se / work:   +46 8 551 124 80  / "Words must
> Benny L??fgren/  mobile: +46 70 718 11 90 /   be weighed,
> /   fax:+46 8 551 124 89/not counted."
>/email:  benny -at- internetlabbet.se



Re: Make expr(1) 64-bit capable and radix-aware

2011-01-15 Thread Benny Lofgren

On 2011-01-15 07.43, Otto Moerbeek wrote:

On Fri, Jan 14, 2011 at 08:22:25PM -0700, Theo de Raadt wrote:

+ Makes it 64-bit capable on 64-bit architectures by changing relevant
int:s to long:s.

I think this is a problem.
I would expect a unix utility of this importance to work exactly the
same on all our platforms.


Additionally, i very much prefer to have as little as possible
differecnes between expr(1) and the ksh builtin.


Ehum, running the risk of looking like a complete fool I've got to ask, 
is there actually a ksh builtin version of expr?


I did actually double check that prior to digging into this, with 
"whence expr", and now after reading your comment I've skimmed the man 
page for ksh as well without finding any reference to a builtin expr. 
What am I missing?


Thanks for the input!


/Benny

--
internetlabbet.se / work:   +46 8 551 124 80  / "Words must
Benny LC6fgren/  mobile: +46 70 718 11 90 /   be weighed,
/   fax:+46 8 551 124 89/not counted."
   /email:  benny -at- internetlabbet.se



Re: Make expr(1) 64-bit capable and radix-aware

2011-01-14 Thread Otto Moerbeek
On Fri, Jan 14, 2011 at 08:22:25PM -0700, Theo de Raadt wrote:

> > + Makes it 64-bit capable on 64-bit architectures by changing relevant
> > int:s to long:s.
> 
> I think this is a problem.
> 
> I would expect a unix utility of this importance to work exactly the
> same on all our platforms.

Additionally, i very much prefer to have as little as possible
differecnes between expr(1) and the ksh builtin.

-Otto



Re: Make expr(1) 64-bit capable and radix-aware

2011-01-14 Thread Benny Lofgren

On 2011-01-15 04.23, Ted Unangst wrote:

On Fri, Jan 14, 2011 at 10:11 PM, Benny Lofgren  wrote:

+ Makes it 64-bit capable on 64-bit architectures by changing relevant int:s
to long:s. I often use expr as a quick calculator for example when
partitioning disks and such, and frequently find myself up against the 32
bit signed integer limits.

I consider this a substantial regression actually.  There's no reason
for it to be machine dependent like this.  Fortunately, the fix should
be easy.  Use int64_t everywhere and then everybody wins.


Yes, I considered that variant also but figured that it was suboptimal 
to use 64-bit arithmetic on 32-bit platforms in such a frequently used 
utility. On the other hand, what are a few machine cycles here and 
there... :-)



The other changes seem useful, though others may care more about the
posixness of it all.  It'd be best to split this into the three
different parts and submit as separate patches so we can discuss them
individually.


I'll resubmit with the 64-bit stuff addressed.


Thanks,

/Benny


--
internetlabbet.se / work:   +46 8 551 124 80  / "Words must
Benny Lvfgren/  mobile: +46 70 718 11 90 /   be weighed,
/   fax:+46 8 551 124 89/not counted."
   /email:  benny -at- internetlabbet.se



Re: Make expr(1) 64-bit capable and radix-aware

2011-01-14 Thread Ted Unangst
On Fri, Jan 14, 2011 at 10:11 PM, Benny Lofgren  wrote:
> + Makes it 64-bit capable on 64-bit architectures by changing relevant int:s
> to long:s. I often use expr as a quick calculator for example when
> partitioning disks and such, and frequently find myself up against the 32
> bit signed integer limits.

I consider this a substantial regression actually.  There's no reason
for it to be machine dependent like this.  Fortunately, the fix should
be easy.  Use int64_t everywhere and then everybody wins.

The other changes seem useful, though others may care more about the
posixness of it all.  It'd be best to split this into the three
different parts and submit as separate patches so we can discuss them
individually.



Re: Make expr(1) 64-bit capable and radix-aware

2011-01-14 Thread Theo de Raadt
> + Makes it 64-bit capable on 64-bit architectures by changing relevant
> int:s to long:s.

I think this is a problem.

I would expect a unix utility of this importance to work exactly the
same on all our platforms.