Pádraig Brady <p...@draigbrady.com> 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 <j...@meyering.net> 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.
