Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Is this valid C?
Date: Sun, 26 Feb 2017 13:13:00 -0800
Organization: None to speak of
Lines: 58
Message-ID: <ln8toshd0j.fsf@kst-u.example.com>
References: <o8858o$g1g$1@dont-email.me> <o8alb0$6pb$1@dont-email.me> <o8an5i$bmv$1@dont-email.me> <ln60k6q31w.fsf@kst-u.example.com> <o8bv3d$dg8$1@dont-email.me> <87shnab3c5.fsf@bsb.me.uk> <ln37fane0p.fsf@kst-u.example.com> <87wpclaoqs.fsf@bsb.me.uk> <o8d5p6$s5l$1@dont-email.me> <4a1d176e-0c60-422e-9eb0-04574b2f32ef@googlegroups.com> <kfnr32puk7l.fsf@x-alumni2.alumni.caltech.edu> <ln4lzkkf2o.fsf@kst-u.example.com> <kfn7f4crfn0.fsf@x-alumni2.alumni.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="b8cd4aeac47b845ed1638f30cd407196"; logging-data="11570"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19+pCQL2WGr9Huvrhkx9RwF"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:qfqftC2g7b1Rneu/G4qCgMP4F4k= sha1:E7myWw0yHQ69m1i69eOxwQLhns0=
Xref: csiph.com comp.lang.c:104790

Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> Now let's look at N1256 section 6.3.2.1 paragraph 2.  Here we
> have another case of undefined behavior, namely, when there is an
> lvalue-to-value conversion with the lvalue being of incomplete
> type.  Here is an example of that situation:
>
>     #include <stdlib.h>
>
>     typedef struct foo Foo;
>
>     extern void takes_foo( Foo );
>
>     int main(void) {
>         if (0) {
>             Foo *p = malloc( 100 );
>             takes_foo( *p );
>         }
>         return  0;
>     }

Which raises a question: *why* is this undefined behavior rather than a
constraint violation?

N1570 6.3.2.1p2 says that lvalue conversion has undefined behavior
if the lvalue has a non-array incomplete type.  p3 says that
array-to-pointer conversion has undefined behavior if the array
object has register storage class.

Are there any cases where either of these conditions cannot be easily
detected at compile time?  Is there any potential benefit in allowing
implementations to define the behavior of either conversion?  Is there
any sensible behavior that could be implemented?  (Neither the C89 nor
the C99 Rationale sheds any light on this.)

[...]

> Taking all of the above into consideration, I conclude that the
> provisions of 6.3.2.1 are meant to apply at compile time unless
> there is an explicit "when it is evaluated" qualification.
>
> Returning now to C11 (and N1570), paragraph 2 adds a new case of
> undefined behavior, namely, reading an uninitialized object (of
> automatic storage duration, and some other qualifiers).  This
> case too cannot be known in general until run time, so why isn't
> there a "when it is evaluated" qualifier?  Very probably, just
> an editorial oversight.
>
> So, there you have it.  What do you think?

I think that the oversight was making those constructs undefined
behavior rather than constraint violations.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"