Re: _STRING_ARCH_unaligned

2011-09-13 Thread Paul Eggert
On 09/13/11 15:15, Loïc Le Loarer wrote: > I'm looking where _STRING_ARCH_unaligned define is defined in gnulib > and in which condition it is set to 0. gnulib never defines it to anything, so any test that looks like this: #if !_STRING_ARCH_unaligned is treated as if it were #if !0 unless th

tempname on MSVC

2011-09-13 Thread Bruno Haible
On MSVC, tempname.c gets a compilation error because it uses O_ACCMODE. This macro is defined in - but only if the module 'fcntl-h' is in use. 2011-09-13 Bruno Haible tempname: Support for MSVC. * doc/posix-headers/fcntl.texi: Document the problem with O_ACCMODE on MS

sys_time on MSVC

2011-09-13 Thread Bruno Haible
On MSVC 9, 'struct timeval' is defined only in , not in . The autoconf test finds that 'struct timeval' is undefined and therefore arranges for to define it. This leads to "duplicate definition of 'struct timeval'" errors in tempname.c, utimens.c, nanosleep.c and others. This fixes it: 2011-09-

_STRING_ARCH_unaligned

2011-09-13 Thread Loïc Le Loarer
Hi All, I'm looking where _STRING_ARCH_unaligned define is defined in gnulib and in which condition it is set to 0. I'd like to be able to test the sha1 code in a condition where it is set to 0. Thanks in advance, Best regards -- Loïc

Re: [PATCH] Improve sha*sum speed

2011-09-13 Thread Loïc Le Loarer
Hi Pádraig, 2011/9/13 Pádraig Brady : > On 09/12/2011 03:49 PM, Loďc Le Loarer wrote: >> Hi, >> >> Here is my latest results and patch. Please find the patches to >> sha1.c, sha256.c and sh512.c attached and the "time" of the resulting >> binaries in sha_benchs.log. For all binaries, in 64 and 32

Re: m4 brackets question

2011-09-13 Thread Eric Blake
On 09/13/2011 03:09 PM, Bruno Haible wrote: Please, can you turn off these "m4 comments" for Autoconf 3.0? You can turn them off yourself with m4_changecom(). This hasn't been a regularly requested feature, but I'm worried about the backwards-compatibility aspect of doing it globally. No

Re: m4 brackets question

2011-09-13 Thread Bruno Haible
Hi Eric, > # is a comment character in m4, which reads until > end-of-line to end the comment. Which means all the [] after the > comment character are treated as part of the comment, instead of as m4 > [] quoting. Thanks for explaining. Now I understand it. What is called an "m4 comment" is

Re: m4 brackets question

2011-09-13 Thread Eric Blake
On 09/10/2011 03:23 AM, Bruno Haible wrote: Hi Eric, Again, I've stumbled across a behaviour of brackets in autoconf macros that I don't understand. If in file m4/include_next.m4 at line 210 I add the following code --

Re: pathmax: support for native Windows

2011-09-13 Thread Bastien ROUCARIES
On Tue, Sep 13, 2011 at 5:33 PM, Bruno Haible wrote: > Bastien ROUCARIES wrote: >> You could use this syntax with win32 api. I used it for opening long >> path and it used byapache on windows. However it will need some >> surgery in order to be used (convert utf8 to ucs2) > > Yes, and this surgery

Re: pathmax: support for native Windows

2011-09-13 Thread Bruno Haible
Bastien ROUCARIES wrote: > You could use this syntax with win32 api. I used it for opening long > path and it used byapache on windows. However it will need some > surgery in order to be used (convert utf8 to ucs2) Yes, and this surgery would be overkill for gnulib. 99.9% of all users and applicat

Re: pathmax: support for native Windows

2011-09-13 Thread Eric Blake
On 09/13/2011 07:07 AM, Bastien ROUCARIES wrote: On Tue, Sep 13, 2011 at 2:50 PM, Eric Blake wrote: On 09/13/2011 06:47 AM, Bastien ROUCARIES wrote: PATH_MAX is this value for win32 name not for kernel name like \\?\c\. It is 32k in this case. When using kernel APIs (like cygwin does), then

Re: pathmax: support for native Windows

2011-09-13 Thread Bastien ROUCARIES
On Tue, Sep 13, 2011 at 2:50 PM, Eric Blake wrote: > On 09/13/2011 06:47 AM, Bastien ROUCARIES wrote: >> >> PATH_MAX is this value for win32 name not for kernel name like \\?\c\. >> It is 32k in this case. > > When using kernel APIs (like cygwin does), then yes, the limit is 32k. But > when using

Re: pathmax: support for native Windows

2011-09-13 Thread Eric Blake
On 09/13/2011 06:47 AM, Bastien ROUCARIES wrote: PATH_MAX is this value for win32 name not for kernel name like \\?\c\. It is 32k in this case. When using kernel APIs (like cygwin does), then yes, the limit is 32k. But when using Windows APIs (like mingw and MSVC do), then you are better off

Re: pathmax: support for native Windows

2011-09-13 Thread Bastien ROUCARIES
PATH_MAX is this value for win32 name not for kernel name like \\?\c\. It is 32k in this case. Bastien On Tue, Sep 13, 2011 at 1:08 PM, Bruno Haible wrote: > Another PATH_MAX related compilation failure on MSVC occurs in lib/stat.c: > > stat.c(76) : fatal error C1189: #error :  "Please port this

Re: [PATCH] Improve sha*sum speed

2011-09-13 Thread Pádraig Brady
On 09/12/2011 03:49 PM, Loïc Le Loarer wrote: > Hi, > > Here is my latest results and patch. Please find the patches to > sha1.c, sha256.c and sh512.c attached and the "time" of the resulting > binaries in sha_benchs.log. For all binaries, in 64 and 32 bits modes > (.m32), I run 3 times the comman

Re: pathmax: support for native Windows

2011-09-13 Thread Bruno Haible
Another PATH_MAX related compilation failure on MSVC occurs in lib/stat.c: stat.c(76) : fatal error C1189: #error : "Please port this replacement to your platform" make[4]: *** [stat.obj] Error 2 This fixes it. 2011-09-13 Bruno Haible stat: Support for MSVC. * lib/stat.c:

pathmax: support for native Windows

2011-09-13 Thread Bruno Haible
lib/tmpfile.c and lib/tmpdir.c give compilation errors on MSVC 9, because PATH_MAX is not defined. Also, mingw defines PATH_MAX in , but to a wrong value (259 instead of 260). Same mistake as on HP-UX. This fixes it: 2011-09-13 Bruno Haible pathmax: Support for native Windows.