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 <<
> 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
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 de
Bruno Haible <[EMAIL PROTECTED]> writes:
> 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
>
> W
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 platfo
[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 str
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.
>
> Ther
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 arc
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 uint
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 9/1/2008 12:00 PM:
> Since the patch I posted does not change the semantics of base_name or
> dir_name, I propose to push it now, and those who want different names
> or changed semantics can build on top of that. Besides,
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 availabl
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.
As a first step, I'm splitting module 'filename' into 'filename' and
'concat-filename'.
Module 'filename' is later to be unified with parts of lib/dirname.h.
Module 'concat-filename' is meant as a simple mechanism for constructing
filenames.
Committed as follows:
2008-09-01 Bruno Haible <[EM
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
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. (J
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 'findprog
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 8/31/2008 9:39 AM:
> Right. close_stdout and more generally close_stream should be changed to
> handle an EPIPE failure. An EPIPE errno value means that the kernel is telling
> the program "This pipe/socket has no readers a
-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, mak
-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 "%.10
19 matches
Mail list logo
