Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #168537
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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