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 1 of 12 [1] 2 3 … 12 Next page →
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2022-08-25 02:33 +0000 |
| Subject | Are there any conformant C compilers? |
| Message-ID | <te6n25$16ga$1@gioia.aioe.org> |
In draft standard (n3047.pdf) I see:
: A conforming hosted implementation shall accept any strictly
: conforming program.
We also have:
: A strictly conforming program shall use only those features of
: the language and library specified in this document. It shall
: not produce output dependent on any unspecified, undefined, or
: implementation-defined behavior, and shall not exceed any minimum
: implementation limit.
Take the following program:
#define x1(y) y + y
#define x2(y) x1(x1(y))
#define x4(y) x2(x2(y))
#define x8(y) x4(x4(y))
#define x16(y) x8(x8(y))
#define x32(y) x16(x16(y))
#define x48(y) x16(x32(y))
#include <stdio.h>
int main(void) {
long long foo = x48(1LL);
long long bar = 1024LL;
bar *= bar;
bar *= bar;
bar *= 1024LL;
if (foo < bar) {
printf("OK\n");
} else {
printf("failed\n");
}
return 0;
}
AFAICS it uses only standard features. Concerning implementation
limits, macro expansion produces huge expression. But the only
limits on macros in the standard are total number of macros and
number of arguments, the program above stay well below both.
There is no limit on expression size, only limits on nesting
depth and above we stay well below limits on nesting depth
(in particular critical expression 'x48(1LL)' after expansion
is entirely flat.
Anyway, gcc runs out of memory compiling this program and
other C compilers are also likely to run out of memory.
In principle compiler which is doing aggressive constant
folding during macro expanson could easily compile this
program, but it is not clear if any is doing this.
And quite likely one could came out with more complicated
examples.
Of course, real question is: why C standard insist on
putting implementation limits in conformance part?
The scope statement says:
: the size or complexity of a program and its data that
: will exceed the capacity of any specific data-processing
: system or the capacity of a particular processor;
but requrements cited above cleary _are_ statements
about capacity. Resorce usage may depend in complex
way on program source, so either all compilers are
nonconformat or statements about environmental limits
are merely advisory (because compiler may be
unable to handle program with valid reason).
Apparently standard wants to apply to 16-bit machines,
and clearly complexity of program which can run
on 16-bit machine can not be very high. This makes
evan hader to give any sensible warranty that
program satisfying some easily formulated condition
can be handled by given implementation.
--
Waldek Hebisch
[toc] | [next] | [standalone]
| From | Kaz Kylheku <480-992-1380@kylheku.com> |
|---|---|
| Date | 2022-08-25 03:00 +0000 |
| Message-ID | <20220824194656.932@kylheku.com> |
| In reply to | #167206 |
On 2022-08-25, antispam@math.uni.wroc.pl <antispam@math.uni.wroc.pl> wrote: > Of course, real question is: why C standard insist on > putting implementation limits in conformance part? Minimum limits are important because without them, conformance is impossible to establish. The abstraction grammar and sematics of the language is such that no limits are placed on the size and complexity of a program. Yet, no implementation can support an arbitrarily large and complex program. There will be inputs to an implementation that cause it to fail. Therefore, without specifying minimum limits, the notion of conformance becomes meaningless. If no limit is placed on how large and complex a strictly conforming program may be that implementations are required to handle, then, for any given implementation, we can find a strictly conforming program which breaks it. In so doing we can declare every implementation to be nonconforming. Limits allow us to say, "although program X breaks implementation Y, program X is beyond the conformance limits, and therefore Y is not judged to be nonconforming due to failing to handle X" or else "program X breaks implementation Y, and program X does not exceed any implementation limit; thus Y may be nonconforming."(*) The hapless EcmaScript (i.e. Javascript) standard makes this mistake; it describes the abstract language only without specifying any minimum limits on what an implementation must handle to be considered conforming. Therefore, no Javascript engine is conforming to EcmaScript. --- * Though there is wording in the standard about a conforming implementation having to be capable of translating at least one strictly conforming program that exercises every minimum limit. It doesn't say that a conforming implementation has to translate *all possible* such programs, and it doesn't say who gets to choose the program: the implementor, or the programmer/user. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2022-08-26 00:22 +0000 |
| Message-ID | <te93nv$1ck9$1@gioia.aioe.org> |
| In reply to | #167207 |
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
> On 2022-08-25, antispam@math.uni.wroc.pl <antispam@math.uni.wroc.pl> wrote:
> > Of course, real question is: why C standard insist on
> > putting implementation limits in conformance part?
>
> Minimum limits are important because without them, conformance
> is impossible to establish.
You can give "partial correctness" statement: if implementation
can handle the program, then results will satify requirement
of the standard. This is actually pretty strong statement,
the "can handle" part can be easily checked experimentally.
And if you have simple program that your compiler can not
handle, then maybe there is time to change your vendor?
In other words, "can handle" part is really quality of
implmentation issue and since it is easy to verify by customers
it is best to leave it to the market.
Of course, there is question if your vendor claim about
conformance is true. But limits really does not change it:
if compiler can not handle resonable testsuite, then
that is enough reasons to change to different compiler.
> The abstraction grammar and sematics of the language is such that no
> limits are placed on the size and complexity of a program.
>
> Yet, no implementation can support an arbitrarily large
> and complex program. There will be inputs to an implementation
> that cause it to fail.
Sure.
> Therefore, without specifying minimum limits, the notion of conformance
> becomes meaningless. If no limit is placed on how large and complex a
> strictly conforming program may be that implementations are required
> to handle, then, for any given implementation, we can find a
> strictly conforming program which breaks it. In so doing we can declare
> every implementation to be nonconforming.
Yes, if you insist on handling _every_ strictly conforming
program. But as explanied weaker statement is still
quite useful.
> Limits allow us to say, "although program X breaks implementation Y,
> program X is beyond the conformance limits, and therefore Y is not
> judged to be nonconforming due to failing to handle X" or else
> "program X breaks implementation Y, and program X does not exceed
> any implementation limit; thus Y may be nonconforming."(*)
AFAICS program I gave does not violate any minimal limits,
so limits are of no help here. And if you interprets the
statement as "there exist program with given features that
is handled correctly", such statement is meanigless as
formal conformace requirement: standard CS excercise is
to write program that prints its own source. A little
variation is to write program that checks that its
source is on standard input and then outputs its binary
on standard output. With a little more effort you
can ensure that binary is quite small and source has
all features specified in section about environmental
limits. So in "there exits" version of requirements we
get completaly useless conformant self-compiling compiler,
which can not compile anything else.
Of course, it is not what was is intended. So as a
formal statement section about limits is useless, and
can only be taken as intent. But, AFACS saying
explicitely about intent would be much better.
Probably already what is in footnote would be good
enough: "Implementations are encouraged to avoid imposing
fixed translation limits whenever possible".
> The hapless EcmaScript (i.e. Javascript) standard makes this mistake;
> it describes the abstract language only without specifying any
> minimum limits on what an implementation must handle to be considered
> conforming. Therefore, no Javascript engine is conforming to EcmaScript.
Do they write "implementation must handle every correct program" or
equivalent of that? Pascal standard simply says that implementation
may have capacity limits and reject program due to this. But
if program is accepted, it must be handled as specified.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <480-992-1380@kylheku.com> |
|---|---|
| Date | 2022-08-26 16:48 +0000 |
| Message-ID | <20220826094252.498@kylheku.com> |
| In reply to | #167227 |
On 2022-08-26, antispam@math.uni.wroc.pl <antispam@math.uni.wroc.pl> wrote: > Kaz Kylheku <480-992-1380@kylheku.com> wrote: >> On 2022-08-25, antispam@math.uni.wroc.pl <antispam@math.uni.wroc.pl> wrote: >> > Of course, real question is: why C standard insist on >> > putting implementation limits in conformance part? >> >> Minimum limits are important because without them, conformance >> is impossible to establish. > > You can give "partial correctness" statement: if implementation > can handle the program, then results will satify requirement > of the standard. The eproblem with that reasoning is that certain flaws in the implementation coudl be doishonestly reframed as being instances of it not "handling" the program. You still need the *existence* of some programs that are handled. If an implementation does not handle *any* program whatsoever, citing that it is too big or complex, is that implementation conforming? What if handles exactly one program, which is useless: is that enough? > the "can handle" part can be easily checked experimentally. > And if you have simple program that your compiler can not > handle, then maybe there is time to change your vendor? > In other words, "can handle" part is really quality of > implmentation issue and since it is easy to verify by customers > it is best to leave it to the market. > > Of course, there is question if your vendor claim about > conformance is true. But limits really does not change it: > if compiler can not handle resonable testsuite, then > that is enough reasons to change to different compiler. But you have to define "reasonable testsuite". One person might think that a reasonable testsuite only has to test whether the compiler handles lines up to 512 characters, but tests expression nesting to 256 levels. Another's engineer's reasonable testsuite might have 4095 character lines, but pobe expression nesting to only 32 levels. Test suites contain tests, and test are specific instances of inputs with concrete values of parameters; someone has to decide what they are.
[toc] | [prev] | [next] | [standalone]
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2022-08-25 03:01 -0700 |
| Message-ID | <d3626730-882e-4ead-8321-85903aa68217n@googlegroups.com> |
| In reply to | #167206 |
On Thursday, 25 August 2022 at 03:33:57 UTC+1, anti...@math.uni.wroc.pl wrote:
> In draft standard (n3047.pdf) I see:
>
> : A conforming hosted implementation shall accept any strictly
> : conforming program.
>
> We also have:
>
> : A strictly conforming program shall use only those features of
> : the language and library specified in this document. It shall
> : not produce output dependent on any unspecified, undefined, or
> : implementation-defined behavior, and shall not exceed any minimum
> : implementation limit.
>
> Take the following program:
>
> #define x1(y) y + y
> #define x2(y) x1(x1(y))
> #define x4(y) x2(x2(y))
> #define x8(y) x4(x4(y))
> #define x16(y) x8(x8(y))
> #define x32(y) x16(x16(y))
> #define x48(y) x16(x32(y))
>
> #include <stdio.h>
> int main(void) {
> long long foo = x48(1LL);
> long long bar = 1024LL;
> bar *= bar;
> bar *= bar;
> bar *= 1024LL;
> if (foo < bar) {
> printf("OK\n");
> } else {
> printf("failed\n");
> }
> return 0;
> }
> In principle compiler which is doing aggressive constant
> folding during macro expanson could easily compile this
> program, but it is not clear if any is doing this.
I don't think it's possible. The preprocessor doesn't understand C expressions. The only expressions it knows about are used with #if, and those have their own rules.
Evaluating a C expression, so that `2 + 2` yields the token '4', requires knowledge of C types, but also, if the full sequence was `2 + 2 * 3`, knowledge of C's operator precedences.
> And quite likely one could came out with more complicated
> examples.
You can always break a compiler if intent on doing so.
(But yours is a good example of why I don't like 'constexpr' in a language, where you execute arbitrary functions at compile-time.
A program may have 100 complex functions that take a long time to evaluate (and may generate MBs of extra data in executables), but at runtime only one my be executed, or none.)
> Of course, real question is: why C standard insist on
> putting implementation limits in conformance part?
I think that is pretty much meaningless.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2022-08-25 14:29 +0000 |
| Message-ID | <te8111$11ga$1@gioia.aioe.org> |
| In reply to | #167210 |
bart c <bart4858@gmail.com> wrote:
> On Thursday, 25 August 2022 at 03:33:57 UTC+1, anti...@math.uni.wroc.pl wrote:
> > In draft standard (n3047.pdf) I see:
> >
> > : A conforming hosted implementation shall accept any strictly
> > : conforming program.
> >
> > We also have:
> >
> > : A strictly conforming program shall use only those features of
> > : the language and library specified in this document. It shall
> > : not produce output dependent on any unspecified, undefined, or
> > : implementation-defined behavior, and shall not exceed any minimum
> > : implementation limit.
> >
> > Take the following program:
> >
> > #define x1(y) y + y
> > #define x2(y) x1(x1(y))
> > #define x4(y) x2(x2(y))
> > #define x8(y) x4(x4(y))
> > #define x16(y) x8(x8(y))
> > #define x32(y) x16(x16(y))
> > #define x48(y) x16(x32(y))
> >
> > #include <stdio.h>
> > int main(void) {
> > long long foo = x48(1LL);
> > long long bar = 1024LL;
> > bar *= bar;
> > bar *= bar;
> > bar *= 1024LL;
> > if (foo < bar) {
> > printf("OK\n");
> > } else {
> > printf("failed\n");
> > }
> > return 0;
> > }
>
> > In principle compiler which is doing aggressive constant
> > folding during macro expanson could easily compile this
> > program, but it is not clear if any is doing this.
>
> I don't think it's possible. The preprocessor doesn't understand C expressions. The only expressions it knows about are used with #if, and those have their own rules.
>
> Evaluating a C expression, so that `2 + 2` yields the token '4', requires knowledge of C types, but also, if the full sequence was `2 + 2 * 3`, knowledge of C's operator precedences.
Sure. A lot of C macros define functions or constants, so it makes
sense for compiler to spend some time trying to understand macros.
In case above it is resonably easy to exclude possiblity of token
pasting or stringification. Basicaly, only sensible possiblity
is that macro expansion will produce C expression. Given
part like '1 + 1 + ... + 1 + 1' the outer ones may be arguments
to some operator outside, if it binds more tightly than +,
but inner ones will simply produce value, so already during
macroexpansion compiler may fold expansions of x?? macros
to form 1 + val + 1 with val being a long long integer constant.
When such thing appers as argument to x1 we get
1 + val + 1 + 1 + val + 1
which can be folded to
1 + val2 + 1
with val2 = 2*val + 2
> > And quite likely one could came out with more complicated
> > examples.
>
> You can always break a compiler if intent on doing so.
>
> (But yours is a good example of why I don't like 'constexpr' in a language, where you execute arbitrary functions at compile-time.
>
> A program may have 100 complex functions that take a long time to evaluate (and may generate MBs of extra data in executables), but at runtime only one my be executed, or none.)
Actually, 'constexpr' is useful, because instead of doing
computation each time at runtime it can be done once at
compile time. IMO main problem with 'constexpr' is that
it is quite limited. In one of languages I use one can
write
#_< arbitrary code >_#
and the construct will be effectively replaced by output of
'arbitrary code'. In simple use it can fill array with
values computed at compile time. It can get effect of
your 'stringinclude'. But it can do more: '#_<' triggers
recursive invocation of compiler, code up to matching '>_#'
is compiled and run, output is fed back to original compilation.
So this construct can perform arbitrary precomputation
like building tree of comparisons or maybe perfect hash
function to do efficient search.
'constexpr' is much more limited. In C++ people use
so called 'template metaprogramming' to get more
complex done at compile time.
Coming back to C, my example was useless. But with
smart macroexpansion similar examples can get some
effect that otherwise need 'constexpr'. And smart
macros could do things which are impossible with
'constexpr' that is generate code (and not only data).
Compared to 'constexpr' or '#_< ... >_#' construct
above macros have problem that compiler must
recognize possibility of optimization, otherwise
one would get extreme inefficiency at compile time
and/or runtime.
BTW: '#_< ... >_#' runs compiled code so code run
via this construct is as fast as code run at runtime.
Of course '#_< ... >_#' is inappropriate for C,
its full use depends on fact that source tokens
are representable in the language as data.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-08-25 08:10 -0700 |
| Message-ID | <86zgfss6k3.fsf@linuxsc.com> |
| In reply to | #167211 |
antispam@math.uni.wroc.pl writes: > IMO main problem with 'constexpr' is that > it is quite limited. If constexpr functions are allowed, constexpr is Turing complete, is it not?
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2022-08-25 16:23 +0000 |
| Message-ID | <te87mu$73l$1@gioia.aioe.org> |
| In reply to | #167212 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> antispam@math.uni.wroc.pl writes:
>
> > IMO main problem with 'constexpr' is that
> > it is quite limited.
>
> If constexpr functions are allowed, constexpr is
> Turing complete, is it not?
Are they allowed? I did not digest whole n3047 yet,
but it looks that 'constexpr' is limited to declaring
that some named values may take part in constant
expressions.
However, I think that Turing completeness is not
very relevant here. Already using preprocessor one
can specify very complex computations. The question
is how convenient it is and what you can do with
result. AFAICS 'constexpr' is limited to initialization
and parameters. One can not generate arbitrary code
from constexpr (unlike macros). If 'constexpr'
functions were defined requiring that all steps
are constexpr one would be limited to purely functional
style. And currently 'constexpr' is forced to live
in its own world, so if you need "the same" computation
in 'constexpr' and in regular code you need to
copy code and rename identifiers to avoid clashes.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-25 20:53 +0200 |
| Message-ID | <te8gfs$3nb4b$2@dont-email.me> |
| In reply to | #167215 |
On 25/08/2022 18:23, antispam@math.uni.wroc.pl wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> antispam@math.uni.wroc.pl writes: >> >>> IMO main problem with 'constexpr' is that >>> it is quite limited. >> >> If constexpr functions are allowed, constexpr is >> Turing complete, is it not? > > Are they allowed? I did not digest whole n3047 yet, > but it looks that 'constexpr' is limited to declaring > that some named values may take part in constant > expressions. That is correct - C23 has constexpr objects, but not functions.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-08-26 06:56 -0700 |
| Message-ID | <86r113rtuo.fsf@linuxsc.com> |
| In reply to | #167215 |
antispam@math.uni.wroc.pl writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> antispam@math.uni.wroc.pl writes: >> >>> IMO main problem with 'constexpr' is that >>> it is quite limited. >> >> If constexpr functions are allowed, constexpr is >> Turing complete, is it not? > > [...] > If 'constexpr' > functions were defined requiring that all steps > are constexpr one would be limited to purely functional > style. And currently 'constexpr' is forced to live > in its own world, so if you need "the same" computation > in 'constexpr' and in regular code you need to > copy code and rename identifiers to avoid clashes. TTBOMK neither of those things is true in C++. I don't know what constexpr will look like in C23. Whatever it is, I figure it's only a matter of time before the C version of constexpr adopts at least most of the C++ semantics for constexpr.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-26 17:29 +0200 |
| Message-ID | <teaos1$ihf$1@dont-email.me> |
| In reply to | #167232 |
On 26/08/2022 15:56, Tim Rentsch wrote: > antispam@math.uni.wroc.pl writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> >>> antispam@math.uni.wroc.pl writes: >>> >>>> IMO main problem with 'constexpr' is that >>>> it is quite limited. >>> >>> If constexpr functions are allowed, constexpr is >>> Turing complete, is it not? >> >> [...] > >> If 'constexpr' >> functions were defined requiring that all steps >> are constexpr one would be limited to purely functional >> style. And currently 'constexpr' is forced to live >> in its own world, so if you need "the same" computation >> in 'constexpr' and in regular code you need to >> copy code and rename identifiers to avoid clashes. > > TTBOMK neither of those things is true in C++. I don't know > what constexpr will look like in C23. Whatever it is, I > figure it's only a matter of time before the C version of > constexpr adopts at least most of the C++ semantics for > constexpr. When constexpr functions were first introduced to C++ (in C++11), they were very limited - you basically had a single return statement, which could be what Waldek meant by "limited to purely functional style". They have been continually expanded in successive C++ standards, and now in C++23 you can have a great deal of code in them. In particular, you can have a lot of code that only makes sense if the function is /not/ evaluated at compile time - exception handling, inline assembly, virtual functions, etc. Of course the function won't be executed at compile time if the execution flow passes through something like inline assembly. But the idea is that you can have a single "constexpr" function that will be evaluated at compile time if given compile-time constant parameters, or at run time if used elsewhere. <https://en.cppreference.com/w/cpp/language/constexpr> 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.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-26 13:44 -0700 |
| Message-ID | <ac177ef7-3925-4541-ba56-fa52b6d83af6n@googlegroups.com> |
| In reply to | #167235 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-26 13:56 -0700 |
| Message-ID | <87zgfqk9l4.fsf@nosuchdomain.example.com> |
| In reply to | #167238 |
Thiago Adams <thiago.adams@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?
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3018.htm
Personally, I'm very glad C is getting constexpr.
--
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 | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-26 16:01 -0700 |
| Message-ID | <bed12ff3-aac9-44bc-8e49-301f7e1c7fcfn@googlegroups.com> |
| In reply to | #167239 |
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? > > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3018.htm > > Personally, I'm very glad C is getting constexpr. 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. 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. Imagine a header with a lot a constants that you don't use. All of them will have linkage? (maybe the linker can remove?) Do you have a motivation for constexpr? 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. This is like a programmer afraid of doing refactoring and instead it add more features that could be factored in one.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-28 10:27 +0200 |
| Message-ID | <tef8t7$j5cj$1@dont-email.me> |
| In reply to | #167241 |
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.
[toc] | [prev] | [next] | [standalone]
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2022-08-28 03:52 -0700 |
| Message-ID | <6226039d-81be-4a36-8a3c-56fcd6564658n@googlegroups.com> |
| In reply to | #167252 |
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.
'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.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-28 15:05 +0200 |
| Message-ID | <tefp6o$kk28$1@dont-email.me> |
| In reply to | #167253 |
(Please switch to a proper news client that gets the line lengths correct. Re-wrapping the mess made by google groups is often bearable, but not when you have pre-formatted text such as code snippets or lists. Following newsgroup standards is polite and helpful to others - remember, it's /your/ posts that end up mangled.) On 28/08/2022 12:52, 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!) > I said I might have preferred "const" to have some of the additional features that C++ "const" has, which is not the same thing. The different ways of expressing constants in C have different pros and cons. This is not unusual in real programming languages - just as most serious languages have multiple ways to express loops. Things might be different when someone creates a new programming language from scratch (especially one with little real-world usage), rather than one that has evolved over many decades and retains backwards compatibility as far as practically possible. (I'm snipping, without comment, anything you write about your personal little language as they are irrelevant here, and have been beaten to death many times over many years. The discussion in this branch of the thread is about new features of C.) > >> 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? > "constexpr" is in no way essential to programming in C - it doesn't let you write code that you could not write before. But it does (IMHO at least) let you write slightly better or safer code than before. A feature that is nice, but not hugely important, is not going to be added to a stable language such as C unless it is very cheap to do so. The usage of "constexpr" in C++ code has arguably spread enough now that it is familiar to many C programmers, as well as being well-established in many compilers - that makes it a "cheap" feature to add now, while it would have been an "expensive" feature in, say, C99. I believe "enum" was in K&R C, but there are others in the group who are better C historians than I. > > '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.) > The most important difference is that C23 does not have constexpr functions, just constexpr objects. > >>> 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.) > I too think "f(nullptr)" is clearer than "f(0)", and when programming in C++ I enable warnings to catch any accidental use of 0 as a null pointer.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-28 17:00 -0700 |
| Message-ID | <87zgfnj4vu.fsf@nosuchdomain.example.com> |
| In reply to | #167256 |
David Brown <david.brown@hesbynett.no> writes:
> (Please switch to a proper news client that gets the line lengths
> correct. Re-wrapping the mess made by google groups is often
> bearable, but not when you have pre-formatted text such as code
> snippets or lists. Following newsgroup standards is polite and
> helpful to others - remember, it's /your/ posts that end up mangled.)
Or copy your post from GG to a text editor, format it properly, and copy
it back to GG.
--
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 | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2022-08-29 15:16 -0700 |
| Message-ID | <d940d1c7-28f1-4979-a649-89c5dab44fb2n@googlegroups.com> |
| In reply to | #167256 |
On Sunday, 28 August 2022 at 14:05:42 UTC+1, David Brown wrote: > (Please switch to a proper news client that gets the line lengths > correct. Re-wrapping the mess made by google groups is often bearable, > but not when you have pre-formatted text such as code snippets or lists. > Following newsgroup standards is polite and helpful to others - > remember, it's /your/ posts that end up mangled.) All code I see on Google Groups is badly formatted (mainly, losing indentation and usually appearing in the wrong font. So reading via GG is a bigger issue.) > (I'm snipping, without comment, anything you write about your personal > little language as they are irrelevant here, and have been beaten to > death many times over many years. The discussion in this branch of the > thread is about new features of C.) I mentioned my stuff in in passing, including that special feature of my C compiler. It would be a mistake to completely dismiss things that people have achieved in similar languages. (And mine is one of the closest languages to C of the ones that I've come across; it just looks very different.) There are some nifty features that have been tried and tested, and more importantly are implemented in a simple manner.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-30 09:38 +0200 |
| Message-ID | <tekeoq$1dvo6$1@dont-email.me> |
| In reply to | #167310 |
On 30/08/2022 00:16, bart c wrote: > On Sunday, 28 August 2022 at 14:05:42 UTC+1, David Brown wrote: >> (Please switch to a proper news client that gets the line lengths >> correct. Re-wrapping the mess made by google groups is often >> bearable, but not when you have pre-formatted text such as code >> snippets or lists. Following newsgroup standards is polite and >> helpful to others - remember, it's /your/ posts that end up >> mangled.) > > All code I see on Google Groups is badly formatted (mainly, losing > indentation and usually appearing in the wrong font. So reading via > GG is a bigger issue.) > Another good reason to use a real newsreader! (Or find some way to persuade google to make a decent web-based newsreader. Surely they could do better, and make everyone happy.) > >> (I'm snipping, without comment, anything you write about your >> personal little language as they are irrelevant here, and have been >> beaten to death many times over many years. The discussion in this >> branch of the thread is about new features of C.) > > I mentioned my stuff in in passing, including that special feature of > my C compiler. > > It would be a mistake to completely dismiss things that people have > achieved in similar languages. (And mine is one of the closest > languages to C of the ones that I've come across; it just looks very > different.) > > 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. This is very different from, say, a thread discussing possible extensions to C for those that write C compilers. I also disagree that your language counts as "close to C", or "tried and tested". I am sorry if it hurts your feelings (and as always, I don't mean to belittle your impressive achievements), but a personal language written by one person and used by one person is not an established language. It has to be used by many people in many circumstances to be "tried and tested". 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++.
[toc] | [prev] | [next] | [standalone]
Page 1 of 12 [1] 2 3 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web