Simon Josefsson wrote:
> This script fails on some systems (e.g., autobuilders) that doesn't have
> a normal ~/.gitconfig:
>
> *** Your name cannot be determined from your system services (gecos).
>
> Run
>
> git config --global user.email "y...@example.com"
> git config --global user.name "You
Hi Bruno,
* Bruno Haible wrote on Sat, May 09, 2009 at 03:12:01AM CEST:
> Ralf Wildenhues wrote:
>
> > why can't your two configure.ac scripts share a
> > build-aux directory? The toplevel one could have
> > AC_CONFIG_AUX_DIR([lib/build-aux])
> >
> > while lib/configure.ac had
> > AC_CONFIG_
James Youngman wrote:
> > How many bytes is "the object" large?
>
> If s is NULL, there _is_ no object.
> ...
> NULL is not a pointer to an object.
This is not what I'm arguing about.
Does memchr(ptr,c,0) for ptr != NULL now access ptr[0] or not?
If yes, then when ptr is a pointer that points p
Simon Josefsson wrote:
> However, gnulib-tool --import puts build-aux files in the wrong
> directory for the lib/gl/m4 base. The reason is because the --auxdir
> variable is read from the top-level configure.ac AC_CONFIG_AUX_DIR.
>
> One work around is to run gnulib-tool --import two times
Yes,
On Fri, May 8, 2009 at 11:21 PM, Bruno Haible wrote:
> Andreas Schwab wrote:
>> They are free to access the object in any random order they like.
>
> The question is: How many bytes are the mem* functions free to access?
>
> How many bytes is "the object" large?
If s is NULL, there _is_ no object
Eric Blake wrote:
> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00419.html
>
> with some interesting ideas for speeding up iteration of an RB tree, either
> at
> the expense of two additional pointers (fastest speed, good cache usage, but
> large memory penalty), or with the addition of two bi
Eric Blake wrote:
> *** argp.11760Fri May 8 08:56:27 2009
> --- - Fri May 8 08:56:27 2009
> ***
> *** 1,4
> Usage: test-argp [-tvCSOlp?V] [-f FILE] [-o[ARG]] [--test] [--file=FILE]
> [--input=FILE] [--verbose] [--cantiga] [--sonet] [--option]
> !
Eric Blake writes:
> Bruno, I noticed this thread on the gcc lists:
>
> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00419.html
>
> with some interesting ideas for speeding up iteration of an RB tree, either
> at
> the expense of two additional pointers (fastest speed, good cache usage, but
>
Andreas Schwab wrote:
> They are free to access the object in any random order they like.
The question is: How many bytes are the mem* functions free to access?
How many bytes is "the object" large?
ISO C 99 7.21.5.1 says:
"The memchr function locates the first occurrence of c (converted to a
Simon Josefsson wrote:
> +#define _SS_PADSIZE (_SS_SIZE - (max (sizeof (sa_family_t), \
> + alignof (__ss_aligntype)) \
'max' is not a predefined macro. I'm applying this fix:
2009-05-08 Bruno Haible
* lib/sys_socket.in.h (_SS_PADSIZ
Bruno, I noticed this thread on the gcc lists:
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00419.html
with some interesting ideas for speeding up iteration of an RB tree, either at
the expense of two additional pointers (fastest speed, good cache usage, but
large memory penalty), or with the a
On Fri, May 8, 2009 at 12:07 PM, Bruno Haible wrote:
> James Youngman wrote:
>> This conflates two separate issues though:
>> 1. Which license the developer chooses to use and their strategy for
>> updating it
>> 2. The technical process by which the project manages files from
>> gnulib (e.g. che
The test for sockaddr_storage failed incorrectly under mingw because the
HAVE_WS2TCPIP_H wasn't set. The patch below moves back the test of
ws2tcpip.h before the sockaddr_storage test.
There is something like a catch-22 here: to test for sockaddr_storage,
we need to test for ws2tcpip.h, but to te
Simon Josefsson writes:
> Bruno, I pushed the following trivial fix because I got 'make dist'
> failures.
Sigh, I should have tested more -- there is an automatic EXTRA_DIST
added, and the error I got was caused by other problems. I reverted the
patch. Sorry about the noise.
/Simon
There are several problems with the argp module:
$ CFLAGS=-Wall ./gnulib-tool --with-tests --test argp
warning: module argp depends on a module with an incompatible license: dirname
warning: module argp depends on a module with an incompatible license: exit
warning: module argp depends on a module
Bruno, I pushed the following trivial fix because I got 'make dist'
failures.
/Simon
>From 0773c46ee42a43177fa958f2437a8c45e748cc06 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Fri, 8 May 2009 17:06:26 +0200
Subject: [PATCH] modules/alignof (Makefile.am): Dist alignof.h.
---
ChangeLog
Bruno Haible writes:
> Simon Josefsson wrote:
>> Looks fine to me. If you push it, I can make sys_socket depend on it.
>
> Pushed.
Thanks. I have pushed the patch below.
/Simon
>From 014f60069ce88c16683c533813b2463771ac2d0b Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Fri, 8 May 200
This script fails on some systems (e.g., autobuilders) that doesn't have
a normal ~/.gitconfig:
*** Your name cannot be determined from your system services (gecos).
Run
git config --global user.email "y...@example.com"
git config --global user.name "Your Name"
to set your account's default
To handle this gracefully, can the module exist but throw up a human-usable
error? That way there's something better than a module not found error.
On May 8, 2009 7:39 AM, "Simon Josefsson" wrote:
Bruno Haible writes: > James Youngman wrote: >> This
conflates two separate issue...
A fdl-1.3 mo
Bruno Haible writes:
> James Youngman wrote:
>> This conflates two separate issues though:
>> 1. Which license the developer chooses to use and their strategy for
>> updating it
>> 2. The technical process by which the project manages files from
>> gnulib (e.g. checking them into the repository
Bruno Haible writes:
> also when ptr is pointing to an I/O mapped address range
You certainly cannot use any of the mem functions for volatile memory
anyway. They are free to access the object in any random order they
like.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprin
Simon Josefsson wrote:
> Looks fine to me. If you push it, I can make sys_socket depend on it.
Pushed.
Bruno
Andreas Schwab wrote:
> > This would certainly be a departure from historical practice.
>
> Implementations are free to define undefined behaviour any way they
> like. The C standard imposes no restrictions on that behaviour.
The question is whether glibc wants to make programs crash, that have
James Youngman wrote:
> This conflates two separate issues though:
> 1. Which license the developer chooses to use and their strategy for updating
> it
> 2. The technical process by which the project manages files from
> gnulib (e.g. checking them into the repository for their own project
> versus
Bruno Haible writes:
> Simon Josefsson wrote:
>> +#define _SS_PADSIZE (_SS_SIZE - (max (sizeof (sa_family_t), \
>> + alignof (__ss_aligntype)) \
>> + + sizeof (__ss_aligntype)))
>
> Fine, except that 'alignof' is not
Jim Meyering writes:
> When the specified length is 0, memchr must not dereference the
> pointer.
The C standard does not support your opinion.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something com
Simon Josefsson wrote:
> +#define _SS_PADSIZE (_SS_SIZE - (max (sizeof (sa_family_t), \
> + alignof (__ss_aligntype)) \
> + + sizeof (__ss_aligntype)))
Fine, except that 'alignof' is not a predefined macro. We have
Bruno Haible writes:
> Andreas Schwab wrote:
>> This is not a bug. NULL is not a valid object pointer.
>
> Do you mean to say that none of the functions
> memchr
> memcmp
> memcpy
> memmove
> memset
> wmemchr
> wmemcmp
> wmemcpy
> wmemmove
> wmemset
> may be called with argum
Andreas Schwab wrote:
> Jim Meyering writes:
>> cat > k.c <<\EOF
>> #include
>> int main() { return !!(memchr (0, 'a', 0)); }
>> EOF
>> gcc -O k.c; ./a.out
>> Segmentation fault
>> [Exit 139 (SIGSEGV)]
>
> This is not a bug. NULL is not a valid object pointer.
It may not be a POSIX conformance
Andreas Schwab wrote:
> This is not a bug. NULL is not a valid object pointer.
Do you mean to say that none of the functions
memchr
memcmp
memcpy
memmove
memset
wmemchr
wmemcmp
wmemcpy
wmemmove
wmemset
may be called with arguments ptr = NULL and n = 0 ?
This would certainly b
Hello
I finished writing this patch. I added test(and fnmatchcomp.m4 which I forgot
in previous). I didnt change much, prettied and fixed bugs discovered by tests.
Now it should be stable. I hope this patch looks OK.
Moreover I made two independent changes
first is preallocating buffer in fnma
On Fri, May 8, 2009 at 12:02 AM, Bruno Haible wrote:
>
> I think gnulib supports all possible ways the maintainer prefers:
> - If the maintainer wants always the newest fdl.texi, he uses the
> 'fdl' module or takes the 'fdl' module.
> - If the maintainer wants always the newest version of a s
Jim Meyering writes:
> cat > k.c <<\EOF
> #include
> int main() { return !!(memchr (0, 'a', 0)); }
> EOF
> gcc -O k.c; ./a.out
> Segmentation fault
> [Exit 139 (SIGSEGV)]
This is not a bug. NULL is not a valid object pointer.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerp
"Tom G. Christensen" writes:
> On Thu, May 07, 2009 at 07:12:31PM +0200, Simon Josefsson wrote:
>> "Tom G. Christensen" writes:
>>
>> > I applied this patch and gave the result a whirl on the actual
>> > Solaris 2.6 system in question but it did not do what I expected it to
>> > do.
>> ...
>> >
Bruno Haible writes:
> Simon Josefsson wrote:
>> +#define _SS_PADSIZE (_SS_SIZE - (2 * sizeof (__ss_aligntype)))
>
> If the goal is that sizeof (struct sockaddr_storage) == _SS_SIZE, then the
> formula is incorrect. It should be
> (_SS_SIZE - (max (sizeof (sa_family_t), alignof (__ss_alignt
On Fri, May 08, 2009 at 01:44:57AM +0200, Bruno Haible wrote:
> Simon Josefsson wrote:
> > +#define _SS_PADSIZE (_SS_SIZE - (2 * sizeof (__ss_aligntype)))
>
> If the goal is that sizeof (struct sockaddr_storage) == _SS_SIZE, then the
> formula is incorrect. It should be
> (_SS_SIZE - (max (s
36 matches
Mail list logo
