Re: PATCH: adds seq [octal]/hexidecimal integer output

[Kuwanger]

On Wednesday 08 June 2005 02:46 pm, Paul Eggert wrote:
> Kuwanger <address@hidden> writes:
> > seq offers -f to output floating point output.  Includes is a patch to
> > add [octal] and hexidecimal output.  Output is cast to int first.
>
> It should be cast to uintmax_t, no?

Though I'm not entirely sure what uintmax_t is (unsigned longest int-like type 
for the platform, I'd guess), the simple answer is no.  Output may range into 
the negative for some reason.  I was thinking about including outputing 
floating point octal and hexidecimal, but that seemed non-trivial.

> > I'd like to change this to output 64-bit numbers, not just 32-bit,
>
> Wouldn't you need to modify 'seq' to use long double uniformly?
> (This would make sense.)

Yea, that'd be the simplest answer.

> And you'd need a host where 'long double' can store at least 64 bits.
> That's not universal, alas.  So perhaps you'd need to use a long-integer
> package or something like that.

That's why I didn't right away try to go through a lot of effort, but there's 
also another reason...

> > though I'm not sure how--coreutils' printf only supports 32-bit
> > ordinal/hexidecimal
>
> No, in recent coreutils it supports 64-bit numbers.  E.g.,
>
> $ printf '%.30d\n' 9223372036854775807
> 000000000009223372036854775807

Are you sure that's not bash outputing the value?  I've checked bash (2.05b) 
and it supports signed 64-bit.   But coreutils 5.2.1's printf seems to be 
limited to signed 32-bit.  But perhaps that's a quirk of gentoo's heavy 
patching of coreutils.  Or is there a later version of coreutils available?

In any case, I'll modify seq to work with intmax_t and use long doubles and 
hope it gets accepted.