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

[J.F. Sebastian]

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?

> 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?

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.

J.F.