Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 5 Aug 1998 07:31:30 -0400 (EDT)
From:      Thomas David Rivers <rivers@dignus.com>
To:        chuckr@glue.umd.edu, rivers@dignus.com
Cc:        freebsd-hackers@FreeBSD.ORG, Nicolas.Souchu@prism.uvsq.fr
Subject:   Re: C and static initialization with unions
Message-ID:  <199808051131.HAA18170@lakes.dignus.com>
In-Reply-To: <Pine.BSF.4.00.9808042107000.409-100000@picnic.mat.net>

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> And you _seem_ to have made my argument ... you said ANSI forbids it,
> you even quoted yourself above, but your quotation from the standard
> says it's implementation-defined.  That means it's legal, but undefined
> behavior.  For any reasonable shop making software for sale, they may
> mean the same thing, but for someone doing one-off controllers, the
> operation is clearly legal, and the programmer is clearly warned that
> they had better know what they're doing, because it's not going to be
> portable.

 You're right... I did say "forbids"... that isn't quite right.

 The standard says:

	"Implementation-defined behaviour - behavior, for a correct
 	 program construct and correct data, that depends on the
	 characteristics of the implementation and that each
	 implementation shall document."

 Thus, the program is correct; but you can't be sure of what it will
 do on any platform.

 Furthermore, a platform may define the behavior as performing in a manner
 similiar to my example.

 Thus, "forbids" is the wrong word.

 Someone's further assertion that we (being SAS) have to diagnose
 reliance on implementation-defined behavior and weed it out of our
 sources is correct.  So, I tend to be a little strong here.  I can
 easily say this is forbidden in SAS Institute sources.  But, anyone
 who isn't concerned about portability between compilers can go
 ahead and do this.  Note that could even be between different versions
 of the same compiler... so, gcc is free to change with its next
 version and "break" any code you have that depends on its previous
 behavior.

 In any event, it is an unwise coding practice.

	- Dave Rivers -

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808051131.HAA18170>