On Wednesday 08 June 2005 02:46 pm, Paul Eggert wrote: > Kuwanger <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
