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 8 of 18 — ← Prev page 1 … 6 7 [8] 9 10 … 18 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-07 22:59 +0100 |
| Message-ID | <uddh4n$34tok$1@dont-email.me> |
| In reply to | #174429 |
On 07/09/2023 22:36, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> I've already suggested a compiler should return all-zeros as a default
>> return value for code that runs into the final '}'. That will provide
>> a consistent return value.
>
> That could mask bugs.
>
> int func(void) {
> if (this) {
> return a_value;
> }
> else if (that) {
> return another_value;
> }
> else if (the_other) {
> return yet_another_value;
> }
> }
>
> Perhaps I simply forgot to write a return statement at the end, either
> before the closing } or in an else clause. Currently, a compiler is not
> required to diagnose this, but many will warn about it with the right
> options. If the language stated that falling off the end implicitly
> returns "all-zeros" (I won't get into what that means), then the behavior
> is well defined and the compiler is unlikely to be able to help.
>
My bcc compiler would report a missing return value on that, unless you
give it the option to pass such code.
In /that/ case, supplying a zero value if the function does actually
fall off the end is preferable. This is exactly what happens with main().
It needn't affect how such things need to be reported.
As for what all-zeros means, it will be something all 0, 0.0 or NULL for
scalar types, and all-bits-zero for small aggregates passed in registers.
For larger aggregates passed in memory, the result of applying
memset(addr, 0, size). But I'm sure you will have guessed this.
(I'm not getting into architectures where ints, floats and pointers have
other representations than all-bits-size for zero or null. Ask the
people who devised them.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-07 16:58 -0700 |
| Message-ID | <87cyyt1qot.fsf@nosuchdomain.example.com> |
| In reply to | #174431 |
Bart <bc@freeuk.com> writes:
[...]
> As for what all-zeros means, it will be something all 0, 0.0 or NULL
> for scalar types, and all-bits-zero for small aggregates passed in
> registers.
>
> For larger aggregates passed in memory, the result of applying
> memset(addr, 0, size). But I'm sure you will have guessed this.
Since I oppose adding a rule to do an implicit return on non-void
functions other than main, I didn't spend much time considering what you
meant by "all-zeros". I'm not surprised that you meant all-bits-zero.
If such a rule were added, "all-zeros" should follow the same rules as
for static objects with no explicit initialization. That means 0 for
integer types, 0.0 for floating-point types, null for pointer types, and
recursively for array, structure, and union types. On many systems,
that happens to be all-bits-zero, which is convenient.
Such a value can be specified as a compound literal: `(return_type){0}`.
(C23 will allow the 0 to be omitted.)
> (I'm not getting into architectures where ints, floats and pointers
> have other representations than all-bits-size for zero or null. Ask
> the people who devised them.)
The C standard must consider such architectures, and it does so by
specifying rules that do not assume the meaning of all-bits-zero (other
than for integer types). It would be silly to add a new requirement for
values implicitly returned from functions that simply specified
all-bits-zero. And again, I oppose any requirement to specify an
implicit return value.
--
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-08 00:35 +0000 |
| Message-ID | <20230907145307.214@kylheku.com> |
| In reply to | #174429 |
On 2023-09-07, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> I've already suggested a compiler should return all-zeros as a default
>> return value for code that runs into the final '}'. That will provide
>> a consistent return value.
>
> That could mask bugs.
If that were an additional step accompanying a well-designed warning, it
would be acceptable. The developer was warned, and the program and its
user are protected from nondeterministic behavior.
> int func(void) {
> if (this) {
> return a_value;
> }
> else if (that) {
> return another_value;
> }
> else if (the_other) {
> return yet_another_value;
> }
> }
But imagine if C had always been like this. Suppose you've been programming
for many years with the backgorund assummption that as soon as you write
an empty function like
int func(void) {
}
you have something that returns zero; you learned it that way from the
start.
Then you're always aware of this and keep it in mind.
"I'm writing various cases that return nonzero, otherwise fall through
to the usual zero."
You might already put a unit test for that empty function before
adding the other cases.
The only reason I might write func as you have it above is not that
I forgot that the function must return a value in all cases, but
that I planned to do that, but got distracted.
With the return zero, I will still have the same thought of planning to
return something in all cases. The difference is that I cannot get
distracted away such that I lose the zero default.
I can get still get distracted in such a way that I forget to write a
few needed cases that must return nonzero.
That problem, however, exists even if I start with this:
int func(void) {
return 0;
}
and then add cases above the return.
I work with Lisp dialect in which there is always a return value,
defaulting to nil (loosely speaking). This is very pleasant to work
with. I have a sense that it fixes more issues than it causes; I've
not had occasion to curse at the mechanism as the cause of a problem.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-05 20:41 +0000 |
| Message-ID | <20230905132941.99@kylheku.com> |
| In reply to | #174041 |
On 2023-09-05, Bart <bc@freeuk.com> wrote: > 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: "X shall appear only in Y" means "in Y and nowhere else". If it appears anywhere but Y, the "shall" requirement is violated. If that is in a "Constraints" paragraph, it requires a diagnotic. Just like "parking is allowed only in designated stalls" means not in the driveway, or on the lawn, or elsewhere. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-05 20:47 +0000 |
| Message-ID | <20230905134222.11@kylheku.com> |
| In reply to | #174041 |
On 2023-09-05, Bart <bc@freeuk.com> wrote: > This paragraph calls them Constraints, as presumably they can't be > expressed via syntax. Contraints paragraphs give rules that require diagnostics if they are violated, which is in the same class a syntax errors. Some constraints could be turned into syntax. For instance, the combinations of type specifiers could all be phrase structures which admit "unsigned int" but not "unsigned struct foo". How ISO specifies it is that any jumble of type specifiers is allowed, and then constraints rules allow only certain combinations. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-05 14:07 -0700 |
| Message-ID | <87msy049dj.fsf@nosuchdomain.example.com> |
| In reply to | #174041 |
Bart <bc@freeuk.com> writes:
[...]
> This paragraph calls them Constraints, as presumably they can't be
> expressed via syntax.
Or just because it's inconvenient to express them via syntax.
> I guess some other sections explains how those are handled.
[...]
Yes, constraints are explained in N1570 5.1.1.3 "Diagnostics":
A conforming implementation shall produce at least one
diagnostic message (identified in an implementation-defined
manner) if a preprocessing translation unit or translation
unit contains a violation of any syntax rule or constraint,
even if the behavior is also explicitly specified as undefined
or implementation-defined. Diagnostic messages need not be
produced in other circumstances.
with a footnote:
The intent is that an implementation should identify the nature of,
and where possible localize, each violation. Of course, an
implementation is free to produce any number of diagnostics as long
as a valid program is still correctly translated. It may also
successfully translate an invalid program.
Is that clear enough for 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 22:22 +0100 |
| Message-ID | <ud866o$24iki$2@dont-email.me> |
| In reply to | #174048 |
On 05/09/2023 22:07, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [...] >> This paragraph calls them Constraints, as presumably they can't be >> expressed via syntax. > > Or just because it's inconvenient to express them via syntax. > >> I guess some other sections explains how those are handled. > [...] > > Yes, constraints are explained in N1570 5.1.1.3 "Diagnostics": > > A conforming implementation shall produce at least one > diagnostic message (identified in an implementation-defined > manner) if a preprocessing translation unit or translation > unit contains a violation of any syntax rule or constraint, > even if the behavior is also explicitly specified as undefined > or implementation-defined. Diagnostic messages need not be > produced in other circumstances. > > with a footnote: > > The intent is that an implementation should identify the nature of, > and where possible localize, each violation. Of course, an > implementation is free to produce any number of diagnostics as long > as a valid program is still correctly translated. It may also > successfully translate an invalid program. > > Is that clear enough for you? > Yeah, thanks. It sounds like these are guidelines. Which is good, as I have my own ideas of how my compilers will work (my first one was 43 years ago!). I can tell you I don't think much of this: "It may also successfully translate an invalid program." I think I'd rather not! What is the incentive in writing a /valid/ program if you will get an executable either way?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-05 15:26 -0700 |
| Message-ID | <87edjc45pe.fsf@nosuchdomain.example.com> |
| In reply to | #174049 |
Bart <bc@freeuk.com> writes:
> On 05/09/2023 22:07, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> This paragraph calls them Constraints, as presumably they can't be
>>> expressed via syntax.
>> Or just because it's inconvenient to express them via syntax.
>>
>>> I guess some other sections explains how those are handled.
>> [...]
>> Yes, constraints are explained in N1570 5.1.1.3 "Diagnostics":
>> A conforming implementation shall produce at least one
>> diagnostic message (identified in an implementation-defined
>> manner) if a preprocessing translation unit or translation
>> unit contains a violation of any syntax rule or constraint,
>> even if the behavior is also explicitly specified as undefined
>> or implementation-defined. Diagnostic messages need not be
>> produced in other circumstances.
>> with a footnote:
>> The intent is that an implementation should identify the nature of,
>> and where possible localize, each violation. Of course, an
>> implementation is free to produce any number of diagnostics as long
>> as a valid program is still correctly translated. It may also
>> successfully translate an invalid program.
>> Is that clear enough for you?
>
> Yeah, thanks.
You're welcome.
> It sounds like these are guidelines. Which is good, as I have my own
> ideas of how my compilers will work (my first one was 43 years ago!).
>
> I can tell you I don't think much of this:
>
> "It may also successfully translate an invalid program."
>
> I think I'd rather not! What is the incentive in writing a /valid/
> program if you will get an executable either way?
You know what? I (mostly) agree with you. I would have preferred it if
the C standard had required any translation unit that violates a syntax
rule or constraint must be rejected (not generate an object file, and
not be linkable into an executable program).
You see, once we have a mutual understanding about what the standard
says, I'm willing to discuss what I think it should say.
On the other hand, it's not that much of a problem in practice.
For example, "gcc -std=c17 -pedantic" is a conforming C compiler that
will generate an executable for many programs that have constraint
errors. "gcc -std=c17 -pedantic-errors" is a conforming C compiler that
will *not* generate an executable for any program that violates a syntax
rule or constraint. (Or rather, it attempts to be conforming; there are
always bugs.)
And if you wanted to write an ISO conforming C compiler, you could make
it unconditionally reject any translation unit that violates a syntax
rule or constraint. The standard allows that. (Neither of us is
entirely happy about the fact that it doesn't require it, but I can live
with it.)
Even if a future edition of the standard required compilers to reject
syntax errors and constraint violations, compilers could still have a
non-conforming mode that treats some of them as non-fatal errors, or
even ignores them.
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-09-05 18:26 -0700 |
| Message-ID | <1zQJM.1001647$TPw2.558688@fx17.iad> |
| In reply to | #174049 |
On 9/5/23 2:22 PM, Bart wrote: > It sounds like these are guidelines. Which is good, as I have my own > ideas of how my compilers will work (my first one was 43 years ago!). > > I can tell you I don't think much of this: > > "It may also successfully translate an invalid program." > > I think I'd rather not! What is the incentive in writing a /valid/ > program if you will get an executable either way? > Because the conversion of a valid program has defined behavior by the Standard. If an "invalid" program (by the Standard) results in a successful translation" then running such a result has Undefined Behavior (by the Standard) The reason for allowing this, is that the implementation might be defining the meaning of the "invalid" code, and thus the behavior of the result. Generally, most "invalid" conditions that just generate warnings (and thus allow a successful translation) have a meaning supplied by the implementation, which is why they just become warnings.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-09-07 23:15 -0400 |
| Message-ID | <ude3k9$3ahp6$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 ... >> 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. Why would there be any danger of that? You've been given, and have ignored, citations identifying precisely the locations that you should look at. Since you did ignore them, you probably don't even remember receiving those citations - but that's your problem.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-05 13:48 -0700 |
| Message-ID | <87r0nc4a8y.fsf@nosuchdomain.example.com> |
| 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. I will have to take somebody's word for it. You
> seem to be implying the answer is Yes, so Yes.
You've written a C compiler.
I cannot imagine even trying to do that without referring to the ISO C
standard.
The answer to the question is yes. The ISO C standard does not require a
diagnostic for a missing return statement in a non-void function.
I can post the URL of an appropriate draft of the standard, along with
specific citations that demonstrate that no such diagnostic is required.
But I probably won't bother, since you'll only complain about it and
pretend not to understand it.
> 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.
Why on Earth would you do that? You have completely misunderstood this
discussion, apparently deliberately. Such warnings are common, useful,
and permitted (though not required) by the ISO C standard. I have not
said anything about what you can or cannot do with your own compiler.
Rejecting a program (as opposed to issuing a non-fatal warning) because
of a missing return statement would make your compiler non-conforming.
I do not care whether your compiler is conforming or not, and you've
made it clear that you don't either.
> (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;}
Both of those are constraint violations, requiring a diagnostic from any
conforming C compiler. Making them "hard errors" is a good idea. It's
not much to brag about, but good for 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 | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-05 21:36 +0000 |
| Message-ID | <20230905142846.381@kylheku.com> |
| In reply to | #174045 |
On 2023-09-05, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > You've written a C compiler. > > I cannot imagine even trying to do that without referring to the ISO C > standard. So you might say in earnest, and on the surface it's a fine enough sentiment, and rings true in reference to the entire activity from start to finish. It seems it would actually be a good idea to initially write as much of it as you're able to from your knowledge as a sort of "closed book exam" before cracking open the standard. "Do I know this stuff well enough to implement it, and to what detail?" Relying on what you know would go pair well with a top-down design, guided by your mental map of the language until the bottom-level details start to become critical. Needless to say, writing a C compiler without planning on ever looking into ISO C is not such a hot idea though. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-05 13:24 +0200 |
| Message-ID | <ud735p$1v0kc$1@dont-email.me> |
| In reply to | #173905 |
On 04/09/2023 22:06, 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? There is one single official current C standard - currently C17. There are older published C standards, which are still very relevant despite being superseded by the latest version. The standards documents from ISO cost money to buy, but drafts are freely available - the final draft before publishing is typically identical baring insignificant typographic fixes. There is not a single set of standard headers. The requirements for the standard library headers (and standard library functions) are part of the C standards, but the headers themselves are provided by each C implementation. It is common, but not required, for C compilers to have the headers that don't have function declarations (such as <stdint.h>) and are used for freestanding and hosted implementations, while other headers are part of a standard library. But different implementations will have different sets of standard library headers as well as different implementations of the standard library functions. And of course OS-specific headers are not part of the C standard at all (even if they happen to be bundled along with a compiler in some cases). > >> >> 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. It's not really a mystery in at least some of the cases. gcc and clang have quite comprehensive documentation - you can easily look up the options for the standards supported, as well as the default standard (for the particular version of the compiler). I am not as familiar with msvc, but I understand it too has a lot of documentation available. As for the rest, I have not checked - and have no intention of doing so. Some compilers provide good documentation, others do not. If you want to use a particular tool, it makes sense to learn what it does - and if you can't find out, it may not be a good choice of tool. > > 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? Read the documentation. Since a C compiler should not be giving a hard error for the missing return, all we know is that compilers that /do/ give a hard error are not implementing standard C. But for details, see the documentation. > > Do I have to to specify -Werror=xxx 173 times for all the possible > things that ought to sensibly be hard errors? "Sensible" in whose eyes? Yours? Silly question - of course that's what you meant, because you are the sole judge of what is "sensible". > > BTW apparently 'gcc' is not a C compiler. "gcc" is the "GNU Compiler Collection". It certainly /can/ be a C compiler - but it is also many other things. Without additional flags, it will compile an extended C dialect that has additional features beyond the standard, and is also laxer (especially about supporting newer or older constructs). This is all documented, and nothing new to you. With appropriate flags (they are not particularly difficult) it will support your choice of C standard. Additional flags can be used to restrict the accepted code to a subset of this with warnings or error messages for going outside that subset - such as requiring the use of "return value;" statements in non-void functions. "gcc" is also, depending on the details of the configuration, a Fortran compiler, a D compiler, and a compiler for several other languages, as well as a driver program and front-end for an assembler and a linker. > 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. > People do indeed refer to it colloquially as a C compiler - and colloquially, that's absolutely fine. But if you want to be precise about the exact handling of corners of the language, "colloquial" will not do - you choose to go down that path, so you need to learn about what "C" means technically, not just colloquially. > > I think you guys just want to keep things a mystery! How can you possibly think that? People have explained this stuff to you hundreds of times over a decade or more. For at least the serious tools, all the information is clearly given in reference manuals online. And if that were not enough, ten seconds of googling should give you everything you are asking. The only reason any of this is a mystery to you is the extraordinary effort you put in to resist any attempt at understanding or learning.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-04 15:46 -0700 |
| Message-ID | <87cyyx5zgc.fsf@nosuchdomain.example.com> |
| In reply to | #173893 |
Kaz Kylheku <864-117-4973@kylheku.com> writes:
[...]
> "C" does not mean "ISO C", unless the debate has been explicitly
> restricted that way.
I understand and respect your point of view, but I do not share it.
For me, "C" means "ISO C" unless otherwise specified, especially in the
context of this newsgroup.
"C" can also *informally* have a wider meaning. (English am confusing
sometimes.)
It doesn't hurt to say "ISO C" rather than "C" when the distinction is
important.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-02 17:44 +0200 |
| Message-ID | <ucvl8e$fb08$1@dont-email.me> |
| In reply to | #173583 |
On 01/09/2023 23:29, Bart wrote:
> And yet, it is possible to create a compiler that gives the common-sense
> results that one would expect. Except I'm not seeing it.
>
That's because you can't tell the difference between "common sense" and
"Bart's personal opinions and preferences, as well as his
misunderstandings of the C language".
> What do you expect the results of compiling this program with -c to be:
>
> int fred(void){}
>
> Here are the results I get:
>
> Warnings Errors
>
> gcc - -
> tcc - -
> clang 1 -
> msvc 1 -
> gcc -Wall 1 -
> lccwin32 1 -
> bcc - 1
>
>
> The problem with that function, in case you haven't spotted it, is that
> it does not return an 'int' value.
I refer you to the C standards, section 6.9.1 "Function definitions",
paragraph 12 - "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".
It is perfectly legal C to have a function defined as returning an "int"
but not having a "return" statement with a value that can be converted
to an "int".
Calling that function, and using the returned value, would be undefined
behaviour. But the function definition itself is not.
Now, you can well argue that that is a poor choice of definition for the
language. I'd agree - it stems from the historic days of C before
prototypes, when functions were assumed to take an unspecified number of
"int" parameters and return an "int" value, before "void" was part of
the language.
However, regardless of whether you like it or not, the function
definition here is perfectly legal C, and can be used safely and
correctly with fully defined behaviour. A compiler that does not accept
that code and compile it would therefore be rejecting correct C code.
Equally clearly, it is likely that the code is in error, and the
function could easily be used incorrectly - so a warning is definitely
appropriate.
So here I would say "clang", "msvc", "gcc -Wall" and "llwin32" did a
good job, while "gcc", "tcc" did a poor job (no warning), and "bcc" was
simply incorrect as a C compiler.
I can fully agree with you that the function was bad, and it is a good
thing to help developers write good code. I can fully agree with you
that the C language would be better if it were defined more strictly
here. But the job of a C compiler is to compile C code as the language
is defined - it is not the job of a C compiler to dictate the compiler
writer's idea of what he thinks C should have been.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-02 01:14 +0100 |
| Message-ID | <87pm31jusi.fsf@bsb.me.uk> |
| In reply to | #173543 |
Bart <bc@freeuk.com> writes: > On 01/09/2023 19:07, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 01/09/2023 14:53, Ben Bacarisse wrote: >>>> Bart <bc@freeuk.com> writes: >>>> >>>>> On 01/09/2023 13:08, Richard Harnden wrote: >>>>>> On 01/09/2023 12:01, Bart wrote: >>>> >>>>>>> We are talking about compilers like gcc where you make up your own rules >>>>>>> as to show strictly you want your program treated: >>>>>>> >>>>>>> gcc prog.c zero warnings, writes .exe >>>>>>> gcc @options prog.c 10000 warnings, but it still writes .exe >>>>>>> gcc @options prog.c 10000 warning and 1 error, no .exe >>>> >>>> Which would you choose as the one and only behaviour? >> No answer? I'll look at the rest of your post, if you decide to address >> this point... > You want an answer, I'd go with the first, since then the three compilers I > use the most work the same way. > > That's not completely satisfactory, It's totally unacceptable to me and, I suspect, a lot of other people. I usually don't want gcc extensions and I want to be able specify the ISO C standard to use at the very least. But I also want as much help spotting errors as the compiler can give me. > since there are aspects of the C language I think are too unsafe, but: > > * Have to be passed because they are legal C > > * Cannot reliably be detected by a compiler > > * Are too extensively used in legacy code to be just outlawed. Yet you want to stop people from having hundreds of helpful diagnostics. I suspect you don't mean what you seem to have said -- that gcc should always behave in it's default mode. But if that is not what you meant to say then you have not answered the question at all. You say, dismissively, that one can "make up ones your rules" with gcc, so I am asking for you to say exactly what you don't want me to be able to ask for in terms of checking and/or its absence. Just how crippled and annoying would I find gcc to be if you were in charge? How much choice will you take away? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-01 18:13 -0700 |
| Message-ID | <2711a385-0bd0-4d0b-8f9a-1cdcf8682586n@googlegroups.com> |
| In reply to | #173599 |
On Saturday, 2 September 2023 at 01:14:36 UTC+1, Ben Bacarisse wrote: > Bart <b...@freeuk.com> writes: > > > On 01/09/2023 19:07, Ben Bacarisse wrote: > >> Bart <b...@freeuk.com> writes: > >> > >>> On 01/09/2023 14:53, Ben Bacarisse wrote: > >>>> Bart <b...@freeuk.com> writes: > >>>> > >>>>> On 01/09/2023 13:08, Richard Harnden wrote: > >>>>>> On 01/09/2023 12:01, Bart wrote: > >>>> > >>>>>>> We are talking about compilers like gcc where you make up your own rules > >>>>>>> as to show strictly you want your program treated: > >>>>>>> > >>>>>>> gcc prog.c zero warnings, writes .exe > >>>>>>> gcc @options prog.c 10000 warnings, but it still writes .exe > >>>>>>> gcc @options prog.c 10000 warning and 1 error, no .exe > >>>> > >>>> Which would you choose as the one and only behaviour? > >> No answer? I'll look at the rest of your post, if you decide to address > >> this point... > > You want an answer, I'd go with the first, since then the three compilers I > > use the most work the same way. > > > > That's not completely satisfactory, > It's totally unacceptable to me and, I suspect, a lot of other people. > I usually don't want gcc extensions and I want to be able specify the > ISO C standard to use at the very least. But I also want as much help > spotting errors as the compiler can give me. > Generally gcc in default mode gives sensible warnings which either indicate actual bugs, or odd programming which should be cleaned up. Then you can ramp up the warning level to get a huge amount, but they tend to be things like warnings about mixed mode arithemetic because size_t is unsigned, which is very unlikely to cause an error. > > > since there are aspects of the C language I think are too unsafe, but: > > > > * Have to be passed because they are legal C > > > > * Cannot reliably be detected by a compiler > > > > * Are too extensively used in legacy code to be just outlawed. > Yet you want to stop people from having hundreds of helpful diagnostics. > > I suspect you don't mean what you seem to have said -- that gcc should > always behave in it's default mode. But if that is not what you meant > to say then you have not answered the question at all. > > You say, dismissively, that one can "make up ones your rules" with gcc, > so I am asking for you to say exactly what you don't want me to be able > to ask for in terms of checking and/or its absence. Just how crippled > and annoying would I find gcc to be if you were in charge? How much > choice will you take away? > In most software, every option you provide represents a failure rather than an enhancement. It's often a symptom of sloppy design - a lot of functions need parameterising, and instead of doing the hard work and finding the parameters to use, the designer just gives the job to the user. It's often a symptom of design by programmers rather than user-interface people. Programmers don't mind -gamma-correction=1.1, but it's a nightmare to someone who just wants to watch telly. I suppose you could argue that a compiler is an exception to the general rule that programmers shouldn't design interfaces. But the general rule is that options make a program easier to write and harder to use. Sometimes the gain in ease of writing is so large that a small loss in ease of use has to be tolerated. And of course there is the issue of what is an "option" and what is a regular instruction to the program that inherently has to come from the user. But basically a compiler should translate C source to object code. That's all it should do. And it shouldn't need telling how to do that.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-02 01:43 +0000 |
| Message-ID | <20230901183816.230@kylheku.com> |
| In reply to | #173604 |
On 2023-09-02, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > Generally gcc in default mode gives sensible warnings which either indicate For values of "default mode" being -Wall, of course. > In most software, every option you provide represents a failure rather than > an enhancement. It's often a symptom of sloppy design - a lot of functions > need parameterising, and instead of doing the hard work and finding the > parameters to use, the designer just gives the job to the user. It's often a > symptom of design by programmers rather than user-interface people. But that's what a programming language is. The vendor describes some assembly language instructions described in the data sheet for the chip, effectively punting to the user the task of deciding which ones to select in order to have it Pac Man. A piano is nothing but sloppy design; you have to pick a sequence of correct notes out of 88 keys. At least they have player pianos though. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-02 17:51 +0200 |
| Message-ID | <ucvlm8$fb08$3@dont-email.me> |
| In reply to | #173609 |
On 02/09/2023 03:43, Kaz Kylheku wrote: > On 2023-09-02, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: >> Generally gcc in default mode gives sensible warnings which either indicate > > For values of "default mode" being -Wall, of course. And "-O2".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-02 17:58 +0200 |
| Message-ID | <ucvm37$fb08$4@dont-email.me> |
| In reply to | #173604 |
On 02/09/2023 03:13, Malcolm McLean wrote: > Generally gcc in default mode gives sensible warnings which either indicate > actual bugs, or odd programming which should be cleaned up. The warnings that gcc gives when run without additional flags are certainly very clear indications of problems. But it accepts a huge range of almost certainly incorrect code without comment unless you specify warning flags. gcc without flags is very weak in terms of warnings - due mainly to the need for historical compatibility. Using gcc without flags as a development tool is incompetence. > Then you can > ramp up the warning level to get a huge amount, but they tend to be things > like warnings about mixed mode arithemetic because size_t is unsigned, > which is very unlikely to cause an error. If only gcc had a way to pick the warnings that are appropriate for the type of programming in question... oh, wait, it does! I have often used the warnings that target mixed sign arithmetic, precisely because they /are/ likely to cause errors. This, of course, depends entirely on the kind of code in question - which is why warnings like this are controlled by flags. >> >>> since there are aspects of the C language I think are too unsafe, but: >>> >>> * Have to be passed because they are legal C >>> >>> * Cannot reliably be detected by a compiler >>> >>> * Are too extensively used in legacy code to be just outlawed. >> Yet you want to stop people from having hundreds of helpful diagnostics. >> >> I suspect you don't mean what you seem to have said -- that gcc should >> always behave in it's default mode. But if that is not what you meant >> to say then you have not answered the question at all. >> >> You say, dismissively, that one can "make up ones your rules" with gcc, >> so I am asking for you to say exactly what you don't want me to be able >> to ask for in terms of checking and/or its absence. Just how crippled >> and annoying would I find gcc to be if you were in charge? How much >> choice will you take away? >> > In most software, every option you provide represents a failure rather than > an enhancement. In most of your posts, any use of the word "most" is an indication that you are about to write completely unsubstantiated nonsense. This post did not disappoint.
[toc] | [prev] | [next] | [standalone]
Page 8 of 18 — ← Prev page 1 … 6 7 [8] 9 10 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web