Re: od: add explicit support for shell integers (intmax_t)

[Pádraig Brady]

On 10/02/2014 01:12 PM, J.F. Sebastian wrote:
> On Thu, Oct 2, 2014 at 4:24 AM, Pádraig Brady <address@hidden> wrote:
>> On 10/01/2014 10:30 PM, John Isidore wrote:
>>> od supports 'long int' using L size e.g., '-t uL'. I suggest
>>> adding M size where M stands for sizeof(intmax_t): '-t uM'.
>>>
>>> Something like:
>>>
>>>
>>> diff --git i/src/od.c w/src/od.c
>>> index 18b1683..2dd1740 100644
>>> --- i/src/od.c
>>> +++ w/src/od.c
>>> @@ -671,6 +671,11 @@ decode_one_format (const char *s_orig, const char
>>> *s, const char **next,
>>>             size = sizeof (long int);
>>>             break;
>>>
>>> +        case 'M':
>>> +          ++s;
>>> +          size = sizeof (intmax_t);
>>> +          break;
>>> +
>>>           default:
>>>             if (! simple_strtoul (s, &p, &size))
>>>               {
>>>
>>>
>>> As far as I can see, it should be enough (excluding tests, docs).
>>
>> This seems like a good idea.
>>
>> Note intmax_t maps to long long within od now.
>> Practically they're the same, but theoretically they may diverge.
>> So a full patch would best have handling of intmax_t separate.
> 
> GCC doesn't support any extended integer types i.e.,
> there is no reason that sizeof(maxint_t) is not MAX_INTEGRAL_TYPE_SIZE.
> A check could be added to assert it:
> 
>   verify (sizeof (intmax_t) == MAX_INTEGRAL_TYPE_SIZE);
> 
> If it holds then no changes other than I've already suggested are needed.
> If it fails then substantive changes to src/od.c are required -- the
> assumption that 'long long' is the widest type is spread throughout
> the code perhaps due to the posix requirement to support types only
> upto 'long long' or 8 (whatever wider). Are there environments where
> od works but the verify test fails?

None currently as far as I know,
though 128 bit ints are already supported by lower layers,
so intmax_t could increase to 128 bits at some stage.
If we're going to expose intmax_t in the interface through 'M'
it seems prudent to have a separate print_intmax implementation.

>> Also it would be worth supporting a size of 'LL' corresponding
>> to long long (falling back to long where unavailable).
>> I see z/os for example, supports an 'LL' specification.
> 
> od uses C, S, I, L (M) while C uses hh, h, <empty>, l (j) length
> modifiers correspondingly. Therefore od's LL would be inline with C's
> ll modifier.
> On the other hand '-t uLL' might be confused with '-t uLuL' easily. Is
> it a concern?

'L' is not supported on its own so there is no compat issue.
Also I don't see a confusion issue either.

> If 'LL' is introduced and if 'long long' is unavailable then an error
> "invalid type string LL;\nthis system doesn't provide long long
> integral type" could be used instead of falling back to long.

I'm not sure about that. Falling back to 'long' would
cater for old compilers where long long ≍ long,
though that's an edge case I agree.
It seems better to hide these details within od and
just fall back to 'long' for these edge cases.

thanks,
Pádraig.