Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Incompatible pointer types with GCC |
| Date | 2016-12-18 20:11 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <87r3555769.fsf@bsb.me.uk> (permalink) |
| References | <o30g9b$v1l$1@dont-email.me> <87eg172468.fsf@bsb.me.uk> <o31o7a$f7g$1@dont-email.me> <641f9236-55db-4b01-aab0-4848d055318f@googlegroups.com> |
martin.uecker@med.uni-goettingen.de writes: > On Friday, December 16, 2016 at 11:02:46 PM UTC+1, August Karlstrom wrote: >> On 2016-12-16 18:07, Ben Bacarisse wrote: >> > August Karlstrom <fusionfile@gmail.com> writes: >> > The [] might confuse some people. This is simply >> > >> > void P(const Row *A) >> >> I prefer to use brackets when a sequence is expected, it provides more >> semantic information. >> >> >> test.c:3:6: note: expected ‘const int (*)[10]’ but argument is of type >> >> ‘int (*)[10]’ >> >> void P(const Row A[]) >> >> ^ >> > >> > I think gcc is right to complain. >> > >> > Whilst the types are not compatible, that's not really the problem here. >> > For example, you can pass an int * to a function that takes const int * >> > and those two types are not compatible. Argument passing is done "as if >> > by assignment", and in an assignment the pointed-to type on the left can >> > have extra qualifiers. But here, the const qualifies the element type, >> > not the pointed-to type, which is an array type. (C has not qualified >> > array types at all). >> >> That's counter-intuitive. I thought const applied to Row. > > Yes, I hope (and it seems) that this gets fixed in the next revision > of the C standard. Arrays should behave like structs with respect > to const but currently they don't. > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1923.htm Interesting. Thanks for posting that. > Without '-pedantic' gcc will accept this, so I recommend to use > this non-standard extension instead of adding casts which > break type safety. Casts can break type safety, but in this case that cast is really just permitting a safe operation currently ruled out by the language. It may be that the value of -pedantic outweighs the concerns about adding what is, after all, a safe cast. -- Ben.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Incompatible pointer types with GCC August Karlstrom <fusionfile@gmail.com> - 2016-12-16 11:41 +0100
Re: Incompatible pointer types with GCC BartC <bc@freeuk.com> - 2016-12-16 11:06 +0000
Re: Incompatible pointer types with GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 17:07 +0000
Re: Incompatible pointer types with GCC August Karlstrom <fusionfile@gmail.com> - 2016-12-16 23:02 +0100
Re: Incompatible pointer types with GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 00:48 +0000
Re: Incompatible pointer types with GCC martin.uecker@med.uni-goettingen.de - 2016-12-18 08:06 -0800
Re: Incompatible pointer types with GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-18 20:11 +0000
Re: Incompatible pointer types with GCC supercat@casperkitty.com - 2016-12-18 14:43 -0800
Re: Incompatible pointer types with GCC Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 13:33 -0800
csiph-web