[CentOS] upgrade problem

Tue Sep 20 15:16:25 UTC 2005
Mike McCarty <mike.mccarty at sbcglobal.net>

Brian T. Brunner wrote:
> My desire is NOT to remain rooted in the past.  Hence 
> my interest in changing my code to meet the compiler of today.

You should not use what some compiler accepts as your
guide for writing code. You should use the Language Definition.

See below.

> If I'm killing the 3.x compiler with code that 2.96 accepted,
> it ought to be from well-known (by now) reasons like 
> 
> (I'm making this up for an example)
> 
> "memset used to be a routine but now it is a macro 
> ..:. don't give it macro parameters."

I realize that this is only an example that you made up, so
I'm not going to comment specifically on this illustration.
But you need to realize that the C Language Definition is not
going to change in a way that would break this type of
construct. The Standard allows either macros or real routines.
But for those which are implemented as macros, it also
requires the macro to behave as if it were implemented as
a routine (except for a few, noted ones, like getc()).
If memset() is provided as a macro (or even built-in), there
must still be a real routine, so its address may be used,
for example.

Also, the C Language did not recently change.

> Known problem and solution:
> 
> We use a message that is a union comprising a char MsgIdT and the 
> 117 message structures, (each of which has a char MsgIdT as the first element);
> we had a null message number macro #define MSG_NULL ((MsgIdT)0)

I'm not sure I understand what you mean. Is MsgIdT a type specifier, or
a structure element? IOW, do you have code like this:

typedef char MsgIdT;

typedef struct some_tag {
	MsgIdT	MsgId;
	union {
		...
	} MsgBody;
} Message_t;

Or do you have code like this:

typedef struct some_tag {
	char	MsgIdT;
	union {
		...
	} MsgBody;
} Message_t;

If the latter, then you have a real problem with violating the
language definition. You can't use a variable name to create
a cast.

> under 2.96 we could allocate a message union, and initialize it with
> union msgstructT msg = {MSG_NULL};  // the 3.x compiler barfs on this
> so now we say
> union msgstructT msg = {0};                // the 3.x compiler is happy with this.
> 
> Why the compiler decided we can't initialize an auto union with a 
> type-cast scalar when we used to do so with no problem
> *should* have been recorded somewhere, if so, that document
> *should* give me other clues about what's making the 3.x compiler 
> barf on this 2.96-happy code.

Your guide to writing proper code should not be what a
compiler accepts, but what the language definition specifies.
I suggest that you get a copy of the ANSI (or ISO if you
like the UN) C Language Standard and read it. If the compiler
accepts code which is non-standard, and which it does not
document as an extension, then you should report a defect.
Likewise, if it does not accept a conforming program, you
should report a defect. With gcc, I like to use

gcc --ansi --pedantic -Wall

to get maximum conformance and portability of my code.

If you were using a structure element name to create a cast,
rather than a type specifier, then the earlier compiler
was accepting something it should not have. OTOH, having a
compiler get an internal error when presented with non-
conforming source is also unacceptable, and if it is
occurring, should be reported as a defect.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!