Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> How about this?
>
> Nearly good. The shell variable GNULIB_VASPRINTF is also only assigned a
> default value. It should be assigned a value 1 if the module 'vasprintf'
> is present. This is best done in the module description thr
Simon Josefsson wrote:
> > Yes, I finally had the same idea. How about this? We don't care much about
> > efficiency at this point in the code.
>
> Seems fine to me, thanks! ...
>
> Stuffing this logic into a separate module might be cleaner though...
> there is some duplicated code now.
There i
Simon Josefsson wrote:
> How about this?
Nearly good. The shell variable GNULIB_VASPRINTF is also only assigned a
default value. It should be assigned a value 1 if the module 'vasprintf'
is present. This is best done in the module description through a
gl_STDIO_MODULE_INDICATOR invocation. See mod
Paul Eggert CS.UCLA.EDU> writes:
>
> Eric Blake byu.net> writes:
>
> > I would recommend getting rid of any test for st_spare1 or st_spare4
> > in m4/stat-time.m4.
>
> Thanks for mentioning this; I've always thought that using those
> "spare" fields was asking for trouble. I installed the f
Eric Blake <[EMAIL PROTECTED]> writes:
> I would recommend getting rid of any test for st_spare1 or st_spare4
> in m4/stat-time.m4.
Thanks for mentioning this; I've always thought that using those
"spare" fields was asking for trouble. I installed the following;
can you please check it?
> you
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Updated patch below.
>
> Looks better. Three points still:
> - In m4/stdio_h.m4 the default value of HAVE_VASPRINTF should be 1, as
> the comment "Assume proper GNU behavior unless another module says
> otherwise" says.
Simon Josefsson wrote:
> Updated patch below.
Looks better. Three points still:
- In m4/stdio_h.m4 the default value of HAVE_VASPRINTF should be 1, as
the comment "Assume proper GNU behavior unless another module says
otherwise" says.
- m4/vasprintf.m4 should set the shell variable HAV
James Youngman <[EMAIL PROTECTED]> wrote:
> 2007-03-27 James Youngman <[EMAIL PROTECTED]>
>
>* lib/stat-time.h (get_stat_birthtime): New function for
> retrieving st_birthtime as provided by UFS2 (hence *BSD).
>* m4/stat-time.m4 (gl_STAT_BIRTHTIME): Probe for st_birthtime
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Actually, nl_langinfo is documented to need not be thread-safe:
>>
>> http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html
>
> And the same page lists also ecvt(), fcvt(), gcvt() as not being thread-safe.
>
Bruno Haible clisp.org> writes:
>
> James Youngman wrote:
> > this version of the patch was not tested on NetBSD-3.1 with UFS2. Sigh.
>
> But now at least you get a ready-to-use package for testing by doing
>
> ./gnulib-tool --create-testdir --dir=/tmp/testdir --with-tests stat-time
On CVS
Bruno Haible <[EMAIL PROTECTED]> writes:
> Hi Simon,
>
>> m4/vasprintf.m4 contains:
>> ...
>> if test $ac_cv_func_vasprintf = yes; then
>> AC_DEFINE([REPLACE_VASPRINTF], 1,
>> [Define if vasprintf exists but is overridden by gnulib.])
>> fi
>> ...
>>
>> Which seems OK to me,
>
> No,
Clive D.W. Feather wrote:
Nick Stoughton said:
As to the original question ... can a system that implements ssize_t
with a SSIZE_MAX of 56k conform to POSIX?
No: SSIZE_MAX is the maximum value of ssize_t; since this is an integer
type, its maximum value must be one less than a power of 2.
Ma
James Youngman wrote:
> this version of the patch was not tested on NetBSD-3.1 with UFS2. Sigh.
But now at least you get a ready-to-use package for testing by doing
./gnulib-tool --create-testdir --dir=/tmp/testdir --with-tests stat-time
Transfer it to the host machine, "./configure CPPFLAGS=
Nick Stoughton wrote:
> As to the original question ... can a system that implements ssize_t
> with a SSIZE_MAX of 56k conform to POSIX? As far as I can see, I don't
> see why not. I agree that it is unnatural, but I can find nothing that
> prohibits it. Most (if not all) interfaces that return ssi
On Mon, 2007-03-26 at 10:57 +0200, Schwarz, Konrad wrote:
> > -Original Message-
> > From: Clive D.W. Feather [mailto:[EMAIL PROTECTED]
> > > While we're at it, I would be interested in the rational
> > for "inventing"
> > > ssize_t and not using ptrdiff_t instead, if anyone would care to
Simon Josefsson wrote:
> Actually, nl_langinfo is documented to need not be thread-safe:
>
> http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html
And the same page lists also ecvt(), fcvt(), gcvt() as not being thread-safe.
Argh.
> Btw, can we use the system's native sprint
Changed test_birthtime's return value to 'void', since the function falls
off without providing a return value, and since the return value is effectively
not used.
Changed NFILES from 5 to 4, to avoid using uninitialized values.
Removed the "1 || " in the test, that disabled the test_birthtime t
Hi Simon,
> m4/vasprintf.m4 contains:
> ...
> if test $ac_cv_func_vasprintf = yes; then
> AC_DEFINE([REPLACE_VASPRINTF], 1,
> [Define if vasprintf exists but is overridden by gnulib.])
> fi
> ...
>
> Which seems OK to me,
No, it is not the right thing. If defines REPLACE_VASPRINTF
James Youngman wrote:
> Needs testing on everything else, notably including:
> Cygwin CVS (i.e. version 1.7 or later)
> mingw
> Systems completely lacking nanosecond timestamps
Thanks for the patch. So it can be tested by everyone easily, I applied
the patch, with trivial modific
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Any objections to installing this patch?
>
> Yes. I think it's a shame to return a non-POSIX-compliant result if there
> are better possibilities. The appended patch is in my queue for a few days;
> I'm meaning to test it a littl
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> > And I don't see any m4/* code that would set the shell variable
>> > HAVE_VASPRINTF
>> > or HAVE_DECL_VASPRINTF to 0. It is only ever set to 1, which is not the
>> > intent.
>>
>> I removed the HAVE*_VASPRINTF code in m4/stdi
On Thu, Mar 22, 2007 at 09:21:37PM +0100, Bruno Haible wrote:
> fnmatch() has a worst-case complexity O(m*n) where m is the size of the
> pattern and n is the size of the sample string. Unfortunately glibc has
> chosen an implementation with exponential running time.
>
> $ mkdir foo
> $ cd foo
> $
Tested on:
Linux (ext3) (no st_birthtime support at all)
NetBSD-3.1 (UFS1) (st_birthtime support in kernel but not filesystem)
NetBSD-3.1 (UFS2) (st_birthtime support both kernel and filesystem)
NetBSD-3.1 (msdos) (st_birthtime support in kernel but not in
filesyste
23 matches
Mail list logo
