bug#16578: Wish: Support for non-native endianness in od

[Niels Möller]

Pádraig Brady <address@hidden> writes:

> Attached in the patch I intend to push in your name.

Nice.

> I also added docs to usage() and the texinfo file, and added a test.

I don't quite understand how the test works, but as far as I see, it
doesn't test floats? So that's inconsistent with the commit message.

> BTW I checked if there was any speed difference with the new code.
> I wasn't expecting this to be a bottleneck, and true enough
> there is only a marginal change. The new code is consistently
> a little _faster_ though on my i3-2310M which is a bit surprising.

Odd. But performance of x86 is usually pretty hard to predict by just
looking at the source or assembly code. I was hoping that in the
non-swapped case, the false conditional

   if (input_swap && sizeof(T) > 1)

should be very friendly to the branch predictor, and hence almost free.

Jim Meyering <address@hidden> writes:

> One nit: please change the type of "j" here (identical in attached)
> to be unsigned, to match that of the upper bound.

Makes sense. In my own projects, I tend to use unsigned int for loop
counts whereever I don't need to iterate over any negative values. But
my impression is that most others prefer to use signed int for
everything which doesn't rely on mod 2^n arithmetic, so that's why I
made j signed here.

> That would be our first use of "rev". Is it ubiquitous enough to depend on?

It appears *not* to be available on my closest solaris box. While on my
gnu/linux system, it's provided by util-linux. For the test, I guess rev
could be implemented something like

while read line
  printf "%s" line | tr -d '\n' | sed 's/./.\n/' | tac | tr -d '\n'
  echo
done 

Maybe rev should be provided by coreutils, similarly to tac? I'd prefer
not to think about the unicode issues for rev, though...

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.