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 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-08-31 18:37 +0100 |
| Message-ID | <teo697$1to1$1@gioia.aioe.org> |
| In reply to | #167385 |
On 31/08/2022 17:43, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> const int abc = 123;
>> *(int*)&abc = 999;
>>
>> printf("abc = %d\n", abc);
>>
>> It tells me that 'abc' is 999; so much for being a named constant, or
>> read-only!
>
> Don't you have a compiler that will tell you that such code is junk?
> (It won't say so in so many words. Compiler writers are more polite
> than I am!)
Apparently not:
c:\c>gcc c.c -oc.exe
c:\c>c
999
c:\c>tcc c.c
c:\c>c
999
With this one I do get a message:
c:\c>bcc c
Compiling c.c to c.exe
In function main
Type error: Modifying read-only var on line 6 c.c
But that's most likely a compiler error or just non-conforming. If I
pull out the stops with gcc, it gives me a warning, but I can still run
the program.
The point is, it's not hard to get around: you can easily modify the
values of such variables. It is impossible (short of hacking the machine
code, in-memory or within an executable file), to do what I did given:
enum {abc = 123};
That shows the benefits of doing such a feature properly. It's a bit
frustating that 'enum' comes so close to such a feature, but has not
been taken further.
(If doing mechanical generation of C code, for example, you can use
'enum' for some specific data types, but also need a fall-back solution
for others. In which case why bother with the special case?)
> Don't you have a compiler that will tell you that such code is junk?
That was a type-punning expression, which can be useful. Losing that
'const' is also easy, because you can call an external function that you
say takes 'const int*', but the actual function in its source file says
'int*'.
(Or anything else for that matter. Or just declare the external function
using a () parameter list, then anything goes.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-31 19:30 +0100 |
| Message-ID | <87tu5snu4o.fsf@bsb.me.uk> |
| In reply to | #167393 |
Bart <bc@freeuk.com> writes:
> On 31/08/2022 17:43, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> const int abc = 123;
>>> *(int*)&abc = 999;
>>>
>>> printf("abc = %d\n", abc);
>>>
>>> It tells me that 'abc' is 999; so much for being a named constant, or
>>> read-only!
>> Don't you have a compiler that will tell you that such code is junk?
>> (It won't say so in so many words. Compiler writers are more polite
>> than I am!)
>
> Apparently not:
>
> c:\c>gcc c.c -oc.exe
> c:\c>c
> 999
As you know perfectly well, you're saying "Sh! I don't want to know if
you don't like this code".
> If I pull out the stops with gcc, it gives me a warning,
So you do know how to get gcc to tell you what you need to know. Since
you know, why would you tell gcc to be quiet?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-08-31 18:47 +0000 |
| Message-ID | <y1OPK.140741$wLZ8.1666@fx18.iad> |
| In reply to | #167396 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>Bart <bc@freeuk.com> writes:
>
>> On 31/08/2022 17:43, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>> const int abc = 123;
>>>> *(int*)&abc = 999;
>>>>
>>>> printf("abc = %d\n", abc);
>>>>
>>>> It tells me that 'abc' is 999; so much for being a named constant, or
>>>> read-only!
>>> Don't you have a compiler that will tell you that such code is junk?
>>> (It won't say so in so many words. Compiler writers are more polite
>>> than I am!)
>>
>> Apparently not:
>>
>> c:\c>gcc c.c -oc.exe
>> c:\c>c
>> 999
>
>As you know perfectly well, you're saying "Sh! I don't want to know if
>you don't like this code".
>
Plus he's running using windows toolsets, which apparently don't
store file scope const int values in read-only pages. On a real OS:
$ cat /tmp/cc.c
const int abc = 123;
int main()
{
*(int*)&abc = 999;
printf ("abc = %d\n", abc);
return 0;
}
$ cc -o /tmp/cc /tmp/cc.c
/tmp/cc.c: In function 'main':
/tmp/cc.c:6:4: warning: incompatible implicit declaration of built-in function 'printf' [enabled by default]
printf ("abc = %d\n", abc);
^
$ /tmp/cc
Memory fault
$
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-08-31 20:37 +0100 |
| Message-ID | <teod9l$10kn$1@gioia.aioe.org> |
| In reply to | #167398 |
On 31/08/2022 19:47, Scott Lurndal wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 31/08/2022 17:43, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>
>>>>> const int abc = 123;
>>>>> *(int*)&abc = 999;
>>>>>
>>>>> printf("abc = %d\n", abc);
>>>>>
>>>>> It tells me that 'abc' is 999; so much for being a named constant, or
>>>>> read-only!
>>>> Don't you have a compiler that will tell you that such code is junk?
>>>> (It won't say so in so many words. Compiler writers are more polite
>>>> than I am!)
>>>
>>> Apparently not:
>>>
>>> c:\c>gcc c.c -oc.exe
>>> c:\c>c
>>> 999
>>
>> As you know perfectly well, you're saying "Sh! I don't want to know if
>> you don't like this code".
>>
>
> Plus he's running using windows toolsets, which apparently don't
> store file scope const int values in read-only pages. On a real OS:
>
> $ cat /tmp/cc.c
> const int abc = 123;
>
> int main()
> {
> *(int*)&abc = 999;
> printf ("abc = %d\n", abc);
> return 0;
> }
>
> $ cc -o /tmp/cc /tmp/cc.c
> /tmp/cc.c: In function 'main':
> /tmp/cc.c:6:4: warning: incompatible implicit declaration of built-in function 'printf' [enabled by default]
> printf ("abc = %d\n", abc);
> ^
> $ /tmp/cc
> Memory fault
> $
But you don't get the memory fault until you execute that bit of code.
Which might be long afterwards at a customer site.
Using the kind of named constant that disallows address-of, it will not
compile. So it's superior.
Is there an advantage to using read-only variables to emulate pure named
literals (other than there might be no other choice)? All I can see is
extra opportunity for things to go wrong.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-08-31 19:47 +0000 |
| Message-ID | <%UOPK.4214$51Rb.1902@fx45.iad> |
| In reply to | #167400 |
Bart <bc@freeuk.com> writes:
>On 31/08/2022 19:47, Scott Lurndal wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 31/08/2022 17:43, Ben Bacarisse wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>>> const int abc = 123;
>>>>>> *(int*)&abc = 999;
>>>>>>
>>>>>> printf("abc = %d\n", abc);
>>>>>>
>>>>>> It tells me that 'abc' is 999; so much for being a named constant, or
>>>>>> read-only!
>>>>> Don't you have a compiler that will tell you that such code is junk?
>>>>> (It won't say so in so many words. Compiler writers are more polite
>>>>> than I am!)
>>>>
>>>> Apparently not:
>>>>
>>>> c:\c>gcc c.c -oc.exe
>>>> c:\c>c
>>>> 999
>>>
>>> As you know perfectly well, you're saying "Sh! I don't want to know if
>>> you don't like this code".
>>>
>>
>> Plus he's running using windows toolsets, which apparently don't
>> store file scope const int values in read-only pages. On a real OS:
>>
>> $ cat /tmp/cc.c
>> const int abc = 123;
>>
>> int main()
>> {
>> *(int*)&abc = 999;
>> printf ("abc = %d\n", abc);
>> return 0;
>> }
>>
>> $ cc -o /tmp/cc /tmp/cc.c
>> /tmp/cc.c: In function 'main':
>> /tmp/cc.c:6:4: warning: incompatible implicit declaration of built-in function 'printf' [enabled by default]
>> printf ("abc = %d\n", abc);
>> ^
>> $ /tmp/cc
>> Memory fault
>> $
>
>But you don't get the memory fault until you execute that bit of code.
>Which might be long afterwards at a customer site.
>
>Using the kind of named constant that disallows address-of, it will not
>compile. So it's superior.
Use the appropriate level of compiler warnings and/or standards-compliance
options and you'll see it before it ever gets to a customer.
Any programmer that worked here who produced shite code like
that would be rapidly counselled appropriately.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-01 09:45 +0200 |
| Message-ID | <tepnvl$247l0$1@dont-email.me> |
| In reply to | #167400 |
On 31/08/2022 21:37, Bart wrote:
> On 31/08/2022 19:47, Scott Lurndal wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 31/08/2022 17:43, Ben Bacarisse wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>>> const int abc = 123;
>>>>>> *(int*)&abc = 999;
>>>>>>
>>>>>> printf("abc = %d\n", abc);
>>>>>>
>>>>>> It tells me that 'abc' is 999; so much for being a named constant, or
>>>>>> read-only!
>>>>> Don't you have a compiler that will tell you that such code is junk?
>>>>> (It won't say so in so many words. Compiler writers are more polite
>>>>> than I am!)
>>>>
>>>> Apparently not:
>>>>
>>>> c:\c>gcc c.c -oc.exe
>>>> c:\c>c
>>>> 999
>>>
>>> As you know perfectly well, you're saying "Sh! I don't want to know if
>>> you don't like this code".
>>>
>>
>> Plus he's running using windows toolsets, which apparently don't
>> store file scope const int values in read-only pages. On a real OS:
>>
>> $ cat /tmp/cc.c
>> const int abc = 123;
>>
>> int main()
>> {
>> *(int*)&abc = 999;
>> printf ("abc = %d\n", abc);
>> return 0;
>> }
>>
>> $ cc -o /tmp/cc /tmp/cc.c
>> /tmp/cc.c: In function 'main':
>> /tmp/cc.c:6:4: warning: incompatible implicit declaration of built-in
>> function 'printf' [enabled by default]
>> printf ("abc = %d\n", abc);
>> ^
>> $ /tmp/cc
>> Memory fault
>> $
>
> But you don't get the memory fault until you execute that bit of code.
> Which might be long afterwards at a customer site.
That is why, as a serious programmer, you must:
1) Understand the language.
2) Be careful to write code as correctly as you are able.
3) Write according to an appropriate coding standard, using language
features that make sense. Just because a language allows a particular
piece of coding or technique, does not mean it is a good idea.
4) Be especially careful when using risky coding techniques, such as casts.
5) Take all the help you can get from static warnings, linters, and
other checkers - that means using decent compilers like gcc or clang,
with optimisation enabled and lots of warning flags. If that is not
enough, there are commercial linter tools available.
6) Test /everything/.
7) Test using sanitizers if possible, to catch subtle bugs.
8) Get code reviews and second opinions.
9) Get someone else to test the code too.
There should probably be a tenth rule too - but I'm sure the group could
come up with a dozens more.
>
> Using the kind of named constant that disallows address-of, it will not
> compile. So it's superior.
There is no problem with taking the address of the constant. It is
writing to it that is the problem. Being able to take the address is a
useful feature - it allows you to pass constants by reference.
Unaddressable constants are okay for small objects, such as an integer,
but impractical for larger objects.
I think it would be nice if compilers spotted such errors and complained
about them by default, but it is not always easy to do so, and will
quickly lead to false positives in some kinds of code that has to cast
away const qualifiers.
For my own coding, I have "-Werror=cast-qual" in my list of standard
warnings for gcc. This makes "* (int*) &abc" an error when "abc" is
const qualified. On the rare occasions when I actually need to cast
away const qualifiers, I must add a "(uintptr_t)" cast in the middle -
that is not something that happens by mistake.
>
> Is there an advantage to using read-only variables to emulate pure named
> literals (other than there might be no other choice)? All I can see is
> extra opportunity for things to go wrong.
It is an extra opportunity to make use of the constants in more
circumstances - which means there are more occasions when you can use
constants, and thus fewer mistakes overall. But the power to use
something also gives the risk of misusing it. C is a language targeting
serious programmers who take responsibility for their code - when you
tell the compiler "I know this is a risky bit of code, but I know what I
am doing", it trusts you. Lie to your compiler at your own risk.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-01 11:55 +0100 |
| Message-ID | <teq33d$60q$1@gioia.aioe.org> |
| In reply to | #167409 |
On 01/09/2022 08:45, David Brown wrote:
> On 31/08/2022 21:37, Bart wrote:
>> But you don't get the memory fault until you execute that bit of code.
>> Which might be long afterwards at a customer site.
>
> That is why, as a serious programmer, you must:
>
> 1) Understand the language.
>
> 2) Be careful to write code as correctly as you are able.
>
> 3) Write according to an appropriate coding standard, using language
> features that make sense. Just because a language allows a particular
> piece of coding or technique, does not mean it is a good idea.
>
> 4) Be especially careful when using risky coding techniques, such as casts.
>
> 5) Take all the help you can get from static warnings, linters, and
> other checkers - that means using decent compilers like gcc or clang,
> with optimisation enabled and lots of warning flags. If that is not
> enough, there are commercial linter tools available.
>
> 6) Test /everything/.
>
> 7) Test using sanitizers if possible, to catch subtle bugs.
>
> 8) Get code reviews and second opinions.
>
> 9) Get someone else to test the code too.
>
> There should probably be a tenth rule too - but I'm sure the group could
> come up with a dozens more.
Or, as I stated in my last post (1.20 BST), use the most sensible way to
define named literals, and:
* The issues I mentioned just cannot occur
* Any attempts to modify those constants can be instantly detected by
the simplest of compilers
Unfortunately the most sensible way does not exist in C, only as 'enum',
for limited cases using a feature designed for a different purpose.
Even then, people will not use 'enum' for suitable literal types, they
will prefer 'const', and now, they will prefer 'constexpr'.
So even if C23 had provided that missing feature, probably no one will
have used it. (Does C23 mainly consist of hand-me-downs from C++?)
>> Using the kind of named constant that disallows address-of, it will
>> not compile. So it's superior.
>
> There is no problem with taking the address of the constant. It is
> writing to it that is the problem. Being able to take the address is a
> useful feature - it allows you to pass constants by reference.
Why is that useful? Last time I did that was writing Fortran IV. That
allowed callees to modify their parameters, so changing the values of
the literals in the caller.
Usually a reference parameter to a scalar - applying an extra level of
indirection - is used for a reason, typically to allowing the caller's data.
> Unaddressable constants are okay for small objects, such as an integer,
> but impractical for larger objects.
Every one of my posts has been about numeric literals.
> I think it would be nice if compilers spotted such errors and complained
> about them by default, but it is not always easy to do so, and will
> quickly lead to false positives in some kinds of code that has to cast
> away const qualifiers.
>
> For my own coding, I have "-Werror=cast-qual" in my list of standard
> warnings for gcc. This makes "* (int*) &abc" an error when "abc" is
> const qualified.
Sure, but how do you know what's going on in some third party library to
which you pass a reference to that constant?
>> Is there an advantage to using read-only variables to emulate pure
>> named literals (other than there might be no other choice)? All I can
>> see is extra opportunity for things to go wrong.
>
> It is an extra opportunity to make use of the constants in more
> circumstances - which means there are more occasions when you can use
> constants, and thus fewer mistakes overall. But the power to use
> something also gives the risk of misusing it.
To me it is just foolhardy: disregarding a feature that is 100% safe,
and using one which requires lots of complex analysis in a compiler, a
dozen options to be supplied, plus your 9 steps, and you still will
never be 100% certain that that value cannot be changed.
> C is a language targeting
> serious programmers who take responsibility for their code
C has a reputation for being highly unsafe. But it is also much more
unsafe than it needs be.
A preference for using const/constexpr over safer alternatives (enum for
example), is one example of many.
(One more is having compilers that DEFAULT to compiling unsafe legacy
code unless told otherwise. It's crazy.
If I pass this:
int spam() {
spam(spam, spam(), spam("spam", "spam"));
}
through gcc with no options, it says nothing at all. If I give it this lot:
-Wall -Wextra -ansi -pedantic -Wformat-nonliteral
-Wcast-align -Wpointer-arith -Wbad-function-cast
-Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations -Winline
-Wundef -Wnested-externs -Wcast-qual -Wshadow -Wconversion
-Wwrite-strings
-Wno-conversion -ffloat-store -std=c11
Then I merely get 2 WARNINGS; it still produces an executable!
Yes, I know about -Werror, but come on, that is treating that dangerous
code as seriously as having an unused label.
Tcc also passes it.
Bcc (my product) will fail it by default, but will pass it if you supply
an option to accept legacy code. Or sometimes even current code, since
so much of it uses those () parameters lists by mistake.
The reason, presumably, is that so many people DO NOT use the correct
options in those big compilers, and so think using () etc is fine.)
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-09-01 05:23 -0700 |
| Message-ID | <15f2bb82-1591-44ad-9a30-6a616a72ece4n@googlegroups.com> |
| In reply to | #167413 |
On Thursday, September 1, 2022 at 7:55:56 AM UTC-3, Bart wrote:
> On 01/09/2022 08:45, David Brown wrote:
> > On 31/08/2022 21:37, Bart wrote:
>
> >> But you don't get the memory fault until you execute that bit of code.
> >> Which might be long afterwards at a customer site.
> >
> > That is why, as a serious programmer, you must:
> >
> > 1) Understand the language.
> >
> > 2) Be careful to write code as correctly as you are able.
> >
> > 3) Write according to an appropriate coding standard, using language
> > features that make sense. Just because a language allows a particular
> > piece of coding or technique, does not mean it is a good idea.
> >
> > 4) Be especially careful when using risky coding techniques, such as casts.
> >
> > 5) Take all the help you can get from static warnings, linters, and
> > other checkers - that means using decent compilers like gcc or clang,
> > with optimisation enabled and lots of warning flags. If that is not
> > enough, there are commercial linter tools available.
> >
> > 6) Test /everything/.
> >
> > 7) Test using sanitizers if possible, to catch subtle bugs.
> >
> > 8) Get code reviews and second opinions.
> >
> > 9) Get someone else to test the code too.
> >
> > There should probably be a tenth rule too - but I'm sure the group could
> > come up with a dozens more.
> Or, as I stated in my last post (1.20 BST), use the most sensible way to
> define named literals, and:
We have a similar view.
I could have played with "named constants" in my experimental
C compiler but this was a low priority for me.
Until now, because constexpr was added into C23 then I need
to consider to implement it.
Your suggestion and implementation is for numbers only, right?
Not including string literal or compound literals, so I think a
better name is "named constant" instead of "named literal".
A "named constant" is a name for a result of constant expression.
Then you need to define what is a constant expression.
I think string literal and compound literals also could have
a usage but it is necessary think much more about them.
For instance, in my code I have escape sequences for colours
#define BLUE "\x1b[34m"
I use like this:
printf(BLUE "text in blue");
This is a sample where constexpr doesn't help.
//#define BLUE "\x1b[34m"
constexpr char BLUE[] = "\x1b[34m";
int main() {
printf(BLUE "text in blue"); //ERROR if constexpr
}
This is complete failure in replacing macros in this case.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-01 14:20 +0100 |
| Message-ID | <teqbj9$13o$1@gioia.aioe.org> |
| In reply to | #167416 |
On 01/09/2022 13:23, Thiago Adams wrote:
> On Thursday, September 1, 2022 at 7:55:56 AM UTC-3, Bart wrote:
>> On 01/09/2022 08:45, David Brown wrote:
>>> On 31/08/2022 21:37, Bart wrote:
>>
>>>> But you don't get the memory fault until you execute that bit of code.
>>>> Which might be long afterwards at a customer site.
>>>
>>> That is why, as a serious programmer, you must:
>>>
>>> 1) Understand the language.
>>>
>>> 2) Be careful to write code as correctly as you are able.
>>>
>>> 3) Write according to an appropriate coding standard, using language
>>> features that make sense. Just because a language allows a particular
>>> piece of coding or technique, does not mean it is a good idea.
>>>
>>> 4) Be especially careful when using risky coding techniques, such as casts.
>>>
>>> 5) Take all the help you can get from static warnings, linters, and
>>> other checkers - that means using decent compilers like gcc or clang,
>>> with optimisation enabled and lots of warning flags. If that is not
>>> enough, there are commercial linter tools available.
>>>
>>> 6) Test /everything/.
>>>
>>> 7) Test using sanitizers if possible, to catch subtle bugs.
>>>
>>> 8) Get code reviews and second opinions.
>>>
>>> 9) Get someone else to test the code too.
>>>
>>> There should probably be a tenth rule too - but I'm sure the group could
>>> come up with a dozens more.
>> Or, as I stated in my last post (1.20 BST), use the most sensible way to
>> define named literals, and:
>
>
> We have a similar view.
>
> I could have played with "named constants" in my experimental
> C compiler but this was a low priority for me.
>
> Until now, because constexpr was added into C23 then I need
> to consider to implement it.
>
> Your suggestion and implementation is for numbers only, right?
> Not including string literal or compound literals, so I think a
> better name is "named constant" instead of "named literal".
>
> A "named constant" is a name for a result of constant expression.
> Then you need to define what is a constant expression.
>
> I think string literal and compound literals also could have
> a usage but it is necessary think much more about them.
>
> For instance, in my code I have escape sequences for colours
>
> #define BLUE "\x1b[34m"
>
> I use like this:
>
> printf(BLUE "text in blue");
>
> This is a sample where constexpr doesn't help.
>
> //#define BLUE "\x1b[34m"
> constexpr char BLUE[] = "\x1b[34m";
>
> int main() {
> printf(BLUE "text in blue"); //ERROR if constexpr
> }
>
> This is complete failure in replacing macros in this case.
The failure here is because string concatenation only works between two
literal strings (I assume using a char* type in constexpr doesn't work
either).
My own 'constant' feature in C is for integers and floats only (it will
say so). Outside of C, I have are several ways to name string literals:
const S = "one" # (type inference used)
macro T = "two" # (macro names are fully scoped)
ichar U = "three"
S and T can be used as named string literals. You can't use &S or &T,
and you can't assign to them (but they can be modified if not careful; S
and T are still pointers to a sequence of bytes; I don't keep them in
r/o memory yet).
U is a variable equivalent to `char* U = "three` in C. This can be
assigned to (unless defined as `let ichar`).
In my language, string concatenation is also between string constants
only, and works like this using "+":
print S + T # shows `onetwo`
But I can't do S+U or U+S.
Your example would probably be written as:
const Blue = "\s[34m" # \s is `eScape`
print Blue + "text in blue"
Or can be used to create a new constant:
const error = Blue + "text in blue"
It's not hard really to do this properly, and simply.
My guess is that the issue with `constexpr` didn't matter in C++,
because it probably has first-class string handling anyway; you just do:
BLUE + "text in blue"
(or for printing, just BLUE << "text in blue").
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2022-09-03 02:20 +0200 |
| Message-ID | <teu6jl$tv4$1@gioia.aioe.org> |
| In reply to | #167398 |
On 8/31/2022 8:47 PM, Scott Lurndal wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 31/08/2022 17:43, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>
>>>>> const int abc = 123;
>>>>> *(int*)&abc = 999;
>>>>>
>>>>> printf("abc = %d\n", abc);
>>>>>
>>>>> It tells me that 'abc' is 999; so much for being a named constant, or
>>>>> read-only!
>>>> Don't you have a compiler that will tell you that such code is junk?
>>>> (It won't say so in so many words. Compiler writers are more polite
>>>> than I am!)
>>>
>>> Apparently not:
>>>
>>> c:\c>gcc c.c -oc.exe
>>> c:\c>c
>>> 999
>>
>> As you know perfectly well, you're saying "Sh! I don't want to know if
>> you don't like this code".
>>
>
> Plus he's running using windows toolsets, which apparently don't
> store file scope const int values in read-only pages. On a real OS:
>
> $ cat /tmp/cc.c
> const int abc = 123;
>
> int main()
> {
> *(int*)&abc = 999;
> printf ("abc = %d\n", abc);
> return 0;
> }
>
> $ cc -o /tmp/cc /tmp/cc.c
> /tmp/cc.c: In function 'main':
> /tmp/cc.c:6:4: warning: incompatible implicit declaration of built-in function 'printf' [enabled by default]
> printf ("abc = %d\n", abc);
> ^
> $ /tmp/cc
> Memory fault
> $
For the sake of accuracy, if you add the required #include <stdio.h> no
warning is given, even with -Wall (gcc 10.3 on linux)
The fact is that this is one of the cases where UB goes undetected, and
only at run time some symptom /may/ show up (we all know what undefined
behavior means)
Plus, if you move the declaration of abc inside main's block then the
same gcc 10.3 on linux demonstrates the same behavior as Bart's example
(did I mention UB?).
The more interesting part here is whether this is bad language design by C.
Well, we all know that this behavior is one of the direct effects of
C-style casts; we also know that C-style cast is the only kind of type
cast available in C, and that it is a sledgehammer tool.
We also know that type cast is a key feature of C - there are cases
where you just need it, so the question really becomes: is type cast a
bad design choice in C?
The answer is that no, it is not bad design (unless you want to switch
to a different language - there's a reason why Bjarne put considerable
effort into handling this very matter), but you have to know how and
when to use type casts. You don't put a sledgehammer in the hands of a
fool, unless you want trouble.
In short:
C is not for fools, like it or not.
(For the record, obviously Bart is no fool at all. My point is
exclusively about the C-style cast being a handle-with-care tool)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-03 00:25 +0000 |
| Message-ID | <O9xQK.7466$OR4c.1346@fx46.iad> |
| In reply to | #167447 |
Manfred <noname@add.invalid> writes:
>On 8/31/2022 8:47 PM, Scott Lurndal wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 31/08/2022 17:43, Ben Bacarisse wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>>> const int abc = 123;
>>>>>> *(int*)&abc = 999;
>>>>>>
>>>>>> printf("abc = %d\n", abc);
>>>>>>
>>>>>> It tells me that 'abc' is 999; so much for being a named constant, or
>>>>>> read-only!
>>>>> Don't you have a compiler that will tell you that such code is junk?
>>>>> (It won't say so in so many words. Compiler writers are more polite
>>>>> than I am!)
>>>>
>>>> Apparently not:
>>>>
>>>> c:\c>gcc c.c -oc.exe
>>>> c:\c>c
>>>> 999
>>>
>>> As you know perfectly well, you're saying "Sh! I don't want to know if
>>> you don't like this code".
>>>
>>
>> Plus he's running using windows toolsets, which apparently don't
>> store file scope const int values in read-only pages. On a real OS:
>>
>> $ cat /tmp/cc.c
>> const int abc = 123;
>>
>> int main()
>> {
>> *(int*)&abc = 999;
>> printf ("abc = %d\n", abc);
>> return 0;
>> }
>>
>> $ cc -o /tmp/cc /tmp/cc.c
>> /tmp/cc.c: In function 'main':
>> /tmp/cc.c:6:4: warning: incompatible implicit declaration of built-in function 'printf' [enabled by default]
>> printf ("abc = %d\n", abc);
>> ^
>> $ /tmp/cc
>> Memory fault
>> $
<snip>
>Plus, if you move the declaration of abc inside main's block then the
>same gcc 10.3 on linux demonstrates the same behavior as Bart's example
>(did I mention UB?).
Of course it works, it's on the stack which isn't considered readonly.
Unlike the .rodata section where the static const integer is stored.
My point was that windows apparently stores the static readonly data
in a writable page which seems, well, microsoftish.
Leaving aside that it is UB.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2022-09-03 02:46 +0200 |
| Message-ID | <teu85a$1c7e$1@gioia.aioe.org> |
| In reply to | #167448 |
On 9/3/2022 2:25 AM, Scott Lurndal wrote:
> Manfred <noname@add.invalid> writes:
>> On 8/31/2022 8:47 PM, Scott Lurndal wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> On 31/08/2022 17:43, Ben Bacarisse wrote:
>>>>>> Bart <bc@freeuk.com> writes:
>>>>>
>>>>>>> const int abc = 123;
>>>>>>> *(int*)&abc = 999;
>>>>>>>
>>>>>>> printf("abc = %d\n", abc);
>>>>>>>
>>>>>>> It tells me that 'abc' is 999; so much for being a named constant, or
>>>>>>> read-only!
>>>>>> Don't you have a compiler that will tell you that such code is junk?
>>>>>> (It won't say so in so many words. Compiler writers are more polite
>>>>>> than I am!)
>>>>>
>>>>> Apparently not:
>>>>>
>>>>> c:\c>gcc c.c -oc.exe
>>>>> c:\c>c
>>>>> 999
>>>>
>>>> As you know perfectly well, you're saying "Sh! I don't want to know if
>>>> you don't like this code".
>>>>
>>>
>>> Plus he's running using windows toolsets, which apparently don't
>>> store file scope const int values in read-only pages. On a real OS:
>>>
>>> $ cat /tmp/cc.c
>>> const int abc = 123;
>>>
>>> int main()
>>> {
>>> *(int*)&abc = 999;
>>> printf ("abc = %d\n", abc);
>>> return 0;
>>> }
>>>
>>> $ cc -o /tmp/cc /tmp/cc.c
>>> /tmp/cc.c: In function 'main':
>>> /tmp/cc.c:6:4: warning: incompatible implicit declaration of built-in function 'printf' [enabled by default]
>>> printf ("abc = %d\n", abc);
>>> ^
>>> $ /tmp/cc
>>> Memory fault
>>> $
> <snip>
>> Plus, if you move the declaration of abc inside main's block then the
>> same gcc 10.3 on linux demonstrates the same behavior as Bart's example
>> (did I mention UB?).
>
> Of course it works, it's on the stack which isn't considered readonly.
>
> Unlike the .rodata section where the static const integer is stored.
>
> My point was that windows apparently stores the static readonly data
> in a writable page which seems, well, microsoftish.
Actually, the example was using the Windows port of gcc, which is
neither made by MS, nor officially supported by the gcc team.
So, in this particular case this is not about the MS implementation of
C, although it might be the case that MSVC shows the same behavior - I
am neither interested nor willing to verify this.
>
> Leaving aside that it is UB.
Indeed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-03 10:11 +0200 |
| Message-ID | <tev26n$2r3g4$1@dont-email.me> |
| In reply to | #167449 |
On 03/09/2022 02:46, Manfred wrote:
> On 9/3/2022 2:25 AM, Scott Lurndal wrote:
>> Manfred <noname@add.invalid> writes:
>>> On 8/31/2022 8:47 PM, Scott Lurndal wrote:
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>> Bart <bc@freeuk.com> writes:
>>>>>
>>>>>> On 31/08/2022 17:43, Ben Bacarisse wrote:
>>>>>>> Bart <bc@freeuk.com> writes:
>>>>>>
>>>>>>>> const int abc = 123;
>>>>>>>> *(int*)&abc = 999;
>>>>>>>>
>>>>>>>> printf("abc = %d\n", abc);
>>>>>>>>
>>>>>>>> It tells me that 'abc' is 999; so much for being a named
>>>>>>>> constant, or
>>>>>>>> read-only!
>>>>>>> Don't you have a compiler that will tell you that such code is junk?
>>>>>>> (It won't say so in so many words. Compiler writers are more polite
>>>>>>> than I am!)
>>>>>>
>>>>>> Apparently not:
>>>>>>
>>>>>> c:\c>gcc c.c -oc.exe
>>>>>> c:\c>c
>>>>>> 999
>>>>>
>>>>> As you know perfectly well, you're saying "Sh! I don't want to know if
>>>>> you don't like this code".
>>>>>
>>>>
>>>> Plus he's running using windows toolsets, which apparently don't
>>>> store file scope const int values in read-only pages. On a real OS:
>>>>
>>>> $ cat /tmp/cc.c
>>>> const int abc = 123;
>>>>
>>>> int main()
>>>> {
>>>> *(int*)&abc = 999;
>>>> printf ("abc = %d\n", abc);
>>>> return 0;
>>>> }
>>>>
>>>> $ cc -o /tmp/cc /tmp/cc.c
>>>> /tmp/cc.c: In function 'main':
>>>> /tmp/cc.c:6:4: warning: incompatible implicit declaration of
>>>> built-in function 'printf' [enabled by default]
>>>> printf ("abc = %d\n", abc);
>>>> ^
>>>> $ /tmp/cc
>>>> Memory fault
>>>> $
>> <snip>
>>> Plus, if you move the declaration of abc inside main's block then the
>>> same gcc 10.3 on linux demonstrates the same behavior as Bart's example
>>> (did I mention UB?).
>>
>> Of course it works, it's on the stack which isn't considered readonly.
>>
>> Unlike the .rodata section where the static const integer is stored.
>>
>> My point was that windows apparently stores the static readonly data
>> in a writable page which seems, well, microsoftish.
>
> Actually, the example was using the Windows port of gcc, which is
> neither made by MS, nor officially supported by the gcc team.
He was using /a/ Windows port of gcc - there are more than one. If you
have static lifetime const data in your code, gcc will put it into a
section called ".rodata" (or a subsection, depending on compiler
options, or a related section, depending on the target). Whether that
ends up in read-only memory of some kind depends on the /linker/, not
the compiler, and how that read-only aspect is enforced depends on the OS.
So without knowing the linker involved, along with linker scripts in
action, blaming the OS is certainly premature.
Even more important, however, is that Bart never posted the entire
program he used for the test. I assume, given the formatting of his
snippet, that the "const" was local to the test function (no doubt "main").
What Bart meant to show is that defining something as "const" in C does
not mean it is immune to change. Of course that's an extreme viewpoint
- in any programming, in any language, you have to assume that people
are writing sensible code (except perhaps at guarded interfaces) or
you'll get nowhere. And any object defined const /will/ be constant,
unless you wield one of C's sledgehammers at your own foot.
> So, in this particular case this is not about the MS implementation of
> C, although it might be the case that MSVC shows the same behavior - I
> am neither interested nor willing to verify this.
>
>>
>> Leaving aside that it is UB.
>
> Indeed.
>
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-03 12:54 +0100 |
| Message-ID | <87ilm4fzau.fsf@bsb.me.uk> |
| In reply to | #167452 |
David Brown <david.brown@hesbynett.no> writes: > ... Of course that's an extreme viewpoint - in any programming, in > any language, you have to assume that people are writing sensible code > (except perhaps at guarded interfaces) or you'll get nowhere. And any > object defined const /will/ be constant, unless you wield one of C's > sledgehammers at your own foot. Some of C's 'sledgehammers' are dressed up as simple everyday tools: extern void edit_string_tail(char *string); ... const char name[] = "Molly Dog"; edit_string_tail(strchr(name, ' ')); -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-03 12:52 -0700 |
| Message-ID | <87o7vwkzge.fsf@nosuchdomain.example.com> |
| In reply to | #167455 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> David Brown <david.brown@hesbynett.no> writes:
>
>> ... Of course that's an extreme viewpoint - in any programming, in
>> any language, you have to assume that people are writing sensible code
>> (except perhaps at guarded interfaces) or you'll get nowhere. And any
>> object defined const /will/ be constant, unless you wield one of C's
>> sledgehammers at your own foot.
>
> Some of C's 'sledgehammers' are dressed up as simple everyday tools:
>
> extern void edit_string_tail(char *string);
> ...
> const char name[] = "Molly Dog";
> edit_string_tail(strchr(name, ' '));
C23 addresses this by making strchr and several other functions generic,
so that the result is a pointer to const if and only if the argument is
a pointer to const. (Presumably this is implemented using macros and
_Generic.)
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf>, section 7.26.5
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-03 21:08 +0100 |
| Message-ID | <87pmgcdxvh.fsf@bsb.me.uk> |
| In reply to | #167467 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> David Brown <david.brown@hesbynett.no> writes: >> >>> ... Of course that's an extreme viewpoint - in any programming, in >>> any language, you have to assume that people are writing sensible code >>> (except perhaps at guarded interfaces) or you'll get nowhere. And any >>> object defined const /will/ be constant, unless you wield one of C's >>> sledgehammers at your own foot. >> >> Some of C's 'sledgehammers' are dressed up as simple everyday tools: >> >> extern void edit_string_tail(char *string); >> ... >> const char name[] = "Molly Dog"; >> edit_string_tail(strchr(name, ' ')); > > C23 addresses this by making strchr and several other functions generic, > so that the result is a pointer to const if and only if the argument is > a pointer to const. (Presumably this is implemented using macros and > _Generic.) > > <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf>, section 7.26.5 Excellent! Thanks for the pointer. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-03 12:46 -0700 |
| Message-ID | <87sfl8kzps.fsf@nosuchdomain.example.com> |
| In reply to | #167452 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> And any object defined const
> /will/ be constant, unless you wield one of C's sledgehammers at your
> own foot.
[...]
It will be const (read-only), not constant (evaluated at compile time).
In spite of the similar spellings, they're very different things.
--
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 <bc@freeuk.com> |
|---|---|
| Date | 2022-09-01 01:25 +0100 |
| Message-ID | <teou5j$vtb$1@gioia.aioe.org> |
| In reply to | #167396 |
On 31/08/2022 19:30, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 31/08/2022 17:43, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>> const int abc = 123;
>>>> *(int*)&abc = 999;
>>>>
>>>> printf("abc = %d\n", abc);
>>>>
>>>> It tells me that 'abc' is 999; so much for being a named constant, or
>>>> read-only!
>>> Don't you have a compiler that will tell you that such code is junk?
>>> (It won't say so in so many words. Compiler writers are more polite
>>> than I am!)
>>
>> Apparently not:
>>
>> c:\c>gcc c.c -oc.exe
>> c:\c>c
>> 999
>
> As you know perfectly well, you're saying "Sh! I don't want to know if
> you don't like this code".
>
>> If I pull out the stops with gcc, it gives me a warning,
>
> So you do know how to get gcc to tell you what you need to know. Since
> you know, why would you tell gcc to be quiet?
>
This isn't about me. Very many people seem to run compilers like gcc
without all the right options. (Perhaps they rightly assume that it
knows how to do its job! That is, enforce the rules of the language,
without needing to be reminded of which ones the user needs enforcing).
That then lets through less than ideal code. And in their next program,
the bad habits are reinforced.
Actually I /don't/ know to get gcc to report it properly. Using -Wall
-Wextra -Wpedantic -std=c11 does nothing. I got my warning by using all
these options, so it's presumably one of them:
-Wall -Wextra -ansi -pedantic -Wformat-nonliteral
-Wcast-align -Wpointer-arith -Wbad-function-cast
-Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations -Winline
-Wundef -Wnested-externs -Wcast-qual -Wshadow -Wconversion
-Wwrite-strings
-Wno-conversion -ffloat-store -std=c11
And as I said, that still only warned. This would be the advantage of
using the proper feature; using 'enum' instead of 'const int', even tcc
reported an error, and without needing to be told!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-01 11:17 +0100 |
| Message-ID | <87r10vmm9m.fsf@bsb.me.uk> |
| In reply to | #167407 |
Bart <bc@freeuk.com> writes:
> On 31/08/2022 19:30, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 31/08/2022 17:43, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>
>>>>> const int abc = 123;
>>>>> *(int*)&abc = 999;
>>>>>
>>>>> printf("abc = %d\n", abc);
>>>>>
>>>>> It tells me that 'abc' is 999; so much for being a named constant, or
>>>>> read-only!
>>>> Don't you have a compiler that will tell you that such code is junk?
>>>> (It won't say so in so many words. Compiler writers are more polite
>>>> than I am!)
>>>
>>> Apparently not:
>>>
>>> c:\c>gcc c.c -oc.exe
>>> c:\c>c
>>> 999
>> As you know perfectly well, you're saying "Sh! I don't want to know if
>> you don't like this code".
>>
>>> If I pull out the stops with gcc, it gives me a warning,
>> So you do know how to get gcc to tell you what you need to know. Since
>> you know, why would you tell gcc to be quiet?
>
> This isn't about me. Very many people seem to run compilers like gcc
> without all the right options. (Perhaps they rightly assume that it
> knows how to do its job! That is, enforce the rules of the language,
> without needing to be reminded of which ones the user needs
> enforcing).
My comments most certainly are about you. Your posts are not designed
to help. In fact they make matters worse. Posting junk code without
saying that it junk code misleads people learning C and does nothing to
prompt compiler authors to change their default settings.
Had you written something like:
"C has const but most compilers are far too lax in their default modes
letting obviously undefined code like this:
<your code here>
through on the nod."
I would not have commented. Or you could have explained that casts are
should be avoided as far as possible (and you might be surprised by how
many junk casts there are in bad C code) because most compilers take
that as a strong indication that the programmer is insisting on
something unusual or even dangerously undefined.
But you don't do that.
> Actually I /don't/ know to get gcc to report it properly.
For your example, it's -Wcast-qual. It's not in the common sets of
warnings because, I think, gcc takes the second view -- if you cast away
const you must know what you are doing. Why, says gcc, would anyone
write all those extra characters without wanting me to do it? You may
not agree, but it's a reasonable choice to have made.
> And as I said, that still only warned.
As you know perfectly well, you can choose to have such code fail with a
hard error (-Werror), but most compilers take the view that putting in a
cast like this indicates you really, really want to risk it.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-01 12:04 +0100 |
| Message-ID | <teq3ka$di7$1@gioia.aioe.org> |
| In reply to | #167412 |
On 01/09/2022 11:17, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> This isn't about me. Very many people seem to run compilers like gcc >> without all the right options. (Perhaps they rightly assume that it >> knows how to do its job! That is, enforce the rules of the language, >> without needing to be reminded of which ones the user needs >> enforcing). > > My comments most certainly are about you. Your posts are not designed > to help. In fact they make matters worse. Posting junk code without > saying that it junk code misleads people learning C and does nothing to > prompt compiler authors to change their default settings. > > Had you written something like: > > "C has const but most compilers are far too lax in their default modes > letting obviously undefined code like this: > > <your code here> > > through on the nod." > > I would not have commented. Come on, no beginners read this group any more. They use forums like Reddit. >> Actually I /don't/ know to get gcc to report it properly. > > For your example, it's -Wcast-qual. It's not in the common sets of > warnings because, I think, gcc takes the second view -- if you cast away > const you must know what you are doing. Why, says gcc, would anyone > write all those extra characters without wanting me to do it? But discarding swathes of code because the compiler thinks it's pointless is fine? (This makes benchmarking using gcc a nightmare.) >> And as I said, that still only warned. > > As you know perfectly well, you can choose to have such code fail with a > hard error (-Werror), but most compilers take the view that putting in a > cast like this indicates you really, really want to risk it. Sure. But then a lot of valid code will fail, because of things like: * Unused local variables (which may only be unused because some code is temporarily commented out) * Defined but unused labels (very common with machine generated code) * Casts between object and function pointers It would be making most code impossibly strict. A compiler needs to throw out OBVIOUSLY wrong and crazy programs without having to be told, and without being forced to fix completely harmless issues (see my spam example to DB just posted).
[toc] | [prev] | [next] | [standalone]
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web