[9fans] C compiler question: initializer is not a constant

[9fans] C compiler question: initializer is not a constant

[Axel Belinfante]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

Last week I ported some code containing an
initialization like one of h in attached test.c:

	struct {
		int a, b, c;
	} x;
	
	int h = (int)&x.b - (int)&x;

The plan 9 C compilers (pcc -c, 8c) complain about it:

test.c:8[stdin:9] initializer is not a constant: h

The author of the code told me that it is accepted by
``all other C compilers except ...''
(and I think the exception named was the irix compiler).
Are the plan 9 C compilers more strict here?

In ``the C programming language'' (2nd edition)
I found on page 209, near the end of A7.19:
"Initializers must evaluate either to a constant or to the
 address of a previously declared external or static object
 plus or minus a constant."
Is this the rule that applies?


I tried some variants, like g:

	int g = (int)(&x.b - (int)&x);

and the plan 9 C compilers also complain here (same error msg).
However, gcc (2.95.3) and sun cc (Sun WorkShop 6 2000/04/07 C 5.1)
do not complain about h, but they do complain about g:

(gcc) /tmp/test.c:8: initializer element is not computable at load time
(sun cc) "/tmp/test.c", line 8: an address is not allowed in a constant
initializer for an integral type whose size is smaller than the
size of a pointer

Axel.

[-- Attachment #2: test.c --]
[-- Type: text/plain , Size: 175 bytes --]

struct {
	int a, b, c;
} x;

int d = (int)&x;
int e = (int)&x.b;
int f = (int)(&x.b - 1);
int g = (int)(&x.b - (int)&x);
int h = (int)&x.b - (int)&x;


main(){
}

Re: [9fans] C compiler question: initializer is not a constant

[Douglas A. Gwyn]

Axel Belinfante wrote:
> "Initializers must evaluate either to a constant or to the
>  address of a previously declared external or static object
>  plus or minus a constant."
> Is this the rule that applies?

Yes.  (The actual rule is slightly more complicated, but the
actual problem you're having is explained by this version.)

The basic issue is that in standardizing C, we decided not
to require linkers to be able to perform elaborate
arithmetic involving external identifiers.  Many modern
linkers have no problem with such arithmetic, but many
older (also simpler) ones have limited abilities in this
regard, essentially what is catered to by that rule.

A workaround would be to add a "static initializer" function
(aka "thunk") which the main program can call upon entry, to
compute such initializer values *at run time*.

Re: [9fans] C compiler question: initializer is not a constant

[Axel Belinfante]

> Douglas A. Gwyn responded:
> Axel Belinfante wrote:
> > "Initializers must evaluate either to a constant or to the
> >  address of a previously declared external or static object
> >  plus or minus a constant."
> > Is this the rule that applies?
> 
> Yes.  (The actual rule is slightly more complicated, but the
> actual problem you're having is explained by this version.)
[...]

I already suspected the reason to be something like this;
Thanks for clarifying. 

> A workaround would be to add a "static initializer" function
> (aka "thunk") which the main program can call upon entry, to
> compute such initializer values *at run time*.

This was the solution we tried (and found succesful).
Axel.

Re: [9fans] C compiler question: initializer is not a constant

[Boyd Roberts]

> test.c:8[stdin:9] initializer is not a constant: h

these line numbers.  i haven't investigated it yet, but
i have a bad feeling that they are just wrong when you're
deep in #include hell.

Re: [9fans] C compiler question: initializer is not a constant

[Axel Belinfante]

>The clean way is to use the ANSI offsetof macro,
Thanks!

Axel.

Re: [9fans] C compiler question: initializer is not a constant

[Axel Belinfante]

> The author of the code needs to be visitted by the Style Police.
> Jeez!


Thanks for the clear statement! I'll forward it...
Axel.

Re: [9fans] C compiler question: initializer is not a constant

[rob pike]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

The compiler is justified in complaining, since it doesn't know the
address of x and can't be expected to recognize that it doesn't need
to know it. If you insist on such horrors, give it the address. The
clean way is to use the ANSI offsetof macro, but since the author
clearly doesn't care about cleanliness, just write something like

	int h = (int) &(((struct x*)0)->b);

-rob


[-- Attachment #2: Type: message/rfc822, Size: 4008 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 1256 bytes --]

Last week I ported some code containing an
initialization like one of h in attached test.c:

	struct {
		int a, b, c;
	} x;
	
	int h = (int)&x.b - (int)&x;

The plan 9 C compilers (pcc -c, 8c) complain about it:

test.c:8[stdin:9] initializer is not a constant: h

The author of the code told me that it is accepted by
``all other C compilers except ...''
(and I think the exception named was the irix compiler).
Are the plan 9 C compilers more strict here?

In ``the C programming language'' (2nd edition)
I found on page 209, near the end of A7.19:
"Initializers must evaluate either to a constant or to the
 address of a previously declared external or static object
 plus or minus a constant."
Is this the rule that applies?


I tried some variants, like g:

	int g = (int)(&x.b - (int)&x);

and the plan 9 C compilers also complain here (same error msg).
However, gcc (2.95.3) and sun cc (Sun WorkShop 6 2000/04/07 C 5.1)
do not complain about h, but they do complain about g:

(gcc) /tmp/test.c:8: initializer element is not computable at load time
(sun cc) "/tmp/test.c", line 8: an address is not allowed in a constant
initializer for an integral type whose size is smaller than the
size of a pointer

Axel.

[-- Attachment #2.1.2: test.c --]
[-- Type: text/plain , Size: 175 bytes --]

struct {
	int a, b, c;
} x;

int d = (int)&x;
int e = (int)&x.b;
int f = (int)(&x.b - 1);
int g = (int)(&x.b - (int)&x);
int h = (int)&x.b - (int)&x;


main(){
}

Re: [9fans] C compiler question: initializer is not a constant

[David Gordon Hogan]

> The author of the code told me that it is accepted by
> ``all other C compilers except ...''
> (and I think the exception named was the irix compiler).

The author of the code needs to be visitted by the Style Police.
Jeez!