intel driver will only compile with gcc

Brian Paul brian.paul at tungstengraphics.com
Tue Jun 12 13:39:11 PDT 2007


Daniel Stone wrote:
> On Tue, Jun 12, 2007 at 10:17:57AM -0700, Kean Johnston wrote:
>> That code works only with a C99 compiler.
> 
> No, again, it does not require a C99 compiler.  gcc is not a C99
> compiler.

By default, gcc is rather loose in terms of C standards adherence.

If you add -pedantic to your flags you'll see that named initializers 
generate warnings with gcc (since the default standard is -std=gnu89).

Example:
$ gcc -pedantic -c init.c
init.c:12: warning: ISO C90 forbids specifying subobject to initialize
init.c:13: warning: ISO C90 forbids specifying subobject to initialize

If -pedantic (or -ansi) were used when building X, we'd certainly see 
some new warnings.  If your code uses named initializers and you really 
care about following the C spec, you'd have to run gcc with -std=c99 
because they're not a feature of c89.

Kean's point is valid.


>> just as legibly
> 
> No, it is not as legible.
> 
>> The named initializer buys you absolutely nothing whatsoever.
> 
> Bar the legibility.

Named initializers do indeed have value beyond legibility.  Suppose you 
have a struct:

struct foo { int x, y; };

and initialize a variable f with:

struct foo f = { 1, 2 };

Now suppose someone interchanged the order of x and y in foo and wasn't 
aware of f's initialization.  The variable f will be initialized 
differently.

But if named initializers were used, f would still be initialized as 
intended:

struct foo f = { .x=1, .y=2 };

This is a contrived example, of course, but I distincly remember being 
bit by this exact problem in Mesa one time.  I wanted to use named 
initializers in Mesa long ago, but there were some older compilers that 
didn't support them.

Nowadays, I'd be surprised to find anyone using a compiler that didn't 
support named initializers (given the right compiler flags), but there 
was definitely a time when it was an issue.  Perhaps Kean has such a 
compiler in mind.


>> The alternative, which works on just about every C compiler ever
>> written, is to have 2 or 3 macros:
> 
> Which is horrific.  Truly horrific.

Yeah, well, that's what you have to do sometimes to maximize portability.

-Brian



More information about the xorg mailing list