On 09/24/11 03:38, Bruno Haible wrote:
> But while doing so, we shouldn't throw the Autoconf principle overboard.
> This means, we have to exerce judgement about which bugs can possibly occur
> on other platforms as well, and let the fixes of Windows platforms also
> benefit the Unix platforms, wi
On 09/24/11 22:31, Gary V. Vaughan wrote:
> $ cc -o hello hello.c
> cc-1241 cc: ERROR File = hello.c, Line = 7
> A declaration cannot appear after an executable statement in a block.
You're supposed to use cc's -c99 flag, no?
Or compile with c99? Then declarations after statements
should work;
On 09/24/11 04:53, Bruno Haible wrote:
> the desire to minimize the number of files did not allow the code to be
> structured in a good way.
Yes, of course. Keeping the number of files small is just one
constraint among many, and is often overridden by other constraints.
> It is more important
On 25 Sep 2011, at 11:32, Paul Eggert wrote:
> On 09/24/11 07:26, Bruno Haible wrote:
>> 1) Is it important for you that what you get from gnulib can be compiled
>> with a C89 compiler (gcc 2.95, IRIX cc, MSVC)?
>
> IRIX users can install either GCC or MIPSpro C (the SGI proprietary compiler).
On 09/24/11 07:26, Bruno Haible wrote:
> 1) Is it important for you that what you get from gnulib can be compiled
>with a C89 compiler (gcc 2.95, IRIX cc, MSVC)?
Not any more.
Platforms that use GCC 2.95 can install a newer GCC and use that.
IRIX users can install either GCC or MIPSpro C (th
On 24 Sep 2011, at 21:26, Bruno Haible wrote:
> Jim Meyering wrote:
>> I will then do what I did for a few years with coreutils:
>>
>>Manually maintain a C99-to-C89 patch for each of the few .c files
>>that deserve the effort, like fts.c.
>>Then, people who require C89 sources can appl
I tried the latest from gnulib via coreutils, and encountered a new failure:
In file included from test-fdutimensat.c:35:0:
test-futimens.h: In function 'test_futimens':
test-futimens.h:95:9: error: declaration of 'fd' shadows a previous local \
[-Werror=shadow]
test-futimen
On 09/24/2011 08:26 AM, Bruno Haible wrote:
All,
Jim Meyering wrote:
I will then do what I did for a few years with coreutils:
Manually maintain a C99-to-C89 patch for each of the few .c files
that deserve the effort, like fts.c.
Then, people who require C89 sources can apply th
The fdopen() function also crashes on MSVC if the fd argument is invalid.
Here's the workaround.
2011-09-24 Bruno Haible
fdopen: Support for MSVC 9.
* m4/fdopen.m4 (gl_FUNC_FDOPEN): Set REPLACE_FDOPEN also if
HAVE_MSVC_INVALID_PARAMETER_HANDLER is 1.
* lib/fdop
> * m4/dup.m4: New file.
Well, this configure-time test leads to a dialog box that notifies the user
about a crash in conftest.exe... Let me simplify the test:
2011-09-24 Bruno Haible
dup: Simplify autoconf test.
* m4/dup.m4 (gl_FUNC_DUP): Don't run a test program. In
Like the read() function, the write() function crashes on invalid parameters
on MSVC 9. Here's the workaround.
2011-09-24 Bruno Haible
write: Support for MSVC 9.
* lib/unistd.in.h (write): Replace also when GNULIB_UNISTD_H_NONBLOCKING
is not 1.
* lib/write.c (w
> * lib/read.c (read_nothrow): New function.
Oops, that was slightly wrong.
2011-09-24 Bruno Haible
read: Fix last commit.
* lib/read.c (read_nothrow): Change return type to 'ssize_t'.
--- lib/read.c.orig Sat Sep 24 16:43:04 2011
+++ lib/read.c Sat Sep 24 16:36:
All,
Jim Meyering wrote:
> I will then do what I did for a few years with coreutils:
>
> Manually maintain a C99-to-C89 patch for each of the few .c files
> that deserve the effort, like fts.c.
> Then, people who require C89 sources can apply the patch manually.
> Or, who knows...
Bruno Haible wrote:
> Hi Jim,
>
>> > About this change of fts.c from 2011-08-18.
>> > The declaration of max_entries in line 1339 comes after a statement. Not
>> > valid C99.
>>
>> s/C99/C89/
>
> Oops, yes. Not valid C89.
>
>> C89 is now more than 12 years old
>
> You meant s/C89/C99/ ?
No, I mean
Hi Jim,
> > About this change of fts.c from 2011-08-18.
> > The declaration of max_entries in line 1339 comes after a statement. Not
> > valid C99.
>
> s/C99/C89/
Oops, yes. Not valid C89.
> C89 is now more than 12 years old
You meant s/C89/C99/ ?
> I see so much more value in using C99's dec
Hi Paul,
> I briefly looked at the more recent changes you installed, and have
> some further comments and suggestions and a couple of patches.
>
> * Why two files, msvc-inval.h and msvc-nothrow.h?
> Would it be simpler to have just one file?
> Is it likely that a package would want one
Bruno Haible wrote:
> Hi Jim,
>
> About this change of fts.c from 2011-08-18.
> The declaration of max_entries in line 1339 comes after a statement. Not
> valid C99.
s/C99/C89/
> gnulib's conventions are still to not require a C99 compiler.
Hi Bruno,
I see so much more value in using C99's decl
Hi Paul,
Paul Eggert wrote:
> > Gnulib uses the "all workarounds for function foo() in file foo.c" approach
> > since the beginning, and has been working very well with that.
>
> I think this can work, but still, we should make it easy for
> non-Windows programmers to see which part of foo.c is f
18 matches
Mail list logo
