Hi Bruno,
* Bruno Haible wrote on Fri, Sep 05, 2008 at 01:09:19AM CEST:
>
> Mostly ok, but not exactly. The modification in line 2505 is not necessary;
> actually it would cause no-op sed invocations to happen. Also, I prefer a
> variable instead of a literal string - as a place where we can put
Bruno Haible wrote:
> Hi Ralf,
>
I count ca. 2 CPU
cycles for a memory access and ca. 8 CPU cycles for a conditional jump,
therefore I would say that the change slows down the program a bit.
>> For what little it's worth, this code cycle argument does not take into
>> account the op
Paul Eggert <[EMAIL PROTECTED]> writes:
> One other thing: if memory serves, the C standard does not require the
> existence of uint32_t and uint16_t (this is for portability to 36-bit
> hosts, I expect); this can easily be worked around by using #ifdef
> UINT32_MAX and #ifdef UINT16_MAX.
For wha
Jim Meyering <[EMAIL PROTECTED]> writes:
> 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, that patch is
> already larger than I would like.
>
That change looks good. Some minor points:
> +/* 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)
On all targets of interest f
Ralf Wildenhues wrote:
> 2008-09-04 Ralf Wildenhues <[EMAIL PROTECTED]>
>
> * gnulib-tool (func_emit_lib_Makefile_am)
> (func_emit_tests_Makefile_am, func_import, func_add_or_update)
> (func_create_testdir): Do not feed empty scripts to `sed -e',
> for AIX sed.
> Re
Albert Chin wrote:
> The patch below would work around this and disable #include_next on this
> platform.
>
> --
> albert chin ([EMAIL PROTECTED])
>
> -- snip snip
> diff --git a/m4/include_next.m4 b/m4/include_next.m4
> index 08c63db..f0f947b 100644
> --- a/m4/include_next.m4
> +++ b/m4/include
Hi Ralf,
> > > I count ca. 2 CPU
> > > cycles for a memory access and ca. 8 CPU cycles for a conditional jump,
> > > therefore I would say that the change slows down the program a bit.
>
> For what little it's worth, this code cycle argument does not take into
> account the optimization features
On Thu, Sep 04, 2008 at 08:40:42PM +0200, Ralf Wildenhues wrote:
> * Albert Chin wrote on Thu, Sep 04, 2008 at 07:33:36PM CEST:
> > $ ./gnulib-tool --test --with-tests fcntl
> [...]
> > sed: 0602-429 No editing script was provided.
> > Usage: sed [-n] Script [File ...]
> > sed [-n]
Hi Albert,
* Albert Chin wrote on Thu, Sep 04, 2008 at 07:33:36PM CEST:
> Should gnulib-tool work on AIX? On AIX 5.3 and 6.1:
Yes.
> $ ./gnulib-tool --test --with-tests fcntl
[...]
> sed: 0602-429 No editing script was provided.
> Usage: sed [-n] Script [File ...]
> sed [-n] [-e
On Thu, Sep 04, 2008 at 12:26:43PM -0500, Albert Chin wrote:
> [[ snip snip ]]
>
> Compiler bug? It seems like #include_next isn't working. Oddly, if I
> modify fcntl.h so it's just:
> #include_next
> then everything works. But, if I precede the #include_next with other
> #include directives, t
Should gnulib-tool work on AIX? On AIX 5.3 and 6.1:
$ ./gnulib-tool --test --with-tests fcntl
Module list with included dependencies:
fcntl
fcntl-tests
include_next
link-warning
unistd
unistd-tests
File list:
build-aux/link-warning.h
lib/dummy.c
lib/fcntl.i
lib/clean-temp.c has:
...
#include
#include
and lib/fcntl.in.h has:
#ifndef _GL_FCNTL_H
@PRAGMA_SYSTEM_HEADER@
#include
#include
#include
/* The include_next requires a split double-inclusion guard. */
[EMAIL PROTECTED]@ @NEXT_FCNTL_H@
On AIX 5.3:
$ cd /tmp/z
$ cat
On Thursday 04 September 2008 00:52:08 you wrote:
> We cannot take this patch, as the gnulib strverscmp function is meant to be
> a substitute for the glibc function of the same name. (Sorry, the doc was
> not clear about it until today.) This means, gnulib's strverscmp needs to
> behave the same a
Hello,
> Bruno Haible <[EMAIL PROTECTED]> wrote:
> > Jim Meyering wrote:
> >
> >>> Some of the changes (& => &&) are unconditional improvements, imho.
> >
> > I disagree. The & => && change inserts a conditional branch into the control
> > flow, with the potential to save a single memory access. I
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> Other opinions welcome.
>
> I mostly agree with Eric here: gnulib's substitute does not guarantee
> that values stored in a 'bool' are either 0 or 1, therefore the code that
> creates 'bool' values must guarantee it.
>
>> The question
16 matches
Mail list logo
