Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Bruno Haible on 1/10/2008 7:24 PM:
> | Thanks for these. So the problem is that if __STRICT_ANSI__ is set,
> | __attribute__(...) gets defined to empty. In some tests with GCC versions
> | starting from 2.95.3, I found that __attribute__ works al
Bruno Haible <[EMAIL PROTECTED]> writes:
> This warning occurs, for example, when I create a tarball on
> one computer and then transfer it to another computer and build it there.
> If the time difference is "12 seconds" I know I can retry in 15 seconds.
You like to live dangerously. :-)
Person
Bruno Haible <[EMAIL PROTECTED]> writes:
> Then the two "git stash" commands were unnecessary; all that's needed is
>
> $ git pull
> # fix conflicts then "git commit" of the merged files
I vaguely recall that when I've done that in the past, I installed
unnecessary gunk into the sav
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 1/10/2008 8:33 PM:
| should I go ahead and prepare a patch for strcasestr, c-strcasestr, and
| memcasecmp to utilize str-two-way.h?
How's this for strcasestr? Glibc's strcasestr is quadratic (no surprise
there, given our t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 1/10/2008 7:53 PM:
| Eric Blake wrote:
|> +# Prerequisites of lib/memmem.c.
|> +AC_DEFUN([gl_PREREQ_MEMMEM], [:])
|> +])
|
| These lines are not needed in m4/strstr.m4.
Oops; copy-n-pasto. Obvious fix coming up soon.
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 1/10/2008 8:04 PM:
|
| I dislike strcasestr because it _appears_ to be locale dependent if you test
| it with some old locales - but it does not work with the majority of locales
| in use today. The only reason to support
Eric Blake wrote:
> I'm committing this series to add a strstr module similar to memmem
> ...
> I'm also thinking that we do not need the c_strstr module - aside from its
> comments on when it is safe to use a bytewise search even in a multibyte
> locale, it behaves no differently than the POSIX
Eric Blake wrote:
> +# Prerequisites of lib/memmem.c.
> +AC_DEFUN([gl_PREREQ_MEMMEM], [:])
> +])
These lines are not needed in m4/strstr.m4.
Bruno
Eric Blake wrote:
> is there any reason to have the c_strstr
> module? Its implementation looks like it is identical to the POSIX
> requirements for strstr (POSIX states that strstr always operates on byte
> sequences, whether or not they form valid character strings for the
> current locale). Yo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 1/10/2008 7:24 PM:
| Thanks for these. So the problem is that if __STRICT_ANSI__ is set,
| __attribute__(...) gets defined to empty. In some tests with GCC versions
| starting from 2.95.3, I found that __attribute__ works
Sylvain Beucler wrote:
> Here's the version:
> $ gcc --version
> gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
>
> Here's how the test is compiled:
> freedink/native/src$ LANG=C make test.o
> gcc ... -std=c99 ...
Thanks for these. So the problem is that if __STRICT_ANSI__ is set,
__attri
Sylvain Beucler <[EMAIL PROTECTED]> writes:
> Here's a test program:
> #include
> #include
> int main(void)
> {
> printf("sizeof(Sint8) = %d\n", sizeof(Sint8));
> printf("sizeof(int8_t) = %d\n", sizeof(int8_t));
> printf("sizeof(unsigned char) = %d\n", sizeof(unsigned char));
Paul Eggert wrote:
> For this particular example, I don't think the "human_time" interface
> will help all that much. Once the time is in the future, it doesn't
> matter much whether it's milliseconds or years, "make" is broken.
I disagree. This warning occurs, for example, when I create a tarbal
Simon Josefsson <[EMAIL PROTECTED]> writes:
> This thread reminds me of this poor warning message from make:
>
> make: Warning: File `Makefile.am' has modification time 7.9e+02 s in the
> future
>
> There are humans that don't instinctual feel whether '7.9e+02 s' is a
> time difference in millise
On Fri, Jan 11, 2008 at 12:56:04AM +0100, Bruno Haible wrote:
> Sylvain Beucler wrote:
> > Afaics Gnulib's string.h will define __attribute__ to be empty:
> >
> > #ifndef __attribute__
> > /* This feature is available in gcc versions 2.5 and later. */
> > # if __GNUC__ < 2 || (__GNUC__ == 2
Sylvain Beucler wrote:
> Afaics Gnulib's string.h will define __attribute__ to be empty:
>
> #ifndef __attribute__
> /* This feature is available in gcc versions 2.5 and later. */
> # if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) ||
> __STRICT_ANSI__
> # define __attribute__(
Eric Blake wrote:
> The first sentence is no longer true - since you provide a way to
> determine if memory was allocated, there is no leak. Rather, I would
> s/leaks memory/potentially allocates memory/.
Yes, you are right. I apply your comment fix. Thanks.
Bruno
Hi Simon,
> right now I'm
> mostly looking for comments on the general approach and on the function
> prototype:
>
> char *
> human_readable_time (time_t age, unsigned int units)
I would also add an 'unsigned int nanoseconds' argument. So that the module
can also be used for applications in the
James Youngman wrote:
> Don't forget that the code you are commenting about is not itself part
> of the module. ...
> This is a proposed gnulib module, it should be no
> surprise that it is not a substitute for adequate package
> documentation.
But if the main usecase of the proposed module has su
Hi,
I got a weird compilation warning when upgrading gnulib today.
Here's a test program:
#include
#include
int main(void)
{
printf("sizeof(Sint8) = %d\n", sizeof(Sint8));
printf("sizeof(int8_t) = %d\n", sizeof(int8_t));
printf("sizeof(unsigned char) = %d\n", sizeof(unsigned
Below is code as a starting point, the self-tests produces:
7 weeks 5 days 12 hours 44 minutes 31 seconds
7 weeks 5 days 12 hours 44 minutes 1 second
7 weeks 5 days 12 hours 1 minute 11 seconds
7 weeks 5 days 1 hour 44 minutes 31 seconds
7 weeks 1 day 12 hours 44 minutes 31 seconds
1 week 5 days 1
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> This thread reminds me of this poor warning message from make:
>>
>> make: Warning: File `Makefile.am' has modification time 7.9e+02 s in the
>> future
>
> This was already reported and fixed: see [1].
That's good.
>> There ar
Simon Josefsson wrote:
> This thread reminds me of this poor warning message from make:
>
> make: Warning: File `Makefile.am' has modification time 7.9e+02 s in the
> future
This was already reported and fixed: see [1].
> There are humans that don't instinctual feel whether '7.9e+02 s' is a
> ti
"James Youngman" <[EMAIL PROTECTED]> writes:
> On Jan 10, 2008 1:06 AM, Bruno Haible <[EMAIL PROTECTED]> wrote:
>> James Youngman wrote:
>> > Lots of packages get bug reports for releases that are pretty old.
>
>> > /* emit the standard version information first. */
>> >
>> > if (release_age (
Eric Blake writes:
>
> maybe it's at least worth adding a compile-time assertion that sizeof(off_t)
> ==sizeof(long) when !HAVE_FSEEKO.
Since I actually have a platform where that's not the case, I'd prefer a
run-time test that only objects when there's an actual problem:
--- fseeko.c.gnulib
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 1/10/2008 3:11 AM:
| /* Memory management: relocate() leaks memory, because it has to construct
| a fresh pathname. If this is a problem because your program calls
| !relocate() frequently, think about caching
On Jan 10, 2008 1:06 AM, Bruno Haible <[EMAIL PROTECTED]> wrote:
> James Youngman wrote:
> > Lots of packages get bug reports for releases that are pretty old.
> > /* emit the standard version information first. */
> >
> > if (release_age (&age))
> > {
> > double weeks = age / (86400
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I'm a Nagios-plugins developer. We're having some issues with
mountlist.c and fsusage.c and since I'm about to update Gnulib I'm
wondering if anything can be done about it.
1. When using get_fs_usage on FreeBSD with a partition filled over 100%
(
Sylvain Beucler wrote:
> > But, more importantly, there's no documentation that says that relocate()
> > returns either the argument string or a freshly allocated string; it could
> > also return - say - a pointer into a hidden global obstack. In fact, one
> > of the return paths of the function (s
Colin Watson wrote:
> I happened to notice a typo in canonicalize-lgpl.c. Patch attached.
Thanks, applied:
2008-01-10 Colin Watson <[EMAIL PROTECTED]>
* lib/canonicalize-lgpl.c (lstat): Fix typo in #if condition.
*** lib/canonicalize-lgpl.c.orig2008-01-10 10:45:50.0 +0
Colin Watson <[EMAIL PROTECTED]> wrote:
> I happened to notice a typo in canonicalize-lgpl.c. Patch attached.
>
> diff --git a/lib/canonicalize-lgpl.c b/lib/canonicalize-lgpl.c
> index e8d2b65..2aebbc6 100644
> --- a/lib/canonicalize-lgpl.c
> +++ b/lib/canonicalize-lgpl.c
> @@ -78,7 +78,7 @@
> # e
I happened to notice a typo in canonicalize-lgpl.c. Patch attached.
Thanks,
--
Colin Watson [EMAIL PROTECTED]
diff --git a/lib/canonicalize-lgpl.c b/lib/canonicalize-lgpl.c
index e8d2b65..2aebbc6 100644
--- a/lib/canonicalize-lgpl.c
+++ b/lib/canonicalize-lg
32 matches
Mail list logo
