Ben Pfaff wrote:
> On the Windows platform, Microsoft documents the rename function
> as refusing to replace existing destination files. ...
>
> Here is a gnulib commit that I am proposing. It (cross)compiles
> on Mingw, but I am waiting to hear back from my Windows tester to
> find out whether i
On the Windows platform, Microsoft documents the rename function
as refusing to replace existing destination files. This is
allowed by C89 (and C99) but it is not POSIX-compliant, and it
can be quite surprising to programs that want to atomically
replace files.
Here is a gnulib commit that I am p
On Fri, 20 Mar 2009, Bruno Haible wrote:
Reuben Thomas wrote:
I suppose it's also a downside of gnulib's being a source library, though
the tools it offers have persuaded me, at least, to treat its files as "not
normally for editing", and hence like a binary library.
You can override gnulib's
On Friday 20 of March 2009 22:25:30 Bob Proulx wrote:
> Kamil Dudka wrote:
> > On Friday 20 of March 2009 12:36:38 Bruno Haible wrote:
> > > Jim Meyering wrote:
> > > > Perhaps "~" isn't the only character we should treat that way.
> > >
> > > I'd say that '~' is pretty special here because it's us
Kamil Dudka wrote:
> On Friday 20 of March 2009 12:36:38 Bruno Haible wrote:
> > Jim Meyering wrote:
> > > Perhaps "~" isn't the only character we should treat that way.
> >
> > I'd say that '~' is pretty special here because it's used as backup file
> > suffix by many text editors. Which is not th
Eric Blake wrote:
> According to Reuben Thomas on 3/20/2009 8:10 AM:
>>> Always including first is easy to forget.
>>> You might want to use rules like these from gnulib's maint.mk:
>> I just checked gnulib out from git and I don't find this rule or
>
> Jim meant coreutil's maint.mk.
I sure did.
Bruno Haible writes:
> Hi Simon,
>
> The sockets.h file is not self-contained on mingw: It leads to a compilation,
> as in the attached snippet.
>
> This fixes it. The modification in sockets.h has the purpose to verify the
> self-contained-ness. Hopefully this is uncontroversial, so I'm committi
Reuben Thomas writes:
> On Fri, 20 Mar 2009, Eric Blake wrote:
>
>> Jim meant coreutil's maint.mk. It is not synced with gnulib's maint.mk,
>> although several people have expressed interest in resyncing them.
>
> Aha! This is surely the sort of rule that should be pushed into
> gnulib. Thanks a
Simon Josefsson wrote:
> This may have been discussed before, but I don't recall a solution, so
> maybe a new report will help.
Yes, in the meantime we all had time to think about it.
> i586-mingw32msvc-gcc -g -O2 -o test-getdelim.exe test-getdelim.o
> ../gllib/libgnu.a
> ../gllib/libgnu.a(c
Reuben Thomas wrote:
> I suppose it's also a downside of gnulib's being a source library, though
> the tools it offers have persuaded me, at least, to treat its files as "not
> normally for editing", and hence like a binary library.
You can override gnulib's source code or apply modifications to
Hi Simon,
The sockets.h file is not self-contained on mingw: It leads to a compilation,
as in the attached snippet.
This fixes it. The modification in sockets.h has the purpose to verify the
self-contained-ness. Hopefully this is uncontroversial, so I'm committing it.
2009-03-20 Bruno Haible
On Fri, 20 Mar 2009, Eric Blake wrote:
Jim meant coreutil's maint.mk. It is not synced with gnulib's maint.mk,
although several people have expressed interest in resyncing them.
Aha! This is surely the sort of rule that should be pushed into gnulib.
Thanks anyway.
This problem seems to occ
Eric Blake writes:
> But C99 also states:
>
> If the same qualifier appears more than once in the same
> specifier-qualifier-list, either directly or via one or more typedefs, the
> behavior is the same as if it appeared only once.
This paragraph is new in C99. Thus it is not a bug if a C89 com
2009/3/20 Bruno Haible :
> Eric Blake wrote:
>> It specifically states that results are unspecified for
>> other things, like %b, where there could be more bytes than screen
>> columns. Which means we should be free to interpret things in the way
>> that makes the most sense, by interpreting %5b a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Reuben Thomas on 3/20/2009 8:10 AM:
>> Always including first is easy to forget.
>> You might want to use rules like these from gnulib's maint.mk:
> I just checked gnulib out from git and I don't find this rule or
Jim meant coreutil's ma
On Thu, 19 Mar 2009, Jim Meyering wrote:
Reuben Thomas wrote:
On Wed, 18 Mar 2009, Eric Blake wrote:
Ahh. The bug is in zile, not gnulib.
Ah, thanks very much, and apologies for the noise.
Always including first is easy to forget.
You might want to use rules like these from gnulib's mai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Andreas Schwab on 3/20/2009 7:20 AM:
> Eric Blake writes:
>
>> But C99 also states:
>>
>> If the same qualifier appears more than once in the same
>> specifier-qualifier-list, either directly or via one or more typedefs, the
>> behavior
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding bug-gnulib]
According to Matthew Woehlke on 3/19/2009 3:07 PM:
> Jim Meyering wrote:
>> Matthew Woehlke wrote:
>>> Also, here is a different (AIX-only) error:
>>>
>>> cc -qlanglvl=ansi -qlanglvl=ansi -g -o ln ln.o libver.a
>>> ../lib/libco
On Friday 20 of March 2009 12:36:38 Bruno Haible wrote:
> Jim Meyering wrote:
> > Perhaps "~" isn't the only character we should treat that way.
>
> I'd say that '~' is pretty special here because it's used as backup file
> suffix by many text editors. Which is not the case for '_', '-', and
> othe
Ralf Wildenhues asked:
> What exactly is the point of using a different format and extraction
> code than aclocal does? ...
> Gettext is using a format slightly incompatible to the aclocal one here,
aclocal exploits '# serial' lines since 2005-02-01. Gettext is using the
format that you call "slig
Colin Watson wrote:
> How about the attached patch to autopoint which causes it to look
> through all m4 directories in ACLOCAL_AMFLAGS and compare serial
> numbers? That would avoid the problem of 'make dist' forgetting to ship
> files even if you do use multiple m4 directories; the files will sim
Jim Meyering wrote:
> Perhaps "~" isn't the only character we should treat that way.
I'd say that '~' is pretty special here because it's used as backup file suffix
by many text editors. Which is not the case for '_', '-', and others.
Bruno
Kamil Dudka wrote:
> Simple patch including clarifying test cases is attached.
The patch removes two test cases from tests/test-filevercmp.c. I would prefer
a patch that only adds test cases, never removes test cases (unless they were
really bogus).
Bruno
Hi Sergey,
Sergey Poznyakoff wrote:
> I am going to submit the updated gnulib.pot to TP. Before this,
> I'd like to change its versioning scheme so that it coincides with the
> version reported by `gnilib-tool --version'. E.g. this potfile will be
> named gnulib-0.0.1991-dbebf.pot. Does it seem
Kamil Dudka wrote:
> On Thursday 19 March 2009 11:27:11 Sven Joachim wrote:
>> While the ordering of hidden files in "ls -v" seems to be fixed
>> now, there are still inconsistencies. Here's what I get in the latest
>> snapshot:
>>
>> ,
>>
>> | LANG=C /usr/local/src/coreutils-7.1.63-8e6a6/src
On Thursday 19 March 2009 11:27:11 Sven Joachim wrote:
> While the ordering of hidden files in "ls -v" seems to be fixed
> now, there are still inconsistencies. Here's what I get in the latest
> snapshot:
>
> ,
>
> | LANG=C /usr/local/src/coreutils-7.1.63-8e6a6/src/ls -alv
> | total 0
> | drwx
Hello,
I am going to submit the updated gnulib.pot to TP. Before this,
I'd like to change its versioning scheme so that it coincides with the
version reported by `gnilib-tool --version'. E.g. this potfile will be
named gnulib-0.0.1991-dbebf.pot. Does it seem a good idea?
Regards,
Sergey
27 matches
Mail list logo
