Sorry, I am not very familiar with all those command line options:
Anyway, redo was easy:
with: --std=c9x
gcc-2.95 --std=c9x -pedantic -Wall -W -ofoo foo.c
foo.c:5: field `b' has incomplete type
foo.c: In function `main':
foo.c:20: warning: unknown conversion type character `z' in format
foo.c:20
Martijn Kuipers wrote:
> [EMAIL PROTECTED]:~$ gcc-2.95 --std=c99 -pedantic -Wall -W -ofoo foo.c
> cc1: unknown C standard `c99'
This makes this test a little less useful. Try with --std=c9x (GCC 2.95
is old enough not to know the standard by the "official" name).
According to GCC 3.0 C99 status
Hi,
I still had 2.95 on my machine (Debian). Results are:
[EMAIL PROTECTED]:~$ gcc-2.95 --version
2.95.4
[EMAIL PROTECTED]:~$ gcc-2.95 --std=c99 -pedantic -Wall -W -ofoo foo.c
cc1: unknown C standard `c99'
foo.c:5: field `b' has incomplete type
foo.c: In function `main':
foo.c:20: warning: unkn
On Sun, 28 Aug 2005, Antti-Juhani Kaijanaho wrote:
>
> This is not true under C99. If an array[] is the last member of a
> struct (which is what we are, AFAIK, talking about), then sizeof that
> struct is defined and gives the size of that struct as if the array's
> size were zero (but the stru
Linus Torvalds wrote:
> But using "array[]" means that "sizeof()" no longer works, and then you
> have to use "offsetof()", which is a big pain.
This is not true under C99. If an array[] is the last member of a
struct (which is what we are, AFAIK, talking about), then sizeof that
struct is defin
On Sun, 28 Aug 2005, Jason Riedy wrote:
>
> I'm fine with requiring a limited C99 compiler. A
> pedantic compiler will reject members with a length
> of zero. 6.7.5.2 para1 requires a value greater than
> zero for a constant array size. So the code now (with
> [0] decls) is neither C89 nor C9
And Junio C Hamano writes:
- > +Replace C99 array initializers with code.
- I presume this is to help older compilers?
Yes, so it's relatively unimportant. I could work
around it in my situation; I only included it
because it's "necessary" for some Sun compilers on
older Solaris installat
Jason Riedy <[EMAIL PROTECTED]> writes:
> If you're interested, I have a few patches in
> http://www.cs.berkeley.edu/~ejr/gits/git.git#portable
> that let git compile with xlc on AIX and Sun's non-c99
> cc on Solaris.
I've taken a look at them. Thanks.
> Changes:
> +Replace C99 array in
And Junio C Hamano writes:
- > BTW, how would people feel about replacing the
- > setenv() and unsetenv() calls with the older putenv()?
- No comment on this one at this moment until I do my own digging
- a bit.
If you're interested, I have a few patches in
http://www.cs.berkeley.edu/~ejr/g
Jason Riedy <[EMAIL PROTECTED]> writes:
> And Junio C Hamano writes:
> - It turns out that your patch breaks GCC build
>
> Whoops, sorry. Your fix works with Sun's cc.
Thanks.
> BTW, how would people feel about replacing the
> setenv() and unsetenv() calls with the older putenv()?
> The So
And Junio C Hamano writes:
- It turns out that your patch breaks GCC build
Whoops, sorry. Your fix works with Sun's cc.
BTW, how would people feel about replacing the
setenv() and unsetenv() calls with the older putenv()?
The Solaris version I have to work on doesn't have
the nicer functio
Jason Riedy <[EMAIL PROTECTED]> writes:
> Sun's cc doesn't know __attribute__.
It turns out that your patch breaks GCC build (#ifndef
__attribute__ is true there, and it should be---what it does
cannot be done in preprocessor alone). I am going to work it
around like this. Could you try it with
Sun's cc doesn't know __attribute__.
Signed-off-by: Jason Riedy <[EMAIL PROTECTED]>
---
cache.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
4181b19f615b3d56f9fae5f3accd435480aa7d2f
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -41,7 +41,7 @@
#endif
#ifndef __
13 matches
Mail list logo
