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 2 of 12 — ← Prev page 1 [2] 3 4 … 12 Next page →
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2022-08-30 04:03 -0700 |
| Message-ID | <1b6e727b-f113-45ec-be0f-3675e79ff7d7n@googlegroups.com> |
| In reply to | #167324 |
On Tuesday, 30 August 2022 at 08:38:16 UTC+1, David Brown wrote: > On 30/08/2022 00:16, bart c wrote: > > There are some nifty features that have been tried and tested, and > > more importantly are implemented in a simple manner. > > > > > I agree that looking at different languages and implementations can be > very useful when considering new features in a language. But we are not > adding new features to C - we are discussing how new features, added by > others (the C standards committee), will work. That's a very different > matter. It does not matter how wonderful a feature of /your/ language > is - it has no bearing on the features of /this/ language. It /doesn't matter/. Anyone can have a view of how a certain feature ought to work, without ever having implemented it, and can give an opinion about it (so can you!). But those who have done so have some extra weight behind their opinion. I've never implemented 'constexpr' for functions, so I guess I'm allowed to say what I think about it? And how good a fit it might be for C. But again, the fact I've long been involved in implementing smaller, C-like languages means I have some extra insight in what makes a feature lightweight and what makes it a can of worms. > This is very > different from, say, a thread discussing possible extensions to C for > those that write C compilers. The thread subject is actually 'conformant C compilers'. > I also disagree that your language counts as "close to C", Well, it is. Unless you have your own candidates in mind for a language that is as close as possible to C but is not C. That doesn't include those where you have to take a tiny subset of the language to make it emulate C (which lets out C++, Zig, Rust, C#, Java, Odin, D among many others). > or "tried and tested". Tried and tested over decades in some cases. Plenty of things also didn't work well and have been dropped or changed. > The prime sources for inspiration for things to > consider adding to the C language are extensions from major C compilers > (such as gcc, clang, MSVC, and many others) and C++. C++ should be the last language to take inspiration from. It just does not know how to keep new features simple. But also, where did those extensions to C come from; what inspired those? Perhaps from individuals, perhaps from other non-C languages.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2022-08-31 01:20 +0300 |
| Message-ID | <20220831012015.eeda2c1543d3538171058d59@gmail.com> |
| In reply to | #167324 |
David Brown: > I agree that looking at different languages and > implementations can be very useful when considering new > features in a language. I am of the opposite opinion. The majority of popular programming languages contract features from one another like some veneral disease: OOP, lamda, multiple returns, you-name-it, exceptions, the worst of C syntax, you-name-it. Very few languages stay true to their philosophy, retaining a personality. I can think of Julia. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-31 09:14 +0200 |
| Message-ID | <ten1ns$1o9d4$1@dont-email.me> |
| In reply to | #167350 |
On 31/08/2022 00:20, Anton Shepelev wrote: > David Brown: > >> I agree that looking at different languages and >> implementations can be very useful when considering new >> features in a language. > > I am of the opposite opinion. The majority of popular > programming languages contract features from one another > like some veneral disease: OOP, lamda, multiple returns, > you-name-it, exceptions, the worst of C syntax, you-name-it. > Very few languages stay true to their philosophy, retaining > a personality. I can think of Julia. > You need to ask what the purpose of a programming language actually is. It is a way for people to codify their tasks, and solve their problems - it is not religious dogma or historic art that must remain "pure" and untouched. If a new feature to a language lets people do more with it, or lets them do the same things better (for some value of "better"), without making it worse for existing purposes, then it is natural and reasonable for it to gain that feature. The alternative is that the language will gradually fade from use. (That's also natural, of course.) There's a reason people don't use Turing Machines for practical coding. That doesn't mean that every language should acquire every feature, and not all features work well together, with some being directly contradictory. But it does mean that if you are responsible for the maintenance and future of a programming language, you should work with a range of other languages too and keep an open mind to taking inspiration from them.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-28 06:19 -0700 |
| Message-ID | <f68d1830-39b9-44dd-9e4e-83973baf2692n@googlegroups.com> |
| In reply to | #167253 |
On Sunday, August 28, 2022 at 7:53:07 AM UTC-3, bart c wrote:
> On Sunday, 28 August 2022 at 09:27:35 UTC+1, David Brown wrote:
> > On 27/08/2022 01:01, Thiago Adams wrote:
> > > On Friday, August 26, 2022 at 5:56:39 PM UTC-3, Keith Thompson wrote:
> > >> Thiago Adams <thiago...@gmail.com> writes:
> > >>> On Friday, August 26, 2022 at 12:29:19 PM UTC-3, David Brown wrote:
> > >>> ...
> > >>>> I don't know whether C will adopt constexpr functions. I suppose some
> > >>>> people will ask for them, others will ask that they remain a C++ only
> > >>>> feature.
> > >>>
> > >>> I think nobody asked for constexpr in C.
> > >> That's clearly not literally true. Can you clarify what you mean?
> > Indeed. People ask for all kinds of odd things in C (not that I think
> > constexpr is an odd addition to the language - I like it). You can be
> > confident that when something is added to the C standards, a non-trivial
> > number of C programmers have been asking for the feature. There might
> > not be a large number, there may be others arguing against the feature,
> > or disagreement about how the feature is to be implemented in practice -
> > but there will definitely be people who want it.
> > >>
> > >> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3018.htm
> > >>
> > >> Personally, I'm very glad C is getting constexpr.
> > >
> > Me too. I might have preferred making const variables a bit more like
> > C++, but I'm quite happy with constexpr
> > > Do you have a motivation for constexpr?
> .> >
> > To me, it gives more flexibility of initialisers and of use in wider
> > areas (such as array sizes, switch cases) than you get with "static
> > const" or "enum", while being clearer, simpler, and better diagnostics
> > than "#define".
> You said above that you preferred 'const'. To me, the combination of 'const', 'enum' and '#define' are just three different ways of working around the lack of proper named constants in C (which is being addressed now by the introduced of 'constexpr' for objects, so there are now 4 four different ways that will be encountered in source code for years to come!)
>
> Those three have different characteristics, as the answers to these questions are usually different (I won't give the actual answers, as GG can't display tabular data):
>
> - Uses normal scope rules
> - Won't create VLAs when used as array bounds
> - Can't take their address
> - Cannot modify, even maliciously
> - Can be used in switch cases
> - Can be reduced when used in expressions to yield another constant value
> - Can have any scalar type
> - Can be used to initialise static data
> - Has guaranteed behaviour not dependent on compiler
>
> The preferred behaviour is to answer Yes to all of these. Your 'const' ranks poorly here, as most answers will be No; you probably rely on that last point to make some of them Yes.
Yes. I Agree. (the same conclusion from previous topics)
> 'enum' ranks the highest here (only failing on not allowing enums to have any type), yet it also feels wrong: it was not intended for a general purpose named constant feature, but to define sequences of related values. I also rarely see it being used in place of #define for simple named constants.
> > It adds clarity to the code in making it obvious that
> > something is a "compile-time constant" - it is immediately obvious to
> > the reader, and misuse will always be a hard compiler-time error.
> Of course. Which is why I've been wondering for /decades/ why such a thing wasn't part of the language anyway. At what point did even 'enums' officially make it in?
>
> (In my own stuff, I've long had 'const' which answers Yes to all the above. And in my C compiler, I experimented with 'constant' which allows this:
>
> ... constant double width=37.1;
> ... constant double height=27.2;
> ... static double dims[] ={width*height, (width+height)/2, width/height};
>
> 'constexpr' probably goes further than what I do, but as I understand it, was deliberately kept limited compared with C++ just to make it easy to implement.)
> > > C23 added a lot of superfluous stuff like nullptr and the standard is afraid
> > > of broke the language changing stuff..instead they added new features.
> > >
> > In my C++ programming, I find nullptr is very useful. I expect to use
> > it in C23 coding too.
> This looks another no-brainer to me. The rationale explains why NULL is problematic. It is also trivial to implement.
>
> (For a few years I've used 'nil' for the same purpose. I no longer allow '0' (this is outside of C) to initialise pointers, which still irks when writing C. But C can't fix that.
>
> Now I can see straightaway that f(nil) passes a pointer, but it is very common to see f(0) in C code, just because it is allowed.)
It takes time to check and adapt new rules in C with the current syntax.
It is easier to add a new feature and I think this is the problem of C++ and C
is taking the same horrible path for (const, constexpr, nullptr)
The way const words in C++ is also different from C. So we have more
combinations for code that is shared with C and C++.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-28 06:11 -0700 |
| Message-ID | <413ae987-3216-415f-88cf-8a6a0f7cfe4an@googlegroups.com> |
| In reply to | #167252 |
On Sunday, August 28, 2022 at 5:27:35 AM UTC-3, David Brown wrote: > On 27/08/2022 01:01, Thiago Adams wrote: > > On Friday, August 26, 2022 at 5:56:39 PM UTC-3, Keith Thompson wrote: > >> Thiago Adams <thiago...@gmail.com> writes: > >>> On Friday, August 26, 2022 at 12:29:19 PM UTC-3, David Brown wrote: > >>> ... > >>>> I don't know whether C will adopt constexpr functions. I suppose some > >>>> people will ask for them, others will ask that they remain a C++ only > >>>> feature. > >>> > >>> I think nobody asked for constexpr in C. > >> That's clearly not literally true. Can you clarify what you mean? > Indeed. People ask for all kinds of odd things in C (not that I think > constexpr is an odd addition to the language - I like it). You can be > confident that when something is added to the C standards, a non-trivial > number of C programmers have been asking for the feature. There might > not be a large number, there may be others arguing against the feature, > or disagreement about how the feature is to be implemented in practice - > but there will definitely be people who want it. > >> > >> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3018.htm > >> > >> Personally, I'm very glad C is getting constexpr. > > > Me too. I might have preferred making const variables a bit more like > C++, but I'm quite happy with constexpr (I know where to find C++ when I > want it). It will make it easier when you have things that are known > fixed values at compile time, but you can't use them in the same way as > you can use "integer constants" or literals. > > > > We had several topics here about constants. > > The problem I see with constexpr is that is has store, and it is very > > similar of const. > > > Neither constexpr nor static (or function local) const have storage, > unless that store is needed, assuming a reasonable compiler. > > I prefer to #define and enumerator. I think in C++ the storage can be > > removed if we don't take the address.. but in C I am not sure. > Of course it can be removed if it is not needed. > > Imagine a header with a lot a constants that you don't use. All of them > > will have linkage? (maybe the linker can remove?) > I am not sure of the details of constexpr in C23, but I would expect the > linkage to be internal. And just like "static const", no decent > compiler will allocate space for them if it is not required. With > constexpr, I expect even weaker compilers (or good compilers in > non-optimising modes) will avoid storage. > > > > Do you have a motivation for constexpr? > > > To me, it gives more flexibility of initialisers and of use in wider > areas (such as array sizes, switch cases) than you get with "static > const" or "enum", while being clearer, simpler, and better diagnostics > than "#define". It adds clarity to the code in making it obvious that > something is a "compile-time constant" - it is immediately obvious to > the reader, and misuse will always be a hard compiler-time error. And > you can make constexpr variables of any type, unlike enum constants. > > C23 added a lot of superfluous stuff like nullptr and the standard is afraid > > of broke the language changing stuff..instead they added new features. > > > In my C++ programming, I find nullptr is very useful. I expect to use > it in C23 coding too. But such things are optional - use it if you > want, or not if you don't want. (You may see it in third-party code > too, but the usage will be obvious.) > > This is like a programmer afraid of doing refactoring and instead it add > > more features that could be factored in one. > > > I am sure that there are features of C23 that I will dislike. For any > selection of features, there will always be some that any given person > likes, others that they don't like, will a great variation on where > these splits go. That is the inevitable nature of programming languages > made by and for more than one person. (Compare this to the posters here > who have made their own languages, and are convinced that their > languages are superior to all others and perfect in every way, but can't > understand why no one agrees with them.) > > However, I would expect "constexpr" to be a relatively uncontroversial > feature once people start to use it. There are a lot of details about storage of constexpr. https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf "NOTE An object declared in block scope with a storage-class specifier constexpr and without static has automatic storage duration, the identifier has no linkage, and each instance of the object has a unique address obtainable with & (if it is not declared with the register specifier), if any. Such an object in file scope has static storage duration, the corresponding identifier has internal linkage, and each translation unit that sees the same textual definition implements a separate object with a distinct address."
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-28 17:20 +0200 |
| Message-ID | <teg13k$lcba$1@dont-email.me> |
| In reply to | #167257 |
On 28/08/2022 15:11, Thiago Adams wrote: > On Sunday, August 28, 2022 at 5:27:35 AM UTC-3, David Brown wrote: >> However, I would expect "constexpr" to be a relatively uncontroversial >> feature once people start to use it. > > > There are a lot of details about storage of constexpr. > https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf > > "NOTE An object declared in block scope with a storage-class specifier constexpr and without static > has automatic storage duration, the identifier has no linkage, and each instance of the object > has a unique address obtainable with & (if it is not declared with the register specifier), if any. > Such an object in file scope has static storage duration, the corresponding identifier > has internal linkage, and each translation unit that sees the same textual definition implements > a separate object with a distinct address." > Do you see anything there you don't like, or which is not pretty obvious?
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-28 12:31 -0700 |
| Message-ID | <b5c0189c-2024-40c1-8038-a23058f6eafan@googlegroups.com> |
| In reply to | #167259 |
On Sunday, August 28, 2022 at 12:20:35 PM UTC-3, David Brown wrote:
> On 28/08/2022 15:11, Thiago Adams wrote:
> > On Sunday, August 28, 2022 at 5:27:35 AM UTC-3, David Brown wrote:
>
> >> However, I would expect "constexpr" to be a relatively uncontroversial
> >> feature once people start to use it.
> >
> >
> > There are a lot of details about storage of constexpr.
> > https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf
> >
> > "NOTE An object declared in block scope with a storage-class specifier constexpr and without static
> > has automatic storage duration, the identifier has no linkage, and each instance of the object
> > has a unique address obtainable with & (if it is not declared with the register specifier), if any.
> > Such an object in file scope has static storage duration, the corresponding identifier
> > has internal linkage, and each translation unit that sees the same textual definition implements
> > a separate object with a distinct address."
> >
> Do you see anything there you don't like, or which is not pretty obvious?
I don't like constexpr mainly because it has storage and it is too similar of const.
But even without storage I would not recommend constexpr without
a extensive analysis to give more power to const. The same for nullptr, give more
power to NULL.
const in C++ already behave like a constant expression.
IN C++
int main() {
const int c = 10;
int a[c];
static_assert(sizeof a == sizeof(int)*10);
}
(In c a is a VLA)
So it is not new that we can have different behaviour with const
compiling the same code in C or C++.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-28 12:49 -0700 |
| Message-ID | <68fbf792-a971-4e42-af84-c02257625abdn@googlegroups.com> |
| In reply to | #167260 |
On Sunday, August 28, 2022 at 4:31:48 PM UTC-3, Thiago Adams wrote: > On Sunday, August 28, 2022 at 12:20:35 PM UTC-3, David Brown wrote: > > On 28/08/2022 15:11, Thiago Adams wrote: > > > On Sunday, August 28, 2022 at 5:27:35 AM UTC-3, David Brown wrote: > > > > >> However, I would expect "constexpr" to be a relatively uncontroversial > > >> feature once people start to use it. > > > > > > > > > There are a lot of details about storage of constexpr. > > > https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf > > > > > > "NOTE An object declared in block scope with a storage-class specifier constexpr and without static > > > has automatic storage duration, the identifier has no linkage, and each instance of the object > > > has a unique address obtainable with & (if it is not declared with the register specifier), if any. > > > Such an object in file scope has static storage duration, the corresponding identifier > > > has internal linkage, and each translation unit that sees the same textual definition implements > > > a separate object with a distinct address." > > > > > Do you see anything there you don't like, or which is not pretty obvious? > I don't like constexpr mainly because it has storage and it is too similar of const. > But even without storage I would not recommend constexpr without > a extensive analysis to give more power to const. The same for nullptr, give more > power to NULL. An interesting exercise is to think about true and false as constexpr. Imagine we have bool in the language but we don't have true and false constants. Then we declare: constexpr bool true = 1; constexpr bool false = 0; bool b = true; The "real" true /false constants don't have storage and we cannot take the address of. The same for nullptr.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-28 21:29 +0100 |
| Message-ID | <87ilmcyuv3.fsf@bsb.me.uk> |
| In reply to | #167262 |
Thiago Adams <thiago.adams@gmail.com> writes: > An interesting exercise is to think about true and false as constexpr. > Imagine we have bool in the language but we don't have true and false > constants. > > Then we declare: > > constexpr bool true = 1; > constexpr bool false = 0; In this hypothetical situation, presumably 1 and 0 are the actual values that bool objects represent. If not, this would be a constraint violation as the standard is deliberately strict about constexpr initialisers: they undergo no conversions. It's not 100% clear to me if, in the finished C23, constexpr bool my_bool = 1; will be permitted. I think not. > bool b = true; > > The "real" true /false constants don't have storage and we cannot > take the address of. Can't take the address of true or false? I don't think that's correct. They are objects and their names are lvalue expressions. You'd have to declare them as register constexpr to make taking the address a constraint violation. Mind you, I don't think things have settled down yet. I can't see any wording in N3047 that stops your true and false being considered /modifiable/ lvalues, and I presume they should not be! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-28 17:49 -0700 |
| Message-ID | <87v8qbj2kx.fsf@nosuchdomain.example.com> |
| In reply to | #167263 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Thiago Adams <thiago.adams@gmail.com> writes:
>
>> An interesting exercise is to think about true and false as constexpr.
>> Imagine we have bool in the language but we don't have true and false
>> constants.
>>
>> Then we declare:
>>
>> constexpr bool true = 1;
>> constexpr bool false = 0;
>
> In this hypothetical situation, presumably 1 and 0 are the actual values
> that bool objects represent. If not, this would be a constraint
> violation as the standard is deliberately strict about constexpr
> initialisers: they undergo no conversions.
>
> It's not 100% clear to me if, in the finished C23,
>
> constexpr bool my_bool = 1;
>
> will be permitted. I think not.
>
>> bool b = true;
>>
>> The "real" true /false constants don't have storage and we cannot
>> take the address of.
>
> Can't take the address of true or false? I don't think that's correct.
> They are objects and their names are lvalue expressions. You'd have to
> declare them as register constexpr to make taking the address a
> constraint violation.
In C23 (N3047), true and false are keywords and predefined constants.
&true is just as invalid as &42.
But if you write
constexpr bool tru = 1;
then &tru is valid.
> Mind you, I don't think things have settled down yet. I can't see any
> wording in N3047 that stops your true and false being considered
> /modifiable/ lvalues, and I presume they should not be!
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-29 02:58 +0100 |
| Message-ID | <87czcjzu75.fsf@bsb.me.uk> |
| In reply to | #167272 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> Thiago Adams <thiago.adams@gmail.com> writes: >> >>> An interesting exercise is to think about true and false as constexpr. >>> Imagine we have bool in the language but we don't have true and false >>> constants. >>> >>> Then we declare: >>> >>> constexpr bool true = 1; >>> constexpr bool false = 0; >> >> In this hypothetical situation, presumably 1 and 0 are the actual values >> that bool objects represent. If not, this would be a constraint >> violation as the standard is deliberately strict about constexpr >> initialisers: they undergo no conversions. >> >> It's not 100% clear to me if, in the finished C23, >> >> constexpr bool my_bool = 1; >> >> will be permitted. I think not. >> >>> bool b = true; >>> >>> The "real" true /false constants don't have storage and we cannot >>> take the address of. >> >> Can't take the address of true or false? I don't think that's correct. >> They are objects and their names are lvalue expressions. You'd have to >> declare them as register constexpr to make taking the address a >> constraint violation. > > In C23 (N3047), true and false are keywords and predefined constants. > &true is just as invalid as &42. Yes. I was talking about TA's hypothetical situation where we have bool but not true and false. > But if you write > constexpr bool tru = 1; > then &tru is valid. Indeed. Maybe I should not have entered so wholeheartedly into the spirit of the hypothetical! By the way, does that definition not involve a conversion? I thought conversions (at least implicit ones) were not permitted in constexpr object initialisers. >> Mind you, I don't think things have settled down yet. I can't see any >> wording in N3047 that stops your true and false being considered >> /modifiable/ lvalues, and I presume they should not be! Do you happen to know what wording (if any) stops a constexpr object from being modifiable lvalue? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-28 19:51 -0700 |
| Message-ID | <87r10ziwxe.fsf@nosuchdomain.example.com> |
| In reply to | #167273 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> Do you happen to know what wording (if any) stops a constexpr object
> from being modifiable lvalue?
N3407 6.3.2.1p1:
A *modifiable lvalue* is an lvalue that does not have array type,
does not have an incomplete type, does not have a const-qualified
type, and if it is a structure or union, does not have any member
(including, recursively, any member or element of all contained
aggregates or unions) with a const-qualified type.
N3407 6.7.1, Storage class specifiers (including "constexpr"),
paragraph 11:
An object declared with a storage-class specifier constexpr has its
value permanently fixed at translation-time; if not yet present, a
const-qualification is implicitly added to the object’s type. The
declared identifier is considered a constant expression of the
respective kind, see ??.
(I presume the "??" will be filled in in a future draft.)
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-29 10:54 +0100 |
| Message-ID | <87v8qbxtla.fsf@bsb.me.uk> |
| In reply to | #167274 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > [...] >> Do you happen to know what wording (if any) stops a constexpr object >> from being modifiable lvalue? > > N3407 6.3.2.1p1: > A *modifiable lvalue* is an lvalue that does not have array type, > does not have an incomplete type, does not have a const-qualified > type, and if it is a structure or union, does not have any member > (including, recursively, any member or element of all contained > aggregates or unions) with a const-qualified type. > > > N3407 6.7.1, Storage class specifiers (including "constexpr"), > paragraph 11: > An object declared with a storage-class specifier constexpr has its > value permanently fixed at translation-time; if not yet present, a > const-qualification is implicitly added to the object’s type. The > declared identifier is considered a constant expression of the > respective kind, see ??. This is the bit I missed (not sure how). There's an implicit const qualification, Thanks. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-12 05:13 -0700 |
| Message-ID | <86illspz8y.fsf@linuxsc.com> |
| In reply to | #167263 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Thiago Adams <thiago.adams@gmail.com> writes:
>
>> An interesting exercise is to think about true and false as
>> constexpr. Imagine we have bool in the language but we don't
>> have true and false constants.
>>
>> Then we declare:
>>
>> constexpr bool true = 1;
>> constexpr bool false = 0;
>
> In this hypothetical situation, presumably 1 and 0 are the actual
> values that bool objects represent. If not, this would be a
> constraint violation as the standard is deliberately strict about
> constexpr initialisers: they undergo no conversions.
>
> It's not 100% clear to me if, in the finished C23,
>
> constexpr bool my_bool = 1;
>
> will be permitted. I think not.
I agree with (what I think is) your conclusion that the latest C23
draft standard (n3047) deems the initializing expression of
my_bool a constraint violation.
However, I do not think that n3047 disallows all conversions (that
are implicit; AFAICS casting is always allowed). My understanding
is that implicit conversions are allowed provided they do not
cause a change of abstract value. For example, a definition such
as
constexpr unsigned int unsigned_one = 1;
would be allowed, because the conversion from int to unsigned int
does not change the abstract value 1. But the definition of
my_bool above is not allowed, because the implicit conversion from
int to bool changes the abstract value 1 to the abstract value
true. Similarly a definition such as
constexpr unsigned int all_ones = -1;
would not be allowed, because the conversion from int to unsigned
int changes the abstract value of -1 to a different abstract
value (certainly an unsigned value cannot be less than zero, as -1
is).
Disallowing the example definitions of my_bool and all_ones given
above shows the foolishness of this rule. It's disappointing to
see these further indications that the ISO C committee is drinking
the C++ kool-aid.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-12 13:55 +0000 |
| Message-ID | <0TGTK.472157$BKL8.553@fx15.iad> |
| In reply to | #167636 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>
>>> An interesting exercise is to think about true and false as
>>> constexpr. Imagine we have bool in the language but we don't
>>> have true and false constants.
>>>
>>> Then we declare:
>>>
>>> constexpr bool true = 1;
>>> constexpr bool false = 0;
>>
>> In this hypothetical situation, presumably 1 and 0 are the actual
>> values that bool objects represent. If not, this would be a
>> constraint violation as the standard is deliberately strict about
>> constexpr initialisers: they undergo no conversions.
>>
>> It's not 100% clear to me if, in the finished C23,
>>
>> constexpr bool my_bool = 1;
>>
>> will be permitted. I think not.
>
>I agree with (what I think is) your conclusion that the latest C23
>draft standard (n3047) deems the initializing expression of
>my_bool a constraint violation.
>
>However, I do not think that n3047 disallows all conversions (that
>are implicit; AFAICS casting is always allowed). My understanding
>is that implicit conversions are allowed provided they do not
>cause a change of abstract value. For example, a definition such
>as
>
> constexpr unsigned int unsigned_one = 1;
>
>would be allowed, because the conversion from int to unsigned int
>does not change the abstract value 1. But the definition of
>my_bool above is not allowed, because the implicit conversion from
>int to bool changes the abstract value 1 to the abstract value
>true. Similarly a definition such as
>
> constexpr unsigned int all_ones = -1;
Wouldn't it be more natural to write
constexpr unsigned int all_ones = ~1;
I'd never use your suggestion in real code; I've seen programmers do
it, but it has never been proper.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-12 15:06 +0100 |
| Message-ID | <87sfkwwutb.fsf@bsb.me.uk> |
| In reply to | #167638 |
scott@slp53.sl.home (Scott Lurndal) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: <cut> >> constexpr unsigned int all_ones = -1; > > Wouldn't it be more natural to write > > constexpr unsigned int all_ones = ~1; You surely meant ~0, yes? > I'd never use your suggestion in real code; I've seen programmers do > it, but it has never been proper. I have exactly the opposite reaction. The conversion of -1 to an unsigned integer type is very explicitly described in such a way that the maximum number of value bits must be set. This contrasts with ~0 that might even be a trap representation. (~0u on the other had is well-defined.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-12 15:22 +0000 |
| Message-ID | <29ITK.274683$wLZ8.259591@fx18.iad> |
| In reply to | #167639 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >scott@slp53.sl.home (Scott Lurndal) writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: ><cut> >>> constexpr unsigned int all_ones = -1; >> >> Wouldn't it be more natural to write >> >> constexpr unsigned int all_ones = ~1; > >You surely meant ~0, yes? Yes, indeed, ~0u. Too early in the morning...
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-12 17:04 +0100 |
| Message-ID | <87bkrkwpcz.fsf@bsb.me.uk> |
| In reply to | #167643 |
scott@slp53.sl.home (Scott Lurndal) writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>scott@slp53.sl.home (Scott Lurndal) writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >><cut> >>>> constexpr unsigned int all_ones = -1; >>> >>> Wouldn't it be more natural to write >>> >>> constexpr unsigned int all_ones = ~1; >> >>You surely meant ~0, yes? > > Yes, indeed, ~0u. Too early in the morning... Ah, well the u makes even /more/ difference. ~0u is entirely well-defined. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-12 17:39 +0000 |
| Message-ID | <d9KTK.413049$iiS8.43847@fx17.iad> |
| In reply to | #167646 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >scott@slp53.sl.home (Scott Lurndal) writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>>scott@slp53.sl.home (Scott Lurndal) writes: >>> >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>><cut> >>>>> constexpr unsigned int all_ones = -1; >>>> >>>> Wouldn't it be more natural to write >>>> >>>> constexpr unsigned int all_ones = ~1; >>> >>>You surely meant ~0, yes? >> >> Yes, indeed, ~0u. Too early in the morning... > >Ah, well the u makes even /more/ difference. ~0u is entirely >well-defined. I just have this personal objection to using a sign (e.g. the dash/hypen/minus sign) with an unsigned value, regardless of how well it is defined by the language. It just looks wrong.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-12 17:40 +0000 |
| Message-ID | <yaKTK.413050$iiS8.119024@fx17.iad> |
| In reply to | #167651 |
scott@slp53.sl.home (Scott Lurndal) writes: >Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>scott@slp53.sl.home (Scott Lurndal) writes: >> >>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>>>scott@slp53.sl.home (Scott Lurndal) writes: >>>> >>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>><cut> >>>>>> constexpr unsigned int all_ones = -1; >>>>> >>>>> Wouldn't it be more natural to write >>>>> >>>>> constexpr unsigned int all_ones = ~1; >>>> >>>>You surely meant ~0, yes? >>> >>> Yes, indeed, ~0u. Too early in the morning... >> >>Ah, well the u makes even /more/ difference. ~0u is entirely >>well-defined. > >I just have this personal objection to using a sign >(e.g. the dash/hypen/minus sign) with an unsigned value, >regardless of how well it is defined by the language. It >just looks wrong. (which, I'm sure, derives from my decade writing operating systems for a line of BCD burroughs mainframes, where unsigned really had no sign at all).
[toc] | [prev] | [next] | [standalone]
Page 2 of 12 — ← Prev page 1 [2] 3 4 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web