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 6 of 18 — ← Prev page 1 … 4 5 [6] 7 8 … 18 Next page →
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-04 21:56 +0000 |
| Message-ID | <20230904145249.15@kylheku.com> |
| In reply to | #173907 |
On 2023-09-04, Bart <bc@freeuk.com> wrote: > On 04/09/2023 20:48, Ben Bacarisse wrote: >> Kaz Kylheku <864-117-4973@kylheku.com> writes: >> >>> On 2023-09-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >>>> For a long while I went along with the idea that "C" can mean many >>>> things, but that's not how Bart uses the term. In fact, that's one of >>>> his big whinging topics -- C is what you care to make it. So I changed >>>> my usage and posted the remark above. He found it worthy of mockery, >>>> but did not want me to respond. Go figure. >>> >>> C is a language family, like Lisp. Some people mean "Clojure" >>> when they are sayhing Lisp, some mean "Racket" or "Emacs Lisp". >> >> Yes. > > Examples of versions of the C family which have their own identities? > > I think it's clear we're not talking about distinct languages like > Objective-C or C++. Mostly dialects. > If you're going to include those, then you're clutching at straws. There is no reason to exclude those. You can meaningfully write C that also compiles as C++ or Objective C. My TXR project is ostensibly written in C, but you can ./configure cc=g++ and it works. I mostly don't work that way, but at least I check it for regressions before releases. From time to time it catches something. Objective C is highly compatible with C due to introducing extensions with @. GNU Awk does that (it has @include); it's still considered Awk. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you're posting from Google Groups, I don't see you!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-05 01:34 +0100 |
| Message-ID | <87ledlsbiq.fsf@bsb.me.uk> |
| In reply to | #173907 |
Bart <bc@freeuk.com> writes: > On 04/09/2023 20:48, Ben Bacarisse wrote: >> Kaz Kylheku <864-117-4973@kylheku.com> writes: >> >>> On 2023-09-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >>>> For a long while I went along with the idea that "C" can mean many >>>> things, but that's not how Bart uses the term. In fact, that's one of >>>> his big whinging topics -- C is what you care to make it. So I changed >>>> my usage and posted the remark above. He found it worthy of mockery, >>>> but did not want me to respond. Go figure. >>> >>> C is a language family, like Lisp. Some people mean "Clojure" >>> when they are sayhing Lisp, some mean "Racket" or "Emacs Lisp". >> Yes. > > Examples of versions of the C family which have their own identities? Do you mean things like ISO/IEC 9899:2017? In general, people tend to make up their own informal names for the close members of the family. If you want to know what gcc calls them look at the -std=xxx options. > I think it's clear we're not talking about distinct languages like > Objective-C or C++. In fact, I was talking about languages like Fortran and Go when I said gcc was not a C compiler. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-04 21:06 +0100 |
| Message-ID | <ud5db8$1k2dj$1@dont-email.me> |
| In reply to | #173903 |
On 04/09/2023 20:17, Kaz Kylheku wrote:
> On 2023-09-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> For a long while I went along with the idea that "C" can mean many
>> things, but that's not how Bart uses the term. In fact, that's one of
>> his big whinging topics -- C is what you care to make it. So I changed
>> my usage and posted the remark above. He found it worthy of mockery,
>> but did not want me to respond. Go figure.
>
> C is a language family, like Lisp. Some people mean "Clojure"
> when they are sayhing Lisp, some mean "Racket" or "Emacs Lisp".
But there is still one current C standard, and one current set of
standard headers?
>
> Bart will just have to be patiently educated in the differences among:
>
> - language family
> - language dialect
> - language standard
> - language implementation
> - language reference manual
Sure, how much more complicated do you want to make it?
But while you're here, perhaps you can tell me which of those myriad Cs
is being compiled in each case here:
gcc prog.c
clang prog.c
tcc lang.c
msvc lang.c
zig cc lang.c
lcc lang.c
pellesc lang.c (I forget the actual compiler name)
None of those likes to be verbose so it's rather a mystery what exactly
they are doing.
All I know is that the family/dialect/standard in each case doesn't care
amount making a missing 'return <value>' a hard error. So else are they
being being lax over?
Do I have to to specify -Werror=xxx 173 times for all the possible
things that ought to sensibly be hard errors?
BTW apparently 'gcc' is not a C compiler. That's both an interesting and
useless bit of information. What is means is that 'gcc.exe' invokes
programs like 'cc.exe', 'as.exe' and 'ld.exe', when presented with a -xc
option or a .c file extension, but people, in a C context, colloquially
refer to 'gcc' as a C compiler.
I think you guys just want to keep things a mystery!
Despite all the smoke and mirrors you want to apply, I seem to remember
a few weeks ago taking a project called libjpeg, and successfully
compiling the C modules it comprised with both 'gcc' and 'bcc' programs,
without any specific dialect options (I might have needed to dumb down
bcc with -old).
So, what language is libjpeg written in? If I look at the Wikipedia
entry for it, it says:
Written in: C
Same with Gzip. Same with CPython.
But, but, there IS no single language called C, right? In the case of
libjpeg, it used also a generic jconfig.h file.
So what's going on? Just trying to bamboozle people? Cut them down to
size? Carry on doing that, and I'll carry on trying to cut all the bullshit.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-04 13:09 -0700 |
| Message-ID | <ud5dif$1k2eb$1@dont-email.me> |
| In reply to | #173905 |
On 9/4/2023 1:06 PM, Bart wrote: > On 04/09/2023 20:17, Kaz Kylheku wrote: >> On 2023-09-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >>> For a long while I went along with the idea that "C" can mean many >>> things, but that's not how Bart uses the term. In fact, that's one of >>> his big whinging topics -- C is what you care to make it. So I changed >>> my usage and posted the remark above. He found it worthy of mockery, >>> but did not want me to respond. Go figure. >> >> C is a language family, like Lisp. Some people mean "Clojure" >> when they are sayhing Lisp, some mean "Racket" or "Emacs Lisp". > > But there is still one current C standard, and one current set of > standard headers? > >> >> Bart will just have to be patiently educated in the differences among: >> >> - language family >> - language dialect >> - language standard >> - language implementation >> - language reference manual > > > Sure, how much more complicated do you want to make it? > > But while you're here, perhaps you can tell me which of those myriad Cs > is being compiled in each case here: > > gcc prog.c > clang prog.c > tcc lang.c > msvc lang.c > zig cc lang.c > lcc lang.c > pellesc lang.c (I forget the actual compiler name) Fwiw, its nice to be able to have one code base that compiles in all of those compilers. I cannot remember trying zig. But I do remember you helping me port one of my programs to most of those compilers. :^) Fwiw, here is a crude version of it online: http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=a3e49ce5df3d492b288b19cc079741fb777535e907b116efa4d06849a4d5d27889712b21995097e47304946224a5d66dbd3cd337e28e3ce1927aedb177eca3aaa468d80e3e9e2883dfe0e60d1a13f2957514ab2c5c Using the "default secret key" so everybody can read it. :^) [...]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-04 16:04 -0700 |
| Message-ID | <878r9l5ym0.fsf@nosuchdomain.example.com> |
| In reply to | #173905 |
Bart <bc@freeuk.com> writes:
[...]
> All I know is that the family/dialect/standard in each case doesn't
> care amount making a missing 'return <value>' a hard error. So else
> are they being being lax over?
I have what I think is a very simple question for you. Will you
acknowledge that the ISO C standard does not require a diagnostic
for a missing return statement in a non-void function?
I'm asking you for nothing more than a "yes" or "no" answer. You can
of course follow that with anything you like, but a "yes" or "no"
would be helpful -- or a brief explanation of why you think neither
"yes" nor "no" is a meaningful answer.
[...]
> I think you guys just want to keep things a mystery!
If I had wanted to keep things a mystery, I wouldn't have spent
a great deal of time explaning things, even after it became clear
that my explanations were falling on deaf ears.
[...]
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-05 00:52 +0100 |
| Message-ID | <ud5qka$1lrm2$1@dont-email.me> |
| In reply to | #173916 |
On 05/09/2023 00:04, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [...] >> All I know is that the family/dialect/standard in each case doesn't >> care amount making a missing 'return <value>' a hard error. So else >> are they being being lax over? > > I have what I think is a very simple question for you. Will you > acknowledge that the ISO C standard does not require a diagnostic > for a missing return statement in a non-void function? > > I'm asking you for nothing more than a "yes" or "no" answer. You can > of course follow that with anything you like, but a "yes" or "no" > would be helpful -- or a brief explanation of why you think neither > "yes" nor "no" is a meaningful answer. > > [...] > >> I think you guys just want to keep things a mystery! > > If I had wanted to keep things a mystery, I wouldn't have spent > a great deal of time explaning things, even after it became clear > that my explanations were falling on deaf ears. You may be right. I think I've become over-saturated with talk of C versions and C compilers (and non-compilers) and people's obsession with trying to muddy things in order to trip me up. You can imagine that recent discussions and newly discovered attitudes have not done much for my appreciation of ... whatever the hell 'C' actually is (right now I have no idea), and its whole ecosystem of maybe-compilers and other tools. I have had enough (I guess you all have too). However there two tools I need to maintain for the time being: * The revised backend of my C-subset compiler, which I'm doing largely for my own satisfaction since I have my own standards to meet * The transpiler necessary to turn that C-subset compiler, written in a large subset of my language, into the same C-subset. If nothing else, it will be able to at least self-host, sort of. Then I can be free of all this nonsense! Back to sanity.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-04 17:16 -0700 |
| Message-ID | <874jk95vaz.fsf@nosuchdomain.example.com> |
| In reply to | #173918 |
Bart <bc@freeuk.com> writes:
> On 05/09/2023 00:04, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> All I know is that the family/dialect/standard in each case doesn't
>>> care amount making a missing 'return <value>' a hard error. So else
>>> are they being being lax over?
>> I have what I think is a very simple question for you. Will you
>> acknowledge that the ISO C standard does not require a diagnostic
>> for a missing return statement in a non-void function?
>> I'm asking you for nothing more than a "yes" or "no" answer. You
>> can
>> of course follow that with anything you like, but a "yes" or "no"
>> would be helpful -- or a brief explanation of why you think neither
>> "yes" nor "no" is a meaningful answer.
>> [...]
I note your refusal to answer this simple question. I asked it
because I believe that any discussion of the merits or demerits of
either C or the ISO C standard should begin with an understanding
of what the standard says.
If you change your mind and decide to post a "yes" or "no" answer
(or an explanation of why neither answer would be meaningful),
I might be willing to continue the discussion.
If not, I am done with you, and barring unforeseen circumstances
this will be my last reply to anything you write here, except that
I *might* reply to misstatements of fact that I think are likely to
mislead others. (In the unlikely event that you wish to contact me,
the email address on this post is valid and will reach me.)
Others will do as they see fit. I'm sure many people here will be
relieved if I stop engaging with you.
[...]
> I think I've become over-saturated with talk of C versions and C
> compilers (and non-compilers) and people's obsession with trying to
> muddy things in order to trip me up.
Nobody has done that.
> You can imagine that recent discussions and newly discovered attitudes
> have not done much for my appreciation of ... whatever the hell 'C'
> actually is (right now I have no idea), and its whole ecosystem of
> maybe-compilers and other tools.
One person has expressed the opinion that "C" doesn't mean "ISO C".
You've probably seen my reply, so I won't repeat it here. If one
person expressing an opinion causes you such confusion, I can't
help you.
[...]
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-05 15:33 +0100 |
| Message-ID | <ud7e75$20tag$1@dont-email.me> |
| In reply to | #173919 |
On 05/09/2023 01:16, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 05/09/2023 00:04, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> All I know is that the family/dialect/standard in each case doesn't
>>>> care amount making a missing 'return <value>' a hard error. So else
>>>> are they being being lax over?
>>> I have what I think is a very simple question for you. Will you
>>> acknowledge that the ISO C standard does not require a diagnostic
>>> for a missing return statement in a non-void function?
>>> I'm asking you for nothing more than a "yes" or "no" answer. You
>>> can
>>> of course follow that with anything you like, but a "yes" or "no"
>>> would be helpful -- or a brief explanation of why you think neither
>>> "yes" nor "no" is a meaningful answer.
>>> [...]
>
> I note your refusal to answer this simple question.
If you mean this:
> Will you
acknowledge that the ISO C standard does not require a diagnostic
for a missing return statement in a non-void function?
Then I don't know. I will have to take somebody's word for it. You seem
to be implying the answer is Yes, so Yes.
In my revised C compiler, I've taken out the -old option (it is now the
default), and no longer bother to the extra check for a solid return
value from a non-void function. Since nobody else cares, I'm not going
to either, and you are now saying I can do that.
(I may, however, need to insert an all-zeros return value in the
generated code, since the IR is stack-based and that becomes more critical.)
But both of the following are still hard errors:
int fred(void) {return;}
void bill(void) {return 1;}
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-05 14:55 +0000 |
| Message-ID | <gjHJM.660199$U3w1.313689@fx09.iad> |
| In reply to | #173999 |
Bart <bc@freeuk.com> writes: >On 05/09/2023 01:16, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >>> On 05/09/2023 00:04, Keith Thompson wrote: >>>> Bart <bc@freeuk.com> writes: >>>> [...] >>>>> All I know is that the family/dialect/standard in each case doesn't >>>>> care amount making a missing 'return <value>' a hard error. So else >>>>> are they being being lax over? >>>> I have what I think is a very simple question for you. Will you >>>> acknowledge that the ISO C standard does not require a diagnostic >>>> for a missing return statement in a non-void function? >>>> I'm asking you for nothing more than a "yes" or "no" answer. You >>>> can >>>> of course follow that with anything you like, but a "yes" or "no" >>>> would be helpful -- or a brief explanation of why you think neither >>>> "yes" nor "no" is a meaningful answer. >>>> [...] >> >> I note your refusal to answer this simple question. > >If you mean this: > > > Will you >acknowledge that the ISO C standard does not require a diagnostic >for a missing return statement in a non-void function? > >Then I don't know. You can download and read the document to alleviate your ignorance.
[toc] | [prev] | [next] | [standalone]
| From | Bobby Moore <bobbymoore018@gmail.com> |
|---|---|
| Date | 2023-09-05 08:30 -0700 |
| Message-ID | <b7a1aa95-3ad1-49be-9cd0-8f9194e2f616n@googlegroups.com> |
| In reply to | #174000 |
https://methamphetaminebox.com/ https://methamphetaminebox.com/product/buy-dmt-5ml-deadhead-chemist-cartridge/ https://methamphetaminebox.com/product/buy-schwifty-labs-1ml-dmt-cartridge/ https://methamphetaminebox.com/product/buy-schwifty-labs-1ml-5-meo-dmt-cartridge/ https://methamphetaminebox.com/product/buy-schwifty-labs-5ml-dmt-cartridge/ https://methamphetaminebox.com/product/buy-schwifty-labs-5-ml-5-meo-dmt-cartridge/ https://methamphetaminebox.com/product/buy-purecybin-1ml-700mg-dmt-carts/ https://methamphetaminebox.com/product/buy-puff-boyz-nn-dmt-5ml400mg-wild-apple-carts/ https://methamphetaminebox.com/product/buy-puff-boyz-nn-dmt-5ml400mg-wild-apple-carts/ https://methamphetaminebox.com/product/buy-crystal-meth-online/ https://methamphetaminebox.com/product/buy-4-fa-powder-online/ https://methamphetaminebox.com/product/buy-25i-nbome-powder-legally/ https://methamphetaminebox.com/product/a-pvp-crystals-for-sale/ https://methamphetaminebox.com/product/buy-alprazolam-powder-updated-2023/ https://methamphetaminebox.com/product/buy-alprazolam-powder-updated-2023/ https://methamphetaminebox.com/product/buy-dmt-crystal-online/ https://methamphetaminebox.com/product/buy-diclazepam-online/
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-05 17:31 +0200 |
| Message-ID | <ud7hkm$21ds7$1@dont-email.me> |
| In reply to | #173999 |
On 05/09/2023 16:33, Bart wrote:
> On 05/09/2023 01:16, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 05/09/2023 00:04, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>> [...]
>>>>> All I know is that the family/dialect/standard in each case doesn't
>>>>> care amount making a missing 'return <value>' a hard error. So else
>>>>> are they being being lax over?
>>>> I have what I think is a very simple question for you. Will you
>>>> acknowledge that the ISO C standard does not require a diagnostic
>>>> for a missing return statement in a non-void function?
>>>> I'm asking you for nothing more than a "yes" or "no" answer. You
>>>> can
>>>> of course follow that with anything you like, but a "yes" or "no"
>>>> would be helpful -- or a brief explanation of why you think neither
>>>> "yes" nor "no" is a meaningful answer.
>>>> [...]
>>
>> I note your refusal to answer this simple question.
>
> If you mean this:
>
> > Will you
> acknowledge that the ISO C standard does not require a diagnostic
> for a missing return statement in a non-void function?
>
> Then I don't know. I will have to take somebody's word for it. You seem
> to be implying the answer is Yes, so Yes.
Is there some reason that you won't look at the standard here? There
are parts of the C standards that are a bit difficult to read, but
surely you are able to read enough to determine the answer for yourself?
Certainly /I/ would be happier to hear that you have looked at the
standards document yourself and understood it. No one wants you just to
take their word for it - after all, you believe very little of things
other people write, and twist much of it to fit your paranoia and confusion.
>
> In my revised C compiler, I've taken out the -old option (it is now the
> default), and no longer bother to the extra check for a solid return
> value from a non-void function. Since nobody else cares, I'm not going
> to either, and you are now saying I can do that.
>
> (I may, however, need to insert an all-zeros return value in the
> generated code, since the IR is stack-based and that becomes more
> critical.)
>
> But both of the following are still hard errors:
>
> int fred(void) {return;}
> void bill(void) {return 1;}
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-05 18:06 +0100 |
| Message-ID | <ud7n60$22dof$1@dont-email.me> |
| In reply to | #174005 |
On 05/09/2023 16:31, David Brown wrote
BC:
>> If you mean this:
>>
>> > Will you
>> acknowledge that the ISO C standard does not require a diagnostic
>> for a missing return statement in a non-void function?
>>
>> Then I don't know. I will have to take somebody's word for it. You
>> seem to be implying the answer is Yes, so Yes.
>
> Is there some reason that you won't look at the standard here?
Yes, it's like someone asking me to check the Bible to see for myself
whether it mentions something or not. But it's quite a big book, and
maybe I'd have to collate slightly different quites in different places.
And maybe I'd end up looking in the wrong place.
> There
> are parts of the C standards that are a bit difficult to read, but
> surely you are able to read enough to determine the answer for yourself?
> Certainly /I/ would be happier to hear that you have looked at the
> standards document yourself and understood it.
The standard wouldn't be enough. I'd need to know the reasons behind why
it says what it says.
If it is more lax than I would like, is that because it it had to
reflect widespread disregard in the existing range of compilers, rather
than what would be a preferable and safer guidance?
And if it is more strict about something I don't consider important, how
seriously should I have to take it?
Because I don't believe in warnings on a routine compilation, I need to
consider carefully whether something should be failed. I like to base
that also on the extensive experience I have with my own languages.
We need to end up with practical, useful tools.
Take this bit of code:
int* p;
double* q;
p = q;
These pointers are not compatible. Now for many years, my own language
ignored that fact, after all these are just addresses. Until I spent 6
hours tracking down a bug caused by such a mismatch.
Now it is a hard error in my language, and in my C compiler.
Not in most compilers however. Should I need to look at the C standard
for guidance? Honestly, I don't care what it says about it. That's the
same document that tells me I can't use an EXPLICIT CAST to convert an
address from a function type to object type or some thing (but two
nested casts are fine!).
Presumably, since compilers don't normally fail this, it's not going to
care what they do. Either it's going say a diagnostic is not required,
or one is, but it's not going to say it needs to be a fatal one (what
/should/ be fatal according to the C standard?).
So common sense plays a bigger role here. In my compiler you have to do
one of:
p = (int*)q;
p = (void*)q;
At least it will until forced to relax that because there is so much bad
code about due to decades of lax compilers.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-05 17:54 +0000 |
| Message-ID | <20230905101716.895@kylheku.com> |
| In reply to | #174015 |
On 2023-09-05, Bart <bc@freeuk.com> wrote: > The standard wouldn't be enough. I'd need to know the reasons behind why > it says what it says. When the first C standard was ratified in 1989, the committee wrote a Rationale. If you google for "ANSI C Rationale" you can find it. There are footnotes in every revision in the standard which sometimes give clarifications that constitute rationalee. > If it is more lax than I would like, is that because it it had to > reflect widespread disregard in the existing range of compilers, rather > than what would be a preferable and safer guidance? > > And if it is more strict about something I don't consider important, how > seriously should I have to take it? In that case, you can emulate the thinking of Richard Stallman and GNU. In the GNU Coding Standards, there are passages about external sstandards: https://www.gnu.org/prep/standards/ "The GNU Project regards standards published by other organizations as suggestions, not orders. We consider those standards, but we do not “obey” them. In developing a GNU program, you should implement an outside standard’s specifications when that makes the GNU system better overall in an objective sense. When it doesn’t, you shouldn’t. [ ... snip ... ] For instance, Standard C says that nearly all extensions to C are prohibited. How silly! GCC implements many extensions, some of which were later adopted as part of the standard. If you want these constructs to give an error message as “required” by the standard, you must specify ‘--pedantic’, which was implemented only so that we can say “GCC is a 100% implementation of the standard”, not because there is any reason to actually use it." I don't agree with everything in the second paragraph, but it gives you a flavor for why GCC is the way it is, and why it accepts the GNU C dialect by default, in which syntax that is invalid ISO C has a meaning and is accepted silently. When they say there is no reason to use --pedantic, they are saying there is no reason to use any compiler other than GCC, and therefore no reason to diagnose whether your code has nonportable GCC-only features. > Because I don't believe in warnings on a routine compilation, I need to > consider carefully whether something should be failed. I like to base > that also on the extensive experience I have with my own languages. > > We need to end up with practical, useful tools. > > Take this bit of code: > > int* p; > double* q; > > p = q; > > These pointers are not compatible. Now for many years, my own language > ignored that fact, after all these are just addresses. Until I spent 6 > hours tracking down a bug caused by such a mismatch. Right? So at least a warning diagnostic is useful. The ISO C standard doesn't distinguis warning and error diagnostics. It specifies only diagnostics. If a program requires an diagnostic by ISO C, the implementation may also stop translating it. If it is translated anyway, it has undefined behavior. GCC warns about a conversion between unlike pointers without a cast; if a cast is used, then there is no diagnostic. > Now it is a hard error in my language, and in my C compiler. Like with gcc -Werror=incompatible-pointer-types. To the astute developer compiling programs locally, there is no difference; that developer takes warnings seriously. In large team projects, you can get sloppy programmers who don't pay attention to warnings. Code is submitted to some review system which builds the code. Reviewers typically don't look at the build log, only at the code and the fact that the build passed. (Code built, unit tests went "green"). So it's easy for warnings to go unnoticed. > Not in most compilers however. Should I need to look at the C standard > for guidance? Honestly, I don't care what it says about it. The right attitude is to care about the bug first. But what the standard says about it is important for conformance. > That's the > same document that tells me I can't use an EXPLICIT CAST to convert an > address from a function type to object type or some thing (but two > nested casts are fine!). This is explicitly acknowledged as a common extension in an Appendix! It is not disallowed; no diagnostic is required for a program which performs that conversion with a cast. It is undefined behavior. If your compiler cannot support a certain conversion (like say that for some reason you had had 128 bit function pointers, but 64 bit data pointers), then it would make sense for it to diagnose that the conversion can't be done. > Presumably, since compilers don't normally fail this, it's not going to > care what they do. Either it's going say a diagnostic is not required, > or one is, but it's not going to say it needs to be a fatal one (what > /should/ be fatal according to the C standard?). Nothing is ever required to be fatal! Some things must be diagnosed, but diagnostics are not required to be fatal. Diagnostics that are required are not required to be distinguishable from custom diagnostics developed by the implementation. > So common sense plays a bigger role here. In my compiler you have to do > one of: > > p = (int*)q; > p = (void*)q; > > At least it will until forced to relax that because there is so much bad > code about due to decades of lax compilers. Yes, other lax compilers can create pressure for yours to be lax. If someone has a big program with a 1000 instances of a pointer conversion without a cast, which someone else's compiler only warns about, and your compiler bails on the first instance, that goofy user might sadly choose to avoid your compiler than fix their code. In general, many people working with C are not familiar with the standard. Then there are those that are, and abhor the idea that a program compiles if it converts between pointers without a cast. You can see why GCC is flexible about picking and choosing diagnostics, and whether they are fatal. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you're posting from Google Groups, I don't see you!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-05 20:10 +0200 |
| Message-ID | <ud7qto$22uso$1@dont-email.me> |
| In reply to | #174015 |
On 05/09/2023 19:06, Bart wrote: > On 05/09/2023 16:31, David Brown wrote > > BC: >>> If you mean this: >>> >>> > Will you >>> acknowledge that the ISO C standard does not require a diagnostic >>> for a missing return statement in a non-void function? >>> >>> Then I don't know. I will have to take somebody's word for it. You >>> seem to be implying the answer is Yes, so Yes. >> >> Is there some reason that you won't look at the standard here? > > Yes, it's like someone asking me to check the Bible to see for myself > whether it mentions something or not. But it's quite a big book, and > maybe I'd have to collate slightly different quites in different places. > And maybe I'd end up looking in the wrong place. > I regularly give you references in the C standard, so that you don't need to figure out where to look. But do you ever use these references? Have you ever looked at the C standards (any version) ? For that matter, have you ever looked at a Bible - clearly you've skipped at least one of these. Read "6.8.6.4 The return statement" and "6.9.1 Function definitions". No more pathetic excuses. > >> There are parts of the C standards that are a bit difficult to read, >> but surely you are able to read enough to determine the answer for >> yourself? Certainly /I/ would be happier to hear that you have >> looked at the standards document yourself and understood it. > > The standard wouldn't be enough. I'd need to know the reasons behind why > it says what it says. Start with the standard, and let's go from there. Learn what it says, then ask why, then listen when people tell you. And stick to one thing at a time. Two thoughts on the same day appear to be beyond you, and we don't want you to get confused again.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-05 20:57 +0100 |
| Message-ID | <ud816v$23vpc$1@dont-email.me> |
| In reply to | #174027 |
On 05/09/2023 19:10, David Brown wrote:
> On 05/09/2023 19:06, Bart wrote:
>> On 05/09/2023 16:31, David Brown wrote
>>
>> BC:
>>>> If you mean this:
>>>>
>>>> > Will you
>>>> acknowledge that the ISO C standard does not require a diagnostic
>>>> for a missing return statement in a non-void function?
>>>>
>>>> Then I don't know. I will have to take somebody's word for it. You
>>>> seem to be implying the answer is Yes, so Yes.
>>>
>>> Is there some reason that you won't look at the standard here?
>>
>> Yes, it's like someone asking me to check the Bible to see for myself
>> whether it mentions something or not. But it's quite a big book, and
>> maybe I'd have to collate slightly different quites in different
>> places. And maybe I'd end up looking in the wrong place.
>>
>
> I regularly give you references in the C standard, so that you don't
> need to figure out where to look. But do you ever use these references?
>
> Have you ever looked at the C standards (any version) ? For that
> matter, have you ever looked at a Bible - clearly you've skipped at
> least one of these.
Admired it, yes. I have a huge edition printed in 1792.
>
> Read "6.8.6.4 The return statement"
6.8.6.4p1 says:
"1 A return statement with an expression shall not appear in a function
whose return type is void. A return statement without an expression
shall only appear in a function whose return type is void."
Aren't these the exact same examples that I recently posted? I already
said I fail those. Although looking at that wording, it is quite
confusing. It appears to say this:
Void func Non-void func
return expr; Not allowed (1)
return; Only here (2)
It doesn't say anything about Non-void functions, so we have to draw
inferences: presumably (1) must be 'Only here', and (2) must be 'Not
allowed'. So:
(Proc) (Func) (My terms)
Void func Non-void func
return expr; N Y
return; Y N
A bit clearer, yes? Maybe /I/ should be writing it! I already implement
these because they are common sense, but the question was, what should a
compiler do about infringements.
This paragraph calls them Constraints, as presumably they can't be
expressed via syntax.
I guess some other sections explains how those are handled.
> and "6.9.1 Function definitions". No
> more pathetic excuses.
>
>
>>
>>> There are parts of the C standards that are a bit difficult to
>>> read, but surely you are able to read enough to determine the answer
>>> for yourself? Certainly /I/ would be happier to hear that you have
>>> looked at the standards document yourself and understood it.
>>
>> The standard wouldn't be enough. I'd need to know the reasons behind
>> why it says what it says.
>
> Start with the standard, and let's go from there. Learn what it says,
> then ask why, then listen when people tell you.
You sound like a Jehovah's Witness.
> And stick to one thing at a time. Two thoughts on the same day appear
> to be beyond you, and we don't want you to get confused again.
Yeah, well I'm busy actually implementing C at the moment.
It would help if you weren't so bloody patronising.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-05 22:37 +0200 |
| Message-ID | <ud83iu$24b2d$1@dont-email.me> |
| In reply to | #174041 |
On 05/09/2023 21:57, Bart wrote: > On 05/09/2023 19:10, David Brown wrote: >> On 05/09/2023 19:06, Bart wrote: >>> On 05/09/2023 16:31, David Brown wrote >>> >>> BC: >>>>> If you mean this: >>>>> >>>>> > Will you >>>>> acknowledge that the ISO C standard does not require a diagnostic >>>>> for a missing return statement in a non-void function? >>>>> >>>>> Then I don't know. I will have to take somebody's word for it. You >>>>> seem to be implying the answer is Yes, so Yes. >>>> >>>> Is there some reason that you won't look at the standard here? >>> >>> Yes, it's like someone asking me to check the Bible to see for myself >>> whether it mentions something or not. But it's quite a big book, and >>> maybe I'd have to collate slightly different quites in different >>> places. And maybe I'd end up looking in the wrong place. >>> >> >> I regularly give you references in the C standard, so that you don't >> need to figure out where to look. But do you ever use these references? >> >> Have you ever looked at the C standards (any version) ? For that >> matter, have you ever looked at a Bible - clearly you've skipped at >> least one of these. > > Admired it, yes. I have a huge edition printed in 1792. > >> >> Read "6.8.6.4 The return statement" > > 6.8.6.4p1 says: > > "1 A return statement with an expression shall not appear in a function > whose return type is void. A return statement without an expression > shall only appear in a function whose return type is void." > > Aren't these the exact same examples that I recently posted? I already > said I fail those. Although looking at that wording, it is quite > confusing. It appears to say this: > > Void func Non-void func > > return expr; Not allowed (1) > > return; Only here (2) > > It doesn't say anything about Non-void functions, so we have to draw > inferences: presumably (1) must be 'Only here', and (2) must be 'Not > allowed'. So: > > (Proc) (Func) (My terms) > Void func Non-void func > > return expr; N Y > > return; Y N > > A bit clearer, yes? Maybe /I/ should be writing it! I already implement > these because they are common sense, but the question was, what should a > compiler do about infringements. > > This paragraph calls them Constraints, as presumably they can't be > expressed via syntax. Yes. (Or at least, the rules are not expressed by the syntax - maybe they could have been, but it seemed easier to express them as constraints.) > > I guess some other sections explains how those are handled. It's all quite clear - you got it. (There are certainly some parts of the standard that are harder to figure out.) Note that it does not say anywhere that you /must/ have a return statement - with or without an expression. It merely says what kind of return statements are allowed. So there is no requirement anywhere here for a function to have a "return <expression>" statement even if the function is non-void. > >> and "6.9.1 Function definitions". No more pathetic excuses. See 6.9.1p12 : "Unless otherwise specified, if the } that terminates a function is reached, and the value of the function call is used by the caller, the behaviour is undefined." Running off the end of a non-void function is only a problem if the the caller tries to use the value. Otherwise it is fine. Bad coding practice, perhaps, and worthy of a warning message in my opinion, but it is valid C code and a C compiler needs to accept it (optionally with a warning message) and not reject it. >> >> >>> >>>> There are parts of the C standards that are a bit difficult to >>>> read, but surely you are able to read enough to determine the answer >>>> for yourself? Certainly /I/ would be happier to hear that you have >>>> looked at the standards document yourself and understood it. >>> >>> The standard wouldn't be enough. I'd need to know the reasons behind >>> why it says what it says. >> >> Start with the standard, and let's go from there. Learn what it says, >> then ask why, then listen when people tell you. > > You sound like a Jehovah's Witness. The difference is, the C standard is real. Once you know what it says here, so you understand how the language is defined, /then/ it makes sense to ask /why/ it is defined that way. (And I quite appreciate that you want to know why - I too like to know the reasons behind decisions.) > >> And stick to one thing at a time. Two thoughts on the same day appear >> to be beyond you, and we don't want you to get confused again. > > Yeah, well I'm busy actually implementing C at the moment. Well, I'm glad you have now found a copy of one of the C standards (which one?), and are starting to show an interest in finding out how the language is defined. It will make it much easier to write a C implementation. > > It would help if you weren't so bloody patronising. If you think I am patronising, it is because you act like a small child. Grow up, stop whining, drop the paranoia, ask sensible questions, pay attention to the answers, and answer the questions you are given. It will make things a lot easier, and you'll learn much more.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-05 22:05 +0100 |
| Message-ID | <ud855t$24iki$1@dont-email.me> |
| In reply to | #174042 |
On 05/09/2023 21:37, David Brown wrote:
> On 05/09/2023 21:57, Bart wrote:
>> 6.8.6.4p1 says:
>> It doesn't say anything about Non-void functions, so we have to draw
>> inferences: presumably (1) must be 'Only here', and (2) must be 'Not
>> allowed'. So:
>>
>> (Proc) (Func) (My terms)
>> Void func Non-void func
>>
>> return expr; N Y
>>
>> return; Y N
>>
>> A bit clearer, yes? Maybe /I/ should be writing it! I already
>> implement these because they are common sense, but the question was,
>> what should a compiler do about infringements.
>>
>> This paragraph calls them Constraints, as presumably they can't be
>> expressed via syntax.
>
> Yes. (Or at least, the rules are not expressed by the syntax - maybe
> they could have been, but it seemed easier to express them as constraints.)
>
>>
>> I guess some other sections explains how those are handled.
>
> It's all quite clear - you got it. (There are certainly some parts of
> the standard that are harder to figure out.)
>
> Note that it does not say anywhere that you /must/ have a return
> statement - with or without an expression. It merely says what kind of
> return statements are allowed. So there is no requirement anywhere here
> for a function to have a "return <expression>" statement even if the
> function is non-void.
So my summary was wrong. It is more like this:
(Proc) (Func) (My terms)
Void func Non-void func
return expr; N Optional
return; Optional N
Optional for a procedure is right, since running into the end of the
function is OK because the compiler will ensure there is a 'return' there.
So my main disagreement is with the Optional return of non-void
functions (which I've now given up on), and how seriously infringements
of those 'N' cases are reported.
Because a compiler could also have have ensured that running into the
end of a non-void function sets up a default return value such as all-zeros.
> Running off the end of a non-void function is only a problem if the the
> caller tries to use the value.
Which in general you can't determine, and is incredibly sloppy anyway.
> Otherwise it is fine.
Assuming it doesn't affect the mechanics of how function calls work in
the target. A stack-based target /must/ push some return value,
otherwise it'll interpret some wrong value as the return address.
>> You sound like a Jehovah's Witness.
>
> The difference is, the C standard is real.
They're both written by humans.
> Once you know what it says here, so you understand how the language is
> defined, /then/ it makes sense to ask /why/ it is defined that way. (And
> I quite appreciate that you want to know why - I too like to know the
> reasons behind decisions.)
>
>>
>>> And stick to one thing at a time. Two thoughts on the same day
>>> appear to be beyond you, and we don't want you to get confused again.
>>
>> Yeah, well I'm busy actually implementing C at the moment.
> Well, I'm glad you have now found a copy of one of the C standards
> (which one?), and are starting to show an interest in finding out how
> the language is defined.
You really think I haven't looked at it before?
> It will make it much easier to write a C
> implementation.
99% of the work is nothing to do with the standard. It's a slog. A lot
of it caused by so much diversity in all the C code out there, /because/
people have too much freedom to write what they like.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-05 15:10 -0700 |
| Message-ID | <87il8o46gy.fsf@nosuchdomain.example.com> |
| In reply to | #174047 |
Bart <bc@freeuk.com> writes:
> On 05/09/2023 21:37, David Brown wrote:
>> On 05/09/2023 21:57, Bart wrote:
>>> 6.8.6.4p1 says:
>>> It doesn't say anything about Non-void functions, so we have to
>>> draw inferences: presumably (1) must be 'Only here', and (2) must
>>> be 'Not allowed'. So:
>>>
>>> (Proc) (Func) (My terms)
>>> Void func Non-void func
>>>
>>> return expr; N Y
>>>
>>> return; Y N
I believe that's an accurate summary of 6.8.6.4p1.
[...]
> So my summary was wrong. It is more like this:
>
> (Proc) (Func) (My terms)
> Void func Non-void func
>
> return expr; N Optional
>
> return; Optional N
It's true that a return statement is optional, but it's not 6.8.6.4p1
that says so.
(In fact the standard doesn't *explicitly* say that a return statement
is optional. It follows from the fact that there is no rule requiring a
return statement, and from explicit statements about what happens if the
closing } of a non-void function is reached.)
> Optional for a procedure is right, since running into the end of the
> function is OK because the compiler will ensure there is a 'return'
> there.
>
> So my main disagreement is with the Optional return of non-void
> functions (which I've now given up on), and how seriously
> infringements of those 'N' cases are reported.
At least you *finally* agree about what the standard says. Perhaps now
we can discuss the reasons.
The standard does not require a diagnostic for reaching the closing } of
a non-void function because it's impossible to detect that at compile
time in all cases.
It does not require a diagnostic for a non-void function that doesn't
have a return statement *somewhere* because that would miss a lot of
potential errors (this is my speculation about the reason):
int func(void) {
if (rand() % 2 == 0) return 42;
}
A future edition of the standard *could* require a diagnostic for
a non-void function that can reach the closing } given certain
assumptions. I've quoted the requirement from C# that does this
and suggested that it could be adapted for C. It requires analysis
that most compilers already do for the purpose of optimization and
issuing optional warnings. Someone would have to make a formal
proposal, and it would have to be approved by WG14. It was not
done originally because (I speculate) the required analysis would
have been a significant burden on compilers at the time, and perhaps
nobody thought of it.
Meanwhile, any (conforming) C compiler is free to do that analysis and
issue a non-fatal warning if it can determine that a non-void function
will, or even might, reach its closing }. It can even reject such a
program in a non-conforming mode. gcc and clang can be made to do so
with the right options.
I suppose another possibility would be to require an implicit call to
abort() immediately before the closing } of any non-void function (other
than main()). The call could be optimized away if the compiler can
determine that it's never reached. Such a requirement would not apply
to a freestanding implementation. I haven't decided whether that would
be a good idea or not.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-06 22:32 -0700 |
| Message-ID | <86v8cmmtud.fsf@linuxsc.com> |
| In reply to | #174054 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: [lack of return statements in non-void functions] > A future edition of the standard *could* require a diagnostic for > a non-void function that can reach the closing } given certain > assumptions. I've quoted the requirement from C# that does this > and suggested that it could be adapted for C. [...] The C# rule is not suitable for C because it would require diagnostics for some strictly conforming programs, and no doubt would break a fair amount of existing code even though that code is not strictly conforming. In practical terms the C# rule is not much different from saying return is always required. That's not a good fit to the C language or its culture.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-07 06:49 +0000 |
| Message-ID | <20230906231300.728@kylheku.com> |
| In reply to | #174279 |
On 2023-09-07, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > The C# rule is not suitable for C because it would require > diagnostics for some strictly conforming programs, and no doubt > would break a fair amount of existing code even though that code > is not strictly conforming. In practical terms the C# rule is > not much different from saying return is always required. That's > not a good fit to the C language or its culture. I'm not sure what culture you're referring there? There are coders out there working with compilers which have this sort of diagnostic, but don't bother learning about it an turning it on. I would hope that's just a subculture. Why would it ever be a priority not to disturb that subculture? -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
Page 6 of 18 — ← Prev page 1 … 4 5 [6] 7 8 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web