[CentOS] upgrade problem

Tue Sep 20 17:21:44 UTC 2005
Mike McCarty <mike.mccarty at sbcglobal.net>

Brian T. Brunner wrote:
> My mailer has no quoted-text-prefix capability.
> ***embedded replies***

Understood.

>>>>mike.mccarty at sbcglobal.net 09/20/05 11:16AM >>>
> 
> 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.
> 
> ***pedantic*** I have to get the compiler to compile the code, the language definition won't do that.
> ***pragmatic*** I'm here to drain the swamp, not analyze the alligators.
> ***overall** How did the compilers change in what they tolerate.

Certainly. I didn't mean something silly like "Well, the compiler
is broken today. I guess I'll go home and watch TV."

If the compiler is broken, then it will soon be fixed. When it
is, it will conform to the Standard. You don't want to have to
continually modify your code. Write to the Standard. If the
compiler breaks, then change as little as possible in ways which
are as close to Standard as possible.

> 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 
>>
> 
> 
> Also, the C Language did not recently change.
> 
> ***the compiler is the  cop, the language definition is the law***

Cops which break the law go to jail just like everyone else.
Eventually, the cops enforce the law as written.

> 
>>Known problem and solution: (amended to clarify my mumbling, for which I apologize)

No problem.

>>We have typedef char MsgIdT 
>>We use a message that is a union comprising a 
>>MsgIdT MsgId;
>>and the 
>>117 message structures, (each of which has a MsgIdT MsgId as the first element);
>>we had a null message number macro #define MSG_NULL ((MsgIdT)0)
>>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 but 2.96 didn't care
>>so now we say
>>union msgstructT msg = {0};                // the 3.x compiler is happy with this.  So is 2.96

Ok, the Standard states that when a union is initialized, the
first element of the union is what gets inited. So what you had
looks like it should have worked. But the compiler seems to have
an internal problem. If "{0}" works, then "{((MsgIdT)0)}" should
also work.

I'd suggest creating a minimal file which reproduces the problem
and filing an error report. In the meantime, I'd change the source
to look like this:

/* A defect in GCC 3.x causes initialization of
** unions with the define below not to work.
**
** Defining this turns on a workaround. It should
** be removed as soon as GCC is repaired.
**/

#define COMPILER_ERROR_1

/* Workaround for GCC 3.x compiler defect */
#ifdef COMPILER_ERROR_1
# define MSG_NULL (0)
#else
# define MSG_NULL ((MsgIdT)0)
#endif

in whatever header you have it defined. I hesitate to suggest
that you add more to your command line, as it seems to be
overburdened already. Normally, I'd put it there. But in this
case, perhaps putting it directly into the source with
more commentary might be better.

>>
>>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.

You may be the first one to notice it. I've been using gcc version 3.3.3 
20040412 (Red Hat Linux 3.3.3-7)
for months without a problem.

> Your guide to writing proper code should not be what a
> compiler accepts, but what the language definition specifies.
> 
> ***the compiler creates the marketable product, that's what I have to please.***
> ***As a theorist, the C and C++ language definitions (law) are fascinating***
> ***As an engineer porting 2.96 code to a 3.4 compiler, the (get this)***
> ***LANGUAGE DEFINITION IS UTTERLY IRRELEVANT***

It is not, as the compiler will eventually conform to the language
specification. If you track the specification, you will also track
the compiler you are eventually going to use. In the meantime, of
course, one has to find a way to get work done.

> ***I've met plenty of cops to whom the law is irrelevant, we do things his way or there's trouble.***
> ***the compiler is my cop.  He's the one I have to please.***
> 
> gcc --ansi --pedantic -Wall
> 
> to get maximum conformance and portability of my code.
> 
> ***this is what I inherited:
> ***COMPILER_OPTIONS = -D_GCC_ -g -g3 -pipe -march=i586 -fstack-check -fcse-follow-jumps -fexpensive-optimizations -fcse-skip-blocks -fforce-mem -frerun-cse-after-loop -fschedule-insns -fschedule-insns2 -fshort-enums -fstrength-reduce -fthread-jumps -fverbose-asm -O2 -Wall -Waggregate-return -Wcast-align -Wcast-qual -Wconversion -Winline -Wpointer-arith -Wshadow -Wwrite-strings
> *** probably more than I need, I might take a (sub) project of stripping this list down to just those needed to get in-spec performance of the object code.
> ** neither ansi nor pedantic are currently in the list of options.

That's about the second longest command line I've seen :-)

I find the "-D_GCC_" to be highly suspicious for these reasons (at least)

(1) The identifier "_GCC_" is reserved, and it's use is illegal
in this context.
(2) I have the uneasy feeling that some special hacks may be in
there that are highly unportable.
(3) Better ways of doing whatever is going on in there may be
available.

> 
> should be reported as a defect.
> 
> ***My mission is to get the code running under the new compiler.  The code pleased the 2.96 compiler.  Things worked!
> ***Now, the new compiler is really displeased with my code.
> ***I'd like to know what the differences are in the two compiler versions relative to what (possibly) non-conforming code is no longer tolerated.

Well, the code you put here looks ok to me.

I just tried compiling this, and got no errors...

typedef char MyChar_t;

#define NULL_MSG    ((MyChar_t)0)

typedef struct {
     MyChar_t        MyChar;
     int             MyInt;
} Si_t;

typedef struct {
     MyChar_t        MyChar;
     unsigned int    MyUint;
} Su_t;

typedef union {
     MyChar_t        MyChar;
     Si_t            MySi;
     Su_t            MySu;
} Message_t;

Message_t   MyMessage = { NULL_MSG };


I wouldn't duplicate the message id like that,
and I prefer to use enumerated types, but I don't
see why it would complain about what you are doing
unless it has an internal error. The message you
reported sounds like an internal error.

If you really just want to know what the internal error
is, then you do need to talk to someone who works with
gcc. It's been several years since I did so. (Worked on
creating a port to the Z8000 many years ago.)

If you just want to get going with something that will work
around, and not munge up your source too much, then I
suggest something like the above code with suitable comments.

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!