Why is this legal?
Henry Spencer
>typedef struct A *A;
>
>"struct A" has not previously been, defined...
It's perfectly legal to talk about a *pointer* to a struct whose contents
are not yet known. Of course, you can't do anything that would get you a
look at that struct or its contents without supplying more information,
but merely shuffling pointers around can be done while in ignorance of
the details. (This does constrain the implementation in some ways.)
Note that struct tags and normal identifiers (including type name) are
in two different name spaces, so those are two different As. There is
no practical difference between the above and `typedef struct A *B;',
so don't get confused by use of the same name twice.
--
The X Window system is not layered, and | Henry Spencer @ U of Toronto Zoology
it was not designed. -Shane P. McCarron | he...@zoo.toronto.edu utzoo!henry
John F. Woods
>----->8 Clip 'n' compile 8<----
>/*
> * Your compiler may warn that the size of `struct foo' is
> * zero, but that doesn't mean it won't generate the
> * executable correctly
> */
>typedef struct A *A;
>struct foo *foo;
>main()
>{
> printf("hello\n");
> printf("*foo size: %d\n", sizeof(struct foo) );
At this point, the compiler is at liberty to generate a program which formats
your hard disk drive. In fact, it probably should. 3.3.3.4, 1.6, six two and
even, over and out.
> printf("A size: %d\n", sizeof(A) );
>}
Phil Howard KA9WGN - I am the NRA
You are assuming a PC? What about UNIX? Why not "cd;/bin/rm -rf ."?
It should also format the floppies, since the offending source code may
be residing there as well.
But I'd be satisfied if the program simply tracked down the source and
all its backups and just deleted them.
Blair P. Houghton
>bhou...@hopi.intel.com (Blair P. Houghton) writes:
>>struct foo *foo;
>
>At this point, the compiler is at liberty to generate a program which formats
>your hard disk drive. In fact, it probably should. 3.3.3.4, 1.6, six two and
>even, over and out.
But tell us WHY, Dr. Define....
--Blair
"I just came out of a demo;
I'm too botched to bother..."
John F. Woods
>In article <10...@ksr.com> j...@ksr.com (John F. Woods) writes:
>>bhou...@hopi.intel.com (Blair P. Houghton) writes:
>>>struct foo *foo;
>>>main(){ printf("*foo size: %d\n", sizeof(struct foo) );
>>At this point, the compiler is at liberty to generate a program which formats
>>your hard disk drive. In fact, it probably should. 3.3.3.4, 1.6, six two and
>>even, over and out.
>But tell us WHY, Dr. Define....
"3.1.2.5 Types
A structure or union type of unknown content (as described in 3.5.2.3)
is an incomplete type."
"3.3.3.4 The sizeof Operator
Constraints
The sizeof operator shall not be applied to an expression that has
function type or an incomplete type, to the parenthesized name of such
a type, ..."
"1.6 Definitions of Terms
In this standard, ... "shall not" is to be interpreted as a prohibition.
* Undefined behavior -- behavior, upon use of a nonportable or erroneous
program construct, ... for which the standard imposes no requirements.
Permissible undefined behavior ranges from ignoring the situation completely
with unpredictable results, to having demons fly out of your nose."
In short, you can't use sizeof() on a structure whose elements haven't been
defined, and if you do, demons may fly out of your nose.
OK, OK; so the Standard doesn't *ACTUALLY* mention demons or noses. Not as
such, anyway.
Blair P. Houghton
>>At this point, the compiler is at liberty to generate a program which formats
In article <1992Feb24....@ux1.cso.uiuc.edu> ph...@ux1.cso.uiuc.edu (Phil Howard KA9WGN - I am the NRA) writes:
>You are assuming a PC? What about UNIX? Why not "cd;/bin/rm -rf ."?
>>bhou...@hopi.intel.com (Blair P. Houghton) writes:
>>>/*
>>> * Your compiler may warn that the size of `struct foo' is
>>> * zero, but that doesn't mean it won't generate the
>>> * executable correctly
>>> */
I dunno. I thought that the reason we put comments
into code was so's people would _read_ them.
Here's a logic lesson: "that doesn't mean it won't" does not imply "it will."
--Blair
"German officer, on viewing
Guernica, shortly after its
completion: 'Did you do that?'
Pablo Picasso, in reply:
'No. You did.'"
Christopher R Volpe
|>In short, you can't use sizeof() on a structure whose elements haven't been
|>defined,
True.
|>and if you do, demons may fly out of your nose.
|>
|>OK, OK; so the Standard doesn't *ACTUALLY* mention demons or noses. Not as
|>such, anyway.
Wait a second. You're acting like this is undefined behavior. It isn't.
The code in question violates a CONSTRAINT. Therefore, a diagnostic is
required. This doesn't mean the compiler can do *anything*. I certainly
hope that a compiler wouldn't format my hard drive if I accidentally left
out a semicolon somewhere.
==================
Chris Volpe
G.E. Corporate R&D
vol...@crd.ge.com
John F. Woods
It's an "erroneous program construct", right? That leaves it out of both
"unspecified behavior" and "implementation-defined behavior", both of which
are only for correct program constructs (see the definitions). That clearly
leaves only "undefined behavior"; once the compiler has issued its one required
diagnostic, no further constraints are put on its behavior, or on the behavior
of whatever translated program it might produce. Who knows, the compiler
writers might consider it to be an important language-extension to be able
to summon nasal demons by taking the sizeof an incomplete type, or to be
able to format a hard drive by simply running the C compiler on a program
missing a colon (I can never remember the arguments to format programs,
that actually sounds like a helpful thing to me... ;-).
If you still disagree, please tell me what the Standard says the compiler
must, or must not, do once it has issued the diagnostic.
Christopher R Volpe
|>vo...@bart.crd.ge.com (Christopher R Volpe) writes:
|>>In article <10...@ksr.com>, j...@ksr.com (John F. Woods) writes:
|>>|>In short, you can't use sizeof() on a structure whose elements
haven't been
|>>|>defined,
|>>True.
|>>|>and if you do, demons may fly out of your nose.
|>>|>
|>>|>OK, OK; so the Standard doesn't *ACTUALLY* mention demons or noses.
Not as
|>>|>such, anyway.
|>>Wait a second. You're acting like this is undefined behavior. It isn't.
|>>The code in question violates a CONSTRAINT. Therefore, a diagnostic is
|>>required. This doesn't mean the compiler can do *anything*. I certainly
|>>hope that a compiler wouldn't format my hard drive if I accidentally left
|>>out a semicolon somewhere.
|>
|>It's an "erroneous program construct", right? That leaves it out of both
|>"unspecified behavior" and "implementation-defined behavior", both of which
|>are only for correct program constructs (see the definitions). That clearly
|>leaves only "undefined behavior"; once the compiler has issued its one
required
No. Undefined behavior is behavior upon use of an erroneous program
construct (on that part you are correct) for which THE STANDARD IMPOSES
NO REQUIREMENTS. If the Standard requires a diagnostic, the behavior is
not undefined.
|>diagnostic, no further constraints are put on its behavior, or on the
behavior
|>of whatever translated program it might produce. Who knows, the compiler
|>writers might consider it to be an important language-extension to be able
|>to summon nasal demons by taking the sizeof an incomplete type, or to be
|>able to format a hard drive by simply running the C compiler on a program
|>missing a colon (I can never remember the arguments to format programs,
|>that actually sounds like a helpful thing to me... ;-).
|>
|>If you still disagree, please tell me what the Standard says the compiler
|>must, or must not, do once it has issued the diagnostic.
Using that logic, a conforming implementation may, after correctly translating
and/or executing your strictly conforming program, reformat your hard drive.
Right? Does the Standard say what an implementation must or must not do
after successful execution of your strictly conforming program?
-Chris
John F. Woods
>No. Undefined behavior is behavior upon use of an erroneous program
>construct (on that part you are correct) for which THE STANDARD IMPOSES
>NO REQUIREMENTS. If the Standard requires a diagnostic, the behavior is
>not undefined.
Nowhere does the standard say what an executable which contains any
erroneous program construct will do. "Undefined behavior is otherwise
indicated in this standard ... by the omission of any explicit definition
of behavior." The Standard COULD say that a compiler must terminate
immediately upon completing the diagnostic issued as a result of a violation
of a constraint, but instead it omits any explicit definition of behavior at
that point.
When a program contains the line ``printf("%d\n", sizeof(struct incomplete));''
* a C compiler is not incorrect for terminating the compilation after a
properly-identified diagnostic message.
* a C compiler is not incorrect for creating an executable which prints 0.
* a C compiler is not incorrect for creating an executable which prints 666.
* a C compiler is not incorrect for creating an executable which causes demons
to fly out of your nose.
because
* the program has made use of an erroneous program construct for which no
explicit definition of execution behavior is given.
I claim that the erroneous program is *explicit* license for loony behavior,
because if you carefully research the behavior of an erroneous C program,
you eventually wind up in the "undefined behavior" bit bucket.
When a program contains the line ``printf("%d\n", sizeof(struct incomplete));''
* the C compiler itself MUST issue a diagnostic IF this is the first required
diagnostic resulting from your program, and then MAY itself cause demons to
fly from your nose (which, by the way, could well BE the documented
diagnostic message) just as it MAY issue further diagnostics for further
violations of syntax rules or constraints (or, for that matter, for any
reason it chooses).
> Using that logic, a conforming implementation may, after correctly
> translating and/or executing your strictly conforming program, reformat
> your hard drive.
Strictly speaking, no. That is, however, at best an implicit license for
loony behavior, which the Standard can no more rule out than it can the
immensely irritating exit messages of VMS. That's a behavior which is
Undefined in the Standard because you would not sensibly ask the Standard
about it in the first place.
Norman Diamond
>In article <10...@ksr.com>, j...@ksr.com (John F. Woods) writes:
>|>In short, you can't use sizeof() on a structure whose elements haven't been
>|>defined,
>True.
>|>and if you do, demons may fly out of your nose.
>The code in question violates a CONSTRAINT. Therefore, a diagnostic is
>required. This doesn't mean the compiler can do *anything*. I certainly
>hope that a compiler wouldn't format my hard drive if I accidentally left
>out a semicolon somewhere.
Hmm. The standard says that implementations may provide extensions as long
as no strictly conforming program can detect them. Until this point, the
posters to this group all seemed to think that an implementation would be
free to "do the right thing" after issuing a diagnostic.
Of course, what is the intuitively expected or desired "right thing" for
one person would not be so for another person. Furthermore, it is only a
matter of quality, not compliance, if an implementation even tries to do a
right thing, rather than a universally condemned obnoxious wrong thing.
Should violation of a constraint should completely prevent a program from
being executed? Mr. Volpe has given a good argument for saying yes.
The standard doesn't say. Does the standard imply it? Maybe we need an
interpretation ruling.
--
Norman Diamond dia...@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring. That was probably it. Very bad."
