Re: on confusing procedure names with the address of procedures

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> (permalink)
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

Show key headers only | View raw

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 */

Thread

on confusing procedure names with the address of procedures Meredith Montgomery <mmontgomery@levado.to> - 2021-10-29 21:37 -0300
  Re: on confusing procedure names with the address of procedures Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-29 18:29 -0700
  Re: on confusing procedure names with the address of procedures Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 18:33 -0700
  Re: on confusing procedure names with the address of procedures Manfred <noname@add.invalid> - 2021-10-30 05:32 +0200
    Re: on confusing procedure names with the address of procedures James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-30 01:26 -0400
      Re: on confusing procedure names with the address of procedures Manfred <noname@add.invalid> - 2021-10-30 19:05 +0200
        Re: on confusing procedure names with the address of procedures James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-30 15:17 -0400
  Re: on confusing procedure names with the address of procedures Bart <bc@freeuk.com> - 2021-10-30 11:36 +0100
  Re: on confusing procedure names with the address of procedures Noob <root@127.0.0.1> - 2021-11-01 13:03 +0100

csiph-web