On 10/02/2014 01:12 PM, J.F. Sebastian wrote: > On Thu, Oct 2, 2014 at 4:24 AM, Pádraig Brady <[email protected]> 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.
