Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #171992 > unrolled thread
| Started by | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| First post | 2023-08-10 04:29 -0700 |
| Last post | 2023-09-13 09:40 -0700 |
| Articles | 20 on this page of 359 — 21 participants |
Back to article view | Back to comp.lang.c
bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-10 04:29 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-10 12:57 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-10 05:07 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-10 13:14 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-10 06:53 -0700
Re: bart again (UCX64) cross@spitfire.i.gajendra.net (Dan Cross) - 2023-08-16 11:52 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-16 02:31 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-28 03:30 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-28 11:43 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-28 03:47 -0700
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-04 18:43 -0700
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-10 04:59 -0700
Re: bart again (UCX64) Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-08-28 17:45 +0300
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-28 19:19 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-29 22:01 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-29 20:00 -0700
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 00:25 -0700
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 01:35 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-30 11:38 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 07:06 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-30 15:53 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 12:46 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-30 22:59 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 15:54 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 00:17 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 16:30 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 11:58 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 05:32 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 14:45 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 07:43 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 15:56 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 08:38 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 12:56 -0700
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 22:09 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 10:12 +0200
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 23:53 -0700
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 14:39 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-31 20:56 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-08-31 14:36 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 15:30 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 16:17 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-08-31 19:36 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 20:26 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 13:17 -0700
Verbosity in command output (Was: bart again (UCX64)) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-31 21:43 +0000
Re: Verbosity in command output (Was: bart again (UCX64)) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-31 23:31 +0000
Re: Verbosity in command output (Was: bart again (UCX64)) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-31 21:36 -0700
Re: Verbosity in command output (Was: bart again (UCX64)) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 17:22 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 23:07 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 15:32 -0700
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 22:05 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 22:07 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 23:18 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 23:03 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 16:46 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 01:44 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 18:09 -0700
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-31 18:11 -0700
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 18:14 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 01:38 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 02:40 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 01:29 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 20:28 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 11:10 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 12:01 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 13:20 +0200
Re: bart again (UCX64) Richard Harnden <richard.nospam@gmail.com> - 2023-09-01 13:08 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 13:39 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 15:29 +0200
Re: bart again (UCX64) Richard Harnden <richard.nospam@gmail.com> - 2023-09-01 14:32 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 18:14 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 19:01 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 18:53 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-01 14:53 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 15:57 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-01 19:07 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 19:27 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 18:55 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 21:27 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 20:46 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 22:29 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 22:19 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 13:56 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 15:31 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 16:05 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 03:17 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 10:34 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-04 03:07 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 11:43 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-04 04:21 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 17:16 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 18:33 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-05 01:33 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-04 15:27 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 17:18 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-04 16:26 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 19:33 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-04 19:17 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 20:48 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 21:25 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-04 21:56 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-05 01:34 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 21:06 +0100
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-04 13:09 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 16:04 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 00:52 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 17:16 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 15:33 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-05 14:55 +0000
Re: bart again (UCX64) Bobby Moore <bobbymoore018@gmail.com> - 2023-09-05 08:30 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-05 17:31 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 18:06 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 17:54 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-05 20:10 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 20:57 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-05 22:37 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 22:05 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 15:10 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 22:32 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 06:49 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-06 16:08 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 07:53 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-06 17:35 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 09:37 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-06 20:49 +0200
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-06 19:51 +0000
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-06 12:52 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 00:36 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 17:06 -0700
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 18:47 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 11:11 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-07 04:04 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 13:24 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-06 18:13 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-06 21:17 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-06 22:24 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 11:37 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 11:53 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 13:33 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 14:36 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 22:59 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 16:58 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-08 00:35 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 20:41 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 20:47 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 14:07 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 22:22 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 15:26 -0700
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-05 18:26 -0700
Re: bart again (UCX64) James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-07 23:15 -0400
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 13:48 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 21:36 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-05 13:24 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 15:46 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 17:44 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-02 01:14 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-01 18:13 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 01:43 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 17:51 +0200
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 17:58 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-02 23:28 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-02 20:09 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 07:15 +0000
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-03 03:03 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 18:53 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 16:24 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 12:22 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 02:01 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-05 21:40 -0700
[OT] Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 17:06 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-03 18:02 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 10:39 +0100
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-02 07:33 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 16:26 +0100
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-02 09:03 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 19:22 +0100
Re: bart again (UCX64) vallor <vallor@cultnix.org> - 2023-09-05 01:38 +0000
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-04 20:05 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 16:45 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 06:49 +0000
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-05 05:30 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 17:16 +0000
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 08:47 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 19:57 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 19:01 -0700
Re: bart again (UCX64) James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-09 01:14 -0400
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 05:22 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 12:51 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-02 12:58 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 16:29 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 20:00 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 00:08 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 01:36 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 02:41 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 17:49 +0200
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 18:32 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-01 18:59 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 18:02 +0200
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-03 15:54 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 19:50 +0200
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-03 21:25 +0000
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-03 16:44 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 11:47 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 18:16 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 17:48 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 19:12 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 18:49 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 21:33 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 21:09 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 22:41 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 22:34 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-01 15:51 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 14:06 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 17:27 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-01 16:02 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 01:50 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 01:12 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-01 19:13 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 11:57 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 18:19 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 19:53 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 06:32 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 16:02 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 18:11 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 11:31 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 20:07 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 22:08 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 03:16 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-04 10:54 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 11:06 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 14:54 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 22:02 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-05 01:31 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 02:24 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 04:29 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 21:06 -0700
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 01:03 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 20:58 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 19:21 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 20:18 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-06 13:07 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 22:41 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-06 15:56 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 00:53 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-06 18:47 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 17:25 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-12 10:32 -0700
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-04 18:30 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 03:04 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 21:48 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 06:10 +0000
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-07 02:06 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 15:52 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 14:18 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 15:28 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 16:54 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 17:02 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 16:12 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 16:17 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 17:37 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 14:51 -0700
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 00:46 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 11:06 +0200
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 10:19 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 15:55 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 15:16 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 17:02 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 16:15 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 17:51 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 17:24 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 21:53 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 21:34 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 17:25 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 21:37 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 21:02 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 16:14 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 16:09 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 17:34 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 17:22 +0000
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-07 11:44 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 15:16 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 23:48 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 17:16 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 11:16 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 10:51 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 13:00 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 13:05 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 16:11 +0200
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 00:56 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 00:47 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-09 18:49 +0200
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-09 10:27 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 12:06 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-08 05:03 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 13:39 +0100
Re: bart again (UCX64) candycanearter07 <no@thanks.net> - 2023-09-08 07:49 -0500
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:07 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-09 18:51 +0200
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 16:35 +0200
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:04 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-04 14:14 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-04 16:59 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 15:41 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-04 18:15 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 18:57 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-30 09:23 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-30 15:55 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 17:10 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-02 13:13 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-02 22:50 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-02 14:54 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-01 19:02 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-02 22:42 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-02 15:08 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 02:00 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 23:18 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 02:28 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 06:58 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 15:52 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 11:02 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 16:25 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 16:49 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 16:16 +0200
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 18:11 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 22:08 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 16:48 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-02 14:52 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 02:23 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-03 03:47 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 18:44 +0000
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 18:01 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 16:59 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-03 17:50 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 10:43 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-01 02:17 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 13:26 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 11:35 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 13:39 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 14:09 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 15:33 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-01 05:14 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 17:41 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-01 18:21 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-01 14:31 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 22:39 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 07:07 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-31 19:17 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-31 19:28 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 21:03 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 11:23 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 20:50 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-31 23:12 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 02:25 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 20:37 -0700
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 07:51 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-30 16:09 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-30 20:17 +0100
Re: bart again (UCX64) Michael S <already5chosen@yahoo.com> - 2023-08-29 04:46 -0700
Buy Magic Mushrooms online Buy Magic Mushroom Chocolate Bars <taresa67kolyta@gmail.com> - 2023-09-13 09:40 -0700
Page 13 of 18 — ← Prev page 1 … 11 12 [13] 14 15 … 18 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-06 13:07 +0100 |
| Message-ID | <ud9q2j$2g6ee$1@dont-email.me> |
| In reply to | #174103 |
On 06/09/2023 04:29, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> This is just wordplay isn't it?
>
> Not from my side, no. I want to illustrate how I think about programs
> and programming languages. To me, programs are texts to which we may be
> able to ascribe a meaning. This text:
>
> int main(void) { return 1; }
>
> has a meaning if we interpret it as C. That's an important step,
> because this program
>
> int main(void) { return 1; };
>
> is meaningless if we interpret it as C, but if we interpret it as GNU C,
> then it /does/ have a well-defined meaning (as it happens, the same
> meaning as the first).
I assume GNU C allows semicolons after function definitions. That's
unfortunate. If the grammar rule was applied strictly, then there would
be no programs in existence that would use semicolons like that.
Instead, some programs will have semicolons, so one that normally
compiles happily, is at risk of failing when a different compiler and/or
different set of options is used. And for what benefit?
> This text:
>
> int main(void) { int a[] = {1}; return a[2]; }
>
> is meaningless (as C). It does not "do" anything because it means
> nothing.
I assume you mean because it accesses out-of-bounds elements of 'a'.
I would not call that meaningless, it is a valid C program with
undefined behaviour. It is not interestingly different from one using
'return a[f()]' where f() is some external function.
But a compiler could choose to point out an out-of-bounds access; I'm
surprised that gcc -Wall -Wextra -Wpedantic doesn't do so.
>> char* getversion(void) {}
>>
>> int main(void) {
>> puts(getversion());
>> }
>>
>> So, I can compile this using:
>>
>> gcc -std=c99 -Wall -Wpedantic prog.c
>>
>> which produces an executable that either crashes or prints nonsense. And
>> that's OK, because it is undefined?
>
> No, what happens is OK because you asked gcc to guess a meaning for this
> meaningless text. You can ask gcc not to (at least in this case) by
> saying
>
> gcc -Werror -std=c99 -Wall -Wpedantic prog.c
Which is OK for this tiny program. But in practice such things are
buried in 10s or 100s of thousands of lines, and using such options
means it is has to be utterly perfect in terms of not upsetting the
compiler.
Then it's a choice between writing a working, bug-free program that does
what it's meant to do, or expending too much effort dotting every I and
crossing every T to satisfy the compiler on a thousand inconsequential
details.
A compiler like the one invoked by gcc doesn't understand that some
things might be more important than others. For example:
Extra semicolon Warning
Incompatible pointers Warning
(without using a cast)
Unused local or parameter Warning
Unused label Warning
Cast T* direct to func ptr Warning
(instead of casting via an int)
Which one of these could have a serious affect on behaviour? Assume that
a programmer using a cast has the matter in hand.
I would say incompatible pointers is what is worth failing a program
for. That can easily be circumvented by using a cast, /if/ it was
intentional and not inadvertent.
However I would also fail the extra semicolon, since it is utterly
trivial to fix, and bestows no advantages in allowing it. (If you say
machine-generated code, then you really need to fix that generator.)
Those other three are harder to do something about. The unused names
might be temporary situations, so you might want to turn on those checks
separately, but not in a routine build.
The object to function pointer casts I think is a flaw in the language,
given that you can convert between object pointers and ints, and between
ints and function pointers, allowing you to do indirectly it that way.
So the objection is silly. (Note that in generated code, you may be
merely transpiling a cast in the original language of T(X) to the C
equivalant which is (T)X, and in both that language and the targets of
interest, the conversion is well-defined.)
>> Even the compilation reported that it
>> ran into the end of a non-void function.
>
> Yes, and you /still/ went ahead and ran the code the compiler invented
> from the meaningless C text.
You could run it like this 'gcc .... prog.c && a'.
Or you or someone else can later run that program without being aware of
the warning that was generated, or having forgotten.
> You can certainly complain that gcc did
> not work hard enough to stop you, but gcc sees itself as a tool not a
> teacher.
As I explained, in my language it is impossible for a non-void function
to run into the end of function without an explicit 'return value' or
equivalent (without going beyond the language).
(Which can be a nuisance when you have new functions not yet populated,
nor yet called, but it is also a minor one. Rules are rules, which here
are to do with the type system. Bypass that one, and I might as well
allow 'a[i] := ;' because I haven't yet gotten around to working out the
RHS of that assignment.)
>
>> * That was not a C compiler
>
> You are mixing up different remarks. gcc (on it's own) is not a C
> compiler. gcc -std=c99 -Wall -Wpedantic is a C compiler.
I don't know about that:
c:\c>gcc -Wall -Wpedantic -Werror -Wextra -std=c99 hello.ftn
gcc: error: hello.ftn: Fortran compiler not installed on this system
Maybe it checks for the right compiler before it looks at those options,
but by themselves, they don't tell gcc to be expecting C input.
> Running gcc with no flags and complaining that it does not report a
> syntax error is simply daft because gcc (with no flags) is not a C
> compiler -- it interprets its input according to rules that are not
> those of the C standard.
So it compiles a C subset or superset. Clearly it's not compiling APL;
we can call it C, especially since gcc derives knowledge of the language
it is compiling from the file extension, and in all examples I've shown,
that is .c. You are stating that:
gcc prog.c
is not compiling C. That is not right.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-06 22:41 +0100 |
| Message-ID | <87tts7ou7x.fsf@bsb.me.uk> |
| In reply to | #174143 |
Bart <bc@freeuk.com> writes:
> On 06/09/2023 04:29, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> This is just wordplay isn't it?
>> Not from my side, no. I want to illustrate how I think about programs
>> and programming languages. To me, programs are texts to which we may be
>> able to ascribe a meaning. This text:
>> int main(void) { return 1; }
>> has a meaning if we interpret it as C. That's an important step,
>> because this program
>> int main(void) { return 1; };
>> is meaningless if we interpret it as C, but if we interpret it as GNU C,
>> then it /does/ have a well-defined meaning (as it happens, the same
>> meaning as the first).
>
> I assume GNU C allows semicolons after function definitions. That's
> unfortunate. If the grammar rule was applied strictly, then there would be
> no programs in existence that would use semicolons like that.
K&R C allowed it, mainly because a type-specifier can be omitted and
defaults to int. The /grammar/ in K&R does not permit it, but the text
says that, if the type-specifier is missing it is taken to be int.
A lot of early C was like that: a very simple grammar (presumably to
keep the compiler small enough to run) with some rules that override or
refine it.
And then C got popular and compilers were stuck with it or risked
rejecting code for something that, frankly, is not important.
> Instead, some programs will have semicolons, so one that normally compiles
> happily, is at risk of failing when a different compiler and/or different
> set of options is used. And for what benefit?
The main benefit is to existing programs. A language with lots of users
can't easily make breaking changes. And if a compiler does, in a
open-source world, a fork will appear to satisfy the demand.
>
>
>> This text:
>> int main(void) { int a[] = {1}; return a[2]; }
>> is meaningless (as C). It does not "do" anything because it means
>> nothing.
>
> I assume you mean because it accesses out-of-bounds elements of 'a'.
>
> I would not call that meaningless, it is a valid C program with undefined
> behaviour. It is not interestingly different from one using 'return a[f()]'
> where f() is some external function.
Well it is to me (though it depends if the text of the external function
is also available).
A program this is, from inspection, undefined is different to one that
may be undefined when run. The canonical example being one that uses
input so that no static analysis could detect the undefined nature.
> But a compiler could choose to point out an out-of-bounds access; I'm
> surprised that gcc -Wall -Wextra -Wpedantic doesn't do so.
It does -O2. That's quiet common with gcc as the optimiser does much
more detailed static analysis.
And if you compile with -fsanitize=undefined, even with no optimisation
you get this when you run the compiled program:
ub.c:1:41: runtime error: index 2 out of bounds for type 'int [1]'
ub.c:1:41: runtime error: load of address 0x7ffce05a9a8c with
insufficient space for an object of type 'int'
That's permitted /because/ the code is undefined. If the meaning were
defined operationally (as I think is your preference) the compiled code
should just access the int at a+2 and set the program's status
accordingly.
>
>>> char* getversion(void) {}
>>>
>>> int main(void) {
>>> puts(getversion());
>>> }
>>>
>>> So, I can compile this using:
>>>
>>> gcc -std=c99 -Wall -Wpedantic prog.c
>>>
>>> which produces an executable that either crashes or prints nonsense. And
>>> that's OK, because it is undefined?
>> No, what happens is OK because you asked gcc to guess a meaning for this
>> meaningless text. You can ask gcc not to (at least in this case) by
>> saying
>> gcc -Werror -std=c99 -Wall -Wpedantic prog.c
>
> Which is OK for this tiny program. But in practice such things are buried
> in 10s or 100s of thousands of lines, and using such options means it is
> has to be utterly perfect in terms of not upsetting the compiler.
Yes. You really need to keep a note of the warnings you want and the
ones you dont't, along with which ones should be errors. Of course you
don't need to that with your own compiler, because you already did is as
you were writing it. It will treast as errors excatly those things you
consider serious, warn about those things you like to know abut and
ignore everything else.
> Then it's a choice between writing a working, bug-free program that does
> what it's meant to do, or expending too much effort dotting every I and
> crossing every T to satisfy the compiler on a thousand inconsequential
> details.
It's better to either keep a set of options you like. But you can also
just fix as you go. Most i dotting and t crossing is trivial.
> A compiler like the one invoked by gcc doesn't understand that some things
> might be more important than others. For example:
>
> Extra semicolon Warning
> Incompatible pointers Warning
> (without using a cast)
> Unused local or parameter Warning
> Unused label Warning
> Cast T* direct to func ptr Warning
> (instead of casting via an int)
>
> Which one of these could have a serious affect on behaviour? Assume that a
> programmer using a cast has the matter in hand.
>
> I would say incompatible pointers is what is worth failing a program
> for. That can easily be circumvented by using a cast, /if/ it was
> intentional and not inadvertent.
gcc allows you to do that. Some people use C like a portable assemler,
so they really don't want to put in something which, on their hardware,
is a no-op. I can't honestly say I don't want gcc to cater to that
style of programming. I don't what people like coding my pacemaker, but
gcc does allow much stricter checks to be used.
> However I would also fail the extra semicolon, since it is utterly trivial
> to fix, and bestows no advantages in allowing it. (If you say
> machine-generated code, then you really need to fix that generator.)
Your choice.
> Those other three are harder to do something about. The unused names might
> be temporary situations, so you might want to turn on those checks
> separately, but not in a routine build.
>
> The object to function pointer casts I think is a flaw in the language,
> given that you can convert between object pointers and ints, and between
> ints and function pointers, allowing you to do indirectly it that way.
You can ask for it with or with a cast as well. The route via an
integer type is just a way to prevent most compilers from saying
anything. None of these different methods will work on all systems, but
if you know it's safe, you can (with gcc) just not ask for the warning
and do it drectly.
I don't know what aspect you consider to be a flaw in the language. The
language says you can't do it directly without a diagnostic, and that if
you go round the houses via an interer type (where it won't always to be
possible to tell where the pointer originally came from) it's up to the
implementation what happens.
> So the objection is silly.
The object is a warning that the code is not portable. C makes are
distinction between object and function pointers because some machines
make that distinction very strictly.
>>> Even the compilation reported that it
>>> ran into the end of a non-void function.
>> Yes, and you /still/ went ahead and ran the code the compiler invented
>> from the meaningless C text.
>
> You could run it like this 'gcc .... prog.c && a'.
You could. So what? It's still running the code without looking at
what the compiler said about it.
> Or you or someone else can later run that program without being aware of
> the warning that was generated, or having forgotten.
Yes, just like any buggy code. The bug has the advantage that is was
identified at compile time but no one wanted to pay attention. That's
low on my list of things to worry about in the world.
You get really worked up about the warning/error distinction in gcc, but
there is never any substitute for paying attention. Making a lot of bad
things are errors made into errors might encourage more people to ignore
the warings that are left. There's an argument for never making
anything a hard error so as to encourage every warning to be properly
onsidered before moving on.
>>> * That was not a C compiler
>> You are mixing up different remarks. gcc (on it's own) is not a C
>> compiler. gcc -std=c99 -Wall -Wpedantic is a C compiler.
>
> I don't know about that:
>
> c:\c>gcc -Wall -Wpedantic -Werror -Wextra -std=c99 hello.ftn
> gcc: error: hello.ftn: Fortran compiler not installed on this system
You are right. Thanks. To be sure, you need something more like
gcc -std=c99 -x c -pedantic
to rule out compiling some fortran as well. I'll remember that the next
time I am talking to someone who wants to complain about what gcc (with
no flags at all) does with some source code. With people who know that
most compilers don't comform in default mode, there is no need to be so
pedantic.
>> Running gcc with no flags and complaining that it does not report a
>> syntax error is simply daft because gcc (with no flags) is not a C
>> compiler -- it interprets its input according to rules that are not
>> those of the C standard.
>
> So it compiles a C subset or superset.
Otherwise know and GNU C so as not to confuse people.
> Clearly it's not compiling APL;
And clearly not compiling C either.
> we can call it C,
I normally would, but not when I am talking to you because you
specifically wanted to coplain that "C is whatever you make it by the
flags you use". You forced my hand. C is defined by an ISO document,
and not by the flags we pass to gcc. When you agree that you won't play
this word game anymore, I might go back to using a more relaxled
interpretation of what "C" means.
> especially since gcc derives knowledge of the language it is compiling
> from the file extension, and in all examples I've shown, that is
> .c.
Yes. The knowlegde derived is that the source might be any one of a
large set of C-like languages. You have no idea (until you read the
manual) which one gcc will pick.
> You are stating that:
>
> gcc prog.c
>
> is not compiling C. That is not right.
Until you stop playing this word game, I will take C to mean the
programming language defined by the ISO, and gcc prog.c does not compile
that language. gcc (with either -x c or a .c source file) compiles one
of a familiy of related C-like languages but /not/ C as it is properly
defined.
You can start moving to a more relaxed and informal use of the word "C"
by agreeing that the languages compiled by gcc and gcc -std=c99 are in
fact different. If I know you know that, I will know that you don't
mean one language when you talk about "C".
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-06 15:56 -0700 |
| Message-ID | <87pm2u3o8i.fsf@nosuchdomain.example.com> |
| In reply to | #174226 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Bart <bc@freeuk.com> writes:
[...]
>> I assume GNU C allows semicolons after function definitions. That's
>> unfortunate. If the grammar rule was applied strictly, then there would be
>> no programs in existence that would use semicolons like that.
Just to be clear, a semicolon after a function definition:
void foo(void) {};
isn't associated with the function definition. The semicolon is treated
as a file-scope declaration. If the above is valid, then so is a
source file consisting of a single line with just a semicolon.
> K&R C allowed it, mainly because a type-specifier can be omitted and
> defaults to int. The /grammar/ in K&R does not permit it, but the text
> says that, if the type-specifier is missing it is taken to be int.
[...]
So K&R C (and C90?) treated this:
;
at file scope as a definition with an implicit type of int, so it's
equivalent to this:
int;
I *think* that's either a constraint violation or a syntax error in C90
and later, but I haven't absorbed the syntax for "declaration" and
"declarator" well enough to be sure of that.
gcc warns about `int;` by default, and rejects it with the options
"-std=c90 -pedantic-errors". The diagnostic is "useless type name in
empty declaration". The diagnostic for a lone semicolon with the same
options is "ISO C does not allow extra ‘;’ outside of a function
[-Wpedantic]".
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-07 00:53 +0100 |
| Message-ID | <87cyyuq2oc.fsf@bsb.me.uk> |
| In reply to | #174235 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Bart <bc@freeuk.com> writes:
> [...]
>>> I assume GNU C allows semicolons after function definitions. That's
>>> unfortunate. If the grammar rule was applied strictly, then there would be
>>> no programs in existence that would use semicolons like that.
>
> Just to be clear, a semicolon after a function definition:
>
> void foo(void) {};
>
> isn't associated with the function definition. The semicolon is treated
> as a file-scope declaration. If the above is valid, then so is a
> source file consisting of a single line with just a semicolon.
>
>> K&R C allowed it, mainly because a type-specifier can be omitted and
>> defaults to int. The /grammar/ in K&R does not permit it, but the text
>> says that, if the type-specifier is missing it is taken to be int.
> [...]
>
> So K&R C (and C90?) treated this:
Not C90 as far as I know.
> ;
>
> at file scope as a definition with an implicit type of int, so it's
> equivalent to this:
>
> int;
Probably, though it's hard to tell if that is "equivalent" since there
are no observable facts. A K&R C Unix V7 compiler running on a PDP11
simulator accepts this code silently:
;
int;
int main(){ return 1; };
K&R1 says that both the type specifier and the storage class specifier
can be omitted, and that int is assumed when no type is given. When the
storage class is missing it is assumed to be auto in a function and
extern outside, with the exception that function are never automatic.
> I *think* that's either a constraint violation or a syntax error in C90
> and later, but I haven't absorbed the syntax for "declaration" and
> "declarator" well enough to be sure of that.
The syntax is not always enough, at least for very early C. K&R syntax
explicitly rules out all the cases above, but the text then adds
(overrides?) the syntax. I don't know of there are cases where the text
in C90 overrides the syntax.
> gcc warns about `int;` by default, and rejects it with the options
> "-std=c90 -pedantic-errors". The diagnostic is "useless type name in
> empty declaration". The diagnostic for a lone semicolon with the same
> options is "ISO C does not allow extra ‘;’ outside of a function
> [-Wpedantic]".
All good on an old K&R compiler! You really had to know what you were
doing in those days.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-06 18:47 -0700 |
| Message-ID | <87ledi3gbt.fsf@nosuchdomain.example.com> |
| In reply to | #174239 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Bart <bc@freeuk.com> writes:
>> [...]
>>>> I assume GNU C allows semicolons after function definitions. That's
>>>> unfortunate. If the grammar rule was applied strictly, then there would be
>>>> no programs in existence that would use semicolons like that.
>>
>> Just to be clear, a semicolon after a function definition:
>>
>> void foo(void) {};
>>
>> isn't associated with the function definition. The semicolon is treated
>> as a file-scope declaration. If the above is valid, then so is a
>> source file consisting of a single line with just a semicolon.
>>
>>> K&R C allowed it, mainly because a type-specifier can be omitted and
>>> defaults to int. The /grammar/ in K&R does not permit it, but the text
>>> says that, if the type-specifier is missing it is taken to be int.
>> [...]
>>
>> So K&R C (and C90?) treated this:
>
> Not C90 as far as I know.
You're right.
>> ;
>>
>> at file scope as a definition with an implicit type of int, so it's
>> equivalent to this:
>>
>> int;
>
> Probably, though it's hard to tell if that is "equivalent" since there
> are no observable facts. A K&R C Unix V7 compiler running on a PDP11
> simulator accepts this code silently:
>
> ;
> int;
> int main(){ return 1; };
>
> K&R1 says that both the type specifier and the storage class specifier
> can be omitted, and that int is assumed when no type is given. When the
> storage class is missing it is assumed to be auto in a function and
> extern outside, with the exception that function are never automatic.
Right. What I was wondering about is which rule makes
int;
at file scope invalid -- and I think I've found the answer.
C90 6.5 has this syntax:
declaration
declaration-specifiers init-declarator-list[opt] ;
with this constraint:
A declaration shall declare at least a declarator, a tag, or the
members of an enumeration.
The wording in later editions is similar. K&R1 did not have that
constraint.
So `int;` satisfies the syntax of a declaration, but violates the
constraint.
The *init-declarator-list* is optional so you can have declarations
like:
enum foo { x, y };
Both `enum foo { x, y }` and `int` are type specifiers; the former is
allowed by itself in a declaration, but the latter is not.
Getting back to the original issue, I think that gcc's acceptance of a
lone semicolon at file scope goes back to K&R C, which allowed it; the
old "implicit int" rule made it equivalent to `int;`, which was allowed
because the constraint I mentioned above had not yet been introduced.
It would IMHO have been reasonable for gcc to make this invalid by
default. Of course it rejects it if you ask for conformance.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-06 17:25 -0700 |
| Message-ID | <86bkeeomn7.fsf@linuxsc.com> |
| In reply to | #174235 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Bart <bc@freeuk.com> writes:
>
> [...]
>
>>> I assume GNU C allows semicolons after function definitions. That's
>>> unfortunate. If the grammar rule was applied strictly, then there would be
>>> no programs in existence that would use semicolons like that.
>
> Just to be clear, a semicolon after a function definition:
>
> void foo(void) {};
>
> isn't associated with the function definition. The semicolon is treated
> as a file-scope declaration. If the above is valid, then so is a
> source file consisting of a single line with just a semicolon.
>
>> K&R C allowed it, mainly because a type-specifier can be omitted and
>> defaults to int. The /grammar/ in K&R does not permit it, but the text
>> says that, if the type-specifier is missing it is taken to be int.
>
> [...]
>
> So K&R C (and C90?) treated this:
>
> ;
>
> at file scope as a definition with an implicit type of int, so it's
> equivalent to this:
>
> int;
>
> I *think* that's either a constraint violation or a syntax error in C90
> and later, but I haven't absorbed the syntax for "declaration" and
> "declarator" well enough to be sure of that.
In ISO C (including C90), a semicolon by itself (and outside of
any function) has no derivation under the grammar. It's not a
declaration or anything else.
In ISO C (including C90), a declaration 'int;' is a constraint
violation.
(The foregoing presumes my cursory checking of the standards is
correct.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-12 10:32 -0700 |
| Message-ID | <86pm2nmh4o.fsf@linuxsc.com> |
| In reply to | #174103 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> This text:
>
> int main(void) { int a[] = {1}; return a[2]; }
>
> is meaningless (as C). It does not "do" anything because it
> means nothing.
I would like to offer a different perspective on this question.
I take the meaning of a C program to be a mapping from inputs
to outcomes. The term outcome is meant to be "the result" of
giving a particular input to a program, without being too
specific about what counts as part of a result. For example,
"outcome" includes the observable behavior of a program, but it
also includes exit status, which is not part of the observable
behavior. (I needed to check the definition of observable
behavior to verify that.)
The first point is that outcome is multi-valued: a result might
be a single outcome, or it might be a set of possible outcomes.
A program that relies on unspecified behavior can produce
different results depending on what choices are made in each case
where the program depends on unspecified behavior. (Side point:
I think we can treat implementation-defined behavior as simply
one more component of program input. In any case we will not
consider it further, as it shouldn't cause any serious problems.)
Viewed from this perspective, the meaning of the program above
is a set containing all possible outcomes (and incidentally that
is the result for all inputs). Of course it can be the case that
some programs have infinite outcome sets for some inputs and
finite outcome sets for other inputs. It may be surprising but
there is actually some positive information content in saying the
meaning of a program is a set of all possible outcomes. To see
that, consider this program:
int main(void) { return 1; };
No doubt there are different points of view about what the outcome
set of this program should be, but we can be sure of one thing: if
there are any elements in this program's outcome set, every one
includes at least one diagnostic message, caused by the syntax
error. So even if the outcome set is infinite, it is a proper
subset of the outcome set of the previous program with undefined
behavior (and no syntax errors or constraint violations), because
some of those outcomes do not include any diagnostics.
My inclination here is to say the second program is "meaningless"
whereas the first program does have a "meaning", even if not an
especially useful one. That view seems consistent with what is
said in the ISO C standard, the very first sentence of which
reads
This International Standard specifies the form and
establishes the interpretation of programs expressed
in the programming language C.
The "meaning" of a proprosed program text is what interpretation is
specified for it. The second program doesn't satisfy the form of
programs written in C, and hence does not have an interpretation
specified for it: meaningless. The first program does satisfy the
form of programs written in C, and so does have an interpretation
specified for it, even though what is specified is unboundedly
liberal. Furthermore I think the distinction described corresponds
to how we normally think of the words used. The second program is
"meaningless" no matter what input it is given. But it's fairly
easy to construct programs that have undefined behavior only on
very large inputs (over, say, 2**128 characters). It seems wrong
to call a program "meaningless" if its behavior is well-defined for
all inputs it will ever be run on. It's much nicer to say that such
a program is meaningful, with the outcome sets for some inputs being
infinite.
So for what it's worth, there is another taken on the matter.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-04 18:30 -0700 |
| Message-ID | <b9e00c9c-e879-49d2-a00a-05256b87d766n@googlegroups.com> |
| In reply to | #173920 |
On Tuesday, 5 September 2023 at 01:31:48 UTC+1, Ben Bacarisse wrote: > > > Do you have your own examples in other languages which do the same: return > > whatever garbage is in a register, since the language allows you to omit an > > explicit value? > If "the language" is C, then it does not allow any such thing. And the > program you posted does not "do" anything. It is as meaningless and any > and all other undefined C programs. > Originally C didn't have a void type. So if (foo()) was always a legitimate statement. If foo() couldn't sensibly return a value, then it would default to int, and whatever garbage was in the register used for passing back values would be used. This wasn't ideal, but it probably made the very primitive first compilers easier to write. It's hung on to the present day. Compilers will still accept functions which return garbage values. Presumably for backwards compatibility, though as some people have pointed out, in some case you would have to add dummy returns on control paths which couldn't in fact be followed, to help the compiler out.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-06 03:04 +0100 |
| Message-ID | <87v8coqcpa.fsf@bsb.me.uk> |
| In reply to | #173937 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Tuesday, 5 September 2023 at 01:31:48 UTC+1, Ben Bacarisse wrote: >> >> > Do you have your own examples in other languages which do the same: return >> > whatever garbage is in a register, since the language allows you to omit an >> > explicit value? >> If "the language" is C, then it does not allow any such thing. And the >> program you posted does not "do" anything. It is as meaningless and any >> and all other undefined C programs. >> > Originally C didn't have a void type. So > > if (foo()) > > was always a legitimate statement. For some values of "legitimate". It's never been legitimate in the sense of "being in accordance with established or accepted rules" when foo does not return a value determined by the programmer. The accepted rules of programming include not making a choice based on garbage data. It is syntactically legitimate, but using the term unqualified could suggest to readers that it was once a reasonable thing to write. > If foo() couldn't sensibly return a value, then it would default to > int, and ... If foo() couldn't sensibly return a value, then the programmer would usually omit the return type as a hint to the reader. Since missing types defaulted to int ... > ... whatever garbage was in the register used for passing back > values would be used. This wasn't ideal, but it probably made the > very primitive first compilers easier to write. > > It's hung on to the present day. What's the "it" refer to? Neither the default int rule nor returning whatever is in a particular register could be taken to apply anymore. The rule has changed, and modern compilers don't always behave that predictably. Optimisation, in particular, is likely to make the behaviour quite different. > Compilers will still accept functions which return > garbage values. Presumably for backwards compatibility, I suspect it's also because detecting the cases that are actual errors is hard and expecting people to sometimes add junk return statements is less than ideal. Modern compilers can detect lots of the cases and can be told to reject such programs which make the problem much less significant (for people who are prepared to use compiler flags). > though as some people have > pointed out, in some case you would have to add dummy returns on control paths > which couldn't in fact be followed, to help the compiler out. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-06 21:48 -0700 |
| Message-ID | <86zg1ymvvv.fsf@linuxsc.com> |
| In reply to | #174082 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: [...] >> Compilers will still accept functions which return >> garbage values. Presumably for backwards compatibility, > > I suspect it's also because detecting the cases that are actual > errors is hard [...] Besides being theoretically impossible, it's not practical because of C allowing separate compilation. To get an answer (potentially) requires examining the entire program. Most C programs are split into several translation units, with only one being compiled at a time. I hope I don't have to explain that any kind of whole-program diagnostic like this is a non-starter given the C compilation model.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-07 06:10 +0000 |
| Message-ID | <20230906223634.465@kylheku.com> |
| In reply to | #174278 |
On 2023-09-07, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
> [...]
>
>>> Compilers will still accept functions which return
>>> garbage values. Presumably for backwards compatibility,
>>
>> I suspect it's also because detecting the cases that are actual
>> errors is hard [...]
>
> Besides being theoretically impossible, it's not practical
> because of C allowing separate compilation. To get an answer
> (potentially) requires examining the entire program.
But why would that even be a goal?
If you need to know what a function in another translation unit
does in order to know whether or not the function "falls off the end",
that's a code smell.
Diagnostics that flag some correct programs are par for the course
in static checking. That's what you accept in order to find problems
without running the program.
For instance, this snippet requires diagnosis:
int x = 3;
char *cpx = &x;
int *ipx = cpx;
printf("%s\n", *cpx); // assumed to be declared properly
The rule of thub in C is that most pointer conversions are a code smell,
and so are diagnosed. The requirement for diagnosis is all which is
rendering the code incorrect; without it, it would be correct, as
would an edited version with casts put in.
That's a clear example of a diagnostic rule which is not accurate
(and we take it for granted that way, even like it).
No I can see that the bar has to be fairly high for making something a
required diagnostic in the international language standard, given that
implementors can already diagnose whatever they want.
The users who want diagnostics about ends of value-returning functions
being reached (and even stop the program in that situation) are getting
them from compilers.
However you look at it, there doesn't seem to be a pressing need to push
that into the language. Sure.
> Most C
> programs are split into several translation units, with only one
> being compiled at a time. I hope I don't have to explain that
> any kind of whole-program diagnostic like this is a non-starter
> given the C compilation model.
It's not just that, but run-time conditions:
if ((*gpio32_ptr & FOO_MASK) != 0)
return 42;
}
I'm quite puzzled by your angle which seems to be that if the
reachability diagnostic cannot be done accurately, due to theory,
translation units and run-time conditions/inputs, then it's
a bad diagnostic not worth doing (or at least not worth having
right in the language). Pardon me if I'm misconstruing antyhing.
Do you have in mind examples of situations in which false positives
would cause problems, or even just irk the programmer?
Say under some simple rule requiring that that if reaching the end of a
function is conditional on the value of one or more expressions,
they must be constant expressions whose values prevent that.
What would be undesirable about working with that?
Say that mountains of legacy code aren't an issue. (Or that they
are, but what else?)
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-07 02:06 -0700 |
| Message-ID | <3b850d75-ae05-4c31-a3d6-9b0333de84abn@googlegroups.com> |
| In reply to | #174280 |
On Thursday, 7 September 2023 at 07:10:49 UTC+1, Kaz Kylheku wrote:
>
> I'm quite puzzled by your angle which seems to be that if the
> reachability diagnostic cannot be done accurately, due to theory,
> translation units and run-time conditions/inputs, then it's
> a bad diagnostic not worth doing (or at least not worth having
> right in the language). Pardon me if I'm misconstruing antyhing.
>
Take this one.
int gamemainloop(void)
{
if (allocatememorybuffers() == -1)
return -1; // out of memory;
if (hardwaretest() == FAIL)
return -2; // proper hardware not installed
loopforever(); // update / render loop, never returns
}
Obviously to prove that loopforever loops forever we need to examine it.
And even if we could, its the halting problem - most real programs written
by humans can be trivially proven to either halt or run forever, but it's hard
to write that requirement into a programming language.
>
> Do you have in mind examples of situations in which false positives
> would cause problems, or even just irk the programmer?
>
We could put a return 0 at the bottom of the fucntion, but that would falsely
imply that in some circumstances it returns 0.
>
> Say under some simple rule requiring that that if reaching the end of a
> function is conditional on the value of one or more expressions,
> they must be constant expressions whose values prevent that.
>
> What would be undesirable about working with that?
>
> Say that mountains of legacy code aren't an issue. (Or that they
> are, but what else?)
>
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-07 15:52 +0000 |
| Message-ID | <20230907082050.403@kylheku.com> |
| In reply to | #174299 |
On 2023-09-07, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On Thursday, 7 September 2023 at 07:10:49 UTC+1, Kaz Kylheku wrote:
>>
>> I'm quite puzzled by your angle which seems to be that if the
>> reachability diagnostic cannot be done accurately, due to theory,
>> translation units and run-time conditions/inputs, then it's
>> a bad diagnostic not worth doing (or at least not worth having
>> right in the language). Pardon me if I'm misconstruing antyhing.
>>
> Take this one.
>
> int gamemainloop(void)
> {
> if (allocatememorybuffers() == -1)
> return -1; // out of memory;
> if (hardwaretest() == FAIL)
> return -2; // proper hardware not installed
> loopforever(); // update / render loop, never returns
> }
>
> Obviously to prove that loopforever loops forever we need to examine it.
Unless there is a good reason for the int return type, it should be
changed to void.
If it doesn't return, it deosn't return int; it returns nothing.
> And even if we could, its the halting problem - most real programs written
> by humans can be trivially proven to either halt or run forever, but it's hard
> to write that requirement into a programming language.
It's not merely hard; it's unwise to even contemplate. Equally unwise
to be deterred from making useful requirements.
>> Do you have in mind examples of situations in which false positives
>> would cause problems, or even just irk the programmer?
>>
> We could put a return 0 at the bottom of the fucntion, but that would falsely
> imply that in some circumstances it returns 0.
That goes hand-in-hand with its declaration, which falsely implies that
the function returns int, do do which it has to return.
If we believe that loopforever() doesn't return, and we cannot change
the return type for whatever reason, we could put an abort() call at the
end of the function.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-07 14:18 -0700 |
| Message-ID | <87cyyt3co1.fsf@nosuchdomain.example.com> |
| In reply to | #174299 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Thursday, 7 September 2023 at 07:10:49 UTC+1, Kaz Kylheku wrote:
>> I'm quite puzzled by your angle which seems to be that if the
>> reachability diagnostic cannot be done accurately, due to theory,
>> translation units and run-time conditions/inputs, then it's
>> a bad diagnostic not worth doing (or at least not worth having
>> right in the language). Pardon me if I'm misconstruing antyhing.
>>
> Take this one.
>
> int gamemainloop(void)
> {
> if (allocatememorybuffers() == -1)
> return -1; // out of memory;
> if (hardwaretest() == FAIL)
> return -2; // proper hardware not installed
> loopforever(); // update / render loop, never returns
> }
>
> Obviously to prove that loopforever loops forever we need to examine it.
No, just declare it as:
_Noreturn void loopforever(void);
in C11 and later, or
[[noreturn]] void loopforever(void);
in C23.
Currently the only effect of _Noreturn is that the behavior is undefined
if the function returns, but if a future C added rules to require return
statements in non-void functions, noreturn functions could easily be
part of the analysis.
> And even if we could, its the halting problem - most real programs
> written by humans can be trivially proven to either halt or run
> forever, but it's hard to write that requirement into a programming
> language.
Nobody is suggesting that a C compiler must include a general halt
decider.
C#, in my opinion, has a reasonable set of rules for this.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-07 15:28 +0100 |
| Message-ID | <874jk6oy5b.fsf@bsb.me.uk> |
| In reply to | #174280 |
Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-09-07, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>> [...]
>>
>>>> Compilers will still accept functions which return
>>>> garbage values. Presumably for backwards compatibility,
>>>
>>> I suspect it's also because detecting the cases that are actual
>>> errors is hard [...]
>>
>> Besides being theoretically impossible, it's not practical
>> because of C allowing separate compilation. To get an answer
>> (potentially) requires examining the entire program.
>
> But why would that even be a goal?
>
> If you need to know what a function in another translation unit
> does in order to know whether or not the function "falls off the end",
> that's a code smell.
Really? If I have
int do_lots_of_stuff(...) {
if (this) ...
else if (that) ...
else if (the other) ...
abort_with_error_message("Don't know what to do.");
}
that's smelly code? Of course, if C23 happens as planned I am permitted
to declare
[[noreturn]] void abort_with_error_message(const char *);
but I don't have to (and I'd have to hide that attribute for compilers
that are catching up).
> Do you have in mind examples of situations in which false positives
> would cause problems, or even just irk the programmer?
Well I'd be irked by having to write a 'return 0;' there just to shut
the compiler up. But, to be clear, it's a tiny irk.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-07 16:54 +0200 |
| Message-ID | <udco6l$317pk$1@dont-email.me> |
| In reply to | #174325 |
On 07/09/2023 16:28, Ben Bacarisse wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>> On 2023-09-07, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>> [...]
>>>
>>>>> Compilers will still accept functions which return
>>>>> garbage values. Presumably for backwards compatibility,
>>>>
>>>> I suspect it's also because detecting the cases that are actual
>>>> errors is hard [...]
>>>
>>> Besides being theoretically impossible, it's not practical
>>> because of C allowing separate compilation. To get an answer
>>> (potentially) requires examining the entire program.
>>
>> But why would that even be a goal?
>>
>> If you need to know what a function in another translation unit
>> does in order to know whether or not the function "falls off the end",
>> that's a code smell.
>
> Really? If I have
>
> int do_lots_of_stuff(...) {
> if (this) ...
> else if (that) ...
> else if (the other) ...
> abort_with_error_message("Don't know what to do.");
> }
>
> that's smelly code?
I will often write something like :
// "opt" must be 1, 2, or 3
int do_stuff(int opt) {
switch (opt) {
case 1 : return do_stuff_1();
case 2 : return do_stuff_2();
case 3 : return do_stuff_3();
}
__builtin_unreachable();
}
I think the "__builtin_unreachable();" is a good indication to both the
compiler and the reader that this line is never reached. Of course,
this is a gcc/clang extension, but in real code you can have a macro
that is adapted to suit the compiler. (Other compilers have their own
alternative, and "assert(false)" is a reasonable fall-back.)
> Of course, if C23 happens as planned I am permitted
> to declare
>
> [[noreturn]] void abort_with_error_message(const char *);
With C11, you can write :
_Noreturn void abort_with_error_message(const char *);
So you don't have to wait until C23 (unless you really want the
attribute syntax).
>
> but I don't have to (and I'd have to hide that attribute for compilers
> that are catching up).
>
>> Do you have in mind examples of situations in which false positives
>> would cause problems, or even just irk the programmer?
>
> Well I'd be irked by having to write a 'return 0;' there just to shut
> the compiler up. But, to be clear, it's a tiny irk.
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-07 17:02 +0100 |
| Message-ID | <87y1hinf85.fsf@bsb.me.uk> |
| In reply to | #174332 |
David Brown <david.brown@hesbynett.no> writes: > With C11, you can write : > > _Noreturn void abort_with_error_message(const char *); > > So you don't have to wait until C23 (unless you really want the attribute > syntax). I somehow missed that in C11. Thanks. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-07 16:12 +0000 |
| Message-ID | <20230907090814.268@kylheku.com> |
| In reply to | #174360 |
On 2023-09-07, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> With C11, you can write :
>>
>> _Noreturn void abort_with_error_message(const char *);
>>
>> So you don't have to wait until C23 (unless you really want the attribute
>> syntax).
>
> I somehow missed that in C11. Thanks.
By the way I agree with you that the code doesn't smell, since the
abort_with_error_message is like abort.
If we are going to have warnings about reachable function tails,
we need a way to declare that some our functions are abort-like.
And, we have it.
Otherwise we might have to resort to
#define abort_with_error_message(msg) \
do {
fprintf(stderr, "%s\n", msg);
abort();
} while (0)
I'm assuing that whatever rule we are working around is sanely designed
and recognizes abort, longjmp and exit as non-returning.
This approach adds code bloat.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-07 16:17 +0000 |
| Message-ID | <mImKM.1038465$SuUf.716696@fx14.iad> |
| In reply to | #174360 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >David Brown <david.brown@hesbynett.no> writes: > >> With C11, you can write : >> >> _Noreturn void abort_with_error_message(const char *); >> >> So you don't have to wait until C23 (unless you really want the attribute >> syntax). > >I somehow missed that in C11. Thanks. And gcc has supported __attribute((noreturn))__ since gcc 2.5.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-07 17:37 +0100 |
| Message-ID | <87h6o6ndmo.fsf@bsb.me.uk> |
| In reply to | #174366 |
scott@slp53.sl.home (Scott Lurndal) writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>David Brown <david.brown@hesbynett.no> writes: >> >>> With C11, you can write : >>> >>> _Noreturn void abort_with_error_message(const char *); >>> >>> So you don't have to wait until C23 (unless you really want the attribute >>> syntax). >> >>I somehow missed that in C11. Thanks. > > And gcc has supported __attribute((noreturn))__ since gcc 2.5. I knew that! I was limiting myself to C (which I would call ISO C if this were not a largely Bart-driven thread). -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 13 of 18 — ← Prev page 1 … 11 12 [13] 14 15 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web