Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: *&aptr , &*aptr question Date: Tue, 14 Jun 2016 16:51:03 -0700 Organization: None to speak of Lines: 61 Message-ID: References: <9e50cd7d-da7b-4f90-9c83-57799cd07ad6@googlegroups.com> <12ba4330-5009-077d-83d8-3e41a7221f7f@verizon.net> <81f2561c-bea5-4846-9d10-9862764110ef@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="4781"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX198pprMNgh7tbxZUiPW1ltN" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:3O6+7Ukl9fHFXjaIq17aJ9vB7L8= sha1:i8xdcKJbPoxFg6f0JsFSEFyIFf8= Xref: csiph.com comp.lang.c:89121 BartC writes: [...] > What's going on here then: > > int* Ptr; > > Ptr = Ptr; > Ptr = *Ptr; > Ptr = &Ptr; > Ptr = &*Ptr; > Ptr = *&Ptr; > > Ptr = &*&Ptr; > Ptr = *&*Ptr; > > Ptr = &*&*Ptr; > Ptr = *&*&Ptr; > > These are all fine according to gcc (and TCC and clang; other compilers > aren't quite so happy). What do you mean by "fine"? Did you not get warnings? gcc is notorious for issuing non-fatal warnings by default for some constraint violations. Surely you've seen that mentioned here before. I get: c.c: In function ‘main’: c.c:7:9: warning: assignment makes pointer from integer without a cast [enabled by default] Ptr = *Ptr; ^ c.c:8:9: warning: assignment from incompatible pointer type [enabled by default] Ptr = &Ptr; ^ c.c:12:9: warning: assignment from incompatible pointer type [enabled by default] Ptr = &*&Ptr; ^ c.c:13:9: warning: assignment makes pointer from integer without a cast [enabled by default] Ptr = *&*Ptr; ^ If you really didn't get any warnings, what version of gcc are you using? If you did, why the &*&* didn't you mention that fact? (Use the -pedantic-errors option if you want fatal errors for constraint violations.) (Of course the standard only requires a diagnostic message, so this isn't a conformance violation.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"