Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: multidimensional heap arrays |
| Date | 2011-04-27 00:24 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <kfntydkxil7.fsf@x-alumni2.alumni.caltech.edu> (permalink) |
| References | (8 earlier) <0.967ba25c6450811178a3.20110426224949BST.87liywd6o2.fsf@bsb.me.uk> <91ouo6Fq9bU12@mid.individual.net> <0.bae52d41338584cfc66d.20110427003859BST.87aafcd1m4.fsf@bsb.me.uk> <kfnaafcze0n.fsf@x-alumni2.alumni.caltech.edu> <0.0ecbc88aadc039f9a3ac.20110427035940BST.87zkncbdr8.fsf@bsb.me.uk> |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Ian Collins <ian-news@hotmail.com> writes:
>>>>
>>>> [snip] I was trying to come up [an example where the VLA-ness
>>>> changes the semantics]:
>>>>
>>>> typedef char C[16];
>>>>
>>>> void f( C* c ) {}
>>>>
>>>> int main(void)
>>>> {
>>>> char c[16];
>>>>
>>>> f( &c );
>>>>
>>>> const unsigned n = 15;
>>>>
>>>> char cc[n];
>>>>
>>>> f( &cc );
>>>> }
>>>>
>>>> Compiles fine as c99 (which was the surprise),
>>>
>>> Hmm... At first glance it looks like a diagnostic is required. 6.7.5.2
>>> p6 says:
>>>
>>> "For two array types to be compatible, both shall have compatible
>>> element types, and if both size specifiers are present, and are
>>> integer constant expressions, then both size specifiers shall have the
>>> same constant value. If the two array types are used in a context
>>> which requires them to be compatible, it is undefined behavior if the
>>> two size specifiers evaluate to unequal values."
>>>
>>> so are '&cc' and the parameter 'c' pointers to compatible types? This
>>> paragraph does not say. Maybe it is specified somewhere else, but I
>>> can't find it.
>>>
>>> I think the intent of the last sentence is to make the program's
>>> behaviour is undefined, but that would imply the need for a diagnostic.
>>
>> No diagnostic is required because the last sentence isn't a
>> constraint. That is, it isn't a restriction on the language
>> (does not have 'shall' or 'shall not').
>
> Yes, I know, but that was not my point. I was saying that if the intent
> was for the behaviour to be undefined (due to that last sentence) it
> would be because the two types are incompatible and that incompatibility
> would require a diagnostic form the call.
Ahh, I see. I misunderstood your intended implication there.
> However, I can see that is
> not what is written. What it says is simply that unequal sizes gives
> rise to UB, not to incompatibility. So thank you for making me read it
> again ore carefully.
You are most welcome, sir.
>>>> but fails as C++ (type
>>>> mismatch). What did surprise me was the VLA type matching even though
>>>> the size differed. Changing the declaration of cc to cc[15] did
>>>> produce the expected compiler warnings.
>>>
>>> The standard can't mandate a type compatibility test that requires an
>>> arbitrary non-constant expression to be evaluated, so in one way it is
>>> not surprising that there is no error message. Unfortunately I can't
>>> square that with the requirement to issue a diagnostic when a pointer to
>>> an incompatible type is passed to a function.
>>
>> The VLA type is compatible with the non-VLA type, per the first
>> sentence of 6.7.5.2p6.
>
> Oh, I see. I am amazed at how differently I read it. I think it would
> be clearer as two sentences:
>
> "For two array types to be compatible, both shall have compatible
> element types. If both size specifiers are present, and are integer
> constant expressions, then both size specifiers shall have the same
> constant value."
>
> but it's late, and no doubt that carries some other unintended meaning.
As written, one problem is the second sentence is (arguably)
decoupled from the definition of compatibility, so its 'shall'
again just causes UB on length mismatches rather than forcing
a diagnostic. Writing Standard-suitable text is a lot harder
than it looks.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
multidimensional heap arrays Jack Boot <jackboot@mailinator.com> - 2011-04-25 19:36 +0000
Re: multidimensional heap arrays Francois Grieu <fgrieu@gmail.com> - 2011-04-25 23:16 +0200
Re: multidimensional heap arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-25 22:35 +0100
Re: multidimensional heap arrays Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2011-04-25 21:19 -0700
Re: multidimensional heap arrays Francois Grieu <fgrieu@gmail.com> - 2011-04-26 08:19 +0200
Re: multidimensional heap arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-26 12:19 +0100
Re: multidimensional heap arrays Ian Collins <ian-news@hotmail.com> - 2011-04-26 23:25 +1200
Re: multidimensional heap arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-26 21:06 +0100
Re: multidimensional heap arrays Ian Collins <ian-news@hotmail.com> - 2011-04-27 08:59 +1200
Re: multidimensional heap arrays Keith Thompson <kst-u@mib.org> - 2011-04-26 14:39 -0700
Re: multidimensional heap arrays Ian Collins <ian-news@hotmail.com> - 2011-04-27 10:03 +1200
Re: multidimensional heap arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-26 23:41 +0100
Re: multidimensional heap arrays Keith Thompson <kst-u@mib.org> - 2011-04-26 16:33 -0700
Re: multidimensional heap arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-27 04:05 +0100
Re: multidimensional heap arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-26 22:49 +0100
Re: multidimensional heap arrays Ian Collins <ian-news@hotmail.com> - 2011-04-27 10:19 +1200
Re: multidimensional heap arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-27 00:38 +0100
Re: multidimensional heap arrays Ian Collins <ian-news@hotmail.com> - 2011-04-27 11:48 +1200
Re: multidimensional heap arrays Keith Thompson <kst-u@mib.org> - 2011-04-26 17:38 -0700
Re: multidimensional heap arrays Ian Collins <ian-news@hotmail.com> - 2011-04-27 13:08 +1200
Re: multidimensional heap arrays Tim Rentsch <txr@alumni.caltech.edu> - 2011-04-26 18:31 -0700
Re: multidimensional heap arrays Ian Collins <ian-news@hotmail.com> - 2011-04-27 14:01 +1200
Re: multidimensional heap arrays Tim Rentsch <txr@alumni.caltech.edu> - 2011-04-27 00:04 -0700
Re: multidimensional heap arrays Ian Collins <ian-news@hotmail.com> - 2011-04-27 19:58 +1200
Re: multidimensional heap arrays Ian Collins <ian-news@hotmail.com> - 2011-04-27 20:03 +1200
Re: multidimensional heap arrays Keith Thompson <kst-u@mib.org> - 2011-04-27 00:03 -0700
Re: multidimensional heap arrays Tim Rentsch <txr@alumni.caltech.edu> - 2011-04-26 18:20 -0700
Re: multidimensional heap arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-27 03:59 +0100
Re: multidimensional heap arrays Tim Rentsch <txr@alumni.caltech.edu> - 2011-04-27 00:24 -0700
Re: multidimensional heap arrays "io_x" <a@b.c.invalid> - 2011-04-26 09:42 +0200
Re: multidimensional heap arrays Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-04-25 20:50 -0400
Re: multidimensional heap arrays James Kuyper <jameskuyper@verizon.net> - 2011-04-25 22:57 -0400
csiph-web