[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Pádraig Brady
Subject: bug#16578: Wish: Support for non-native endianness in od
Date: Sun, 09 Feb 2014 11:34:43 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 02/09/2014 08:42 AM, Niels Möller wrote:
> 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.

Oops, I removed an 'f' while developing. Added that back now
which also gets sizes up to 16 tested.

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

Ugh good point.

> 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 

I went with:

rev() {
  while read line; do
    printf '%s' "$line" | sed 's/./&\n/g' | tac | paste -s -d ''

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

I think so too. It's not Linux specific and we've previously
mentioned rev in alternative for adding various functionality to coreutils.

Thanks to both of you for the review!

I've now pushed:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]