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 | 16 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 12 of 12 — ← Prev page 1 … 10 11 [12]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-30 08:50 -0700 |
| Message-ID | <8c9fe846-b5a8-4467-9da5-0057536b84e7n@googlegroups.com> |
| In reply to | #167336 |
On Tuesday, August 30, 2022 at 12:08:36 PM UTC-3, David Brown wrote: ... > You are advocating for option 2 - throw out the old, outdated, or > replaced features when there are new and better ways to handle things. The option I want (I wish I had time to create an experiment) is to create a new language that is like C. You can use the same code but it is a completely new language! In this language #define will do what beginners think it does that is - create a constant. The same for #include. It will "import" declarations just like beginners think it does and more.
[toc] | [prev] | [next] | [standalone]
| From | Opus <ifonly@youknew.org> |
|---|---|
| Date | 2022-08-27 20:04 +0200 |
| Message-ID | <tedmb3$1anl$1@gioia.aioe.org> |
| In reply to | #167239 |
Le 26/08/2022 à 22:56, Keith Thompson a écrit : > 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. Same here. And I fail to see what woudn't be good with constexpr. I'd also like to see modules! (That I don't think are even mentioned for C23?) But not as taken from C++. C++ modules are pretty meh at this point IMHO.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-25 17:03 +0100 |
| Message-ID | <87czcowbsa.fsf@bsb.me.uk> |
| In reply to | #167210 |
bart c <bart4858@gmail.com> writes: > (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.) You don't have to use a feature, just because it's there. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-25 09:50 -0700 |
| Message-ID | <87v8qgw9m1.fsf@nosuchdomain.example.com> |
| In reply to | #167210 |
bart c <bart4858@gmail.com> writes:
> On Thursday, 25 August 2022 at 03:33:57 UTC+1, anti...@math.uni.wroc.pl wrote:
[...]
>> 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.
`2 + 2 * 3` is a valid preprocessor expression, usable in `#if`, so the
preprocessor has to be able to evaluate it at compile time.
--
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-25 12:04 -0700 |
| Message-ID | <e1fb5af7-67c7-4078-b7cb-d0d0ac5c9363n@googlegroups.com> |
| In reply to | #167216 |
On Thursday, 25 August 2022 at 17:50:45 UTC+1, Keith Thompson wrote: > bart c <bart...@gmail.com> writes: > > On Thursday, 25 August 2022 at 03:33:57 UTC+1, anti...@math.uni.wroc.pl wrote: > [...] > >> 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. > `2 + 2 * 3` is a valid preprocessor expression, usable in `#if`, so the > preprocessor has to be able to evaluate it at compile time. My post made a distinction between a preprocessor expression '2+2*3', used in contexts like `#if`, and the C expression '2+2*3', used outside that special CPP context, and which can incorporate a bunch of other C syntax that the CPP should know nothing about, even apart from the type rules of C. The logistics just don't work. Even if it could isolate "(2+2)" and turn that into "4", which you might think is a safe conversion, that token sequence may itself be processed further when passed as another macro parameter, eg. it could be stringified. Then you need it to stay as it is. C's type rules (on 64-bit machines) mean that arithmetic is normally done at 32 bits, but CPP arithmetic is done at 64 bits. Maybe this reduction is possible with a hairy enough processors (even more hairy than they already are just to do their job), but the OP hasn't observed that to be the case.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-25 12:25 -0700 |
| Message-ID | <87czcoktvs.fsf@nosuchdomain.example.com> |
| In reply to | #167220 |
bart c <bart4858@gmail.com> writes:
> On Thursday, 25 August 2022 at 17:50:45 UTC+1, Keith Thompson wrote:
>> bart c <bart...@gmail.com> writes:
>> > On Thursday, 25 August 2022 at 03:33:57 UTC+1, anti...@math.uni.wroc.pl wrote:
>> [...]
>> >> 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.
Yes, but the rules are similar, and the operator precedence rules are
exactly the same.
>> > 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.
>
>> `2 + 2 * 3` is a valid preprocessor expression, usable in `#if`, so the
>> preprocessor has to be able to evaluate it at compile time.
>
> My post made a distinction between a preprocessor expression '2+2*3',
> used in contexts like `#if`, and the C expression '2+2*3', used
> outside that special CPP context, and which can incorporate a bunch of
> other C syntax that the CPP should know nothing about, even apart from
> the type rules of C.
>
> The logistics just don't work. Even if it could isolate "(2+2)" and
> turn that into "4", which you might think is a safe conversion, that
> token sequence may itself be processed further when passed as another
> macro parameter, eg. it could be stringified. Then you need it to stay
> as it is.
>
> C's type rules (on 64-bit machines) mean that arithmetic is normally
> done at 32 bits, but CPP arithmetic is done at 64 bits.
>
> Maybe this reduction is possible with a hairy enough processors (even
> more hairy than they already are just to do their job), but the OP
> hasn't observed that to be the case.
I think I skipped over the "yields the token '4'" part of what you wrote
above.
`2 + 2 * 3` is a valid preprocessor expression, usable in `#if` In that
context, the preprocessor has to evaluate it -- not to the token `8`,
but to the value 8`.
Outside a preprocessor directive, it's a valid expression (if it appears
in an expression context). Some contexts require it to be evaluated at
compile time -- and most compilers are likely to do so regardless of the
context. For example, given `int n = 2 + 2 * 3;` I wouldn't expect any
production quality compiler to generate add and multiply instructions.
But you were talking about something like having the preprocessor
replace the token sequence `2 + 2 * 3` with the token `8` outside any
preprocessor directives. Yes, it would be very difficult to do that
correctly, and the only purpose would be guard against exploding macro
expansions as in the parent article of this thread. It's probably just
not worth doing.
(BTW. I had to reboot my computer after attempting to compile the
program in the parent article of this thread. Beware.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-08-25 08:23 -0700 |
| Message-ID | <86v8qgs5ww.fsf@linuxsc.com> |
| In reply to | #167206 |
antispam@math.uni.wroc.pl writes: > 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: [..cut..] > > Anyway, gcc runs out of memory compiling this program and > other C compilers are also likely to run out of memory. > [...] I suspect you are confusing the notion of accepting a program and the capability of being able to compile a program successfully. The C standard does not say that implementations must be able to compile successfully any strictly conforming program, only that they must accept them. Not the same thing. At any point in compiling a program (assuming a #error directive has not yet been seen) a compiler is free to say "I don't yet see anything wrong with this program, but it's too large for me to handle." The compiler is accepting the program by virtue of not rejecting it. > Of course, real question is: why C standard insist on > putting implementation limits in conformance part? The answer to this question seems obvious: if no limits are stated about what programs must be accepted, then all programs must be accepted. To say that the other way around, putting in some limits as to what must be accepted gives the implementation permission, in those cases, to reject any program that exceeds a given stated limit. > 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. Again, the C standard requires only that the program not be rejected, and not that it be "handled" in any useful way.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-25 09:58 -0700 |
| Message-ID | <87r114w98x.fsf@nosuchdomain.example.com> |
| In reply to | #167213 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> antispam@math.uni.wroc.pl writes:
>
>> 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: [..cut..]
>>
>> Anyway, gcc runs out of memory compiling this program and
>> other C compilers are also likely to run out of memory.
>> [...]
>
> I suspect you are confusing the notion of accepting a program and
> the capability of being able to compile a program successfully.
> The C standard does not say that implementations must be able to
> compile successfully any strictly conforming program, only that
> they must accept them. Not the same thing. At any point in
> compiling a program (assuming a #error directive has not yet been
> seen) a compiler is free to say "I don't yet see anything wrong
> with this program, but it's too large for me to handle." The
> compiler is accepting the program by virtue of not rejecting it.
As I recall, you have your own definition of "accept" that I was never
able to figure out. In particular, you believe that a compiler can
"accept" a program even if it dies with a stack overflow.
Can you clarify what you mean by "accept"?
If you have the program from the top of this thread, which causes a
compiler to crash, followed by a #error directive, does the compiler
"accept" that program if it never sees the #error directive?
My impression is that you're warping the meaning of "accept" to force
the requirement that "A conforming hosted implementation shall accept
any strictly conforming program." to make sense. In my opinion, a
compiler that terminates a compilation with a message that it has run
out of memory, or that simply crashes, has not "accepted" the program.
It's impossible to satisfy that requirement in all cases, but most
people accept the intent rather than the literal meaning (though it
might be nice to refine the wording).
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-08-26 07:51 -0700 |
| Message-ID | <86mtbrrrb4.fsf@linuxsc.com> |
| In reply to | #167218 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> antispam@math.uni.wroc.pl writes: >> >>> 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: [..cut..] >>> >>> Anyway, gcc runs out of memory compiling this program and >>> other C compilers are also likely to run out of memory. >>> [...] >> >> I suspect you are confusing the notion of accepting a program and >> the capability of being able to compile a program successfully. >> The C standard does not say that implementations must be able to >> compile successfully any strictly conforming program, only that >> they must accept them. Not the same thing. At any point in >> compiling a program (assuming a #error directive has not yet been >> seen) a compiler is free to say "I don't yet see anything wrong >> with this program, but it's too large for me to handle." The >> compiler is accepting the program by virtue of not rejecting it. > > As I recall, you have your own definition of "accept" that I was never > able to figure out. In particular, you believe that a compiler can > "accept" a program even if it dies with a stack overflow. > > Can you clarify what you mean by "accept"? I think my point of view is easy to explain: The opposite of "accept" is "reject" (a term not used in the C standard, but that isn't important to this explanation). A compiler (or implementation) "rejects" a program if it refuses to compile the program. That is not if the compiler _is unable_ to compile the program, but only if the compiler _refuses_ to compile the program. Note that a compiler can refuse to compile a program if it can't make sense of the program, as for example if there is a syntax error. Even so, such cases fall into the category of refusing to compile the program, as opposed to, let us say, running out of memory, which falls under the heading of being unable to compile the program, and not of refusing to compile the program. If a compiler doesn't refuse to compile a program then it accepts the program; it's always either one or the other. > If you have the program from the top of this thread, which causes a > compiler to crash, followed by a #error directive, does the compiler > "accept" that program if it never sees the #error directive? I don't think it matters whether that counts as "accepting" the program or not. The rule for a #error directive is only that an implementation cannot _successfully translate_ a program with an (unskipped) #error directive. Whether the compiler explicitly rejects the program (or translation unit), or crashes trying to compile it, the implementation still has not successfully translated the program (or that part of the program). Thus what the C standard decrees is correctly observed. > My impression is that you're warping the meaning of "accept" to force > the requirement that "A conforming hosted implementation shall accept > any strictly conforming program." to make sense. In my opinion, a > compiler that terminates a compilation with a message that it has run > out of memory, or that simply crashes, has not "accepted" the program. > It's impossible to satisfy that requirement in all cases, but most > people accept the intent rather than the literal meaning (though it > might be nice to refine the wording). I believe I understand your reaction. My notion of "accept" is simple, consistent, and easy to understand. Also it gives results that obey what the C standard says, without having to resort to talking about "intent" or "literal meaning". Personally I think that makes it a better fit for the C standard is trying to express. You are welcome to a different point of view if that is your preference. I don't see anything in your statement above that your reaction is anything other than that you have a different opinion.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-26 11:50 -0700 |
| Message-ID | <874jxyltz1.fsf@nosuchdomain.example.com> |
| In reply to | #167234 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> antispam@math.uni.wroc.pl writes:
>>>
>>>> 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: [..cut..]
>>>>
>>>> Anyway, gcc runs out of memory compiling this program and
>>>> other C compilers are also likely to run out of memory.
>>>> [...]
>>>
>>> I suspect you are confusing the notion of accepting a program and
>>> the capability of being able to compile a program successfully.
>>> The C standard does not say that implementations must be able to
>>> compile successfully any strictly conforming program, only that
>>> they must accept them. Not the same thing. At any point in
>>> compiling a program (assuming a #error directive has not yet been
>>> seen) a compiler is free to say "I don't yet see anything wrong
>>> with this program, but it's too large for me to handle." The
>>> compiler is accepting the program by virtue of not rejecting it.
>>
>> As I recall, you have your own definition of "accept" that I was never
>> able to figure out. In particular, you believe that a compiler can
>> "accept" a program even if it dies with a stack overflow.
>>
>> Can you clarify what you mean by "accept"?
>
> I think my point of view is easy to explain:
>
> The opposite of "accept" is "reject" (a term not used in the C
> standard, but that isn't important to this explanation).
>
> A compiler (or implementation) "rejects" a program if it refuses
> to compile the program. That is not if the compiler _is unable_
> to compile the program, but only if the compiler _refuses_ to
> compile the program.
>
> Note that a compiler can refuse to compile a program if it can't
> make sense of the program, as for example if there is a syntax
> error. Even so, such cases fall into the category of refusing
> to compile the program, as opposed to, let us say, running out
> of memory, which falls under the heading of being unable to
> compile the program, and not of refusing to compile the program.
>
> If a compiler doesn't refuse to compile a program then it accepts
> the program; it's always either one or the other.
>
>
>> If you have the program from the top of this thread, which causes a
>> compiler to crash, followed by a #error directive, does the compiler
>> "accept" that program if it never sees the #error directive?
>
> I don't think it matters whether that counts as "accepting" the
> program or not. The rule for a #error directive is only that an
> implementation cannot _successfully translate_ a program with an
> (unskipped) #error directive. Whether the compiler explicitly
> rejects the program (or translation unit), or crashes trying to
> compile it, the implementation still has not successfully
> translated the program (or that part of the program). Thus what
> the C standard decrees is correctly observed.
>
>> My impression is that you're warping the meaning of "accept" to force
>> the requirement that "A conforming hosted implementation shall accept
>> any strictly conforming program." to make sense. In my opinion, a
>> compiler that terminates a compilation with a message that it has run
>> out of memory, or that simply crashes, has not "accepted" the program.
>> It's impossible to satisfy that requirement in all cases, but most
>> people accept the intent rather than the literal meaning (though it
>> might be nice to refine the wording).
>
> I believe I understand your reaction.
>
> My notion of "accept" is simple, consistent, and easy to
> understand. Also it gives results that obey what the C standard
> says, without having to resort to talking about "intent" or
> "literal meaning". Personally I think that makes it a better
> fit for the C standard is trying to express. You are welcome
> to a different point of view if that is your preference. I don't
> see anything in your statement above that your reaction is
> anything other than that you have a different opinion.
Thank you for the explanation. I understand what you mean by "accept",
but in my opinion it's ... I don't quite want to say it's wrong, but it
seems at odds with ordinary English usage.
If I had not written this response, I hope you wouldn't say that I have
*accepted* your definition.
If an employer offers you a job and you say yes and sign the paperwork,
you've accepted it. If you say no, you've rejected it. If you do
nothing (say, if the offer letter was lost in the mail), by your
definition you've "accepted" the offer. That seems absurd.
"Accept" and "reject" are exclusive, but not exhaustive. It's entirely
possible to neither accept nor reject something.
N1570 4p6 says:
A conforming hosted implementation shall accept any strictly
conforming program.
1p2 says:
This International Standard does not specify
[...]
- 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;
(And the latest C23 draft has the same wording.)
My take on this is that 4p6 is not worded quite as precisely as it could
be. It's obvious to me that an implementation does not "accept" a
program that exceeds its capacity by, for example, causing the compiler
to crash with a stack overflow.
Since as far as I know no compiler implementers are spending time
ensuring their compilers have infinite resources so they can satisfy
4p6, and no users are expecting them to, it's not clear that it
needs to be reworded. My own preference would be to update 4p6 to
say something like:
A conforming hosted implementation shall accept any strictly
conforming program that does not exceed its capacity.
but it's probably ok the way it is, given that the standard already
explicitly acknowledges that capacity limitations exist.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-08-26 19:45 -0700 |
| Message-ID | <86fshis8ua.fsf@linuxsc.com> |
| In reply to | #167237 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>>> antispam@math.uni.wroc.pl writes: >>>> >>>>> 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: [..cut..] >>>>> >>>>> Anyway, gcc runs out of memory compiling this program and >>>>> other C compilers are also likely to run out of memory. >>>>> [...] >>>> >>>> I suspect you are confusing the notion of accepting a program and >>>> the capability of being able to compile a program successfully. >>>> The C standard does not say that implementations must be able to >>>> compile successfully any strictly conforming program, only that >>>> they must accept them. Not the same thing. At any point in >>>> compiling a program (assuming a #error directive has not yet been >>>> seen) a compiler is free to say "I don't yet see anything wrong >>>> with this program, but it's too large for me to handle." The >>>> compiler is accepting the program by virtue of not rejecting it. >>> >>> As I recall, you have your own definition of "accept" that I was never >>> able to figure out. In particular, you believe that a compiler can >>> "accept" a program even if it dies with a stack overflow. >>> >>> Can you clarify what you mean by "accept"? >> >> I think my point of view is easy to explain: >> >> The opposite of "accept" is "reject" (a term not used in the C >> standard, but that isn't important to this explanation). >> >> A compiler (or implementation) "rejects" a program if it refuses >> to compile the program. That is not if the compiler _is unable_ >> to compile the program, but only if the compiler _refuses_ to >> compile the program. >> >> Note that a compiler can refuse to compile a program if it can't >> make sense of the program, as for example if there is a syntax >> error. Even so, such cases fall into the category of refusing >> to compile the program, as opposed to, let us say, running out >> of memory, which falls under the heading of being unable to >> compile the program, and not of refusing to compile the program. >> >> If a compiler doesn't refuse to compile a program then it accepts >> the program; it's always either one or the other. >> >> >>> If you have the program from the top of this thread, which causes a >>> compiler to crash, followed by a #error directive, does the compiler >>> "accept" that program if it never sees the #error directive? >> >> I don't think it matters whether that counts as "accepting" the >> program or not. The rule for a #error directive is only that an >> implementation cannot _successfully translate_ a program with an >> (unskipped) #error directive. Whether the compiler explicitly >> rejects the program (or translation unit), or crashes trying to >> compile it, the implementation still has not successfully >> translated the program (or that part of the program). Thus what >> the C standard decrees is correctly observed. >> >>> My impression is that you're warping the meaning of "accept" to force >>> the requirement that "A conforming hosted implementation shall accept >>> any strictly conforming program." to make sense. In my opinion, a >>> compiler that terminates a compilation with a message that it has run >>> out of memory, or that simply crashes, has not "accepted" the program. >>> It's impossible to satisfy that requirement in all cases, but most >>> people accept the intent rather than the literal meaning (though it >>> might be nice to refine the wording). >> >> I believe I understand your reaction. >> >> My notion of "accept" is simple, consistent, and easy to >> understand. Also it gives results that obey what the C standard >> says, without having to resort to talking about "intent" or >> "literal meaning". Personally I think that makes it a better >> fit for the C standard is trying to express. You are welcome >> to a different point of view if that is your preference. I don't >> see anything in your statement above that your reaction is >> anything other than that you have a different opinion. > > Thank you for the explanation. I understand what you mean by > "accept", but in my opinion it's ... I don't quite want to say > it's wrong, but it seems at odds with ordinary English usage. If you look up the word "accept" in a few online dictionaries you will find that it has several definitions. Some of those definitions are consistent with the usage I have explained. (Incidentally I have confirmed that view with disinterested third parties.) > If I had not written this response, I hope you wouldn't say > that I have *accepted* your definition. I think you have accepted my comments as reflecting my view, even if your own views are different. A statement can be accepted without agreeing with it. > If an employer offers you a job and you say yes and sign the > paperwork, you've accepted it. If you say no, you've rejected it. > If you do nothing (say, if the offer letter was lost in the mail), > by your definition you've "accepted" the offer. That seems > absurd. The word "accept" has more than one meaning. > "Accept" and "reject" are exclusive, but not exhaustive. It's > entirely possible to neither accept nor reject something. The word "accept" has more than one meaning. So does the word "reject". It seems to me, if a word used in the C standard (and one not defined by the C standard nor in any of the normative references) has more than one meaning, what makes the most sense is to choose the meaning that provides the best fit with how the word is used and how it relates to other passages in the C standard. That is what I've done. Conversely, it seems odd to insist on a different meaning for the word, a meaning that presents difficulties when considered in conjunction with other parts of the C standard. It appears that that is what you have done. > N1570 4p6 says: > A conforming hosted implementation shall accept any strictly > conforming program. > > 1p2 says: > This International Standard does not specify > [...] > - 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; > > (And the latest C23 draft has the same wording.) > > My take on this is that 4p6 is not worded quite as precisely as > it could be. [...] My take on this is that you are interpreting passages in the C standard based on your own preconceptions of what the word "accept" means, rather than investigating the matter and accepting the inherent ambiguity of usage in the English language.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-26 22:03 -0700 |
| Message-ID | <87lerajn1f.fsf@nosuchdomain.example.com> |
| In reply to | #167242 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> My take on this is that you are interpreting passages in the C
> standard based on your own preconceptions of what the word
> "accept" means, rather than investigating the matter and
> accepting the inherent ambiguity of usage in the English
> language.
Based on past experience, debating this further would be a waste of my
time.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-08-27 08:14 -0700 |
| Message-ID | <86bks5sopz.fsf@linuxsc.com> |
| In reply to | #167243 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > [...] > >> My take on this is that you are interpreting passages in the C >> standard based on your own preconceptions of what the word >> "accept" means, rather than investigating the matter and >> accepting the inherent ambiguity of usage in the English >> language. > > Based on past experience, debating this further would be a waste > of my time. I don't know why you think of it as debate. I am expressing my opinions. You are expressing your opinions. As far as I know there has been no disagreement over any statement of fact. Do you feel some sort of need to convince other people that your opinions are "right"?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-27 11:23 -0700 |
| Message-ID | <87czclk0kh.fsf@nosuchdomain.example.com> |
| In reply to | #167244 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>
>>> My take on this is that you are interpreting passages in the C
>>> standard based on your own preconceptions of what the word
>>> "accept" means, rather than investigating the matter and
>>> accepting the inherent ambiguity of usage in the English
>>> language.
>>
>> Based on past experience, debating this further would be a waste
>> of my time.
>
> I don't know why you think of it as debate. I am expressing my
> opinions. You are expressing your opinions. As far as I know
> there has been no disagreement over any statement of fact. Do
> you feel some sort of need to convince other people that your
> opinions are "right"?
Yeah, definitely a waste of my time.
--
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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-08-25 12:41 -0700 |
| Message-ID | <te8j8g$3nja8$1@dont-email.me> |
| In reply to | #167206 |
On 8/24/2022 7:33 PM, antispam@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;
> }
[...]
Always keep chaos-pp in mind:
https://github.com/rofl0r/chaos-pp
A good benchmark for a preprocessor?
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <480-992-1380@kylheku.com> |
|---|---|
| Date | 2022-08-25 20:30 +0000 |
| Message-ID | <20220825124713.5@kylheku.com> |
| In reply to | #167206 |
On 2022-08-25, antispam@math.uni.wroc.pl <antispam@math.uni.wroc.pl> wrote:
> 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);
I can't find any limit in the C23 draft or C99 standard which your
program violates.
The closest one is that an implementation can have a limit as low as
4095 on the length of a logical line. Logical lines are what exists
before preprocessing; the output of preprocessing is a token sequence
that is no longer logical lines. Even if macro preprocessing produces
something that we may informally understand to be a huge "line", it is
not actually a line as far as the standard language is concerned.
Thus, you may have found a way to write a program which exhausts the
resources of the implemetnation, without violating a minimum limit.
Does that mean the implementations which don't handle this program
are nonconforming?
That isn't the case because the criterion for conformance isn't
that an implementation must handle *all* strictly conforming programs
that are within the limits.
The standard only requires that an implementation must be capable of
translating *a* program which exercises each of the limits.
Conformance is existentially quantified, not universally.
The exact details are between the implementor and the user; the
standard doesn't dictate all the details about how implementors and
users should come to an agreement whereby the users accept the
implementation.
Your program is alluded to in this statement in the 1 Scope section:
"This document does not specify ... ---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."
You have made such a program with respect to a particular
data-processing system and its C implementation. But that entire
consideration/situation is out of scope.
As a user, you're free to specify that you need a C implementation in
which you can successfully perform experiments with very large macro
expansions. Thus, for your purposes, those installations of GCC which
don't handle your programs are not acceptable to you. You could hire
someone to fix the problem, and pay them only if they solve it. The
problem to be fixed isn't one described in the standard though;
you would have to come up with your own requirement specification,
and test cases (like that program, and others similar to it).
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [standalone]
Page 12 of 12 — ← Prev page 1 … 10 11 [12]
Back to top | Article view | comp.lang.c
csiph-web