Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #168537

Re: typedef in old C

From Kaz Kylheku <864-117-4973@kylheku.com>
Newsgroups comp.lang.c
Subject Re: typedef in old C
Date 2022-12-13 18:07 +0000
Organization A noiseless patient Spider
Message-ID <20221213095812.129@kylheku.com> (permalink)
References <tn9vlg$5ra$1@gioia.aioe.org> <1b20f5a8-6319-4bda-abec-240a9ca3e979n@googlegroups.com> <69bf93cf-c747-497f-8236-94c848b0a66an@googlegroups.com> <tna7ai$aer$1@gioia.aioe.org>

Show all headers | View raw


On 2022-12-13, Bart <bc@freeuk.com> wrote:
> On 13/12/2022 14:46, Thiago Adams wrote:
>> On Tuesday, December 13, 2022 at 11:42:43 AM UTC-3, Thiago Adams wrote:
>> ...
>>> I think this is one of the biggest problem of C.. but this bothers more implementers.
>> 
>> The data representation of C types are incredible complex.
>> 
>> Also types can have extra parentheses that are useless like:
>> int (((a)));
>
> Most languages will allow (((a))) in expressions too; it is not unusual.
>
> What's different with C is treating a type specification as though it 
> was an expression too, which can be confusing if you come across it 
> unexpectedly. So:
>
>      f(x);
>
> looks like a function call, but could equally be declaring 'x' of type 
> 'f', depending on what 'f' actually is.

Similarly:

  (f)(x)

can be casting (x) to type f, or calling f(x).

> Mixing up expression syntax and type syntax was deliberate, but also a 
> mistake.

They aren't deep abiguities in the sense that while scanning the f
token, we can resolve it by looking up f, and giving it a token category
like "type-name" versus "identifier". Then the parser just has rules
that involve "type-name".

Still, anyone who just wants an accurate C parser has to implement
declarations, which is annoying.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

typedef in old C Bart <bc@freeuk.com> - 2022-12-13 13:45 +0000
  Re: typedef in old C Thiago Adams <thiago.adams@gmail.com> - 2022-12-13 06:42 -0800
    Re: typedef in old C Thiago Adams <thiago.adams@gmail.com> - 2022-12-13 06:46 -0800
      Re: typedef in old C Bart <bc@freeuk.com> - 2022-12-13 15:56 +0000
        Re: typedef in old C Kaz Kylheku <864-117-4973@kylheku.com> - 2022-12-13 18:07 +0000
          Re: typedef in old C Thiago Adams <thiago.adams@gmail.com> - 2022-12-13 11:11 -0800
  Re: typedef in old C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-13 16:40 +0000
    Re: typedef in old C scott@slp53.sl.home (Scott Lurndal) - 2022-12-13 17:05 +0000
    Re: typedef in old C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-13 10:27 -0800
    Re: typedef in old C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-18 17:25 -0800
  Re: typedef in old C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-13 10:30 -0800
  Re: typedef in old C luser droog <luser.droog@gmail.com> - 2022-12-14 09:42 -0800
    Re: typedef in old C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-14 20:59 +0000
      Re: typedef in old C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-14 13:44 -0800
        Re: typedef in old C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-15 02:46 +0000
      Re: typedef in old C scott@slp53.sl.home (Scott Lurndal) - 2022-12-15 15:01 +0000
        Re: typedef in old C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-15 17:07 +0000
      Re: typedef in old C luser droog <luser.droog@gmail.com> - 2022-12-15 18:34 -0800
        Re: typedef in old C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-16 17:41 +0000
  Re: typedef in old C Bonita Montero <Bonita.Montero@gmail.com> - 2022-12-17 07:54 +0100

csiph-web