Re: bitrotate

Paolo Bonzini [EMAIL PROTECTED] writes: +/* Given an unsigned 16-bit argument X, return the value corresponding + to rotating the bits N steps to the left. N must be between 1 to + 15 inclusive. */ +static inline uint16_t +rotl16 (uint16_t x, int n) +{ + return ((x n) | (x (16 -

Re: bitrotate

I suspect the rotation part is the sarl+sall and or. Either we could experiment with changing the code, or we could try to make gcc detect that this code actually is a rotate... Possibly gcc already does that right thing, with today's CPU architectures it can be difficult to know which ops

Re: bitrotate

Simon Josefsson wrote: --- a/modules/bitrotate +++ b/modules/bitrotate @@ -1,5 +1,5 @@ Description: -Rotate bits in 16 and 32 bit integers. +Rotate bits in 16 and 32 bit integers using stdint.h. Files: lib/bitrotate.h Well, that's not what I meant. I meant to add a format

Re: bitrotate

There was a suggestion to support 64-bit rotates as well. That would use uint64_t. Does stdint.m4 define some symbol that may be useful here? The code is rather complex so I'm trying to save time asking here first. I guess stdint.h cannot always define a uint64_t type, for example if the

Re: `nstrftime ()' prototype

[EMAIL PROTECTED] (Ludovic Courtès) wrote: Hi again, Jim Meyering [EMAIL PROTECTED] writes: +/* Just like strftime, but with two more arguments: + POSIX requires that strftime use the local timezone information. + When __UTC is nonzero and tm-tm_zone is NULL or the empty string, +

Re: findprog: don't exit = exit-free base_name, dir_name, etc

Paul Eggert [EMAIL PROTECTED] wrote: Eric Blake [EMAIL PROTECTED] writes: how about we go one step further, and have a deprecation period, where for a year or so, we provide mbase_name (returns NULL on failure) and xbase_name (calls xmalloc on failure) but no base_name. There's a better

Re: bitrotate

Paolo Bonzini [EMAIL PROTECTED] writes: I suspect the rotation part is the sarl+sall and or. Either we could experiment with changing the code, or we could try to make gcc detect that this code actually is a rotate... Possibly gcc already does that right thing, with today's CPU

Re: bitrotate

Simon Josefsson [EMAIL PROTECTED] writes: There was a suggestion to support 64-bit rotates as well. That would use uint64_t. Does stdint.m4 define some symbol that may be useful here? I believe that UINT64_C (for writing an unsigned 64-bit integer literal) is defined if and only if uint64_t

Re: bitrotate

Ben Pfaff wrote: There was a suggestion to support 64-bit rotates as well. That would use uint64_t. Does stdint.m4 define some symbol that may be useful here? I believe that UINT64_C (for writing an unsigned 64-bit integer literal) is defined if and only if uint64_t is available.

Re: findprog: don't exit = exit-free base_name, dir_name, etc

Jim Meyering wrote: I propose to push it now, and those who want different names or changed semantics can build on top of that. Besides, that patch is already larger than I would like. Please give me a few hours to do the changes on the 'filename' and 'findprog' modules in the way I prefer.

new module 'xconcat-filename'

This splits module 'concat-filename' into 'concat-filename' (LGPL) and 'xconcat-filename' (GPL). I don't have to worry here about the old function name taking on a different semantics, because the old function name was removed from module 'filename': Packages which are not updated and use current

new module 'findprog-lgpl'

This patch adds a module 'findprog-lgpl'. The GPLed and the LGPLed variant of find_in_path have the same specification; therefore they can share the same function name. In a gnulib build where both are requested, we need to ensure the LGPLed variant is compiled and the GPLed variant is omitted.

Re: findprog: don't exit = exit-free base_name, dir_name, etc

Jim Meyering wrote: I propose to push it now, and those who want different names or changed semantics can build on top of that. Besides, that patch is already larger than I would like. You can push it now, except for the changes to 'findprog'. In libvirt, you should be able to use

improve c-stack.m4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When looking at a report on a c-stack failure on Irix 5.3 [1], I noticed that we weren't checking for success after calling sigaction. Fixed as follows: [1] http://lists.gnu.org/archive/html/bug-m4/2008-09/msg0.html - -- Don't work too hard,

Re: diversion failure [was: snapshot in preparation for m4 1.4.12]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 8/19/2008 6:29 AM: According to Alain Guibert on 8/19/2008 4:40 AM: Sure. There is a segfault on the test for large precisions, on %.4000d. On libc5 this format works well until %.1020d, but segfaults for %.1021d and