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
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
"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.
>> ...
>> >
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
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
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
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
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
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
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
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
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
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
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
Simon Josefsson wrote:
> Looks fine to me. If you push it, I can make sys_socket depend on it.
Pushed.
Bruno
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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 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
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
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,
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
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_
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
36 matches
Mail list logo
