Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: on confusing procedure names with the address of procedures
Date: Fri, 29 Oct 2021 18:29:48 -0700
Organization: None to speak of
Lines: 42
Message-ID: <878rybz4dv.fsf@nosuchdomain.example.com>
References: <86bl37e49v.fsf@levado.to> <address-of-20211030021305@ram.dialup.fu-berlin.de>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="679ddad86518bcd07b55dfd2beeff025"; logging-data="14946"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+hd2ISmSAEsKlfGzTMylgJ"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:y36N2FVMH1VhbZMq43wAkMoXMno= sha1:fWgcaPKvMS+uKYiopXcwQS++lrs=
Xref: csiph.com comp.lang.c:163262

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Meredith Montgomery <mmontgomery@levado.to> writes:
>>printf("and the addr of the addr of c1 is at %p\n", &&c1);
>
>   The operand of the unary & operator shall be either a
>   function designator, the result of a [] or unary * operator,
>   or an /lvalue/ that designates an object that is * not a
>   bit-field and is not declared with the register
>   storage-class specifier.
>
>   The unary & operator yields the /address/ of its operand.
>   Such an address is a mere data value, not an object.
>   It is not an lvalue. So it does not have an address.
>   So, one cannot use "&&c1".
>
>   Therefore, the GNU compiler uses "&&" as its notation to
>   take the address of a /label/, but this is not standard C.

And gcc does this because "&&" is already a token (the logical "and"
operator).  Since C uses the "maximal munch" rule, the sequence
    &&c
is tokenized as "&&" followed by "c".  If it were legal to apply unary "&"
to a unary "&" operation you'd have to write it as:
    & &c
or
    &(&c)

That would probably give you (Meredith) an error message closer to what
you were expecting.

The "maximal munch" rule is why
    x+++++y
is tokenized as
    x ++ ++ + y
(a syntax error) rather than as
    x ++ + ++ y
(which could be a valid expression).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */