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 12 of 18 — ← Prev page 1 … 10 11 [12] 13 14 … 18 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-02 19:53 +0100 |
| Message-ID | <ud00bc$grer$1@dont-email.me> |
| In reply to | #173670 |
On 02/09/2023 17:19, David Brown wrote:
> On 02/09/2023 12:57, Bart wrote:
>> However, my example is simple: there are clearly zero return
>> statements; at least one is needed for a value-returning function.
>
> By that definition, this version would be perfectly acceptable to you :
>
> int fred(void) {
> if (1 + 1 != 2) return 0;
> }
I explained elsewhere that such a simple rule would catch at least some
errors. And actually, that program is not acceptable to my compiler:
c:\c>type d.c
int fred(void) {
if (1 + 1 != 2) return 0;
}
c:\c>bcc -c d.c
Compiling d.c to d.obj
In function fred On line 2 in file d.c
** Code Gen Error: Function needs explicit return statement: fred **
c:\c>bcc -c d.c -old
Compiling d.c to d.obj
It suppresses that check when -old is used, to allow existing programs
to be compiled.
> You'd be surprised how often reality is vastly more complicated than
Exactly. Some of us are trying to make it less complicated. And along
the way, end up writing safer, less buggy code too!
What exactly are the consequences of requiring programs to satisfy my
compiler regarding 'return'? Virtually one. But it would then be
impossible to write a function without a proper return value.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-03 06:32 +0000 |
| Message-ID | <20230902232814.635@kylheku.com> |
| In reply to | #173678 |
On 2023-09-02, Bart <bc@freeuk.com> wrote:
> On 02/09/2023 17:19, David Brown wrote:
>> On 02/09/2023 12:57, Bart wrote:
>
>>> However, my example is simple: there are clearly zero return
>>> statements; at least one is needed for a value-returning function.
>>
>> By that definition, this version would be perfectly acceptable to you :
>>
>> int fred(void) {
>> if (1 + 1 != 2) return 0;
>> }
>
> I explained elsewhere that such a simple rule would catch at least some
> errors. And actually, that program is not acceptable to my compiler:
Why would you have this simple rule, when GCC has a decent
implementation of the diagnostic? The only problem is that it's not in
the ISO standard.
Your rule is poor, at times requiring unreachable return statements
to appear, uglyfying code --- and also is not in any ISO standard.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-03 16:02 +0200 |
| Message-ID | <ud23ls$um2u$1@dont-email.me> |
| In reply to | #173678 |
On 02/09/2023 20:53, Bart wrote:
> On 02/09/2023 17:19, David Brown wrote:
>> On 02/09/2023 12:57, Bart wrote:
>
>>> However, my example is simple: there are clearly zero return
>>> statements; at least one is needed for a value-returning function.
>>
>> By that definition, this version would be perfectly acceptable to you :
>>
>> int fred(void) {
>> if (1 + 1 != 2) return 0;
>> }
>
> I explained elsewhere that such a simple rule would catch at least some
> errors. And actually, that program is not acceptable to my compiler:
>
> c:\c>type d.c
> int fred(void) {
> if (1 + 1 != 2) return 0;
> }
>
> c:\c>bcc -c d.c
> Compiling d.c to d.obj
> In function fred On line 2 in file d.c
> ** Code Gen Error: Function needs explicit return statement: fred **
>
> c:\c>bcc -c d.c -old
> Compiling d.c to d.obj
So it turns out that simple rules are not sufficient after all.
>
> It suppresses that check when -old is used, to allow existing programs
> to be compiled.
I think that's a good idea. My personal preference would be for gcc to
be far stricter by default (at least roughly equivalent to "gcc -Wall
-O2"). I know that is not going to happen, and I understand why it is
not going to happen, but I still think it's a shame.
(I did file a bug that lead to "-fno-common" being the default, so
there's some progress.)
>
>
>> You'd be surprised how often reality is vastly more complicated than
>
> Exactly. Some of us are trying to make it less complicated.
You can only make it less complicated by limiting the scope - such as
having a small language that is only ever implemented and used by one
person. Then it's a lot easier to keep things small and simple. It
does not scale, however.
> And along
> the way, end up writing safer, less buggy code too!
>
We have absolutely no evidence for that whatsoever. If you had learned
C decades ago, and wrote code C rather than your own personal little
languages, there is no reason to believe you would not have written safe
and bug-free C code. There is nothing inherently unsafe about C coding
- lots of us write safe C code with minimal risk of bugs. C does have
significant scope for writing bad code too, but that does not mean you
can't write good code in the language.
> What exactly are the consequences of requiring programs to satisfy my
> compiler regarding 'return'? Virtually one. But it would then be
> impossible to write a function without a proper return value.
>
You live in such a small bubble! Don't you ever feel the need to look
outside, or at least /think/ a bit about the rest of the world?
Even such a seemingly trivial and obvious change would be an enormous
cost and effort. Making changes to internation standards is a long
process. Changing the thousands of C compilers to support it is a
massive effort. Checking the millions of existing C programs with their
billions of lines of code is even more.
In comparison, having warnings on mainstream compilers that check this
is peanuts (most decent compilers have done so forever). Developers who
know how to do good software development, learn and understand how to
use available tools to the best effect - such as enabling appropriate
warnings and other flags. Developers who don't understand good
engineering practice will make a mess of things anyway.
I agree with you that C would be better if it had been stricter - and
modern languages tend to be much better in such areas. But you are
wrong to think C could easily be changed here.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-03 18:11 +0100 |
| Message-ID | <ud2eod$10jv5$1@dont-email.me> |
| In reply to | #173775 |
On 03/09/2023 15:02, David Brown wrote:
> On 02/09/2023 20:53, Bart wrote:
>> What exactly are the consequences of requiring programs to satisfy my
>> compiler regarding 'return'? Virtually one. But it would then be
>> impossible to write a function without a proper return value.
>>
>
> You live in such a small bubble! Don't you ever feel the need to look
> outside, or at least /think/ a bit about the rest of the world?
What's wrong with that?
This discussion about minor points of design in C is interesting, but to
me academic. This particular issue is:
* A reluctance to write 'return x;' in a value-returning function
* A desire for a compiler to turn a blind eye to that end, despite
omitting such a return being bad news for 99% of functions
* So leaving it pretty much a choice for the user whether they write it,
and whether a compiler reports it.
All stuff I consider sloppy, lax, and irresponsible.
My language deals with this in other ways:
* I can simply omit 'return' and just have the value
* That also allows me to have a function myexit() which returns a
suitable value, so nothing (no dummy 'return x' or even 'x') is needed
* I can choose to use 'stop n' to terminate. Here the compiler knows
control can't proceed past this statement, and can suppress the
error, or cause 'stop' to yield the value needed. (I haven't done
this, but could.)
So I can do both things at once: have a stricter, safer language, and
not have to write a full 'return x' that I know will not be executed
(although I'm not that bothered by it).
Now let's turn things around: can I write, in my language, a
value-returning function that returns without a value (that is, whatever
happens to be left over in a register)?
In C:
void* fred(void) {
(long long int)rand()*3.14159;
}
int main(void) {
printf("%p\n", fred());
printf("%p\n", fred());
}
The output varies considerably between 'bcc -old' and tcc/gcc. It is UB.
So in C is it really not very hard, actually surprisingly easy; too
easy: not a peep from the compiler invoked in what is likely the most
common way.
But in my language I can't it:
func fred:ref void =
int(rand()*pi)
end
proc main=
println fred()
println fred()
end
(Type conversion error.) No doubt you will argue C is superior here.
Sure, then ASM is even more superior!
Anyway, my view is that it is you who live in more of a bubble, even if
a very large and complex one! I at least can look outside C at my
languages which are of the same rank, and compare how they approach
common problems.
I acknowledge that it is easy for me to try new things, but that itself
allows me to say whether they are better than how C does it, or worse.
(Usually the former! The others don't last long.)
You can't that because there is nothing to compare with except languages
at a very different level.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-03 11:31 -0700 |
| Message-ID | <86msy3qfbv.fsf@linuxsc.com> |
| In reply to | #173800 |
Bart <bc@freeuk.com> writes: > On 03/09/2023 15:02, David Brown wrote: > >> On 02/09/2023 20:53, Bart wrote: >> >>> What exactly are the consequences of requiring programs to satisfy >>> my compiler regarding 'return'? Virtually one. But it would then be >>> impossible to write a function without a proper return value. >> >> You live in such a small bubble! Don't you ever feel the need to >> look outside, or at least /think/ a bit about the rest of the world? > > What's wrong with that? Nothing wrong with living in a bubble. What's wrong is acting like what people inside the bubble (ie, you) want is the same as what people outside the bubble want. Stop acting that way and people will stop complaining. Duh!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-03 20:07 +0100 |
| Message-ID | <87a5u3vzwj.fsf@bsb.me.uk> |
| In reply to | #173800 |
Bart <bc@freeuk.com> writes:
> This discussion about minor points of design in C is interesting, but to me
> academic. This particular issue is:
>
> * A reluctance to write 'return x;' in a value-returning function
I don't remember anyone being reluctant to do that. I was reluctant to
do that in a function that was /not/ value returning (despite it having
a non-void return type), but even then it was a very specific case. I
have no reluctance to return a value from a function that should return
one and I will write, with no reluctance at all, an unneeded 'return x;'
to silence a warning when the situation comes up.
> * A desire for a compiler to turn a blind eye to that end, despite omitting
> such a return being bad news for 99% of functions
And no one has expressed that desire as far as I can recall. Everyone
is (so far as I recall) very happy to see the diagnostics about it.
Even you will be happy to see them when you start asking for them.
> * So leaving it pretty much a choice for the user whether they write it,
> and whether a compiler reports it.
That choice is indeed there. It's simply a fact. But no one here,
including you, seems prepared to do anything to change that fact. (I am
not including whinging about it in this tiny corner of the Internet as
"doing something about it". YMMV.)
> In C:
>
> void* fred(void) {
> (long long int)rand()*3.14159;
> }
>
> int main(void) {
> printf("%p\n", fred());
> printf("%p\n", fred());
> }
>
> The output varies considerably between 'bcc -old' and tcc/gcc. It is UB.
>
> So in C is it really not very hard, actually surprisingly easy; too easy:
> not a peep from the compiler invoked in what is likely the most common
> way.
I get at least three diagnostics about that program from gcc, but I
suspect you didn't post the actual program. But I get your point. It
is, as always, simply that you don't like gcc's defaults.
Since the gist of almost every complaint from you is that you don't want
to ask for diagnostics from gcc, it's worth saying why that is not such
a bad choice for the default. Running
gcc -o prog *.c
(or make!) is the sort of thing you do when you've got some code and
want to try it out. You are not a "developer" of the code, you just
want to run it. Any messages about the code are of no interest to you.
That situation calls for a lax approach to diagnostics, hence the
default.
No developer ever does that (unless they are not wearing their developer
hat at the time). They will at least run
gcc -Wall -o prog *.c
Can you promise that, from today, you won't complain about what gcc says
about some code unless you have at least asked for -Wall? There will
still be lots for you to moan about because that's only "warnings about
constructions that some users consider questionable, and that are easy
to avoid".
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-03 22:08 +0100 |
| Message-ID | <ud2skl$12t43$1@dont-email.me> |
| In reply to | #173813 |
On 03/09/2023 20:07, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> In C:
>>
>> void* fred(void) {
>> (long long int)rand()*3.14159;
>> }
>>
>> int main(void) {
>> printf("%p\n", fred());
>> printf("%p\n", fred());
>> }
>>
>> The output varies considerably between 'bcc -old' and tcc/gcc. It is UB.
>>
>> So in C is it really not very hard, actually surprisingly easy; too easy:
>> not a peep from the compiler invoked in what is likely the most common
>> way.
>
> I get at least three diagnostics about that program from gcc, but I
> suspect you didn't post the actual program.
The program is shown below. The version posted was pasted from that, but
before I added the cast, which I added manually above.
--------------------------------
c:\c>type c.c
#include <stdio.h>
#include <stdlib.h>
void* fred(void) {
(long long int)rand()*3.14159;
}
int main(void) {
printf("%p\n", fred());
printf("%p\n", fred());
}
c:\c>gcc c.c
c:\c>a
0000000000000029
0000000000004823
c:\c>tcc c.c
c:\c>c
0000000000000029
0000000000004823
c:\c>bcc c.c -old
Compiling c.c to c.exe
c:\c>c
406019C41DD1A21E
40EC53F7C2CE4649
(Switching to WSL on the same folder:)
root@DESKTOP-11:/mnt/c/c# gcc c.c
root@DESKTOP-11:/mnt/c/c# ./a.out
0x6b8b4567
0x327b23c6
--------------------------------
If I use gcc -Wall (not -Wpedantic), I get a warning, but I still manage
to get an executable that I can run with potentially undesirable behaviour.
> But I get your point. It
> is, as always, simply that you don't like gcc's defaults.
As always, it always seems like I have to twist its arm to get it to do
its job. It's more complicated than simply using -Wall, since that gives
me warnings about things that are less serious, like unused labels.
> Since the gist of almost every complaint from you is that you don't want
> to ask for diagnostics from gcc, it's worth saying why that is not such
> a bad choice for the default. Running
>
> gcc -o prog *.c
>
> (or make!) is the sort of thing you do when you've got some code and
> want to try it out. You are not a "developer" of the code, you just
> want to run it. Any messages about the code are of no interest to you.
> That situation calls for a lax approach to diagnostics, hence the
> default.
This is open source situation that I have described, normally on a
working program. The problem is usually getting the information about
which files to submit as the /developer's/ build process is not suited.
> No developer ever does that (unless they are not wearing their developer
> hat at the time). They will at least run
>
> gcc -Wall -o prog *.c
>
> Can you promise that, from today, you won't complain about what gcc says
> about some code unless you have at least asked for -Wall? There will
> still be lots for you to moan about because that's only "warnings about
> constructions that some users consider questionable, and that are easy
> to avoid".
Let's take a slightly different version of my program, as before I
wanted to avoid a crash:
----------------------------
#include <stdio.h>
#include <stdlib.h>
char* fred(void) {
(long long int)rand()*3.14159;
}
int main(void) {
printf("%s\n", fred());
}
----------------------------
If I blindly do this, perhaps in a script:
c:\c>bcc c && c
Compiling c.c to c.exe
In function fred On line 5 in file c.c
**** ... Error: Function needs explicit return statement: fred ****
it won't let me run the program. If try it with gcc:
----------------------------
c:\c>gcc c.c -Wall && a
c.c: In function 'fred':
c.c:5:26: warning: value computed is not used [-Wunused-value]
5 | (long long int)rand()*3.14159;
| ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
c.c:6:1: warning: control reaches end of non-void function [-Wreturn-type]
6 | }
| ^
----------------------------
it crashes. You can't see it here, but there's a small delay and a busy
cursor. So I'll try it on WSL:
----------------------------
root@DESKTOP-11:/mnt/c/c# gcc c.c -Wall && ./a.out
c.c: In function ‘fred’:
c.c:5:26: warning: value computed is not used [-Wunused-value]
5 | (long long int)rand()*3.14159;
| ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
c.c:6:1: warning: control reaches end of non-void function [-Wreturn-type]
6 | }
| ^
Segmentation fault
----------------------------
So it's a little bit elaborate than just -Wall. Here is where I disagree
that I should go that rabbit-hole of myriad combinations of options in
order to get a supposed C compiler to do what I expect: detect obviously
wrong things in a program (NOT unused labels), and stop me running those.
I don't expect it to detect logic errors or prove my program is correct
or not. What I'm asking is quite possible in a simple compiler.
Do you know what the most common thing encountered with BCC is that
requires the -old option?
It is using a () parameter list for declarations rather than (void). ()
means the numbers and types of arguments to a function are completely
unchecked. Sounds really safe!
Mostly likely people wrongly assume that () means zero parameters. And
the reason for that is because a () parameter list is legal C; it just
doesn't mean what people think it means.
I decided that was too dangerous to allow by default. Now of course C23
decides it should means zero parameters too! This was why I said it was
going backwards.
Obviously what I'm after in a C compiler must be impossible:
* Compile code without needing any extra options most of the time
* (Ideally, not have to write .c on file names, but I can pass)
* Detect clearly wrong things and refuse to create an executable
that could have dangerously unsafe code.
* Make it obvious at the end (maybe I was out of the room when it
was working, and there was a lot of output) whether it passed or
failed.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-04 03:16 +0100 |
| Message-ID | <87sf7uvg1u.fsf@bsb.me.uk> |
| In reply to | #173816 |
Bart <bc@freeuk.com> writes:
> On 03/09/2023 20:07, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> In C:
>>>
>>> void* fred(void) {
>>> (long long int)rand()*3.14159;
>>> }
>>>
>>> int main(void) {
>>> printf("%p\n", fred());
>>> printf("%p\n", fred());
>>> }
>>>
>>> The output varies considerably between 'bcc -old' and tcc/gcc. It is UB.
>>>
>>> So in C is it really not very hard, actually surprisingly easy; too easy:
>>> not a peep from the compiler invoked in what is likely the most common
>>> way.
>> I get at least three diagnostics about that program from gcc, but I
>> suspect you didn't post the actual program.
>
> The program is shown below.
Yes, I know what you intended to post.
> If I use gcc -Wall (not -Wpedantic), I get a warning, but I still manage to
> get an executable that I can run with potentially undesirable
> behaviour.
Some people advise compiling with -Werror. I advice you to either set
specific ones (-Werror=xyz) or set them all and down-grade those you
don't care so much about (-Werror -Wno-error=xyz).
>> But I get your point. It
>> is, as always, simply that you don't like gcc's defaults.
>
> As always, it always seems like I have to twist its arm to get it to do its
> job. It's more complicated than simply using -Wall, since that gives me
> warnings about things that are less serious, like unused labels.
How often will go round this same loop? You don't like gcc's defaults.
I know that, you know that. You also know how to change them. By this
stage, if you wanted to use gcc, you could have set it up to match,
pretty closely, your requirements. If you don't want to use gcc, don't
use it and stop complaining about its defaults.
You can't make the world a better place by moaning. You can help by
replying to posts by beginners, helping them to understand the pitfalls
of C and telling them how to get more help from compilers like gcc. You
could even try to persuade them to use an alternative language, but
moaning won't do anything.
>> Since the gist of almost every complaint from you is that you don't want
>> to ask for diagnostics from gcc, it's worth saying why that is not such
>> a bad choice for the default. Running
>> gcc -o prog *.c
>> (or make!) is the sort of thing you do when you've got some code and
>> want to try it out. You are not a "developer" of the code, you just
>> want to run it. Any messages about the code are of no interest to you.
>> That situation calls for a lax approach to diagnostics, hence the
>> default.
>
> This is open source situation that I have described, normally on a working
> program. The problem is usually getting the information about which files
> to submit as the /developer's/ build process is not suited.
Yes, your second most common moan is that developers have not ported
their build system to your preferred OS, but you won't help by setting
something up for them for even a single program (not all of them, just
on you care about!). (You have falsely claimed that when I suggest this
I'm asking you to work on every program out there.)
>> No developer ever does that (unless they are not wearing their developer
>> hat at the time). They will at least run
>> gcc -Wall -o prog *.c
>> Can you promise that, from today, you won't complain about what gcc says
>> about some code unless you have at least asked for -Wall?
No answer I see.
>> There will
>> still be lots for you to moan about because that's only "warnings about
>> constructions that some users consider questionable, and that are easy
>> to avoid".
>
> Let's take a slightly different version of my program, as before I wanted
> to avoid a crash:
I see no point, since you present nothing new. You don't like gcc's
defaults (in this extended moan, you don't like that an executable is
still built after a warning). Set gcc up to be what you want or stop
complaining about it.
> Here is where I disagree
> that I should go that rabbit-hole of myriad combinations of options in
> order to get a supposed C compiler to do what I expect: detect obviously
> wrong things in a program (NOT unused labels), and stop me running
> those.
Don't use gcc then. You are missing out on a very useful tool, though,
as it can also detect run-time issues with options like
-fsanitize=undefined. I would have given my right arm for a tool like
gcc when I was a working C programmer back in the last century.
> Obviously what I'm after in a C compiler must be impossible:
>
> * Compile code without needing any extra options most of the time
To be frank, that's just a silly thing to say. If I write (in my bash
set-up)
function bencc {
gcc -std=c99 -pedantic -Wall -Werror "$@"
}
then I have new C compiler called bencc that does a different job than
the gcc command.
You should have done this years ago and refined the options (probably
via a file) as you found things that you prefer to be done this way or
that way. It's trivial. Do it now.
> * (Ideally, not have to write .c on file names, but I can pass)
>
> * Detect clearly wrong things and refuse to create an executable
> that could have dangerously unsafe code.
Use bencc.
> * Make it obvious at the end (maybe I was out of the room when it
> was working, and there was a lot of output) whether it passed or
> failed.
function cc { bencc "$@" && echo OK || echo FAILED; }
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-04 10:54 +0200 |
| Message-ID | <ud4604$1cbam$1@dont-email.me> |
| In reply to | #173800 |
On 03/09/2023 19:11, Bart wrote: > On 03/09/2023 15:02, David Brown wrote: >> On 02/09/2023 20:53, Bart wrote: > >>> What exactly are the consequences of requiring programs to satisfy my >>> compiler regarding 'return'? Virtually one. But it would then be >>> impossible to write a function without a proper return value. >>> >> >> You live in such a small bubble! Don't you ever feel the need to look >> outside, or at least /think/ a bit about the rest of the world? > > > What's wrong with that? If you can live inside a bubble, and be happy with that, then I suppose that's fine. However, you don't have the experience or understanding to criticise those outside the bubble. You can live in your blissful ignorance if that's what suits you - but please understand that others do not want to be in your bubble. It does not appeal at all to me. Your bubble tools and languages are of little use or interest to all but a very few other people. > > Anyway, my view is that it is you who live in more of a bubble, even if > a very large and complex one! I at least can look outside C at my > languages which are of the same rank, and compare how they approach > common problems. I think you'll find that most people here - and certainly all of the regulars - have a lot of experience with a variety of programming languages. Probably a fair fraction do not use C much in their regular programming. We focus on C here, because it is a C discussion group. Do not imagine for a moment that you are special because you have another language to compare to C. > I acknowledge that it is easy for me to try new things, but that itself > allows me to say whether they are better than how C does it, or worse. > (Usually the former! The others don't last long.) No, it does not allow you to say anything of the sort - except within the very limited and niche confines of your little bubble. You have no concept of how your ideas might work or fail to work in the real world - you've demonstrated that repeatedly here. You have no inkling about what other people want or need, or how they could apply to other people's projects. This is because you directly avoid anything outside your bubble, refuse to listen to anything people tell you, and you will not make any attempt to learn or understand. Nothing gets through your walls of smugness, self-satisfaction, and irrational hatred. That does not mean you don't have good ideas, or that your programming languages don't have their good points - far from it, there are some nice things there. They are not as unique or innovative as you believe, and certainly not as universally good, but can be good things for at least some people and some uses. > > You can't that because there is nothing to compare with except languages > at a very different level. > What an odd and ignorant thing to say.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-04 11:06 +0100 |
| Message-ID | <ud4a6a$1d4cd$1@dont-email.me> |
| In reply to | #173866 |
On 04/09/2023 09:54, David Brown wrote:
> On 03/09/2023 19:11, Bart wrote:
>> What's wrong with that?
>
> If you can live inside a bubble, and be happy with that, then I suppose
> that's fine. However, you don't have the experience or understanding to
> criticise those outside the bubble. You can live in your blissful
> ignorance if that's what suits you - but please understand that others
> do not want to be in your bubble. It does not appeal at all to me. Your
> bubble tools and languages are of little use or interest to all but a
> very few other people.
That may be so. But you can still learn things from them. A good idea is
a good idea.
>
>
> We focus on C here, because it is a C discussion group.
The thread has been largely about how compilers work. That surely can be
compared with how compilers for like languages work. Or even how my
compiler for C works.
> Do
> not imagine for a moment that you are special because you have another
> language to compare to C.
Why not? How many here:
* Have used a viable alternative to C for most of their careers?
(I don't mean C++!)
* How many have /designed and implemented/ that alternative?
* How many here have written compilers? That includes a 'full stack'
implementation
* How many here have tried implementing a C compiler?
You don't think that can give someone a rather special perspective?
You can tell any other upstart, This is what a C compiler is and how it
is supposed to work. But not when that upstart says, No, a C compiler
can also look and behave like /this/, because I've done it.
>> I acknowledge that it is easy for me to try new things, but that
>> itself allows me to say whether they are better than how C does it, or
>> worse. (Usually the former! The others don't last long.)
>
> No, it does not allow you to say anything of the sort - except within
> the very limited and niche confines of your little bubble. You have no
> concept of how your ideas might work or fail to work in the real world -
> you've demonstrated that repeatedly here.
The real world consisting of half a century's accumulation of cruft in
the C language, compilers, options, libraries, makefiles and assorted
other tools?
I fully agree.
Of course, you can /change/ that in the real world if somebody put their
mind to it. But nobody will. Most people's contribution in that area is
to add to the cruft: 51 year's accummulatation instead of 50!
> You have no inkling about
> what other people want or need, or how they could apply to other
> people's projects. This is because you directly avoid anything outside
> your bubble, refuse to listen to anything people tell you, and you will
> not make any attempt to learn or understand. Nothing gets through your
> walls of smugness, self-satisfaction, and irrational hatred.
>
> That does not mean you don't have good ideas, or that your programming
> languages don't have their good points - far from it, there are some
> nice things there. They are not as unique or innovative as you believe,
> and certainly not as universally good, but can be good things for at
> least some people and some uses.
And yet, I can't get this program to compile when expressed in my langage:
char* fred(void) {
(long long int)rand()*3.14159;
}
int main(void) {
printf("%s\n", fred());
}
I can very easily do so in C, /and/ I can run it.
And not by providing extra options to override compiler's choices; you
don't have to provide /any/ options!
I don't really need to say anything else.
>
>>
>> You can't that because there is nothing to compare with except
>> languages at a very different level.
>>
> What an odd and ignorant thing to say.
Why is it odd? You can't compare the handling of a feature between C and
Python, or C and Haskell, because they are too different. You /can/
compare between C and my language, because even you said (in
comp.lang.misc) that they were more or less the same language. Just very
different implementations.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-04 14:54 +0100 |
| Message-ID | <87edjeujqw.fsf@bsb.me.uk> |
| In reply to | #173874 |
Bart <bc@freeuk.com> writes:
> On 04/09/2023 09:54, David Brown wrote:
>> On 03/09/2023 19:11, Bart wrote:
>
>>> What's wrong with that?
>> If you can live inside a bubble, and be happy with that, then I suppose
>> that's fine. However, you don't have the experience or understanding to
>> criticise those outside the bubble. You can live in your blissful
>> ignorance if that's what suits you - but please understand that others do
>> not want to be in your bubble. It does not appeal at all to me. Your
>> bubble tools and languages are of little use or interest to all but a
>> very few other people.
>
> That may be so. But you can still learn things from them.
I think I've asked before, but is there a language reference manual?
> And yet, I can't get this program to compile when expressed in my langage:
>
> char* fred(void) {
> (long long int)rand()*3.14159;
> }
>
> int main(void) {
> printf("%s\n", fred());
> }
C (as currently defined) has nothing to say about the behaviour of this
program. That makes it trivial to implement an "equivalent" in almost
any language. If your view of equivalent is the inclusive one, then any
program at all will match the behaviour permitted for this one. And if
your view of equivalent is quite narrow, then any text that has no
defined meaning in the other language will do instead.
I post this only to explain how I interpret the notion of "expressing" a
program in another language. I am sure your view of the term is quite
different.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-04 22:02 +0100 |
| Message-ID | <ud5gkt$1kj5t$1@dont-email.me> |
| In reply to | #173883 |
On 04/09/2023 14:54, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 04/09/2023 09:54, David Brown wrote:
>>> On 03/09/2023 19:11, Bart wrote:
>>
>>>> What's wrong with that?
>>> If you can live inside a bubble, and be happy with that, then I suppose
>>> that's fine. However, you don't have the experience or understanding to
>>> criticise those outside the bubble. You can live in your blissful
>>> ignorance if that's what suits you - but please understand that others do
>>> not want to be in your bubble. It does not appeal at all to me. Your
>>> bubble tools and languages are of little use or interest to all but a
>>> very few other people.
>>
>> That may be so. But you can still learn things from them.
>
> I think I've asked before, but is there a language reference manual?
No.
In my case it's not worth doing. There was something a few years ago,
but it's out of date, is too long and needs a rewrite. Since the
expected audience is zero, it is not a priority.
The language is also volatile; it adapts to new hardware, and contains
many experimental features. If it was going to be used by others, it
would need to be more stable first.
However, the language has been self-hosted through various versions and
implementations in a continuous chain going back to the mid-eighties.
The first compiler of the chain would have been written in assembly.
So again, no; I'm keeping my languages private as support, even just
docs, is not viable. But people are welcome to benefit from any features
that come up in forums like these.
>> And yet, I can't get this program to compile when expressed in my langage:
>>
>> char* fred(void) {
>> (long long int)rand()*3.14159;
>> }
>>
>> int main(void) {
>> printf("%s\n", fred());
>> }
>
> C (as currently defined) has nothing to say about the behaviour of this
> program. That makes it trivial to implement an "equivalent" in almost
> any language. If your view of equivalent is the inclusive one, then any
> program at all will match the behaviour permitted for this one. And if
> your view of equivalent is quite narrow, then any text that has no
> defined meaning in the other language will do instead.
The equivalent program in my language is this:
func fred:ref char =
int(rand()*pi)
end
proc main=
println fred()
end
The language uses the value of the last statement or expression as the
return value in a function.
The error here is not a missing return (it is implicit), it is that the
value has the wrong type: int rather than 'ref char'.
This version:
func fred:ref char =
do end # (endless loop)
end
Shows the error "Void expression or return value missing". (A loop
statement has a 'void' type.)
To emulate the behaviour of the C, this used to do the trick, but the
current code generator has an issue with it that I need to fix:
func fred:ref char =
int(rand()*pi)
asm nop
end
(Inline assembly blocks are assumed to have set up a suitable value of
the right type.) However I'd only use assembly as a last resort,
preferably in an isolated module.
> I post this only to explain how I interpret the notion of "expressing" a
> program in another language. I am sure your view of the term is quite
> different.
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?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-05 01:31 +0100 |
| Message-ID | <87tts9sbo8.fsf@bsb.me.uk> |
| In reply to | #173908 |
Bart <bc@freeuk.com> writes:
> On 04/09/2023 14:54, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 04/09/2023 09:54, David Brown wrote:
>>>> On 03/09/2023 19:11, Bart wrote:
>>>
>>>>> What's wrong with that?
>>>> If you can live inside a bubble, and be happy with that, then I suppose
>>>> that's fine. However, you don't have the experience or understanding to
>>>> criticise those outside the bubble. You can live in your blissful
>>>> ignorance if that's what suits you - but please understand that others do
>>>> not want to be in your bubble. It does not appeal at all to me. Your
>>>> bubble tools and languages are of little use or interest to all but a
>>>> very few other people.
>>>
>>> That may be so. But you can still learn things from them.
>> I think I've asked before, but is there a language reference manual?
>
> No.
Then no significant learning can happen.
>>> And yet, I can't get this program to compile when expressed in my langage:
>>>
>>> char* fred(void) {
>>> (long long int)rand()*3.14159;
>>> }
>>>
>>> int main(void) {
>>> printf("%s\n", fred());
>>> }
>> C (as currently defined) has nothing to say about the behaviour of this
>> program. That makes it trivial to implement an "equivalent" in almost
>> any language. If your view of equivalent is the inclusive one, then any
>> program at all will match the behaviour permitted for this one. And if
>> your view of equivalent is quite narrow, then any text that has no
>> defined meaning in the other language will do instead.
>
> The equivalent program in my language is this:
As I said. It's trivial since the C program has no defined meaning.
>> I post this only to explain how I interpret the notion of "expressing" a
>> program in another language. I am sure your view of the term is quite
>> different.
>
> 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.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-05 02:24 +0100 |
| Message-ID | <ud6016$1mhka$1@dont-email.me> |
| In reply to | #173920 |
On 05/09/2023 01:31, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 04/09/2023 14:54, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 04/09/2023 09:54, David Brown wrote:
>>>>> On 03/09/2023 19:11, Bart wrote:
>>>>
>>>>>> What's wrong with that?
>>>>> If you can live inside a bubble, and be happy with that, then I suppose
>>>>> that's fine. However, you don't have the experience or understanding to
>>>>> criticise those outside the bubble. You can live in your blissful
>>>>> ignorance if that's what suits you - but please understand that others do
>>>>> not want to be in your bubble. It does not appeal at all to me. Your
>>>>> bubble tools and languages are of little use or interest to all but a
>>>>> very few other people.
>>>>
>>>> That may be so. But you can still learn things from them.
>>> I think I've asked before, but is there a language reference manual?
>>
>> No.
>
> Then no significant learning can happen.
It's not going to happen anyway. I'm not going to spend a month slaving
over a document just so you can say:
<snip>
I've posted enough examples over the years for you to have a good idea
of what my language looks like and how it is used. Example:
c:\cx>ms cc -run hello
Compiling hello.c to hello.exe
Hello, World!
This builds my C compiler from source, runs it in-memory and uses it to
compile hello.c and then run that executable.
Learn something about creating lean, genuinely simple, effortless build
systems.
> As I said. It's trivial since the C program has no defined meaning.
>
>>> I post this only to explain how I interpret the notion of "expressing" a
>>> program in another language. I am sure your view of the term is quite
>>> different.
>>
>> 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.
>
This is just wordplay isn't it?
I posted examples of something that looked like C code, and of running
programs that people often use to compile C code, which turned that code
into an executable that promptly crashed.
But that's impossible, because C 'doesn't allow it'? Another wind-up?
> And the
> program you posted does not "do" anything.
Let's say the intention is to call a function to return a string. But
that return statement has been left out. So it's undefined. But, that's OK?
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? Even the compilation reported that
it ran into the end of a non-void function.
I'm struggling to reconcile this behaviour, with your statement that 'C
does not allow any such thing'.
Well SOMETHING is allowing it! But you're going to argue that:
* That code was not C
* That had undefined behaviour
* That was not a C compiler
Anything to put me in the wrong and absolve C and that C compiler
invoked by gcc from any blame in passing a program that could have wiped
my hard drive.
I don't get it. But, I really no longer care.
You want to pretend that there is nothing really wrong that writing your
own compiler preprocessor can't fix, then fine.
Nobody's mind is going to be changed here.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-06 04:29 +0100 |
| Message-ID | <87pm2wq8se.fsf@bsb.me.uk> |
| In reply to | #173932 |
Bart <bc@freeuk.com> writes:
> On 05/09/2023 01:31, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 04/09/2023 14:54, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> On 04/09/2023 09:54, David Brown wrote:
>>>>>> On 03/09/2023 19:11, Bart wrote:
>>>>>
>>>>>>> What's wrong with that?
>>>>>> If you can live inside a bubble, and be happy with that, then I suppose
>>>>>> that's fine. However, you don't have the experience or understanding to
>>>>>> criticise those outside the bubble. You can live in your blissful
>>>>>> ignorance if that's what suits you - but please understand that others do
>>>>>> not want to be in your bubble. It does not appeal at all to me. Your
>>>>>> bubble tools and languages are of little use or interest to all but a
>>>>>> very few other people.
>>>>>
>>>>> That may be so. But you can still learn things from them.
>>>> I think I've asked before, but is there a language reference manual?
>>>
>>> No.
>> Then no significant learning can happen.
>
> It's not going to happen anyway. I'm not going to spend a month slaving
> over a document just so you can say:
I would never expect you write a manual just for me. I had thought you
have user who would want to know the details.
> <snip>
You said you didn't like my writing that and I stopped. Had you not
noticed? I will still cut discussion of code that only you have a
reference manual for, but I won't write "<snip>" to indicate that
editing.
>>> 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.
>
> 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).
This text:
int main(void) { int a[] = {1}; return a[2]; }
is meaningless (as C). It does not "do" anything because it means
nothing.
You can choose to say that it's meaning is what the generated code does
(since most compilers will generate an executable) but then you link the
meaning of a text to the whims of a compiler author, the version of the
compiler and even to the flags you use when compiling.
> I posted examples of something that looked like C code, and of running
> programs that people often use to compile C code, which turned that code
> into an executable that promptly crashed.
>
> But that's impossible, because C 'doesn't allow it'? Another wind-up?
I didn't say it was impossible. C says "that's meaning less junk text"
but the compiler said "OK, here's some code I decided to generate from
that text" and that code crashes.
You want C to have rules that mean that this specific type of error can
never occur. I am happy with a compiler that tells me (as gcc does when
ask to) that this code is junk.
>> And the
>> program you posted does not "do" anything.
>
> Let's say the intention is to call a function to return a string. But that
> return statement has been left out. So it's undefined. But, that's OK?
C says that is not OK (if the value is used). I say it's not OK as well.
> 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
> 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 can certainly complain that gcc did
not work hard enough to stop you, but gcc sees itself as a tool not a
teacher.
> I'm struggling to reconcile this behaviour, with your statement that 'C
> does not allow any such thing'.
gcc's inventions of code from meaningless C texts in not "C allowing it"
it's gcc making something up.
> Well SOMETHING is allowing it! But you're going to argue that:
No, something (the compiler) is doing what you describe. That's not
"allowing" it. Allowing is a legalistic term.
> * That code was not C
It has no meaning when interpreted as C.
> * That had undefined behaviour
Code does not "have" undefined behaviour. C code either has a meaning
given to it by the language standard or it does not. UB means the
language no longer says what the source code means. All bets are off.
> * 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.
> Anything to put me in the wrong and absolve C and that C compiler invoked
> by gcc from any blame in passing a program that could have wiped my hard
> drive.
>
> I don't get it. But, I really no longer care.
Seriously, if you don't care, don't post. I've tried to explain my
remarks to you and that takes time. If you really don't care, I've
wasted my time. At the very least, put "I don't care" near the top as
you did when you told me not to bother answering.
> You want to pretend that there is nothing really wrong that writing your
> own compiler preprocessor can't fix, then fine.
You keep interpreting my replies as meaning that I think there is
nothing wrong with C.
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. You then find something else you don't like
(an un-diagnosed missing return value) so I tell you how to have it
diagnosed. But you don't like that gcc makes up some target code
anyway, so I tell you how to stop that and, in passing, explain how I
think about junk C code and what compilers do with it.
None of that means I think there is nothing wrong. The trouble is I
don't think I know exactly what's wrong and how to fix it. Do I think
your examples show a problem? Not really as I don't ignore it when gcc
tells me there's a missing return. And for the more complicated real
life examples, do I want to be made to add a fake return statement? No,
I think if you twisted my arm I'd want something more like an attribute
or a new kind of assert. And if C had codified rules about
reachability, I'd want exit and longjmp to be factored in as well. But
is that a good idea? I don't know.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-05 21:06 -0700 |
| Message-ID | <877cp43pzi.fsf@nosuchdomain.example.com> |
| In reply to | #174103 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> 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).
[...]
A very small quibble. I haven't found anything in gcc's documentation
that says it allows that extra semicolon. It does have a diagnostic
message that's enabled by -pedantic, but unless I'm missing something,
the lack of documentation means that it's not an *extension* in the
sense defined in section 4 of the C standard.
--
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 | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-06 01:03 -0700 |
| Message-ID | <63384370-a010-4c35-a3d7-9eaaeb9dbdd4n@googlegroups.com> |
| In reply to | #174103 |
On Wednesday, 6 September 2023 at 04:29:22 UTC+1, Ben Bacarisse wrote:
> Bart <b...@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:
>
To me, a program is a "functional device". I see why you think it is a "text"
and it has some non-superficialities to a text. But it is not a text which has
a meaning but a device which achieves a result.
>
> >> And the
> >> program you posted does not "do" anything.
> >
> > Let's say the intention is to call a function to return a string. But that
> > return statement has been left out. So it's undefined. But, that's OK?
>
> C says that is not OK (if the value is used). I say it's not OK as well.
>
> > 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
>
> > 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 can certainly complain that gcc did
> not work hard enough to stop you, but gcc sees itself as a tool not a
> teacher.
>
A C program is a functional device and the function is defined by the compiler
we run it through. Or in this case, the compiler plus the flags to that compiler.
Does the program mean anything? Well yes, the identifier getversion() conveys
a meaning to the human reader. Clearly we are trying to print out a version
number of some kind, and, because function doesn't have a return statement,
clearly we don't have it. It needs fixing, which would be achieved by asking
"what's the current version number?" and putting it in. Of course the compiler
is nowhere near clever enough to understand that.
>
> > I'm struggling to reconcile this behaviour, with your statement that 'C
> > does not allow any such thing'.
>
> gcc's inventions of code from meaningless C texts in not "C allowing it"
> it's gcc making something up.
>
> > Well SOMETHING is allowing it! But you're going to argue that:
>
> No, something (the compiler) is doing what you describe. That's not
> "allowing" it. Allowing is a legalistic term.
>
The term is accepting or rejecting the input. If an executable results, the
input has been accepted, otherwise it has been rejected.
>
> > * That code was not C
>
> It has no meaning when interpreted as C.
>
> > * That had undefined behaviour
>
> Code does not "have" undefined behaviour. C code either has a meaning
> given to it by the language standard or it does not. UB means the
> language no longer says what the source code means. All bets are off.
>
> > * 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.
>
> > Anything to put me in the wrong and absolve C and that C compiler invoked
> > by gcc from any blame in passing a program that could have wiped my hard
> > drive.
> >
> > I don't get it. But, I really no longer care.
>
> Seriously, if you don't care, don't post. I've tried to explain my
> remarks to you and that takes time. If you really don't care, I've
> wasted my time. At the very least, put "I don't care" near the top as
> you did when you told me not to bother answering.
>
> > You want to pretend that there is nothing really wrong that writing your
> > own compiler preprocessor can't fix, then fine.
>
> You keep interpreting my replies as meaning that I think there is
> nothing wrong with C.
>
> 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. You then find something else you don't like
> (an un-diagnosed missing return value) so I tell you how to have it
> diagnosed. But you don't like that gcc makes up some target code
> anyway, so I tell you how to stop that and, in passing, explain how I
> think about junk C code and what compilers do with it.
>
> None of that means I think there is nothing wrong. The trouble is I
> don't think I know exactly what's wrong and how to fix it. Do I think
> your examples show a problem? Not really as I don't ignore it when gcc
> tells me there's a missing return. And for the more complicated real
> life examples, do I want to be made to add a fake return statement? No,
> I think if you twisted my arm I'd want something more like an attribute
> or a new kind of assert. And if C had codified rules about
> reachability, I'd want exit and longjmp to be factored in as well. But
> is that a good idea? I don't know.
>
It's easy enough for the compiler to detect if a control path is unreachable
with no false positives. But it's impossible to remove all the false negatives
(code which is in fact unreachable, but falsely labelled as reachable).
It's also often difficult for a human to make the same determination.
So if you require dummy return statements, this can have a serious impact
on the reader's ability to understand the code.
However we can easily solve the problem. Simply define a macro with the
value 0 in the file assert.h, then
assert(UNREACHABLE);
The code following then becomes trivially unreachable.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-06 20:58 +0100 |
| Message-ID | <87zg1zoyyo.fsf@bsb.me.uk> |
| In reply to | #174110 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Wednesday, 6 September 2023 at 04:29:22 UTC+1, Ben Bacarisse wrote:
>> Bart <b...@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:
>>
> To me, a program is a "functional device". I see why you think it is a "text"
> and it has some non-superficialities to a text.
I am curious as to how you are so sure that you can see why I think it
is a text. I have a suspicion (from the way you reject my point of view
with almost no consideration) that you /don't/ see why I think it.
Can you say why I think it a text? You may be right, but if not it's
going to be hard to have a reasonable discussion.
> A C program is a functional device and the function is defined by the
> compiler we run it through. Or in this case, the compiler plus the
> flags to that compiler.
I've come across this opinion before. I can't take it seriously. The
effect is that the same text denotes wildly different "functional
devices". The code I posted (with an int-valued function that consisted
of a call to exit(...)) is a non-device when given to a compiler like
Bart's compiler (since it won't compile it) and yet works exactly as
intended when given to gcc. What's more, its actions -- when they are
permitted to exit at all -- are fully determined by what the language
standard says about the text but, according to you, that is not
sufficient. Without the compiler, there is no meaning.
Will you indulge in a thought experiment? For a long while after the
publication of the Revised Report on the Algorithmic Language ALGOL 68,
there were no compilers for Algol 68. Did that mean the Algol 68
programs had no meaning? Or were their meanings pending and tentative,
based on the assumed appearance of compilers that "did the right thing"?
If so, why not always do that -- why not always say that the meaning is
defined by the report because that's the meaning a compiler should give
it?
> Does the program mean anything? Well yes, the identifier getversion()
> conveys a meaning to the human reader.
To be honest, my first reaction was that this is just a wind. The only
concession to the notion that the program text means anything at all is
that the names might convey something to the reader.
>> > I'm struggling to reconcile this behaviour, with your statement that 'C
>> > does not allow any such thing'.
>>
>> gcc's inventions of code from meaningless C texts in not "C allowing it"
>> it's gcc making something up.
>>
>> > Well SOMETHING is allowing it! But you're going to argue that:
>>
>> No, something (the compiler) is doing what you describe. That's not
>> "allowing" it. Allowing is a legalistic term.
>>
> The term is accepting or rejecting the input.
Eh? That's not the term Bart used. I wanted to say what I thought was
wrong about the terms actually being used. By introducing yet another
term, while suggesting it's what was meant all along ("the term is...",
rather than "we might use the term...") you just muddy the waters.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-06 19:21 -0700 |
| Message-ID | <79370b99-e428-4858-90f9-991652392927n@googlegroups.com> |
| In reply to | #174201 |
On Wednesday, 6 September 2023 at 20:59:13 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > On Wednesday, 6 September 2023 at 04:29:22 UTC+1, Ben Bacarisse wrote: > >> Bart <b...@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: > >> > > To me, a program is a "functional device". I see why you think it is a "text" > > and it has some non-superficialities to a text. > I am curious as to how you are so sure that you can see why I think it > is a text. I have a suspicion (from the way you reject my point of view > with almost no consideration) that you /don't/ see why I think it. > > Can you say why I think it a text? You may be right, but if not it's > going to be hard to have a reasonable discussion. > A C script is indistinguishable from text to any program which is not a C compiler (strictly, a C parser). The symbols are what is important, not the physical substrate. And a human can read the program and say what it means. So it's a text. That's probably a summary of your position. But I can't actually speak for you, of course. > > > A C program is a functional device and the function is defined by the > > compiler we run it through. Or in this case, the compiler plus the > > flags to that compiler. > I've come across this opinion before. I can't take it seriously. The > effect is that the same text denotes wildly different "functional > devices". The code I posted (with an int-valued function that consisted > of a call to exit(...)) is a non-device when given to a compiler like > Bart's compiler (since it won't compile it) and yet works exactly as > intended when given to gcc. What's more, its actions -- when they are > permitted to exit at all -- are fully determined by what the language > standard says about the text but, according to you, that is not > sufficient. Without the compiler, there is no meaning. > It's a device that needs other devices to function correctly. A Philips screwdriver is entirely useless without the special screws. A normal electrical screwdriver will break a reverse-thread screw. It's very common for devices either not to function at all or to function differently if the other devices they interact with are not set up in the way expected. > > Will you indulge in a thought experiment? For a long while after the > publication of the Revised Report on the Algorithmic Language ALGOL 68, > there were no compilers for Algol 68. Did that mean the Algol 68 > programs had no meaning? Or were their meanings pending and tentative, > based on the assumed appearance of compilers that "did the right thing"? > If so, why not always do that -- why not always say that the meaning is > defined by the report because that's the meaning a compiler should give > it? > OK. So first case. We have "Hello world" in Algol 68. But no Algol 68 compiler is in existence. So we cannot say that "the meaning of this program is defined by the compiler". However it seems a bit of a stretch to say, "this program has no meaning". Anyone, probably anyone with a bit of programming experience but no Algol 68 knowledge, can see that it is "Hello world". So on the basis of case one, let's say that programs have a meaning, and that is defiend by the standards documents. Now let's consider case 2. Bart builds a "Bartlang to Algol 68 compiler". A non- trivial program in Bartlang is run through it, and Algol 68 results. But humans can't understand this output. It might have hundreds of levels of intricately nested parentheses. So, given the Algol 68 and the Algol 68 specification, it's impossible to say what this program means. Given the Bartlang and the Bartlang manual, it is possible to say what the program means, as long as we accept that the Bartlang to Algol 68 compiler is bug free. But not given the Algol 68. Can we therefore say that the Algol 68 is not an Algol 68 program? Of course not. And can we say "it has no meaning?". Depends how we use the word. Can we say that the Algol 68 is a "functional device" which, when fed to an Algol 68 compiler, will produce an executable which does something useful? Certainly. It is a functional device, no dispute. The fact that we don't actually have the Algol 68 compiler doesn't change that. (Clearly there must have been some point in history when there were Philps screws but no screwdrivers, or Philips screwdrivers but no screws. But they were still devices.) > > > Does the program mean anything? Well yes, the identifier getversion() > > conveys a meaning to the human reader. > To be honest, my first reaction was that this is just a wind. The only > concession to the notion that the program text means anything at all is > that the names might convey something to the reader. > That's also a non-trival way in which programs might be thought of as texts. They contain symbols which are meaningless to the compiler, but not to the human reader.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-07 20:18 +0100 |
| Message-ID | <87edj9okqf.fsf@bsb.me.uk> |
| In reply to | #174254 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Wednesday, 6 September 2023 at 20:59:13 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Wednesday, 6 September 2023 at 04:29:22 UTC+1, Ben Bacarisse wrote:
>> >> Bart <b...@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:
>> >>
>> > To me, a program is a "functional device". I see why you think it is a "text"
>> > and it has some non-superficialities to a text.
>> I am curious as to how you are so sure that you can see why I think it
>> is a text. I have a suspicion (from the way you reject my point of view
>> with almost no consideration) that you /don't/ see why I think it.
>>
>> Can you say why I think it a text? You may be right, but if not it's
>> going to be hard to have a reasonable discussion.
>>
> A C script is indistinguishable from text to any program which is not
> a C compiler (strictly, a C parser). The symbols are what is important,
> not the physical substrate. And a human can read the program and say
> what it means. So it's a text.
>
> That's probably a summary of your position. But I can't actually speak
> for you, of course.
I'm not sure if that's my position. It's not something I'd write to
explain what I mean. The first sentence in particular is baffling me.
Anyway, there is no need for you to know what I mean (unless you
particularly want to know).
>> > A C program is a functional device and the function is defined by the
>> > compiler we run it through. Or in this case, the compiler plus the
>> > flags to that compiler.
>> I've come across this opinion before. I can't take it seriously. The
>> effect is that the same text denotes wildly different "functional
>> devices". The code I posted (with an int-valued function that consisted
>> of a call to exit(...)) is a non-device when given to a compiler like
>> Bart's compiler (since it won't compile it) and yet works exactly as
>> intended when given to gcc. What's more, its actions -- when they are
>> permitted to exit at all -- are fully determined by what the language
>> standard says about the text but, according to you, that is not
>> sufficient. Without the compiler, there is no meaning.
>>
> It's a device that needs other devices to function correctly.
But, I would say, one only knows what "function correctly" means because
one knows the meaning of the text. Here's a C program running through a
compiler I have just written:
$ cat test.c
#include <stdio.h>
int main(void) {
printf("%g\n", 12e3);
}
$ bcc test.c
$ ./a.out
3
Is it functioning correctly? How can you tell?
>> Will you indulge in a thought experiment? For a long while after the
>> publication of the Revised Report on the Algorithmic Language ALGOL 68,
>> there were no compilers for Algol 68. Did that mean the Algol 68
>> programs had no meaning? Or were their meanings pending and tentative,
>> based on the assumed appearance of compilers that "did the right thing"?
>> If so, why not always do that -- why not always say that the meaning is
>> defined by the report because that's the meaning a compiler should give
>> it?
>>
> OK. So first case. We have "Hello world" in Algol 68. But no Algol 68
> compiler is in existence. So we cannot say that "the meaning of this
> program is defined by the compiler". However it seems a bit of a
> stretch to say, "this program has no meaning".
I am glad you agree. I'd say it's way more than a stretch to say that.
It's is patently absurd to say that since the programmer wrote
BEGIN
print(("Hello world", new line))
END
knowing the computation that that text is supposed to represent. And
the compiler authors will be working hard to give that text exactly that
meaning.
> Anyone, probably anyone
> with a bit of programming experience but no Algol 68 knowledge, can
> see that it is "Hello world". So on the basis of case one, let's say
> that programs have a meaning, and that is defiend by the standards
> documents.
OK.
> Now let's consider case 2. Bart builds a "Bartlang to Algol 68
> compiler". A non- trivial program in Bartlang is run through it, and
> Algol 68 results. But humans can't understand this output. It might
> have hundreds of levels of intricately nested parentheses. So, given
> the Algol 68 and the Algol 68 specification, it's impossible to say
> what this program means.
Hard is not impossible. But that's incidental because I see now that
you have misinterpreted my meaning. A program text has a meaning
derived from the rules of the language even if no human can grasp it.
Given that this is case 2 of the thought experiment, you need to explain
how the Bartlang to Algol 68 compiler was written. Did the author just
make up the meaning of the Algol 68 text that the compiler produces, or
was the generation of the text driven by understanding what the
generated text (piece by piece at least) means?
> Given the Bartlang and the Bartlang manual,
> it is possible to say what the program means, as long as we accept
> that the Bartlang to Algol 68 compiler is bug free. But not given the
> Algol 68. Can we therefore say that the Algol 68 is not an Algol 68
> program? Of course not.
No one has ever suggested such a thing.
> And can we say "it has no meaning?". Depends
> how we use the word. Can we say that the Algol 68 is a "functional
> device" which, when fed to an Algol 68 compiler, will produce an
> executable which does something useful? Certainly.
So what? You are not (yet) addressing the question you remembered to
ask "has it a meaning"? And you don't know that it ever will do
anything at all, let along something useful as there may never be a
compiler that can handle it.
> It is a functional device, no dispute. The fact that we don't
> actually have the Algol 68 compiler doesn't change that.
It's your term, so how can I dispute it? All know is that
"A [..] program is a functional device and the function is defined by
the compiler we run it through."
so in case 2 we have a "functional device" with no defined function.
Seems odd to call it functional but as I say, it's your term.
But you don't seem to have answered the questions, the first being the
key one. I asked:
|| For a long while after the publication of the Revised Report on the
|| Algorithmic Language ALGOL 68, there were no compilers for Algol
|| 68. Did that mean the Algol 68 programs had no meaning? Or were their
|| meanings pending and tentative, based on the assumed appearance of
|| compilers that "did the right thing"? If so, why not always do that
|| -- why not always say that the meaning is defined by the report
|| because that's the meaning a compiler should give it?
Does the program in case 2 have no meaning? You have stated (and I
can't dispute) that it is something you call a "functional device", but
you've also said it has no defined function, so does that mean it has no
meaning?
> (Clearly there must have been some point in history when there were
> Philps screws but no screwdrivers, or Philips screwdrivers but no
> screws. But they were still devices.)
Sneaky change of focus to simply "a device"! Are they "functional
devices" on their own? Not according to you:
"It's a device that needs other devices to function correctly. A
Philips screwdriver is entirely useless without the special screws."
Now I suppose (since I think you are just seeing if these idea fly) you
can claim that "functional" and "function correctly" are different. Is
that going to be the game?
But if that is the case, you still have to address the question of what
correctly means for an Algol 68 program. Could it be that "function
correctly" means that the behaviour is one of those permitted by the
meaning of the source text?
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 12 of 18 — ← Prev page 1 … 10 11 [12] 13 14 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web