Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #167206 > unrolled thread
| Started by | antispam@math.uni.wroc.pl |
|---|---|
| First post | 2022-08-25 02:33 +0000 |
| Last post | 2022-08-25 20:30 +0000 |
| Articles | 20 on this page of 236 — 17 participants |
Back to article view | Back to comp.lang.c
Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-08-25 02:33 +0000
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-25 03:00 +0000
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-08-26 00:22 +0000
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-26 16:48 +0000
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-25 03:01 -0700
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-08-25 14:29 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-25 08:10 -0700
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-08-25 16:23 +0000
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-25 20:53 +0200
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-26 06:56 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-26 17:29 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-26 13:44 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-26 13:56 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-26 16:01 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 10:27 +0200
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-28 03:52 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 15:05 +0200
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-28 17:00 -0700
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-29 15:16 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 09:38 +0200
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-30 04:03 -0700
Re: Are there any conformant C compilers? Anton Shepelev <anton.txt@gmail.com> - 2022-08-31 01:20 +0300
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 09:14 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 06:19 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 06:11 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 17:20 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 12:31 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 12:49 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-28 21:29 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-28 17:49 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-29 02:58 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-28 19:51 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-29 10:54 +0100
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-12 05:13 -0700
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 13:55 +0000
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 15:06 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 15:22 +0000
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 17:04 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 17:39 +0000
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 17:40 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 15:52 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 17:24 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 22:55 +0200
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 22:51 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 14:57 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 00:46 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 16:13 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 08:47 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 20:13 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 20:30 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 09:36 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 00:43 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 10:44 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 04:50 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 05:48 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 14:31 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 15:15 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 16:41 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 08:55 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 17:43 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 18:37 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 19:30 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-08-31 18:47 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 20:37 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-08-31 19:47 +0000
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-01 09:45 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 11:55 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-01 05:23 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 14:20 +0100
Re: Are there any conformant C compilers? Manfred <noname@add.invalid> - 2022-09-03 02:20 +0200
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-03 00:25 +0000
Re: Are there any conformant C compilers? Manfred <noname@add.invalid> - 2022-09-03 02:46 +0200
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-03 10:11 +0200
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-03 12:54 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-03 12:52 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-03 21:08 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-03 12:46 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 01:25 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-01 11:17 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 12:04 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-01 16:06 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-04 23:24 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-31 11:39 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 18:57 +0200
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-02 17:37 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 23:51 +0100
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-03 01:23 +0000
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-02 20:42 -0700
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-03 14:34 +0000
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-03 17:39 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 12:00 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 14:45 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-03 17:40 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 17:30 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-04 15:02 +0200
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-04 22:45 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 01:02 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-05 08:22 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 12:28 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-05 15:52 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 15:15 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-05 22:54 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 22:49 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-05 23:05 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-06 01:41 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-06 09:39 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-06 10:50 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-06 15:29 +0200
Re: Are there any conformant C compilers? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2022-09-06 17:05 +0300
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-06 15:43 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-06 17:19 +0200
Re: Are there any conformant C compilers? tTh <tth@none.invalid> - 2022-09-06 18:19 +0200
Re: Are there any conformant C compilers? Öö Tiib <ootiib@hot.ee> - 2022-09-08 06:18 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-07 18:10 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-07 20:31 +0200
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-07 19:41 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-07 22:05 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-08 10:07 +0200
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-05 21:42 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 23:11 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-05 23:03 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-06 01:02 +0100
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-05 12:27 +0000
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-05 21:40 +0000
Re: Are there any conformant C compilers? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-05 14:55 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-03 20:24 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 22:30 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-04 00:19 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-04 12:35 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-04 14:17 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-04 15:20 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-04 15:58 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-04 18:00 +0100
Re: Are there any conformant C compilers? Manfred <noname@add.invalid> - 2022-09-04 19:26 +0200
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-03 16:24 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 18:23 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-03 13:56 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 06:52 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 15:06 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 12:50 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 15:19 +0200
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-28 16:51 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 09:45 +0200
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 10:04 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-29 04:59 -0700
Re: Are there any conformant C compilers? Öö Tiib <ootiib@hot.ee> - 2022-08-29 07:32 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 16:47 +0200
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-29 17:51 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 13:15 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-30 14:58 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-30 15:54 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 09:17 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-30 18:34 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 11:25 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 14:14 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 15:28 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 15:02 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 15:28 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 17:06 +0200
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-08-31 15:29 +0000
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 17:48 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 19:58 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 20:31 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-31 13:01 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 15:26 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-31 15:42 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-01 10:00 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-01 04:35 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-01 15:10 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 00:09 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-02 09:30 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 13:24 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 05:56 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 15:14 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 16:19 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 17:52 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 10:01 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-02 11:50 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 12:18 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 20:45 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 13:08 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 21:41 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 13:55 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 23:29 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 16:25 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-03 10:23 +0200
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-03 13:07 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-03 15:06 +0200
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 21:22 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 12:01 +0100
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 07:40 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-12 12:32 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-12 09:33 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 07:34 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-13 16:41 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-14 07:41 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-14 11:06 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-15 01:03 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-16 06:52 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-15 00:14 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-15 17:29 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-19 02:33 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 21:07 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-02 11:03 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 20:47 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-02 15:52 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 16:01 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-02 19:22 +0200
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-02 10:50 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 00:30 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 21:35 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-01 10:14 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 07:58 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 17:49 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 09:02 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 18:36 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 09:25 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 05:31 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 17:08 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 08:40 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 08:50 -0700
Re: Are there any conformant C compilers? Opus <ifonly@youknew.org> - 2022-08-27 20:04 +0200
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-25 17:03 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 09:50 -0700
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-25 12:04 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 12:25 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-25 08:23 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 09:58 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-26 07:51 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-26 11:50 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-26 19:45 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-26 22:03 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-27 08:14 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-27 11:23 -0700
Re: Are there any conformant C compilers? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-08-25 12:41 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-25 20:30 +0000
Page 10 of 12 — ← Prev page 1 … 8 9 [10] 11 12 Next page →
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-09-02 13:08 -0700 |
| Message-ID | <f78eb4b4-e249-4748-a5a3-72cfa93c84efn@googlegroups.com> |
| In reply to | #167439 |
On Friday, September 2, 2022 at 4:46:00 PM UTC-3, Ben Bacarisse wrote:
> Thiago Adams <thiago...@gmail.com> writes:
>
> > On Friday, September 2, 2022 at 1:53:06 PM UTC-3, Bart wrote:
> >> On 02/09/2022 16:19, Ben Bacarisse wrote:
> >> > Bart <b...@freeuk.com> writes:
> >> >
> >> >>>> The only other actual literal is a string.
> >> >>> How about compound literals?
> >> >>
> >> >> The 'literal' in those is just a term somebody decided use.
> >> >
> >> > They are literals because they describe a specific value in the source
> >> > code. The value is "literally" in the source.
> >> >
> >> >> (Elsewhere I would call them constructors.)
> >> >
> >> > Sure. And the ASCII digit 1 is a constructor for an int value. And a "
> >> > optionally followed by characters and another " is a constructor for a
> >> > char array object.
> >> >
> >> > Both terms work, but the one C has chosen is "literal".
> >> >
> >> Some constructors are special:
> >>
> >> 123456
> >> 123.456
> >> "abcdef"
> >> 'A'
> >>
> >> because they can /only/ comprise values known at compile-time. These I
> >> like to call literals.
> >
> > Compound literals also are values known at compile time.
> They /may/ be but they don't have to be (except at file scope). And yet
> the syntax is still called a compound literal.
>
> Bart had a point here. The only guaranteed compile-time literal part is
> the structure and not the actual value.
What do you mean?
Maybe this?
void F(int i)
{
constexpr struct X { int i; } x = {i};
}
//error: 'i' is not a constant expression
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-02 21:41 +0100 |
| Message-ID | <878rn1h5lk.fsf@bsb.me.uk> |
| In reply to | #167441 |
Thiago Adams <thiago.adams@gmail.com> writes:
> On Friday, September 2, 2022 at 4:46:00 PM UTC-3, Ben Bacarisse wrote:
>> Thiago Adams <thiago...@gmail.com> writes:
>>
>> > On Friday, September 2, 2022 at 1:53:06 PM UTC-3, Bart wrote:
>> >> On 02/09/2022 16:19, Ben Bacarisse wrote:
>> >> > Bart <b...@freeuk.com> writes:
>> >> >
>> >> >>>> The only other actual literal is a string.
>> >> >>> How about compound literals?
>> >> >>
>> >> >> The 'literal' in those is just a term somebody decided use.
>> >> >
>> >> > They are literals because they describe a specific value in the source
>> >> > code. The value is "literally" in the source.
>> >> >
>> >> >> (Elsewhere I would call them constructors.)
>> >> >
>> >> > Sure. And the ASCII digit 1 is a constructor for an int value. And a "
>> >> > optionally followed by characters and another " is a constructor for a
>> >> > char array object.
>> >> >
>> >> > Both terms work, but the one C has chosen is "literal".
>> >> >
>> >> Some constructors are special:
>> >>
>> >> 123456
>> >> 123.456
>> >> "abcdef"
>> >> 'A'
>> >>
>> >> because they can /only/ comprise values known at compile-time. These I
>> >> like to call literals.
>> >
>> > Compound literals also are values known at compile time.
>> They /may/ be but they don't have to be (except at file scope). And yet
>> the syntax is still called a compound literal.
>>
>> Bart had a point here. The only guaranteed compile-time literal part is
>> the structure and not the actual value.
>
> What do you mean?
>
> Maybe this?
> void F(int i)
> {
> constexpr struct X { int i; } x = {i};
> }
> //error: 'i' is not a constant expression
No, I think we have crossed wires. Compound literals can have constant
initialisers (and must have constant initialisers when at file scope),
but they can also have non-constant initialisers inside functions.
constexpr does not come into it.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-09-02 13:55 -0700 |
| Message-ID | <9586550c-6a4b-4a75-a10a-25f26e109b85n@googlegroups.com> |
| In reply to | #167442 |
On Friday, September 2, 2022 at 5:41:26 PM UTC-3, Ben Bacarisse wrote:
> Thiago Adams <thiago...@gmail.com> writes:
>
> > On Friday, September 2, 2022 at 4:46:00 PM UTC-3, Ben Bacarisse wrote:
> >> Thiago Adams <thiago...@gmail.com> writes:
> >>
> >> > On Friday, September 2, 2022 at 1:53:06 PM UTC-3, Bart wrote:
> >> >> On 02/09/2022 16:19, Ben Bacarisse wrote:
> >> >> > Bart <b...@freeuk.com> writes:
> >> >> >
> >> >> >>>> The only other actual literal is a string.
> >> >> >>> How about compound literals?
> >> >> >>
> >> >> >> The 'literal' in those is just a term somebody decided use.
> >> >> >
> >> >> > They are literals because they describe a specific value in the source
> >> >> > code. The value is "literally" in the source.
> >> >> >
> >> >> >> (Elsewhere I would call them constructors.)
> >> >> >
> >> >> > Sure. And the ASCII digit 1 is a constructor for an int value. And a "
> >> >> > optionally followed by characters and another " is a constructor for a
> >> >> > char array object.
> >> >> >
> >> >> > Both terms work, but the one C has chosen is "literal".
> >> >> >
> >> >> Some constructors are special:
> >> >>
> >> >> 123456
> >> >> 123.456
> >> >> "abcdef"
> >> >> 'A'
> >> >>
> >> >> because they can /only/ comprise values known at compile-time. These I
> >> >> like to call literals.
> >> >
> >> > Compound literals also are values known at compile time.
> >> They /may/ be but they don't have to be (except at file scope). And yet
> >> the syntax is still called a compound literal.
> >>
> >> Bart had a point here. The only guaranteed compile-time literal part is
> >> the structure and not the actual value.
> >
> > What do you mean?
> >
> > Maybe this?
> > void F(int i)
> > {
> > constexpr struct X { int i; } x = {i};
> > }
> > //error: 'i' is not a constant expression
> No, I think we have crossed wires. Compound literals can have constant
> initialisers (and must have constant initialisers when at file scope),
> but they can also have non-constant initialisers inside functions.
> constexpr does not come into it.
>
Maybe this sample will give the perspective that compound literal
and string literals are the same.
#include <stdio.h>
int main()
{
printf("%s\n", (char []){'a', 'b', '\0'});
printf("%s\n", "ab");
}
having c23 storage specifiers
printf("%s\n", (static char []){'a', 'b', '\0'});
Some difference is that "literal string" or 1 or 1.2
have the type implicitly defined. But we can also add
type using different forms.
printf("%ld", ((long)1));
printf("%ld", ((long){1}));
printf("%ld", 1L);
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-02 23:29 +0100 |
| Message-ID | <87tu5pfm0t.fsf@bsb.me.uk> |
| In reply to | #167443 |
Thiago Adams <thiago.adams@gmail.com> writes:
> Maybe this sample will give the perspective that compound literal
> and string literals are the same.
I don't see why you are posting this. What about the code do you think
I don't know or don't accept?
(They are not exactly the same in that you can't initialise a declared
array with a char[] compound literal, but that's not the point.)
> #include <stdio.h>
> int main()
> {
> printf("%s\n", (char []){'a', 'b', '\0'});
> printf("%s\n", "ab");
> }
>
> having c23 storage specifiers
>
> printf("%s\n", (static char []){'a', 'b', '\0'});
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-09-02 16:25 -0700 |
| Message-ID | <38331300-95c3-4499-aa89-062b82974309n@googlegroups.com> |
| In reply to | #167444 |
On Friday, September 2, 2022 at 7:29:38 PM UTC-3, Ben Bacarisse wrote: > Thiago Adams <thiago...@gmail.com> writes: > > > Maybe this sample will give the perspective that compound literal > > and string literals are the same. > I don't see why you are posting this. What about the code do you think > I don't know or don't accept? I am just trying to understand if you or Bart are considering these compound literals different from string literal or numeric. We all understand how it works. I am just offering my perspective that for me they are all the same.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-03 10:23 +0200 |
| Message-ID | <tev2uo$2r5ie$1@dont-email.me> |
| In reply to | #167446 |
On 03/09/2022 01:25, Thiago Adams wrote:
> On Friday, September 2, 2022 at 7:29:38 PM UTC-3, Ben Bacarisse wrote:
>> Thiago Adams <thiago...@gmail.com> writes:
>>
>>> Maybe this sample will give the perspective that compound literal
>>> and string literals are the same.
>> I don't see why you are posting this. What about the code do you think
>> I don't know or don't accept?
>
> I am just trying to understand if you or Bart are considering these compound literals
> different from string literal or numeric.
> We all understand how it works.
>
> I am just offering my perspective that for me they are all the same.
Again, I think your wires are slightly crossed. Ben's point (and he'll
correct me if I'm wrong) is that you can write :
void foo(char x, char y) {
printf("%s\n", (char []){ x, y, 0 });
}
The second argument to printf is, in C terminology, a "compound literal"
- despite its value not being determined until runtime.
Does that help?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-03 13:07 +0100 |
| Message-ID | <87czccfyq0.fsf@bsb.me.uk> |
| In reply to | #167453 |
David Brown <david.brown@hesbynett.no> writes:
> On 03/09/2022 01:25, Thiago Adams wrote:
>> On Friday, September 2, 2022 at 7:29:38 PM UTC-3, Ben Bacarisse wrote:
>>> Thiago Adams <thiago...@gmail.com> writes:
>>>
>>>> Maybe this sample will give the perspective that compound literal
>>>> and string literals are the same.
>>> I don't see why you are posting this. What about the code do you think
>>> I don't know or don't accept?
>> I am just trying to understand if you or Bart are considering these compound literals
>> different from string literal or numeric.
>> We all understand how it works.
>> I am just offering my perspective that for me they are all the same.
>
> Again, I think your wires are slightly crossed. Ben's point (and
> he'll correct me if I'm wrong) is that you can write :
Well it was Bart's point originally. I don't think there's any
confusion about what's possible. I just think there been some wires
crossed at some point.
> void foo(char x, char y) {
> printf("%s\n", (char []){ x, y, 0 });
> }
>
> The second argument to printf is, in C terminology, a "compound
> literal" - despite its value not being determined until runtime.
I am pretty sure everyone in the thread knows all the facts!
Thinking about it a bit more, the common factor with all literals is
that they represent /anonymous/ values. Without compound literals you
could not write a value of any aggregate type, other than char[]. And
if C were to get lambdas (anonymous functions), it might be reasonable
to call them function literals. I don't know if that's a common usage,
but it would explain how C uses the term.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-03 15:06 +0200 |
| Message-ID | <tevjg7$2sppo$1@dont-email.me> |
| In reply to | #167456 |
On 03/09/2022 14:07, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 03/09/2022 01:25, Thiago Adams wrote:
>>> On Friday, September 2, 2022 at 7:29:38 PM UTC-3, Ben Bacarisse wrote:
>>>> Thiago Adams <thiago...@gmail.com> writes:
>>>>
>>>>> Maybe this sample will give the perspective that compound literal
>>>>> and string literals are the same.
>>>> I don't see why you are posting this. What about the code do you think
>>>> I don't know or don't accept?
>>> I am just trying to understand if you or Bart are considering these compound literals
>>> different from string literal or numeric.
>>> We all understand how it works.
>>> I am just offering my perspective that for me they are all the same.
>>
>> Again, I think your wires are slightly crossed. Ben's point (and
>> he'll correct me if I'm wrong) is that you can write :
>
> Well it was Bart's point originally. I don't think there's any
> confusion about what's possible. I just think there been some wires
> crossed at some point.
>
>> void foo(char x, char y) {
>> printf("%s\n", (char []){ x, y, 0 });
>> }
>>
>> The second argument to printf is, in C terminology, a "compound
>> literal" - despite its value not being determined until runtime.
>
> I am pretty sure everyone in the thread knows all the facts!
>
> Thinking about it a bit more, the common factor with all literals is
> that they represent /anonymous/ values. Without compound literals you
> could not write a value of any aggregate type, other than char[]. And
> if C were to get lambdas (anonymous functions), it might be reasonable
> to call them function literals. I don't know if that's a common usage,
> but it would explain how C uses the term.
>
Terminology morphs over time, sometimes beyond all recognition from the
common language meaning of the word. "Register" in C means "you can't
take the address of this object". "Inline" in C++ means "can be defined
in multiple units as long as the definition is the same in each". And
$DEITY only knows a succinct way to express the meaning of "static" :-)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-11 21:22 -0700 |
| Message-ID | <86mtb5p6gd.fsf@linuxsc.com> |
| In reply to | #167456 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 03/09/2022 01:25, Thiago Adams wrote:
>>
>>> On Friday, September 2, 2022 at [...], Ben Bacarisse wrote:
>>>
>>>> Thiago Adams <thiago...@gmail.com> writes:
>>>>
>>>>> Maybe this sample will give the perspective that compound
>>>>> literal and string literals are the same.
>>>>
>>>> I don't see why you are posting this. What about the code do
>>>> you think I don't know or don't accept?
>>>
>>> I am just trying to understand if you or Bart are considering
>>> these compound literals different from string literal or
>>> numeric.
>>> We all understand how it works. I am just offering my
>>> perspective that for me they are all the same.
>>
>> Again, I think your wires are slightly crossed. Ben's point (and
>> he'll correct me if I'm wrong) is that you can write :
>
> Well it was Bart's point originally. I don't think there's any
> confusion about what's possible. I just think there been some
> wires crossed at some point.
>
>> void foo(char x, char y) {
>> printf("%s\n", (char []){ x, y, 0 });
>> }
>>
>> The second argument to printf is, in C terminology, a "compound
>> literal" - despite its value not being determined until runtime.
>
> I am pretty sure everyone in the thread knows all the facts!
>
> Thinking about it a bit more, the common factor with all literals is
> that they represent /anonymous/ values. Without compound literals you
> could not write a value of any aggregate type, other than char[].
The key difference is that "constants" are values, and "literals"
are objects.
That difference is a significant distinction, and justifies using
different words for the two kinds of syntactic elements.
> And if C were to get lambdas (anonymous functions), it might be
> reasonable to call them function literals. I don't know if that's
> a common usage, but it would explain how C uses the term.
Right. It never makes sense -- nor is it allowed -- to take the
address of a constant. It does make sense -- and furthermore is
allowed -- to take the address of a literal. Presumably lambdas,
aka anonymous functions, could have their addresses taken, which
makes "function literal" the natural terminology to use.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-12 12:01 +0100 |
| Message-ID | <874jxcyhyh.fsf@bsb.me.uk> |
| In reply to | #167628 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: <cut> >> Thinking about it a bit more, the common factor with all literals is >> that they represent /anonymous/ values. Without compound literals you >> could not write a value of any aggregate type, other than char[]. > > The key difference is that "constants" are values, and "literals" > are objects. That's how C uses the term (for the time being) but it's hardly universal. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-13 07:40 -0700 |
| Message-ID | <861qsfpcc2.fsf@linuxsc.com> |
| In reply to | #167634 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > > <cut> > >>> Thinking about it a bit more, the common factor with all literals is >>> that they represent /anonymous/ values. Without compound literals you >>> could not write a value of any aggregate type, other than char[]. >> >> The key difference is that "constants" are values, and "literals" >> are objects. > > That's how C uses the term (for the time being) but it's hardly > universal. Certainly I didn't mean to imply that these usages are universal; only that the ISO C standard observes them consistently, and that in the context of the C standard the distinction is a useful one.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-12 12:32 +0100 |
| Message-ID | <tfn5bh$4mc$1@gioia.aioe.org> |
| In reply to | #167628 |
On 12/09/2022 05:22, Tim Rentsch wrote: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> Thinking about it a bit more, the common factor with all literals is >> that they represent /anonymous/ values. Without compound literals you >> could not write a value of any aggregate type, other than char[]. > > The key difference is that "constants" are values, and "literals" > are objects. So a literal like 726163 is an object, and not a value? Okay... I've never really used 'literal' but picked it up from hanging around here. Personally, I'd use 'integer-constant' for 726163, 'char-constant' for 'A', 'real-constant' for 72.6163, and 'string-constant' for "ABC".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-12 09:33 -0700 |
| Message-ID | <87edwgimda.fsf@nosuchdomain.example.com> |
| In reply to | #167635 |
Bart <bc@freeuk.com> writes:
> On 12/09/2022 05:22, Tim Rentsch wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>>> Thinking about it a bit more, the common factor with all literals is
>>> that they represent /anonymous/ values. Without compound literals you
>>> could not write a value of any aggregate type, other than char[].
>> The key difference is that "constants" are values, and "literals"
>> are objects.
>
> So a literal like 726163 is an object, and not a value?
>
> Okay...
>
> I've never really used 'literal' but picked it up from hanging around here.
>
> Personally, I'd use 'integer-constant' for 726163, 'char-constant' for
> 'A', 'real-constant' for 72.6163, and 'string-constant' for "ABC".
The C standard calls 726163 a "constant", not a "literal". It uses the
term "literal" only for string literals and compound literals.
However, other languages do refer to 726163 as a "literal" (my vague
impression is that *most* languages do so; certainly C++ does), and it's
common for C programmers to use the term "literal" informally. Which is
why I don't particularly like the idea that constants are values and
literals are objects. It happens to work out that way using the
terminology of the C standard, but I don't think it's a general
principle.
--
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 */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-13 07:34 -0700 |
| Message-ID | <865yhrpcl9.fsf@linuxsc.com> |
| In reply to | #167635 |
Bart <bc@freeuk.com> writes: > On 12/09/2022 05:22, Tim Rentsch wrote: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> >>> Thinking about it a bit more, the common factor with all literals is >>> that they represent /anonymous/ values. Without compound literals you >>> could not write a value of any aggregate type, other than char[]. >> >> The key difference is that "constants" are values, and "literals" >> are objects. > > So a literal like 726163 is an object, and not a value? As far as ISO C is concerned, the token '726163' is a constant, not a literal, and is a value rather than an object.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <480-992-1380@kylheku.com> |
|---|---|
| Date | 2022-09-13 16:41 +0000 |
| Message-ID | <20220913082247.233@kylheku.com> |
| In reply to | #167671 |
On 2022-09-13, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Bart <bc@freeuk.com> writes: > >> On 12/09/2022 05:22, Tim Rentsch wrote: >> >>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>> >>>> Thinking about it a bit more, the common factor with all literals is >>>> that they represent /anonymous/ values. Without compound literals you >>>> could not write a value of any aggregate type, other than char[]. >>> >>> The key difference is that "constants" are values, and "literals" >>> are objects. >> >> So a literal like 726163 is an object, and not a value? > > As far as ISO C is concerned, the token '726163' is a constant, > not a literal, and is a value rather than an object. The term "literal" in computer science is a shortening of "literal constant". (There are also symbolic/manifest constants.) ISO C carefully avoids using the unqualified term "literal"; it consistently uses the phrases "string literal" and "compound literal". The unqualified term "literal" is therefore not claimed by ISO C; Nowhere does ISO C say that a literal constant like 42 is *not* a literal; it just omits that usage itself and uses only the word "constant". Since the unqualified word "literal" is not used by ISO C, it may be used to talk about 42 without conflicting with ISO C. The "literal" in "literal constant" refers to the encoding of an object at its point of use in the program, by syntax which directly gives its value. It does not refer to the concept that the value, once obtained, is thereafter passed around by reference; literal constants may have reference or copy semantics. A "manifest constant" isn't a "literal constant" because it doesn't encode the value at the point of use; it encodes an identifier which resolves to the value through its definition elsewhere. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-14 07:41 -0700 |
| Message-ID | <86leqmm319.fsf@linuxsc.com> |
| In reply to | #167676 |
Kaz Kylheku <480-992-1380@kylheku.com> writes: > On 2022-09-13, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Bart <bc@freeuk.com> writes: >> >>> On 12/09/2022 05:22, Tim Rentsch wrote: >>> >>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>>> >>>>> Thinking about it a bit more, the common factor with all literals is >>>>> that they represent /anonymous/ values. Without compound literals you >>>>> could not write a value of any aggregate type, other than char[]. >>>> >>>> The key difference is that "constants" are values, and "literals" >>>> are objects. >>> >>> So a literal like 726163 is an object, and not a value? >> >> As far as ISO C is concerned, the token '726163' is a constant, >> not a literal, and is a value rather than an object. > > The term "literal" in computer science is a shortening of > "literal constant". (There are also symbolic/manifest constants.) I am not aware of any authoritative reference that defines the term "literal" for the field of computer science. In any case, my comments are only about how the terms "literal" and "constant" are used in the ISO C standard. This newsgroup is comp.lang.c, and I see nothing wrong in restricting the domain of my remarks to just that of the C language.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-14 11:06 -0700 |
| Message-ID | <87fsgthltw.fsf@nosuchdomain.example.com> |
| In reply to | #167717 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Kaz Kylheku <480-992-1380@kylheku.com> writes:
>
>> On 2022-09-13, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 12/09/2022 05:22, Tim Rentsch wrote:
>>>>
>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>>
>>>>>> Thinking about it a bit more, the common factor with all literals is
>>>>>> that they represent /anonymous/ values. Without compound literals you
>>>>>> could not write a value of any aggregate type, other than char[].
>>>>>
>>>>> The key difference is that "constants" are values, and "literals"
>>>>> are objects.
>>>>
>>>> So a literal like 726163 is an object, and not a value?
>>>
>>> As far as ISO C is concerned, the token '726163' is a constant,
>>> not a literal, and is a value rather than an object.
>>
>> The term "literal" in computer science is a shortening of
>> "literal constant". (There are also symbolic/manifest constants.)
>
> I am not aware of any authoritative reference that defines the
> term "literal" for the field of computer science.
>
> In any case, my comments are only about how the terms "literal"
> and "constant" are used in the ISO C standard. This newsgroup is
> comp.lang.c, and I see nothing wrong in restricting the domain of
> my remarks to just that of the C language.
Sure, but plenty of people informally use the word "literal" to refer to
constants. Even K&R2's reference manual says:
The characters /* introduce a comment, which terminates with the
characters */. Comments do not nest, and they do not occur within
string or character literals.
As much as I prefer to use the terminology defined in the standard, I
have no real problem with referring to 42 or 'x' as a literal.
I suggest that the "key difference" you see ("constants" are values, and
"literals" are objects") is accidental.
--
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 */
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <480-992-1380@kylheku.com> |
|---|---|
| Date | 2022-09-15 01:03 +0000 |
| Message-ID | <20220914171440.521@kylheku.com> |
| In reply to | #167724 |
On 2022-09-14, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> Kaz Kylheku <480-992-1380@kylheku.com> writes: >> >>> On 2022-09-13, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> Bart <bc@freeuk.com> writes: >>>> >>>>> On 12/09/2022 05:22, Tim Rentsch wrote: >>>>> >>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>>>>> >>>>>>> Thinking about it a bit more, the common factor with all literals is >>>>>>> that they represent /anonymous/ values. Without compound literals you >>>>>>> could not write a value of any aggregate type, other than char[]. >>>>>> >>>>>> The key difference is that "constants" are values, and "literals" >>>>>> are objects. >>>>> >>>>> So a literal like 726163 is an object, and not a value? >>>> >>>> As far as ISO C is concerned, the token '726163' is a constant, >>>> not a literal, and is a value rather than an object. >>> >>> The term "literal" in computer science is a shortening of >>> "literal constant". (There are also symbolic/manifest constants.) >> >> I am not aware of any authoritative reference that defines the >> term "literal" for the field of computer science. >> >> In any case, my comments are only about how the terms "literal" >> and "constant" are used in the ISO C standard. This newsgroup is >> comp.lang.c, and I see nothing wrong in restricting the domain of >> my remarks to just that of the C language. > > Sure, but plenty of people informally use the word "literal" to refer to > constants. Even K&R2's reference manual says: It is not "informally" just because it's not in ISO C. When I use "literal", the only sense in which I am not speaking informally is that I didn't use the full word "literal constant". > The characters /* introduce a comment, which terminates with the > characters */. Comments do not nest, and they do not occur within > string or character literals. > > As much as I prefer to use the terminology defined in the standard, I > have no real problem with referring to 42 or 'x' as a literal. Neither has ISO C; it doesn't claim the unqualified word. However, ISO C has another a problem: "compound literal" conflicts with the common understanding of "litearl", supported by dictionaries of computing terms. C compound literals simply aren't literals, except maybe static ones outside of a function. Firstly, compound literals in a function are objects with automatic duration. A literal is no such temporary thing; it denotes the same value, indefinitely. Anything which has a machine address, but which disappears when some limited scope of the program terminates, is not possibly a literal. Secondly, a literal always demonstrates the same value. A compound literal does not. A block-scoped compound literal may contain initializing expressions whose values are computed at run-time, and different on each invocation of the block scope where the literal occurs. No, a C compound literal isn't a literal at all. It is more like a constructor for an anonymous object that has a restricted lifetime. Other languages have this problem. Python calls this "literal": [ a, b, c, 1 ] event hough (1) it produces a new list object every time it is evaluated, and (2) using whatever values of a, b and c that are current. The only literal in that picture is 1. This is a constructor, like the following expression in Lisp: (list a b c 1) A literal looks like this: '(a b c 1) Here is a litmus test for literal: can it be put into ROM? JavaScript object literals also aren't literals, but constructors. A constructor may closely resemble the printed representation of an object, but that resemblance deosn't make it a litera. If it interpolates the values of expressions and variables, and/or specifies the fresh instantiation of a new, mutable object, or something of a limited lifetime, it isn't a literal. A compiler may treat some constructor expressions as literals depending on their exact content. In Lisp, the backquote expression `(1 2 ,a) isn't a literal because it allocates a new list, with the current value of a in the third spot. If the backquote notation is used on constant data like `(1 2 3), the Lisp dialect's specification may indicate that such a case may be (or even must be) be transformed to the literal '(1 2 3). Then that is de facto a literal. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-16 06:52 -0700 |
| Message-ID | <86r10bl94l.fsf@linuxsc.com> |
| In reply to | #167724 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Kaz Kylheku <480-992-1380@kylheku.com> writes:
>>
>>> On 2022-09-13, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> On 12/09/2022 05:22, Tim Rentsch wrote:
>>>>>
>>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>>>
>>>>>>> Thinking about it a bit more, the common factor with all
>>>>>>> literals is that they represent /anonymous/ values. Without
>>>>>>> compound literals you could not write a value of any aggregate
>>>>>>> type, other than char[].
>>>>>>
>>>>>> The key difference is that "constants" are values, and
>>>>>> "literals" are objects.
>>>>>
>>>>> So a literal like 726163 is an object, and not a value?
>>>>
>>>> As far as ISO C is concerned, the token '726163' is a constant,
>>>> not a literal, and is a value rather than an object.
>>>
>>> The term "literal" in computer science is a shortening of
>>> "literal constant". (There are also symbolic/manifest constants.)
>>
>> I am not aware of any authoritative reference that defines the
>> term "literal" for the field of computer science.
>>
>> In any case, my comments are only about how the terms "literal"
>> and "constant" are used in the ISO C standard. This newsgroup is
>> comp.lang.c, and I see nothing wrong in restricting the domain of
>> my remarks to just that of the C language.
>
> Sure, but plenty of people informally use the word "literal" to
> refer to constants. Even K&R2's reference manual says:
>
> The characters /* introduce a comment, which terminates with
> the characters */. Comments do not nest, and they do not
> occur within string or character literals.
I acknowledge the existence of other usages. I just don't think
it's helpful to confuse the conversation by mixing in those other
usages when talking about how to understand the C standard.
> As much as I prefer to use the terminology defined in the standard,
> I have no real problem with referring to 42 or 'x' as a literal.
Aren't you one of the people who advocates using terminology as
it is used in the C standard when writing comp.lang.c postings?
That's all I'm doing. I don't see any reason why this case
should be different.
> I suggest that the "key difference" you see ("constants" are
> values, and "literals" are objects") is accidental.
I see no reason to think that is true. Do you have any facts
to support this hypothesis? If anything, the consistency of
usage observed in the C standard (at least eight different kinds
of constants, two kinds of constant expressions, and two kinds of
literals), plus the high quality of writing in the C standard
generally, both suggest that the choice was deliberate, and not
accidental. The existence of the quote you gave from K&R2 adds
more weight to that conclusion: surely the authors of the ANSI
and ISO C standards must have known of that comment, yet they
chose "character constant" rather than "character literal" when
writing the standards documents.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <480-992-1380@kylheku.com> |
|---|---|
| Date | 2022-09-15 00:14 +0000 |
| Message-ID | <20220914162303.734@kylheku.com> |
| In reply to | #167717 |
On 2022-09-14, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Kaz Kylheku <480-992-1380@kylheku.com> writes: > >> On 2022-09-13, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> >>> Bart <bc@freeuk.com> writes: >>> >>>> On 12/09/2022 05:22, Tim Rentsch wrote: >>>> >>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>>>> >>>>>> Thinking about it a bit more, the common factor with all literals is >>>>>> that they represent /anonymous/ values. Without compound literals you >>>>>> could not write a value of any aggregate type, other than char[]. >>>>> >>>>> The key difference is that "constants" are values, and "literals" >>>>> are objects. >>>> >>>> So a literal like 726163 is an object, and not a value? >>> >>> As far as ISO C is concerned, the token '726163' is a constant, >>> not a literal, and is a value rather than an object. >> >> The term "literal" in computer science is a shortening of >> "literal constant". (There are also symbolic/manifest constants.) > > I am not aware of any authoritative reference that defines the > term "literal" for the field of computer science. The Oxford Dictionary of Computer Science (7th ed, 2016) has an entry: literal A word or symbol in a program that stands for itself rather than as a name for something else, i.e. an object whose value is determined by its denotation. Numbers are literals; if other symbols are used as literals it is necessary to use some form of quoting mechanism to distinguish them from variables [...] Microsoft Computer Dictionary (5th ed, ebook, 2002): literal n. A value, used in a program, that is expressed as itself rather than as a variable’s value or the result of an expression. Examples are the numbers 25 and 32.1, the character a, the string Hello, and the Boolean value TRUE. See also constant, variable. We might not take these references as authoritative but on the other hand, the term in question is pretty deeply entrenched; the above references are not free to define it in a significantly different way. > In any case, my comments are only about how the terms "literal" > and "constant" are used in the ISO C standard. This newsgroup is > comp.lang.c, and I see nothing wrong in restricting the domain of > my remarks to just that of the C language. The unqualified term "literal" isn't used in the C standard, only "string literal" and "compound literal". Unqualified "literal" isn't defined, and isn't found in the referenced ISO 2382-1 document. There is no wording which says that there is a category of literals which is comprised only of string literals and compound literals. We can use words that are not in the standard, if they don't conflict with its special definitions. For instance an arrangement of like-typed structs connected by pointers may be called a "linked list", because ISO C doesn't define such a term meaning something else, and its use of "link", "linkage", "linking" and "linked" in reference to translation unit combination doesn't stand in the way, either. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
Page 10 of 12 — ← Prev page 1 … 8 9 [10] 11 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web