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 16 of 18 — ← Prev page 1 … 14 15 [16] 17 18 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-04 14:14 +0000 |
| Message-ID | <yDlJM.780911$mPI2.239837@fx15.iad> |
| 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. A good idea is >a good idea. Not really. Define 'good' in this context.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-04 16:59 +0200 |
| Message-ID | <ud4rbl$1h1t4$1@dont-email.me> |
| In reply to | #173874 |
On 04/09/2023 12:06, Bart wrote:
> 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.
I agree entirely that you can learn from them, and some good ideas are
widely applicable.
But a good idea for one language is not necessarily a good idea for a
different language.
>
>>
>>
>
>> 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.
Your own languages are basically irrelevant here. Languages related to
C are sometimes interesting for comparison, but should at least be
languages familiar to people here. (Thus C++ can sometimes come up.)
How your C compilers act on C code /is/ relevant.
>
>> 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++!)
Why don't you mean C++? It is a viable alternative to C for a great
many uses. Other languages that can be used in places where C might
also be a reasonable choice include Rust, Go, D, Fortran, Ada, Pascal,
Java, Objective-C, Ocaml, Zig, Forth, and probably several others.
Your language is not viable as a choice for programming. I would not
consider a personal one-man language as acceptable for professional
work. (Your opinion, naturally, will differ here - I can only speak for
myself.) I've seen what happens when rare or obscure languages are
picked for development projects, and it is not pretty. Even when the
tool involved is a perfect for the task, and even when it is an
established tool (at least big enough to have its own Wikipedia page),
you have a maintenance disaster. The customer is left with software
that has cost them a great deal of time and money, and as soon as it
hits a limit or a new feature is required, it is worthless because they
can't get someone to build on it.
No, at least for the customers I have had over the decades, your tools
would not be considered viable at all.
(And of course they are completely useless on the main targets for most
of my code.)
And regardless, your point is irrelevant to being able to compare C with
other languages.
>
> * How many have /designed and implemented/ that alternative?
That is completely irrelevant to understanding other languages.
>
> * How many here have written compilers? That includes a 'full stack'
> implementation
Again, irrelevant.
>
> * How many here have tried implementing a C compiler?
>
Again, irrelevant.
> You don't think that can give someone a rather special perspective?
Not for this point, no.
Don't get me wrong - you've done some impressive stuff over the years,
and creating your own languages and tools is no minor achievement.
Implementing a C compiler does (or should) give you some useful
insights. (Though you are not alone in this group in having implemented
a compiler.)
But does any of that mean you have unique insights or are able to offer
comparisons or views on C that others cannot? No, it does not. For
every time you bring up your own language in comparison to C, I could
compare it to half a dozen other languages (and there are other regulars
here would could do far more) - all equally irrelevant. I don't need to
have had a career programming in Ada or D to be able to compare them to
C - I just need to know enough about the languages. And these have the
overwhelming benefit that everyone here can look up the details if they
want to know more, try them online at godbolt.org (or other similar
sites), and test them out on their own machines.
So yes, you certainly have done something few others have over the
decades. Call yourself "special" if you want - it would not be
unreasonable. But don't mistake that for thinking you have special
knowledge of C or unique abilities to compare it to other languages.
>
> 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.
Well, no, you haven't.
You've made a compiler for a sort-of C language, of unknown standard,
with unknown details, that rejects code that is by definition valid C,
works in limited use-cases, and is missing features that other people
want when developing in C.
That doesn't mean it is a bad tool - being small, fast and easy to use
is a good thing. (And it certainly does not mean it is not an
impressive achievement.) And when your tool is good enough, it is good
enough.
I would be much happier to see you take credit and stand for what you
have achieved, than making absurd comparisons that lead to ridicule.
Say you have made a sort-of C compiler that handles a useful subset of
the language and has defaults and error handling that you personally
find more useful than other tools and the standard C language - that's
honest opinion, and perfectly valid. Telling people that the defaults
they find useful in massively popular software are objectively wrong, or
that C compilers should work contrary to the requirements of the
language, is entirely different - it makes you look arrogant and
ignorant. (This is especially the case since you have proved that your
knowledge of C is barely enough to write code in the language, and
certainly not accurate enough to write a conforming C compiler.)
>
>>> 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.
You can't "agree" with something completely unrelated to what I wrote.
>
> 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!
>
And what, exactly, do you think /you/ are doing? Whining, moaning and
complaining to people who have no influence whatsoever on the language
or tools in question? You've written a sort-of-C compiler that is, if I
understand correctly, not even that useful for your own work - and the
only other person interested in it makes flat-earthers look rational.
What do you think we should all be doing - even if anyone here agreed
with you on more than a few small points?
>> 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:
Why should anyone care about your language?
>
> 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.
As you know, it is not valid C code. As you know, proper C compilers
will - at least - warn you about it when asked to treat the input
according to the C standards. As you know, there isn't a compiler in
the world for any language which will stop programmers from writing
incorrect code.
>
> And not by providing extra options to override compiler's choices; you
> don't have to provide /any/ options!
And yet no matter what options I give your compiler, it is incapable of
doing the job I need from a compiler. So my choice would be - use gcc
and give it some options and get what I need, or use your compiler
without options and fail to get what I need. What a difficult choice!
>
> I don't really need to say anything else.
>
Does that mean you will stop posting about your language?
>
>>
>>>
>>> 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.
>
I am familiar enough with a dozen languages to be able to compare them
with C, excluding Python and Haskell. And I have on many occasions
written code to do the same task in Python and in C, more than enough to
know that they certainly can be usefully compared despite the different
levels of language.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-04 15:41 -0700 |
| Message-ID | <87h6o95znv.fsf@nosuchdomain.example.com> |
| In reply to | #173886 |
David Brown <david.brown@hesbynett.no> writes:
> On 04/09/2023 12:06, Bart wrote:
[...]
>> char* fred(void) {
>> (long long int)rand()*3.14159;
>> }
>> int main(void) {
>> printf("%s\n", fred());
>> }
[...]
> As you know, it is not valid C code. As you know, proper C compilers
> will - at least - warn you about it when asked to treat the input
> according to the C standards. As you know, there isn't a compiler in
> the world for any language which will stop programmers from writing
> incorrect code.
Given the context of the discussion, pedantry seems appropriate.
It's invalid C code because it doesn't declare rand() and printf(),
correctable by adding `#include <stdlib.h>` and `#include <stdio.h>`.
(It also contains NO-BREAK SPACE characters, but that's that's just a
Usenet formatting issue.)
Other than that, a conforming C compiler is not required to diagnose
the above code. It does have undefined behavior, and a C compiler is
likely to warn about it with appropriate warnings, but it does not
violate any syntax rule or constraint.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-04 18:15 -0700 |
| Message-ID | <86jzt5pgho.fsf@linuxsc.com> |
| In reply to | #173913 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 04/09/2023 12:06, Bart wrote:
>
> [...]
>
>>> char* fred(void) {
>>> (long long int)rand()*3.14159;
>>> }
>>> int main(void) {
>>> printf("%s\n", fred());
>>> }
>
> [...]
>
>> As you know, it is not valid C code. As you know, proper C compilers
>> will - at least - warn you about it when asked to treat the input
>> according to the C standards. As you know, there isn't a compiler in
>> the world for any language which will stop programmers from writing
>> incorrect code.
>
> Given the context of the discussion, pedantry seems appropriate.
>
> It's invalid C code because it doesn't declare rand() and printf(),
> correctable by adding `#include <stdlib.h>` and `#include <stdio.h>`.
> (It also contains NO-BREAK SPACE characters, but that's that's just a
> Usenet formatting issue.)
>
> Other than that, a conforming C compiler is not required to diagnose
> the above code. It does have undefined behavior, and a C compiler is
> likely to warn about it with appropriate warnings, but it does not
> violate any syntax rule or constraint.
I say it does.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-04 18:57 -0700 |
| Message-ID | <87zg214c1j.fsf@nosuchdomain.example.com> |
| In reply to | #173931 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 04/09/2023 12:06, Bart wrote:
>> [...]
>>
>>>> char* fred(void) {
>>>> (long long int)rand()*3.14159;
>>>> }
>>>> int main(void) {
>>>> printf("%s\n", fred());
>>>> }
>>
>> [...]
>>
>>> As you know, it is not valid C code. As you know, proper C compilers
>>> will - at least - warn you about it when asked to treat the input
>>> according to the C standards. As you know, there isn't a compiler in
>>> the world for any language which will stop programmers from writing
>>> incorrect code.
>>
>> Given the context of the discussion, pedantry seems appropriate.
>>
>> It's invalid C code because it doesn't declare rand() and printf(),
>> correctable by adding `#include <stdlib.h>` and `#include <stdio.h>`.
>> (It also contains NO-BREAK SPACE characters, but that's that's just a
>> Usenet formatting issue.)
>>
>> Other than that, a conforming C compiler is not required to diagnose
>> the above code. It does have undefined behavior, and a C compiler is
>> likely to warn about it with appropriate warnings, but it does not
>> violate any syntax rule or constraint.
>
> I say it does.
If you're right, then gcc 13.2.0 and clang 16.0.0 have a bug. Both
compile the above code (once the required #include directives are added)
without error, though clang prints a couple of optional warnings. I used
"-std=c17 -pedantic-errors" with both compilers. (With "-Wall", gcc
prints warnings similar to the ones clang prints without it.)
What syntax rule or constraint does it violate?
Does it occur to you that you would save everyone a lot of time if
you'd explain what you mean in the first place?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-30 09:23 -0700 |
| Message-ID | <868r8nfx49.fsf@linuxsc.com> |
| In reply to | #173940 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 04/09/2023 12:06, Bart wrote:
>>>
>>> [...]
>>>
>>>>> char* fred(void) {
>>>>> (long long int)rand()*3.14159;
>>>>> }
>>>>> int main(void) {
>>>>> printf("%s\n", fred());
>>>>> }
>>>
>>> [...]
>>>
>>>> As you know, it is not valid C code. As you know, proper C compilers
>>>> will - at least - warn you about it when asked to treat the input
>>>> according to the C standards. As you know, there isn't a compiler in
>>>> the world for any language which will stop programmers from writing
>>>> incorrect code.
>>>
>>> Given the context of the discussion, pedantry seems appropriate.
>>>
>>> It's invalid C code because it doesn't declare rand() and printf(),
>>> correctable by adding `#include <stdlib.h>` and `#include <stdio.h>`.
>>> (It also contains NO-BREAK SPACE characters, but that's that's just a
>>> Usenet formatting issue.)
>>>
>>> Other than that, a conforming C compiler is not required to diagnose
>>> the above code. It does have undefined behavior, and a C compiler is
>>> likely to warn about it with appropriate warnings, but it does not
>>> violate any syntax rule or constraint.
>>
>> I say it does.
>
> If you're right, then gcc 13.2.0 and clang 16.0.0 have a bug. Both
> compile the above code (once the required #include directives are added)
> without error, though clang prints a couple of optional warnings. I used
> "-std=c17 -pedantic-errors" with both compilers. (With "-Wall", gcc
> prints warnings similar to the ones clang prints without it.)
>
> What syntax rule or constraint does it violate?
I'm sorry the point I was trying to make got lost. I was
hoping for some value to result from my comment, and I feel
bad that that is unlikely to happen. I'll try to do better
next time.
> Does it occur to you that you would save everyone a lot of time if
> you'd explain what you mean in the first place?
You say that like you think saving people time should always
be my highest priority. It isn't, at least not always.
When there is some tension between two or more areas of
consideration usually (at least) one has to be shortchanged.
I prioritize the factors I think are the most important in
each particular case. I'm sorry if my choices seem poor to
you but I need to follow the path that I think has the best
chance of success.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-30 15:55 -0700 |
| Message-ID | <87ttrbqniz.fsf@nosuchdomain.example.com> |
| In reply to | #176814 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> On 04/09/2023 12:06, Bart wrote:
>>>> [...]
>>>>
>>>>>> char* fred(void) {
>>>>>> (long long int)rand()*3.14159;
>>>>>> }
>>>>>> int main(void) {
>>>>>> printf("%s\n", fred());
>>>>>> }
>>>>
>>>> [...]
>>>>
>>>>> As you know, it is not valid C code. As you know, proper C compilers
>>>>> will - at least - warn you about it when asked to treat the input
>>>>> according to the C standards. As you know, there isn't a compiler in
>>>>> the world for any language which will stop programmers from writing
>>>>> incorrect code.
>>>>
>>>> Given the context of the discussion, pedantry seems appropriate.
>>>>
>>>> It's invalid C code because it doesn't declare rand() and printf(),
>>>> correctable by adding `#include <stdlib.h>` and `#include <stdio.h>`.
>>>> (It also contains NO-BREAK SPACE characters, but that's that's just a
>>>> Usenet formatting issue.)
>>>>
>>>> Other than that, a conforming C compiler is not required to diagnose
>>>> the above code. It does have undefined behavior, and a C compiler is
>>>> likely to warn about it with appropriate warnings, but it does not
>>>> violate any syntax rule or constraint.
>>>
>>> I say it does.
>>
>> If you're right, then gcc 13.2.0 and clang 16.0.0 have a bug. Both
>> compile the above code (once the required #include directives are added)
>> without error, though clang prints a couple of optional warnings. I used
>> "-std=c17 -pedantic-errors" with both compilers. (With "-Wall", gcc
>> prints warnings similar to the ones clang prints without it.)
>>
>> What syntax rule or constraint does it violate?
>
> I'm sorry the point I was trying to make got lost. I was
> hoping for some value to result from my comment, and I feel
> bad that that is unlikely to happen. I'll try to do better
> next time.
I'm sorry you chose not to answer my simple and direct question.
What syntax rule or constraint does the code violate?
Also, what was the point you were trying to make?
I asserted that the code (after adding the required #include
directives) does not violate any syntax rule or constraint.
You asserted that it does, but didn't elaborate. I asked you
directly what syntax rule or constraint it violates.
I can't imagine a valid rationale for refusing to answer that
question, and I find your behavior very frustrating. My frustration
is compounded by the fact that, for whatever reason, you gave no
response at all for several weeks.
I am, for now, convinced that the code in question has undefined
behavior but does not violate any syntax error or constraint.
I respect your technical abilities enough that I'm hesitant to assume
that you're wrong, but that's the only conclusion I can make unless
you choose to explain what you're talking about.
>> Does it occur to you that you would save everyone a lot of time if
>> you'd explain what you mean in the first place?
>
> You say that like you think saving people time should always
> be my highest priority. It isn't, at least not always.
> When there is some tension between two or more areas of
> consideration usually (at least) one has to be shortchanged.
> I prioritize the factors I think are the most important in
> each particular case. I'm sorry if my choices seem poor to
> you but I need to follow the path that I think has the best
> chance of success.
No, I'm not saying saving people time should "always be [your]
highest priority". That's an absurd exaggeration. I'm saying
that it should be one thing for you to consider. You mention the
"best chance of success". Success at what?
I'm having great difficulty reaching a conclusion other than that
you're being rude, inconsiderate, and deliberately evasive, for no
reason that I can discern. I think that's probably not your intent.
I welcome any clarification you can offer.
--
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 | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-02 17:10 +0000 |
| Message-ID | <20230902093734.397@kylheku.com> |
| In reply to | #173646 |
On 2023-09-02, Bart <bc@freeuk.com> wrote:
> On 02/09/2023 02:12, Kaz Kylheku wrote:
>> Basically we want the last statement to to be a "tail statement",
>> which is defined as a return statement, or else a statement which
>> has a tail statement in every tail position.
>
> Diagnosing this fully is difficult.
Breaking news: the C language historically ducks out of "difficult"!
It's only worth doing fully or not at all (within reasonable limits of
static analysis: not trying to solvve the halting problem).
> be able to determine if control flow ever runs into the end of the
> function, and then whether 'return' is executed when the last statement
> in the function is complex.
No; Keith nailed it. We don't care about return, specifically. We want
to diagnose the situation that the end of the function is reachable.
A return statement before the end of the function is one way
that the end is unreachable, and thus okay. There are other ways
that reaching it can be blocked.
We could have it so that it has to be "statically obvious" that
the end of the function is not reached, where by "statically obvious"
we identify all dead code implicated by constant expressions.
If the end of the function is eliminated as dead code, then it's
not reached.
Thus this diagnoses:
int fred(void)
{
extern int always_true(void);
while (always_true()) {
}
}
This doesn't:
int fred(void)
{
while (1) {
}
}
The previous one will be a nuisance diagnosic since the always_true
function always returns true.
If the belief is correct, why not restructure the code:
int fred(void)
{
extern int always_true(void);
for (;;) {
always_true(); // call for its side effect only
}
}
> And a variation of my test is 'int fred{return;}'. Here, any return
> obviously needs a value, and that is very easy to check.
>
> gcc will report a warning here; clang an error; and tcc nothing.
>
> You'd think this is a no-brainer.
The only no-brainer is that tcc is deficient.
ISO C99 says, in a Constraints paragraph: "A return statement without an
expression shall only appear in a function whose return type is void."
Thus, it requires a diagnostic.
I'm suspect it's been there since ANSI C 1989.
That is one diagnostic you don't want to put to a --pedantic
mode, either. It's not a reasonable local language extension to allow
"return;" in a function with non-void return type.
Of course, Your Language could never be deficient in this way,
because you're the only arbiter of what is correct. Do you even
have a document which could differ from what is implemented?
> (My own language compiler has no problem detecting whether a complex
> last statement/expression yields a suitable return value, but it does no
> analysis to detect whether that last expression is ever executed. So
> sometimes a dummy return value is needed.
That's ugly:
{
if (this)
return that;
else
return other_thing;
return 0; // shut up dumb compiler?
}
it does the job of reducing errors, but smacks of immaturity.
>>> Imagine buying a car with no brakes. Oh, nothing wrong that, only if you
>>
>> Imagine buying a power transistor with no thermal shutoff.
>>
>> Wait, that's pretty much all of them.
>>
>> Engineering products and consumer products are different.
>>
>> A transistor has good reasons for being the way it is; a language
>> allowing control flow to fall off the end without a return value
>> isn't such a good reason. We can't compare the justification.
>
> If such a function was used in a library module within automotive
> software that controlled the brakes, then yes there is justification.
There is justification in using a good compiler with tons of warnings,
which enforces the MISRA coding recommendations and such.
> Why make C even more crazily unsafe than it already is? You should have
> to fight to allow unsafe code, not have to fight to make it safe!
That's simply not the kind of tool that C is, and will likely never
evolve into that. In the foreseeable future, it's compilers,
run-time tools, static analaysis tools, around a language that stays
more or less the same.
The newsgroups for safe-by-default languages are not immune to
trolling, like someone complaining that all the default safety
gets in the way of just telling the machine what to do, and look
how much shorter this C example is!
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-02 13:13 -0700 |
| Message-ID | <87r0ng72r6.fsf@nosuchdomain.example.com> |
| In reply to | #173672 |
Kaz Kylheku <864-117-4973@kylheku.com> writes:
[...]
> ISO C99 says, in a Constraints paragraph: "A return statement without an
> expression shall only appear in a function whose return type is void."
> Thus, it requires a diagnostic.
>
> I'm suspect it's been there since ANSI C 1989.
No, it was introduced in C99. C90 says:
Constraints
A return statement with an expression shall not appear in a function
whose return type is void
Semantics
...
If a return statement without an expression is executed. and the
value of the function call is used by the caller, the behavior is
undefined. Reaching the } that terminates a function is equivalent
to executing a return statement without an expression.
This was to cater to pre-ANSI code that used implicit int where modern
code would use a void return type. For example, a function that
performs some action and doesn't return a value might be defined in
modern C as:
In K&R C, a function that performs some action and doesn't return a
value might be written as:
do_something(void) {
if (already_done) return;
do_the_thing();
}
In modern C, it might be written as:
void do_something(void) {
if (already_done) return;
do_the_thing();
}
The function implicitly returns int, but the return statement without an
expression was appropriate because the caller would not use the result.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-02 22:50 +0100 |
| Message-ID | <87edjgjld3.fsf@bsb.me.uk> |
| In reply to | #173682 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> In K&R C, a function that performs some action and doesn't return a
> value might be written as:
>
> do_something(void) {
> if (already_done) return;
> do_the_thing();
> }
Nit: in what I call K&R C it would be
do_something() {
if (already_done) return;
do_the_thing();
}
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-02 14:54 -0700 |
| Message-ID | <87il8s6y18.fsf@nosuchdomain.example.com> |
| In reply to | #173686 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> In K&R C, a function that performs some action and doesn't return a
>> value might be written as:
>>
>> do_something(void) {
>> if (already_done) return;
>> do_the_thing();
>> }
>
> Nit: in what I call K&R C it would be
>
> do_something() {
> if (already_done) return;
> do_the_thing();
> }
Quite right, thanks.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-01 19:02 -0700 |
| Message-ID | <877cp98h80.fsf@nosuchdomain.example.com> |
| In reply to | #173602 |
Bart <bc@freeuk.com> writes:
> On 02/09/2023 00:02, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> But tell me what dialect of C my 'int fred(void){}' is a valid program
>>> of. Then tell me why most C compilers are still compiling that dialect
>>> by default in 2023.
>> [...]
>> Can you clarify what point you're making with `int fred(void){}`?
>> That's a valid function definition and translation unit in every
>> version
>> of ISO C going back to C90, by which I mean that it does not violate any
>> constraint or syntax rule. (I presume we're not concerned with K&R C,
>> which didn't have void.) It is not a valid *program* for a hosted
>> implementation in any version of C, since it lacks a `main` function.
>> A compiler may reasonably warn about the fact that control reaches
>> the
>> end of a non-void function, but the standard doesn't require a
>> diagnostic. Calling `fred` and not using the result is well defined.
>> Calling `fred` and attempting to use the result has undefined behavior.
>> No diagnostic is required, up to and including C23. (There are
>> historical reasons for this, which I won't go into.)
>> Note carefully that I am describing the requirements given by the C
>> standard, not expressing an opinion on whether they're good or bad.
>> Now, what was your point, and how does `int fred(void){}` illustrate
>> it?
>
> I would have said it's obviously wrong.
Reading the rest of your reply, it takes you several paragraphs to get
around to saying *why* it's "obviously wrong". You think it's obviously
wrong because it's defined to return a non-void, but it does not do so.
I mentioned that there are historical reasons why this is not a fatal
error. I've probably discussed those reasons here before, though not in
this thread. If I thought you were interested in learning something,
I'd be glad to do so again. If someone else asks I'll explain it to
them, and you can read along if you like.
It is a fact that `int fred(void){}` does not, according to any edition
of the ISO C standard, require a diagnostic. It does not violate any
syntax rule or constraint.
I don't know how to make it any clearer that I was explaining to you
what the standard says, not expressing or soliciting an opinion about
it.
> But in this group, so many people have argued that black is white, or
> vice versa, that nothing surprises me any more.
If you're saying that I'm wrong about what the standard says, I'm
interested in hearing why.
Am I wrong about what the standard says?
If you're saying that you don't like what the standard says, I'm aware
of that and profoundly uninterested in discussing it with you.
And of course gcc can be made to warn about it with the right options.
[...]
> I'm going back to my own saner language and compilers that don't beat
> about the bush:
>
> func fred:int =
> end
>
> "Return value missing"
>
> I can't proceed until I provide one, or change it to a function that
> doesn't return a value.
>
> Is there ... anything wrong with that?
No, and I have never said or implied that there is. But you know that.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-02 22:42 +0100 |
| Message-ID | <87jzt8jlqo.fsf@bsb.me.uk> |
| In reply to | #173602 |
Bart <bc@freeuk.com> writes:
> On 02/09/2023 00:02, Keith Thompson wrote:
>> Now, what was your point, and how does `int fred(void){}` illustrate it?
>
> I would have said it's obviously wrong.
Curiously, I wrote a similar function two days ago. I had a table of
function pointers and I wanted a "nothing here" value I could store and
test for. Rather than use a null function pointer, I chose
void *no_op(int) { exit(error("placeholder called")); }
so that I'd know if it were accidentally called. It uses /two/ features
you dislike: unnamed parameters in a function definition, and a body
with no return statement. But I am happy with this choice. Even with
as many warning on as I can find (my preference during development) gcc
does not complain about either, and the code does exactly what I want.
I note from another part of the thread that your bcc would most likely
reject my program.
> But in this group, so many people have argued that black is white, or vice
> versa, that nothing surprises me any more.
No one is doing that. C is what it is, but you get frustrated when
people don't join you in wailing and gnashing of teeth.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-02 15:08 -0700 |
| Message-ID | <87bkek6xet.fsf@nosuchdomain.example.com> |
| In reply to | #173685 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> Curiously, I wrote a similar function two days ago. I had a table of
> function pointers and I wanted a "nothing here" value I could store and
> test for. Rather than use a null function pointer, I chose
>
> void *no_op(int) { exit(error("placeholder called")); }
The missing identifier for the parameter is a constraint violation.
See N1570 6.9.1p5. gcc rejects it with "-std=c11 -pedantic-errors":
c.c:5:13: error: ISO C does not support omitting parameter names in function definitions before C2X [-Wpedantic]
5 | void *no_op(int) { exit(error("placeholder called")); }
C23 relaxes this requirement.
(exit() is declared with _Noreturn, so the lack of a return statement
shouldn't be a problem if a future standard added the rule we're
discussing.)
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-03 02:00 +0100 |
| Message-ID | <87pm30xe83.fsf@bsb.me.uk> |
| In reply to | #173689 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> Curiously, I wrote a similar function two days ago. I had a table of
>> function pointers and I wanted a "nothing here" value I could store and
>> test for. Rather than use a null function pointer, I chose
>>
>> void *no_op(int) { exit(error("placeholder called")); }
>
> The missing identifier for the parameter is a constraint violation.
> See N1570 6.9.1p5. gcc rejects it with "-std=c11 -pedantic-errors":
>
> c.c:5:13: error: ISO C does not support omitting parameter names in function definitions before C2X [-Wpedantic]
> 5 | void *no_op(int) { exit(error("placeholder called")); }
>
> C23 relaxes this requirement.
Yes, and gcc has implemented that with -std=c2x which is what I was
using.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-02 23:18 +0100 |
| Message-ID | <ud0cce$iju4$1@dont-email.me> |
| In reply to | #173685 |
On 02/09/2023 22:42, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 02/09/2023 00:02, Keith Thompson wrote:
>
>>> Now, what was your point, and how does `int fred(void){}` illustrate it?
>>
>> I would have said it's obviously wrong.
>
> Curiously, I wrote a similar function two days ago. I had a table of
> function pointers and I wanted a "nothing here" value I could store and
> test for. Rather than use a null function pointer, I chose
>
> void *no_op(int) { exit(error("placeholder called")); }
>
> so that I'd know if it were accidentally called. It uses /two/ features
> you dislike: unnamed parameters in a function definition, and a body
> with no return statement. But I am happy with this choice. Even with
> as many warning on as I can find (my preference during development) gcc
> does not complain about either, and the code does exactly what I want.
The missing parameter makes it fail on tcc, MSVC, bcc and icc (icx will
warn).
I understand the point about the void* result type needing to match a
set of other functions. But how much of an imposition is it to supply a
'return NULL' line at the end?
Then it doesn't matter what precedes it; that exit line could could be
commented out, it can be changed, or it's to be maintained by someone
else. Or maybe one day, you will populate this function, and forget the
return statement.
I will speculate that the vast majority of value-returning functions in
a code-base, need to return an actual value, and not risk returning
garbage or possibly crash while trying to return.
So it seems irresponsible to me to not report an inadvertent missing
return, just for the minor benefit of avoiding a superfluous return in a
very small minority of cases.
> I note from another part of the thread that your bcc would most likely
> reject my program.
The missing parameter name, yes (although in the revamp, I enabled that
experimentally).
The missing return can be enabled with -old.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-03 02:28 +0100 |
| Message-ID | <87jzt8xcxb.fsf@bsb.me.uk> |
| In reply to | #173690 |
Bart <bc@freeuk.com> writes:
> On 02/09/2023 22:42, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 02/09/2023 00:02, Keith Thompson wrote:
>>
>>>> Now, what was your point, and how does `int fred(void){}` illustrate it?
>>>
>>> I would have said it's obviously wrong.
>> Curiously, I wrote a similar function two days ago. I had a table of
>> function pointers and I wanted a "nothing here" value I could store and
>> test for. Rather than use a null function pointer, I chose
>> void *no_op(int) { exit(error("placeholder called")); }
>> so that I'd know if it were accidentally called. It uses /two/ features
>> you dislike: unnamed parameters in a function definition, and a body
>> with no return statement. But I am happy with this choice. Even with
>> as many warning on as I can find (my preference during development) gcc
>> does not complain about either, and the code does exactly what I want.
>
> The missing parameter makes it fail on tcc, MSVC, bcc and icc (icx will
> warn).
Maybe they will all catch up. I used gcc -std=c2x.
> I understand the point about the void* result type needing to match a set
> of other functions.
No, void * is the actual type I wanted. It was not being used as a
point "to any object". Mind you, the return has nothing to do with the
point of the post.
> But how much of an imposition is it to supply a 'return
> NULL' line at the end?
Not much, but why should I add pointless junk?
> Then it doesn't matter what precedes it; that exit line could could be
> commented out, it can be changed, or it's to be maintained by someone
> else.
And then the function would be incorrect. The exit (with a message
output by the error function) is there for a purpose. If I (or someone
else) were to comment it out (by accident, presumably) I /want/ a
warning from gcc that the function won't return a value. If I follow
your advice, nothing will alert me that I've commented out the key part
of the function.
> Or maybe one day, you will populate this function, and forget the
> return statement.
Of course I won't. It's a "sentinel" used to say "nothing here" with
the added advantage that if it gets called because of some bug, I'll
know about it. As I said, I could have used a null pointer (and I'd
still get to know about a mistaken call because of a "crash"), but my
message will tell me more, sooner.
>> I note from another part of the thread that your bcc would most likely
>> reject my program.
>
> The missing parameter name, yes (although in the revamp, I enabled that
> experimentally).
>
> The missing return can be enabled with -old.
Ironic, since the code is targeted at C23!
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-03 06:58 +0000 |
| Message-ID | <20230902235645.588@kylheku.com> |
| In reply to | #173697 |
On 2023-09-03, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > Bart <bc@freeuk.com> writes: >> The missing parameter makes it fail on tcc, MSVC, bcc and icc (icx will >> warn). > > Maybe they will all catch up. I used gcc -std=c2x. Which is what "gcc" alone would be if it followed Bart's recommendation that a compiler should use the current language by default. People would write code with missing function parameter names and it would work fine, until they tried to port it.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-03 15:52 +0100 |
| Message-ID | <87wmx7wbql.fsf@bsb.me.uk> |
| In reply to | #173726 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: > On 2023-09-03, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >> Bart <bc@freeuk.com> writes: >>> The missing parameter makes it fail on tcc, MSVC, bcc and icc (icx will >>> warn). >> >> Maybe they will all catch up. I used gcc -std=c2x. > > Which is what "gcc" alone would be if it followed Bart's recommendation > that a compiler should use the current language by default. Apart from some debate about what constitutes the "current language". Does something not yet fully implemented (or even not yet published) count? > People would write code with missing function parameter names and it > would work fine, until they tried to port it. But that's pretty much always true if you call a C compiler with no options. It would not matter if gcc followed Bart's recommendation or if it did what it does now -- code accepted by a naked gcc command is not going to be portable. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-03 11:02 +0100 |
| Message-ID | <ud1lkb$s793$1@dont-email.me> |
| In reply to | #173697 |
On 03/09/2023 02:28, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> On 02/09/2023 22:42, Ben Bacarisse wrote: >>> Bart <bc@freeuk.com> writes: >> I understand the point about the void* result type needing to match a set >> of other functions. > > No, void * is the actual type I wanted. It was not being used as a > point "to any object". Mind you, the return has nothing to do with the > point of the post. Then I /don't/ understand. Why not just make it a 'void' function? I had assumed the address of no_op was used in a table of function pointers sharing a void* return type. >> But how much of an imposition is it to supply a 'return >> NULL' line at the end? > > Not much, but why should I add pointless junk? And yet, some people are happy to add attributes like _Noreturn. Some are also happy to write 'i' three times in a simple for-header. /You/ are even happy to write a return type that doesn't correspond to the function body. >> Then it doesn't matter what precedes it; that exit line could could be >> commented out, it can be changed, or it's to be maintained by someone >> else. > > And then the function would be incorrect. The exit (with a message > output by the error function) is there for a purpose. If I (or someone > else) were to comment it out (by accident, presumably) I /want/ a > warning from gcc that the function won't return a value. This is what I've complained that it doesn't do. > If I follow > your advice, nothing will alert me that I've commented out the key part > of the function. I can't win this can I? Obviously if you comment out swathes of code, the behaviour will change. But in this case, that is not the issue, as it will silently invoke undefined behaviour. This affects the integrity of the underlying code. For most targets, the likelihood is that a garbage value is returned. That is undesirable.
[toc] | [prev] | [next] | [standalone]
Page 16 of 18 — ← Prev page 1 … 14 15 [16] 17 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web