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 17 of 18 — ← Prev page 1 … 15 16 [17] 18 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-03 16:25 +0200 |
| Message-ID | <ud250s$um2u$3@dont-email.me> |
| In reply to | #173741 |
On 03/09/2023 12:02, Bart wrote: > On 03/09/2023 02:28, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 02/09/2023 22:42, Ben Bacarisse wrote: >>>> Bart <bc@freeuk.com> writes: > >>> I understand the point about the void* result type needing to match a >>> set >>> of other functions. >> >> No, void * is the actual type I wanted. It was not being used as a >> point "to any object". Mind you, the return has nothing to do with the >> point of the post. > > Then I /don't/ understand. Why not just make it a 'void' function? > It is in a table of function pointers. Presumably some or all of the other functions in the table return something useful. > I had assumed the address of no_op was used in a table of function > pointers sharing a void* return type. Yes. While it is possible to use casts between different function pointer types so that the function pointers in the table point to actual functions with different types, it is rarely a good idea. You would have to cast back to the correct type before calling the function. You are not allowed to call a function that has a type returning void using a function pointer of a type returning void* . > > >>> But how much of an imposition is it to supply a 'return >>> NULL' line at the end? >> >> Not much, but why should I add pointless junk? > > And yet, some people are happy to add attributes like _Noreturn. Should people be happy to add information that helps the programmer, helps people reading the code, lets the compiler optimise better, and lets the compiler and other tools do better automatic checking? Yes, absolutely - that is /far/ from pointless. > Some > are also happy to write 'i' three times in a simple for-header. > > /You/ are even happy to write a return type that doesn't correspond to > the function body. It corresponds to the required function type (assuming I understand Ben's code correctly). > >>> Then it doesn't matter what precedes it; that exit line could could be >>> commented out, it can be changed, or it's to be maintained by someone >>> else. >> >> And then the function would be incorrect. The exit (with a message >> output by the error function) is there for a purpose. If I (or someone >> else) were to comment it out (by accident, presumably) I /want/ a >> warning from gcc that the function won't return a value. > > This is what I've complained that it doesn't do. It does. Oh, are you still failing to use gcc correctly, and still complaining about that? > >> If I follow >> your advice, nothing will alert me that I've commented out the key part >> of the function. > > I can't win this can I? You could try dropping your paranoia and your mindless hatred of C and gcc. Then you might "win". > Obviously if you comment out swathes of code, > the behaviour will change. > > But in this case, that is not the issue, as it will silently invoke > undefined behaviour. How would undefined behaviour be invoked here? Since "exit" does not return, there is no possibility of the calling function attempted to use the non-existent return value, and thus no undefined behaviour. > > This affects the integrity of the underlying code. For most targets, the > likelihood is that a garbage value is returned. That is undesirable. > The likelihood of that is zero - since the function does not return.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-03 16:49 +0100 |
| Message-ID | <87lednw927.fsf@bsb.me.uk> |
| In reply to | #173741 |
Bart <bc@freeuk.com> writes:
> On 03/09/2023 02:28, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 02/09/2023 22:42, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>
>>> I understand the point about the void* result type needing to match a set
>>> of other functions.
>> No, void * is the actual type I wanted. It was not being used as a
>> point "to any object". Mind you, the return has nothing to do with the
>> point of the post.
>
> Then I /don't/ understand. Why not just make it a 'void' function?
>
> I had assumed the address of no_op was used in a table of function pointers
> sharing a void* return type.
Yes, but exactly what that type is is not the point. All the functions
have the same type and a non-void return type.
>>> But how much of an imposition is it to supply a 'return
>>> NULL' line at the end?
>> Not much, but why should I add pointless junk?
>
> And yet, some people are happy to add attributes like _Noreturn. Some are
> also happy to write 'i' three times in a simple for-header.
C programmers have no choice. You can't conflate a reluctance to moan
alongside you with happiness about everything.
But worse, even if I /were/ happy about redundancy in some cases, you
should not assume that I will be happy about all redundant code.
> /You/ are even happy to write a return type that doesn't correspond to the
> function body.
No. You may not understand the point of the example, but just ask more,
don't assume.
Let me try again... All the functions have the same type. For all of
the functions that will be called, the return value is used (and the
arguments passed will be used as well).
I wanted a value to store, like a null pointer, to indicate that
something is wrong -- that a pointer has not been correctly set to a
proper, usable, function pointer value. Initially I used a null
pointer, but then I'd just get a crash if it a program bug caused it to
be called. Instead, I decided to use a pointer to a function of the
same type as all the others. And it makes sense that it should report
an error if it were, in fact, called as a result of some bug in the
program.
Now all the pointer variables always have a valid pointer and I can
still tell if one is not yet set correctly by testing ptr == no_op.
(Actually that might have been a bad name for the example. The actual
function was called 'not_set'.)
>>> Then it doesn't matter what precedes it; that exit line could could be
>>> commented out, it can be changed, or it's to be maintained by someone
>>> else.
>>
>> And then the function would be incorrect. The exit (with a message
>> output by the error function) is there for a purpose. If I (or someone
>> else) were to comment it out (by accident, presumably) I /want/ a
>> warning from gcc that the function won't return a value.
>
> This is what I've complained that it doesn't do.
You know that it will, though, so this is just the same old gripe.
>> If I follow
>> your advice, nothing will alert me that I've commented out the key part
>> of the function.
>
> I can't win this can I? Obviously if you comment out swathes of code, the
> behaviour will change.
You can't win this one point because you are wrong.
void *not_set(int) {
exit(error("should not happen"));
}
is better than
void *not_set(int) {
exit(error("should not happen"));
return NULL;
}
because (a) the latter has redundant code, and (b) if, as you suggest
might happen, I or someone else comments out the exit call your version
will not result in a diagnostic whereas mine will (in part because I
know how to use gcc).
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-03 16:16 +0200 |
| Message-ID | <ud24fp$um2u$2@dont-email.me> |
| In reply to | #173697 |
On 03/09/2023 03:28, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 02/09/2023 22:42, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 02/09/2023 00:02, Keith Thompson wrote:
>>>
>>>>> Now, what was your point, and how does `int fred(void){}` illustrate it?
>>>>
>>>> I would have said it's obviously wrong.
>>> Curiously, I wrote a similar function two days ago. I had a table of
>>> function pointers and I wanted a "nothing here" value I could store and
>>> test for. Rather than use a null function pointer, I chose
>>> void *no_op(int) { exit(error("placeholder called")); }
>>> so that I'd know if it were accidentally called. It uses /two/ features
>>> you dislike: unnamed parameters in a function definition, and a body
>>> with no return statement. But I am happy with this choice. Even with
>>> as many warning on as I can find (my preference during development) gcc
>>> does not complain about either, and the code does exactly what I want.
>>
>> The missing parameter makes it fail on tcc, MSVC, bcc and icc (icx will
>> warn).
>
> Maybe they will all catch up. I used gcc -std=c2x.
>
>> I understand the point about the void* result type needing to match a set
>> of other functions.
>
> No, void * is the actual type I wanted. It was not being used as a
> point "to any object". Mind you, the return has nothing to do with the
> point of the post.
>
>> But how much of an imposition is it to supply a 'return
>> NULL' line at the end?
>
> Not much, but why should I add pointless junk?
It would be far worse than pointless. It would hide possible problems
that would otherwise be spotted by the compiler, such as changes to the
function. Maybe you one day would change from using "exit" to using
some other logging or messaging function - you would want a warning from
gcc if that function was not "_Noreturn", and you would not want the
warning hidden by an extra "return NULL;".
Perhaps more importantly, it is never a good thing to have code lines
that are not executed. This could easily confuse people reading the
code - they would be left wondering if the "exit" function returned, so
that the next line would be executed. On some compilers with some
options, it could also lead to warnings about unreachable code. And for
some kinds of programming, you want to do code coverage to ensure that
every line of code is tested - that is impossible with code lines that
cannot be reached.
If I had to add a line here to quieten a compiler warning (perhaps I
knew that "exit" never returns, but the compiler did not know that, if
it were a function declared without _Noreturn or
__attribute__(("noreturn")) ), I would much prefer to write
"__builtin_unreachable();" and a comment.
>
>> Then it doesn't matter what precedes it; that exit line could could be
>> commented out, it can be changed, or it's to be maintained by someone
>> else.
>
> And then the function would be incorrect. The exit (with a message
> output by the error function) is there for a purpose. If I (or someone
> else) were to comment it out (by accident, presumably) I /want/ a
> warning from gcc that the function won't return a value. If I follow
> your advice, nothing will alert me that I've commented out the key part
> of the function.
>
>> Or maybe one day, you will populate this function, and forget the
>> return statement.
>
> Of course I won't. It's a "sentinel" used to say "nothing here" with
> the added advantage that if it gets called because of some bug, I'll
> know about it. As I said, I could have used a null pointer (and I'd
> still get to know about a mistaken call because of a "crash"), but my
> message will tell me more, sooner.
>
And of course if you /did/ change the function to do something else,
/and/ you forgot an appropriate return statement, you would rather have
a warning message than have the message covered up by a
counter-productive fake "return NULL;" line.
>>> I note from another part of the thread that your bcc would most likely
>>> reject my program.
>>
>> The missing parameter name, yes (although in the revamp, I enabled that
>> experimentally).
>>
>> The missing return can be enabled with -old.
>
> Ironic, since the code is targeted at C23!
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-02 18:11 +0200 |
| Message-ID | <ucvmqm$fb08$6@dont-email.me> |
| In reply to | #173594 |
On 02/09/2023 01:02, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> But tell me what dialect of C my 'int fred(void){}' is a valid program
>> of. Then tell me why most C compilers are still compiling that dialect
>> by default in 2023.
> [...]
>
> Can you clarify what point you're making with `int fred(void){}`?
>
> That's a valid function definition and translation unit in every version
> of ISO C going back to C90, by which I mean that it does not violate any
> constraint or syntax rule. (I presume we're not concerned with K&R C,
> which didn't have void.) It is not a valid *program* for a hosted
> implementation in any version of C, since it lacks a `main` function.
>
> A compiler may reasonably warn about the fact that control reaches the
> end of a non-void function, but the standard doesn't require a
> diagnostic. Calling `fred` and not using the result is well defined.
> Calling `fred` and attempting to use the result has undefined behavior.
> No diagnostic is required, up to and including C23. (There are
> historical reasons for this, which I won't go into.)
Also note that it is perfectly fine to have :
int fred(void) { }
int boo(void) {
int x = fred();
return x + 1;
}
There is nothing in this code that is undefined behaviour - it's all
valid C. There is only a problem - undefined behaviour - if the program
actually /calls/ "boo".
You can even add :
int main(int argc, char * argv[]) {
if (arc == 2) return boo();
}
The whole thing is valid C, and is only undefined behaviour if the
executable is called with one argument.
This is the kind of thing that makes warnings and static error checking
a challenge in C - in most cases, undefined behaviour is a run-time
issue, not a compile-time issue, and the compiler does not know how the
program will be run.
>
> Note carefully that I am describing the requirements given by the C
> standard, not expressing an opinion on whether they're good or bad.
>
> Now, what was your point, and how does `int fred(void){}` illustrate it?
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-02 22:08 +0100 |
| Message-ID | <ud0887$i2hk$1@dont-email.me> |
| In reply to | #173669 |
On 02/09/2023 17:11, David Brown wrote:
> On 02/09/2023 01:02, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> But tell me what dialect of C my 'int fred(void){}' is a valid program
>>> of. Then tell me why most C compilers are still compiling that dialect
>>> by default in 2023.
>> [...]
>>
>> Can you clarify what point you're making with `int fred(void){}`?
>>
>> That's a valid function definition and translation unit in every version
>> of ISO C going back to C90, by which I mean that it does not violate any
>> constraint or syntax rule. (I presume we're not concerned with K&R C,
>> which didn't have void.) It is not a valid *program* for a hosted
>> implementation in any version of C, since it lacks a `main` function.
>>
>> A compiler may reasonably warn about the fact that control reaches the
>> end of a non-void function, but the standard doesn't require a
>> diagnostic. Calling `fred` and not using the result is well defined.
>> Calling `fred` and attempting to use the result has undefined behavior.
>> No diagnostic is required, up to and including C23. (There are
>> historical reasons for this, which I won't go into.)
>
> Also note that it is perfectly fine to have :
>
> int fred(void) { }
>
> int boo(void) {
> int x = fred();
> return x + 1;
> }
>
> There is nothing in this code that is undefined behaviour - it's all
> valid C. There is only a problem - undefined behaviour - if the program
> actually /calls/ "boo".
That sounds like a let-out clause for ALL undefined behaviour in a
program. So you can have 100,000 lines of code each of which invokes UB
if executed. but the main program is:
int main(void) {
// f(); // f is where things get rolling.
}
Or maybe you don't a main function at all, as those 100,000 lines form a
library with no entry point of its own.
In fact, your own fred() function is exported so that could also be called.
So I'm not sure what point you're trying to make.
I can also say that it is fine for my compiler to generate buggy code,
provided you don't try and execute it!
> This is the kind of thing that makes warnings and static error checking
> a challenge in C - in most cases, undefined behaviour is a run-time
> issue, not a compile-time issue, and the compiler does not know how the
> program will be run.
Well, quite. That's why you diagnose it anyway, since the assumption is
that that code could well be run at some point, otherwise what was the
purpose of it?
>>
>> Note carefully that I am describing the requirements given by the C
>> standard, not expressing an opinion on whether they're good or bad.
(Why not express an opinion? Afraid you might agree with me?)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-03 16:48 +0200 |
| Message-ID | <ud26b5$v525$1@dont-email.me> |
| In reply to | #173684 |
On 02/09/2023 23:08, Bart wrote:
> On 02/09/2023 17:11, David Brown wrote:
>> On 02/09/2023 01:02, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> But tell me what dialect of C my 'int fred(void){}' is a valid program
>>>> of. Then tell me why most C compilers are still compiling that dialect
>>>> by default in 2023.
>>> [...]
>>>
>>> Can you clarify what point you're making with `int fred(void){}`?
>>>
>>> That's a valid function definition and translation unit in every version
>>> of ISO C going back to C90, by which I mean that it does not violate any
>>> constraint or syntax rule. (I presume we're not concerned with K&R C,
>>> which didn't have void.) It is not a valid *program* for a hosted
>>> implementation in any version of C, since it lacks a `main` function.
>>>
>>> A compiler may reasonably warn about the fact that control reaches the
>>> end of a non-void function, but the standard doesn't require a
>>> diagnostic. Calling `fred` and not using the result is well defined.
>>> Calling `fred` and attempting to use the result has undefined behavior.
>>> No diagnostic is required, up to and including C23. (There are
>>> historical reasons for this, which I won't go into.)
>>
>> Also note that it is perfectly fine to have :
>>
>> int fred(void) { }
>>
>> int boo(void) {
>> int x = fred();
>> return x + 1;
>> }
>>
>> There is nothing in this code that is undefined behaviour - it's all
>> valid C. There is only a problem - undefined behaviour - if the
>> program actually /calls/ "boo".
>
> That sounds like a let-out clause for ALL undefined behaviour in a
> program.
Yes.
There are some things that are undefined behaviour at compile-time, some
things that are UB at link time. But most UB is only UB at run time.
If the problematic code is not run, there is no problem - no UB.
Now, I am all in favour of having compilers warn about such /potential/
UB whenever possible. I use a wide selection of warnings when
compiling, and want my compilers to complain about such code. (I
usually have such warnings marked as errors to make them impossible to
miss.)
But whatever my personal preferences here in terms of using tools to
help me write correct code and avoid mistakes, the fact remains that you
cannot have run-time undefined behaviour in code that is not run.
> So you can have 100,000 lines of code each of which invokes UB
> if executed. but the main program is:
>
> int main(void) {
> // f(); // f is where things get rolling.
> }
>
> Or maybe you don't a main function at all, as those 100,000 lines form a
> library with no entry point of its own.
>
> In fact, your own fred() function is exported so that could also be called.
>
> So I'm not sure what point you're trying to make.
>
> I can also say that it is fine for my compiler to generate buggy code,
> provided you don't try and execute it!
It /is/ fine to have buggy code that is not run - there will be no
run-time errors and no run-time undefined behaviour.
But it is probably useless code, and being informed about it by your
tools is a good thing.
I think you are mixing up /correctness/ with /usefulness/. It is
/correct/ for a compiler to transform :
unsigned int mult(unsigned int x, unsigned int y) {
return x * y;
}
into
unsigned int mult(unsigned int x, unsigned int y) {
unsigned int z = 0;
for (unsigned int i = 0; i < y; i++) {
z += x;
}
return z;
}
But it is not /useful/ for it to do so.
It is /correct/ for compilers to accept the "fred" and "boo" above.
Indeed, it is /required/ for them to do so for C standard conformance
(though they can complain loudly and give warnings). It is, IMHO, more
useful if they complain and give warning messages. I'd be even happier
for a compiler to make it a hard error - but that would be against the C
standards. So the sensible way for a general-purpose C compiler to
behave is to accept the code and to have options to let those who want
useful checks, have those checks. I'd rather that gcc gave a warning by
default, regardless of the options, but I'm fine with it needing
"-Wall". After all, pretty much no one who is competent as a software
developer would be programming without basic warnings enabled in their
tools somewhere.
>
>> This is the kind of thing that makes warnings and static error
>> checking a challenge in C - in most cases, undefined behaviour is a
>> run-time issue, not a compile-time issue, and the compiler does not
>> know how the program will be run.
>
>
> Well, quite. That's why you diagnose it anyway, since the assumption is
> that that code could well be run at some point, otherwise what was the
> purpose of it?
>
Yes, such warnings are definitely useful. That's why I always enable them.
>>>
>>> Note carefully that I am describing the requirements given by the C
>>> standard, not expressing an opinion on whether they're good or bad.
>
> (Why not express an opinion? Afraid you might agree with me?)
>
I am certainly not afraid to agree with you - I have agreed with you
countless times about things that I would have preferred to be otherwise
in C. (I have also disagreed with you countless times.) But you are
unable to comprehend the difference between someone understanding how C
or gcc works, or why C or gcc works in a particular way, with someone
/wanting/ them to work in that way.
So to be clear - C (the language defined by the standards) regards
"fred" and "boo" as valid code. gcc, by default, regards it as valid
code. gcc, used as a development tool, complains about it. gcc, as I
use it for development, makes it a hard error.
I understand exactly why it is allowed in C. I understand exactly why
it is allowed in gcc. I understand why it would be impossible to change
the rules in C. I understand why it would be very difficult to change
the default behaviour in gcc here.
I would have been happier if C did not allow such code. I would have
been happier if gcc gave at least a warning, and perhaps an error
message, by default - and required specific flags to enabled such code
to be accepted.
Now, does that make you happy?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-02 14:52 -0700 |
| Message-ID | <87msy46y4n.fsf@nosuchdomain.example.com> |
| In reply to | #173669 |
David Brown <david.brown@hesbynett.no> writes:
> On 02/09/2023 01:02, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> But tell me what dialect of C my 'int fred(void){}' is a valid program
>>> of. Then tell me why most C compilers are still compiling that dialect
>>> by default in 2023.
>> [...]
>> Can you clarify what point you're making with `int fred(void){}`?
>> That's a valid function definition and translation unit in every
>> version
>> of ISO C going back to C90, by which I mean that it does not violate any
>> constraint or syntax rule. (I presume we're not concerned with K&R C,
>> which didn't have void.) It is not a valid *program* for a hosted
>> implementation in any version of C, since it lacks a `main` function.
>> A compiler may reasonably warn about the fact that control reaches
>> the
>> end of a non-void function, but the standard doesn't require a
>> diagnostic. Calling `fred` and not using the result is well defined.
>> Calling `fred` and attempting to use the result has undefined behavior.
>> No diagnostic is required, up to and including C23. (There are
>> historical reasons for this, which I won't go into.)
>
> Also note that it is perfectly fine to have :
>
> int fred(void) { }
>
> int boo(void) {
> int x = fred();
> return x + 1;
> }
>
> There is nothing in this code that is undefined behaviour - it's all
> valid C. There is only a problem - undefined behaviour - if the
> program actually /calls/ "boo".
It's "perfectly fine" only in the sense that it doesn't violate
a constraint or syntax rule and doesn't cause undefined behavior
unless it's called. It's still bad code.
I wouldn't mind if a future edition of the C standard added a
requirement that the } of a non-void function must be unreachable
(with an exception for main()). There are languages that have such
a requirement, and in my limited experience it works pretty well.
The problem is that such a requirement requires the compiler
to perform control flow analysis that's not otherwise required.
Most large modern compilers already do such analysis for optimization
and diagnostic purposes; at most they might have to enable it
at all optimization levels. Small "hobby" compilers might have
to do some extra work -- but such compilers often aren't fully
conforming anyway.
Such a requirement would have been a more substantial burden when
the language was originally being defined, and inertia probably
has a lot to do with why it hasn't been imposed since then.
I think we'd need a rigorous definition of reachability that's not too
difficult to implement. It might require adding unnecessary return
statements in some corner cases, but IMHO that's ok. There's precedent
in other languages that C could steal.
Simply requiring a non-void function to have a return statement
*somewhere* would be far less helpful, and would not be worth the
effort. It would allow such obviously incorrect code as:
int fred(void) {
if (condition) return 42;
}
--
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-03 02:23 -0700 |
| Message-ID | <86v8crr4p3.fsf@linuxsc.com> |
| In reply to | #173687 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: [...] > I wouldn't mind if a future edition of the C standard added a > requirement that the } of a non-void function must be unreachable > (with an exception for main()). There are languages that have such > a requirement, and in my limited experience it works pretty well. > > The problem is that such a requirement requires the compiler > to perform control flow analysis that's not otherwise required. > [...] The problem is that in C such a determination cannot be made precisely, for reasons that are both theoretical and practical. Only heuristics are possible, but requirements in the C standard are never stated in terms of heuristics (and rightly so).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-03 03:47 -0700 |
| Message-ID | <877cp77cu9.fsf@nosuchdomain.example.com> |
| In reply to | #173732 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> [...]
>
>> I wouldn't mind if a future edition of the C standard added a
>> requirement that the } of a non-void function must be unreachable
>> (with an exception for main()). There are languages that have such
>> a requirement, and in my limited experience it works pretty well.
>>
>> The problem is that such a requirement requires the compiler
>> to perform control flow analysis that's not otherwise required.
>> [...]
>
> The problem is that in C such a determination cannot be made
> precisely, for reasons that are both theoretical and practical.
> Only heuristics are possible, but requirements in the C standard
> are never stated in terms of heuristics (and rightly so).
Yes, I addressed that in my previous post:
I think we'd need a rigorous definition of reachability that's not too
difficult to implement. It might require adding unnecessary return
statements in some corner cases, but IMHO that's ok. There's precedent
in other languages that C could steal.
For example, the closing } in this function:
int func(void) {
if (rand() >= 0)
return 42;
}
will never be reached (because rand() always returns a non-negative
result), but compilers should not be required to do that level of
analysis. In a future version of C that requires the closing } of a
non-void function other than main() to be unreachable, I'd expect this
to be diagnosted as a constraint violation, fixable by adding a return
statement in an else clause or after the if statement.
To put it another way, if the compiler can't prove that the closing }
cannot be reached via any control path *without* making any assumptions
about the values of any conditions, a diagnostic would be required.
I've seen this kind of requirement in other languages, but I don't
remember which ones off the top of my head.
--
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-03 18:44 +0000 |
| Message-ID | <20230903110003.361@kylheku.com> |
| In reply to | #173732 |
On 2023-09-03, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > > [...] > >> I wouldn't mind if a future edition of the C standard added a >> requirement that the } of a non-void function must be unreachable >> (with an exception for main()). There are languages that have such >> a requirement, and in my limited experience it works pretty well. >> >> The problem is that such a requirement requires the compiler >> to perform control flow analysis that's not otherwise required. >> [...] > > The problem is that in C such a determination cannot be made > precisely, for reasons that are both theoretical and practical. > Only heuristics are possible, but requirements in the C standard > are never stated in terms of heuristics (and rightly so). I believe this is false on both counts. There is nothing imprecise about "heuristics". What heuristics aren't is "accurate". They are precise rules that substitute for the accurate rules. (Because they much more cheaply yield a useful result or whatever.) We can stipulate an algorithm that is loaded with precise heuristics. In this application area, heuristics can also have the benefit of being easy to understand and their effect to predict. An example of a heuristic rule in C is the difference between pp-numbers tokens and actual numeric tokens. The preprocessing phases (originally a separate program in the Unix implementation of C) uses a heuristic, rather than the real rule, which brings about some simplifications as well as benefits. That old rule that an object cannot be modified more than once between sequence points, and that an object shall be accessed only to determinet he new value to be stored, is another example of a heuristic; the real rule requires an elaborate formal model of sequence points. Static checking itself is predicatid on heuristics. There are more correct programs than programs that can be statically checked. Sometimes, correct programs are diagnosed (and possibly rejected). For instance, the rule that a conversion between pointers to unlike object types requires a diagnostic is a heuristic, based on the inaccurate estimate that many programs which requrest such conversions do so by mistake, resulting in incorrectness. However, correct programs can exist which do that, and so pointer casting is provided so those programs can be made exceptions to the heuristic. -- 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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-03 18:01 -0700 |
| Message-ID | <86o7iipx8a.fsf@linuxsc.com> |
| In reply to | #173807 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: > On 2023-09-03, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >> [...] >> >>> I wouldn't mind if a future edition of the C standard added a >>> requirement that the } of a non-void function must be unreachable >>> (with an exception for main()). There are languages that have such >>> a requirement, and in my limited experience it works pretty well. >>> >>> The problem is that such a requirement requires the compiler >>> to perform control flow analysis that's not otherwise required. >>> [...] >> >> The problem is that in C such a determination cannot be made >> precisely, for reasons that are both theoretical and practical. >> Only heuristics are possible, but requirements in the C standard >> are never stated in terms of heuristics (and rightly so). > > I believe this is false on both counts. > > There is nothing imprecise about "heuristics". What heuristics > aren't is "accurate". [...] Stop quibbling. The point is that any proposed rule will sometimes give wrong answers, because there is no way for any computable function to give correct assessments in all cases.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-03 16:59 +0200 |
| Message-ID | <ud270u$v8o8$1@dont-email.me> |
| In reply to | #173687 |
On 02/09/2023 23:52, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 02/09/2023 01:02, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> But tell me what dialect of C my 'int fred(void){}' is a valid program
>>>> of. Then tell me why most C compilers are still compiling that dialect
>>>> by default in 2023.
>>> [...]
>>> Can you clarify what point you're making with `int fred(void){}`?
>>> That's a valid function definition and translation unit in every
>>> version
>>> of ISO C going back to C90, by which I mean that it does not violate any
>>> constraint or syntax rule. (I presume we're not concerned with K&R C,
>>> which didn't have void.) It is not a valid *program* for a hosted
>>> implementation in any version of C, since it lacks a `main` function.
>>> A compiler may reasonably warn about the fact that control reaches
>>> the
>>> end of a non-void function, but the standard doesn't require a
>>> diagnostic. Calling `fred` and not using the result is well defined.
>>> Calling `fred` and attempting to use the result has undefined behavior.
>>> No diagnostic is required, up to and including C23. (There are
>>> historical reasons for this, which I won't go into.)
>>
>> Also note that it is perfectly fine to have :
>>
>> int fred(void) { }
>>
>> int boo(void) {
>> int x = fred();
>> return x + 1;
>> }
>>
>> There is nothing in this code that is undefined behaviour - it's all
>> valid C. There is only a problem - undefined behaviour - if the
>> program actually /calls/ "boo".
>
> It's "perfectly fine" only in the sense that it doesn't violate
> a constraint or syntax rule and doesn't cause undefined behavior
> unless it's called. It's still bad code.
Yes.
>
> I wouldn't mind if a future edition of the C standard added a
> requirement that the } of a non-void function must be unreachable
> (with an exception for main()). There are languages that have such
> a requirement, and in my limited experience it works pretty well.
I would not mind that at all either. I don't think it will ever happen.
Backwards compatibility, and the general conservativism of C standards
makes it highly unlikely. It is also not an error that is likely to be
common - or at least, not something that is likely to occur without all
sorts of other messes in code written by someone with little knowledge
or regard for good code.
>
> The problem is that such a requirement requires the compiler
> to perform control flow analysis that's not otherwise required.
Indeed. And even with advanced flow analysis, there will always be
cases where it is impractical to determine if the returns are correct.
> Most large modern compilers already do such analysis for optimization
> and diagnostic purposes; at most they might have to enable it
> at all optimization levels. Small "hobby" compilers might have
> to do some extra work -- but such compilers often aren't fully
> conforming anyway.
Yes. Often even big compilers don't do appropriate analysis unless you
ask for it - "gcc -Wall" is much more limited without "-O1" or "-O2".
(I'd rather "-Wall -O2", or something close to that, were the default
for gcc - but I know that's highly unlikely to change.)
>
> Such a requirement would have been a more substantial burden when
> the language was originally being defined, and inertia probably
> has a lot to do with why it hasn't been imposed since then.
>
Yes.
> I think we'd need a rigorous definition of reachability that's not too
> difficult to implement. It might require adding unnecessary return
> statements in some corner cases, but IMHO that's ok. There's precedent
> in other languages that C could steal.
>
I think it's better to leave that to other languages. A key feature of
C is that it does not change much. It would be difficult to "fix" C
(even if people could agree on what needs fixing) without simultaneously
breaking C.
> Simply requiring a non-void function to have a return statement
> *somewhere* would be far less helpful, and would not be worth the
> effort. It would allow such obviously incorrect code as:
>
> int fred(void) {
> if (condition) return 42;
> }
>
Agreed.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-03 17:50 -0700 |
| Message-ID | <87ledm69tq.fsf@nosuchdomain.example.com> |
| In reply to | #173687 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> I wouldn't mind if a future edition of the C standard added a
> requirement that the } of a non-void function must be unreachable
> (with an exception for main()). There are languages that have such
> a requirement, and in my limited experience it works pretty well.
>
> The problem is that such a requirement requires the compiler
> to perform control flow analysis that's not otherwise required.
> Most large modern compilers already do such analysis for optimization
> and diagnostic purposes; at most they might have to enable it
> at all optimization levels. Small "hobby" compilers might have
> to do some extra work -- but such compilers often aren't fully
> conforming anyway.
>
> Such a requirement would have been a more substantial burden when
> the language was originally being defined, and inertia probably
> has a lot to do with why it hasn't been imposed since then.
>
> I think we'd need a rigorous definition of reachability that's not too
> difficult to implement. It might require adding unnecessary return
> statements in some corner cases, but IMHO that's ok. There's precedent
> in other languages that C could steal.
I found a concrete example: C#.
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/statements#132-end-points-and-reachability
If a statement can possibly be reached by execution, the statement
is said to be reachable. Conversely, if there is no possibility that
a statement will be executed, the statement is said to be
*unreachable*.
...
Note: To determine whether a particular statement or end point is
reachable, the compiler performs flow analysis according to the
reachability rules defined for each statement. The flow analysis
takes into account the values of constant expressions (§12.23) that
control the behavior of statements, but the possible values of
non-constant expressions are not considered. In other words, for
purposes of control flow analysis, a non-constant expression of a
given type is considered to have any possible value of that type.
...
It is a compile-time error for the end point of the block of a
function member or an anonymous function that computes a value to be
reachable. If this error occurs, it typically is an indication that
a return statement is missing (§13.10.5).
*If* a future C standard were to introduce new rules like we've been
discussing, I suggest that adapting the current C# rules could be a good
approach.
--
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-01 10:43 +0200 |
| Message-ID | <ucs87g$3n796$1@dont-email.me> |
| In reply to | #173423 |
On 31/08/2023 21:26, Bart wrote: > On 31/08/2023 18:36, David Brown wrote: >> On 31/08/2023 16:30, Bart wrote: >>> On 31/08/2023 13:36, David Brow > >>> But putting it in the current directory is sloppy. The current >>> location can be arbitrary (or it might not be writeable): >>> >>> c:\random>gcc \proj1\foo.c >>> c:\random>gcc \proj2\bar.c >>> >> >> So don't do that. >> >> Make sure you are in the appropriate directory, then compile - or give >> the output file name directly. As I said, whatever default you use, >> it will be wrong sometimes. > > But it's an extra thing that could be easily have been done right. > Compilers work for us, not us for them. Agreed. A compiler that put its object files in the source directory would be working against me, not for me. Can you really not understand that people don't always agree with your subjective opinions? Different people want different things. The defaults you pick for your tool written by you and for you, are (hopefully) going to work well for /you/. But that doesn't mean they are of any use to anyone else. Personally, I think it might be better to have fewer defaults at all for this kind of thing. I'd be quite happy for a compiler to require an explicit output file for compilation or linking (if it also handles linking). Maybe when compiling, it would accept just an output directory and have a default object file name. If there are no defaults, there are no misunderstandings. (For the record, there are lots of things that gcc has defaults for that I would prefer to be explicit.) > > Suppose gcc decided to put the output files in a root directory, or some > place where it would be a very bad idea to write or overwrite a file. > Suppose bcc had decided to put the output files in "c:\Program Files\bcc\" ? Or better - suppose we /don't/ try to think about worse choices that no tool has made? > You can't just fob people off with 'So don't do that'; it needs to be > fixed. But then neither can you further fob them off with: 'It's always > done that, and further, one person in 1000, or some makefile from 1974, > depends on it, so we can't change it, ever'. > Putting object files in the current directory is a useful default. It won't suit everyone, but it will suit some people. And since almost anyone who has an "everything in one directory" structure will be in that directory when they run their compiler (or make, or whatever), it would give the same effect as your compiler's default choice. I really don't understand what you have against it - other than your knee-jerk reaction of "gcc does it, therefore it must be terrible and I must invent absurd situations to justify myself". > >>> Here, both compilations generate a.exe. But to cap that, both end up >>> in c:\random; the second overwrites the first, something you might be >>> unaware of. >> >> If you are not aware of that, you'll learn pretty quickly! > > It may not have crossed your mind, or if it had, your might assume that > two distinct a.exe files were produced. > True. And you'll learn very quickly. >>> >>> If I do: >>> >>> c:\random[gcc \proj1\foo.c >>> c:\random>gcc \proj2\bar.c >>> >>> then there are three differences from gcc: >>> >>> (1) The executables are called foo.exe and bar.exe respectively >>> (2) They are written to their respective folders >>> (3) The compiler will report exactly what it is doing so there >>> are fewer surprises: >>> >>> Compiling \proj1\foo.c to \proj2\foo.exe >>> >>> You can use -v with gcc, but it is not helpful! >> >> Nor is it helpful for the compiler to tell me what it is doing - > > If the compiler is doing multiple files, especially a slow compiler, > then it is highly useful to know where it's up to, or what it's stuck on. That is not my experience. And I thought the point of your compiler was to be absurdly fast? Still, I've nothing against compilers giving such messages - I just personally prefer not to see them, so I at least want a way to hide them (without hiding useful messages). I have happily used compilers with a "-quiet" flag in the makefile. > > But this seems to be a Linux thing: if I do 'cp *.c dest', then nothing > is output, until you get the prompt back. So, did work, did it copy > anything, was it one big file, or lots of small ones? It certainly is a common Unix practice that you get told when things failed, and sometimes when things worked, but rarely get told that the program is about to do what you asked it to do. And in cases where more information is useful, you use "-v". So you can assume "cp *.c dest" worked - it did what you asked it to do. You did not ask how many files there were, or how big they are - there are other commands to do that. Unix philosophy (which is not always followed) is for one program to do one thing. "cp" copies files - if you want a listing of files, use "ls". Windows philosophy (which is also not always followed) is for every program to re-invent the wheel in a different way and do all sorts of things, because there are no common practices, few common libraries, and most stuff is closed source. > > If I do 'copy *.c test' on Windows, it shows each file copied, and it > tells how many files were copied in all. The 'cp' command needs '-v' to > force to show what it's doing. > > The defaults are backwards. Then add "alias cp='cp -v'" to your .bashrc. Choice is a wonderful thing. (And so is google, so that you don't need to remember the details here.) > >> generally I know what it is doing - it is doing what I told it to do. >> It is only if it can't do that (due to some error) that I want to be >> told. >> >> Again, different defaults suit different uses and different people. >> Plenty of gcc's defaults are inappropriate for me, and I think should >> be different - but your compiler's defaults are no better. You only >> /think/ that your compiler's defaults are good, because they suit you >> personally > > No, they make more sense for casual use from a command line for anybody. I'm sorry, but you are simply wrong here - in /my/ opinion. Your opinion is your own, but you do not speak for anyone but yourself. > >> Do you also have a "-quiet" option to hide non-essential messages? >> That's also something I like in compilers and other tools, if it is >> not the default - though again, preferences vary. > > Yes, I think it's -q. If a lot of files are being processed, then you > might want to turn it off (or if timing, it can make a small difference). > Good. If I were using your compiler, I would add that to my makefile - giving me the options I want rather than the defaults you like. > However gcc's -v option generates 40 times as much output as my compiler > without -q. So it's either far too verbose, or not enough. > I still don't see why a compiler should print out a line to say it is compiling the file you asked it to compile. If I want that information, I have it in the command I typed in. (Or I would have my makefile show the command before it is run.) As for "gcc -v" being verbose - yes, it certainly is. It's not something I have often used. It provides a lot of information that can vary between systems, which is occasionally useful to know about. (I have, for example, used it to see the include search paths used in embedded gcc toolchains.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-01 02:17 -0700 |
| Message-ID | <a9ce76da-1de7-40c7-b9ca-eba8adefba5an@googlegroups.com> |
| In reply to | #173501 |
On Friday, 1 September 2023 at 09:43:43 UTC+1, David Brown wrote: > > Putting object files in the current directory is a useful default. It > won't suit everyone, but it will suit some people. And since almost > anyone who has an "everything in one directory" structure will be in > that directory when they run their compiler (or make, or whatever), it > would give the same effect as your compiler's default choice. > > I really don't understand what you have against it - other than your > knee-jerk reaction of "gcc does it, therefore it must be terrible and I > must invent absurd situations to justify myself". > It was the old way of doing things. Noways most people prefer the "out of tree build". Basically your valuable, human-generated, human-meaningful source files go in one directory, the object files and various other intermediates automatically generated by tools are sequestrated in another directory. The new way is in my view a lot better, but it does make it a bit more difficult to set up tools like "make".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-01 13:26 +0200 |
| Message-ID | <ucshq0$3ogjc$2@dont-email.me> |
| In reply to | #173504 |
On 01/09/2023 11:17, Malcolm McLean wrote: > On Friday, 1 September 2023 at 09:43:43 UTC+1, David Brown wrote: >> >> Putting object files in the current directory is a useful default. It >> won't suit everyone, but it will suit some people. And since almost >> anyone who has an "everything in one directory" structure will be in >> that directory when they run their compiler (or make, or whatever), it >> would give the same effect as your compiler's default choice. >> >> I really don't understand what you have against it - other than your >> knee-jerk reaction of "gcc does it, therefore it must be terrible and I >> must invent absurd situations to justify myself". >> > It was the old way of doing things. It is also the current way of doing things for smaller projects. And out of tree builds are not new. People prefer different ways of arranging their builds, which is absolutely fine. > Noways most people prefer the "out of tree build". Some do, some don't, and some do for some projects and not others. Unless you have the statistics to prove it, please don't try to speak for "most people". I also usually prefer out-of-tree builds for bigger projects (but I find in-tree builds convenient for small single-file programs). But "you and I" does not mean "most people". > Basically your valuable, > human-generated, human-meaningful source files go in one directory, > the object files and various other intermediates automatically generated by > tools are sequestrated in another directory. > The new way is in my view a lot better, but it does make it a bit more difficult > to set up tools like "make". It's not hard at all. You do have to consider it in the makefile, but I would not classify it as "difficult".
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-01 11:35 +0100 |
| Message-ID | <ucseq9$3o9ic$1@dont-email.me> |
| In reply to | #173501 |
On 01/09/2023 09:43, David Brown wrote:
> On 31/08/2023 21:26, Bart wrote:
> Putting object files in the current directory is a useful default.
'gcc -c' will do that if the input file is in the same current directory.
So if the current directory happens to be /abc, compiling hello.c will
produce /abc/hello.o from /abc/hello.c.
Everyone has been saying, do the build from inside the source directory.
They've also been saying don't put the object file in the source directory!
That means gcc breaks that rule by default. But look at this pattern:
Object file written to:
abc> gcc hello.c /abc/hello.o
abc> gcc /abc/hello.c /abc/hello.o
xyz> gcc /abc/hello.c /xyz/hello.o
This looks wrong.
> It
> won't suit everyone, but it will suit some people. And since almost
> anyone who has an "everything in one directory" structure will be in
> that directory when they run their compiler (or make, or whatever), it
> would give the same effect as your compiler's default choice.
>
> I really don't understand what you have against it - other than your
> knee-jerk reaction of "gcc does it, therefore it must be terrible
Or "gcc does it, therefore it must be OK, and the model of how all
software must work"
If I give gcc 100 files to build, will it finish it in a few seconds, or
do I go and make a drink? Simply listing the same of each file will give
a useful indication of where it's up to and how until it's done.
Presumably, you can't see the point of those progress bars you see in GUIs?
> and I
> must invent absurd situations to justify myself".
I raised the issue because the OP did this:
cc64 -c -out:cclib/cclib.obj cclib/cclib.i
I assumed this was out of habit because other compilers required it, and
I double-checked mine.
Note that the current directory is not known in this posted fragment.
With bcc however, I KNOW that with:
bcc -c cclib/cclib.i
the .obj file will be cclib/cclib.obj, in the same directory, as that is
the clear intent. But with:
gcc -c cclib/cclib.i
I don't where the .o file will be; I will guess it is one directory
above. If the path was /cclib/cclib.i, then it could be anywhere in the
file system.
> I still don't see why a compiler should print out a line to say it is
> compiling the file you asked it to compile. If I want that information,
> I have it in the command I typed in.
It is confirming the input file, output file, the extensions that will
be used, and the operations that can be done.
The output file is certainly not clear from what you typed:
gcc -shared -oprog prog.c
On Windows, this writes prog.exe, NOT prog.dll that you might expect.
The destination is not clear from what you typed:
root@DESKTOP-11:/mnt/c/c# gcc /abc/hello.c
The destination here is derived from the CWD, and will be
/mnt/c/c/hello.o. Not what you typed.
The operation being done is not clear from what you typed as that
depends on 'options' file:
gcc @options hello.c
The files being compiled are not always clear from what you typed:
gcc *.c
gcc @input
There could 1 file, or 1000 files. You're really not curious as to what
it's doing?
I've noticed that ./configure and makefile scripts are not usually
silent; quite the opposite! apt-get install likes to give a running
commentary too.
So verbosity is good when a tool is verbose. Verbosity is bad when a
tool usually says nothing. This sounds very much like defending or
excusing all the tools you use against ANY sort or criticism.
Summary:
gcc prog.c producing 0 bytes of output: Great
gcc prog.c -v producing 5000 bytes of output: Great
bcc prog producing 25 bytes of output: Terrible!
Have I summed up your view correctly?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-01 13:39 +0200 |
| Message-ID | <ucsihq$3opnq$1@dont-email.me> |
| In reply to | #173511 |
On 01/09/2023 12:35, Bart wrote: > On 01/09/2023 09:43, David Brown wrote: >> On 31/08/2023 21:26, Bart wrote: > >> Putting object files in the current directory is a useful default. > > 'gcc -c' will do that if the input file is in the same current directory. > > So if the current directory happens to be /abc, compiling hello.c will > produce /abc/hello.o from /abc/hello.c. > > Everyone has been saying, do the build from inside the source directory. > They've also been saying don't put the object file in the source directory! Really? Everyone? Do you bother to read the posts here, or do you just cherry-pick a few snippets that you can complain about? I have said /many/ times that sometimes people what out-of-tree builds, and sometimes they want in-tree builds, and that there are pros and cons of each. Generally you are better with out-of-tree builds for big projects, while it can be convenient with in-tree builds for small projects. Will you please acknowledge that you have read that paragraph, and that you understand it, so that we can go on? > > That means gcc breaks that rule by default. But look at this pattern: > > Object file written to: > > abc> gcc hello.c /abc/hello.o > abc> gcc /abc/hello.c /abc/hello.o > xyz> gcc /abc/hello.c /xyz/hello.o > > This looks wrong. It only looks wrong because you make it look wrong. Every time, the file is written to "./hello.o". Simple and consistent. And if that's not what you want, then specify the output file that you /do/ want. (Or write a wrapper. Or use make. Or do one of a dozen alternatives that get you what you wanted, rather than bursting a blood vessel and blaming the wrong people for your own wilful and self-created problems.) > >> It won't suit everyone, but it will suit some people. And since >> almost anyone who has an "everything in one directory" structure will >> be in that directory when they run their compiler (or make, or >> whatever), it would give the same effect as your compiler's default >> choice. >> >> I really don't understand what you have against it - other than your >> knee-jerk reaction of "gcc does it, therefore it must be terrible > > Or "gcc does it, therefore it must be OK, and the model of how all > software must work" No one has /ever/ said anything of the sort. You are tilting at windmills again. > > If I give gcc 100 files to build, will it finish it in a few seconds, or > do I go and make a drink? Simply listing the same of each file will give > a useful indication of where it's up to and how until it's done. I suggest you don't bother with gcc - just go and have that drink. Maybe you'll feel better. > > Presumably, you can't see the point of those progress bars you see in GUIs? Presumably you are making stuff up again. I would suggest that the answer to your problem is that you should not call gcc on 100 files - the normal practice is to use make (or something similar) to call gcc a hundred times on one file at a time, taking advantage of modern multi-core machines, skipping unnecessary re-builds, and generally being more efficient. (And also printing out "Compiling file.c" lines if you want.) But I'll keep quite, because I know you don't want a useful suggestion that would hinder you in your god-given right to be the pain in your own arse. > > Have I summed up your view correctly? > No, but that is only to be expected from you.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-01 14:09 +0100 |
| Message-ID | <ucsnr7$3pipi$1@dont-email.me> |
| In reply to | #173515 |
On 01/09/2023 12:39, David Brown wrote:
> On 01/09/2023 12:35, Bart wrote:
>> Object file written to:
>>
>> abc> gcc hello.c /abc/hello.o
>> abc> gcc /abc/hello.c /abc/hello.o
>> xyz> gcc /abc/hello.c /xyz/hello.o
>>
>> This looks wrong.
>
> It only looks wrong because you make it look wrong. Every time, the
> file is written to "./hello.o". Simple and consistent.
And dangerous, since "." is variable. And it can't be consistent since
that third line writes it to xyz not abc. With bcc (excuse use of /
rather than \):
abc> bcc hello.c /abc/hello.obj
abc> bcc /abc/hello.c /abc/hello.obj
xyz> bcc /abc/hello.c /abc/hello.obj
Position-independent compilation!
>> Or "gcc does it, therefore it must be OK, and the model of how all
>> software must work"
>
> No one has /ever/ said anything of the sort. You are tilting at
> windmills again.
>
>>
>> If I give gcc 100 files to build, will it finish it in a few seconds,
>> or do I go and make a drink? Simply listing the same of each file will
>> give a useful indication of where it's up to and how until it's done.
>
> I suggest you don't bother with gcc - just go and have that drink. Maybe
> you'll feel better.
>
>>
>> Presumably, you can't see the point of those progress bars you see in
>> GUIs?
>
> Presumably you are making stuff up again.
And you're not answering the question. Progress bars obviously ARE
useful, but not for a compiler?
>> Have I summed up your view correctly?
>>
>
> No, but that is only to be expected from you.
Have I then summed up the capabilities of gcc correctly?
That it either it says nothing, or spouts pages of nonsense.
But then, you don't really care do you, as you mainly use such compilers
from inside a script, where its behaviour is carefully orchestrated.
So the actual problems others experience are no skin off your nose.
I'm glad that my own product is friendlier, helps with such problems,
and is amenable to being tweaked according to suggestions.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-01 15:33 +0200 |
| Message-ID | <ucsp7m$3pmm2$2@dont-email.me> |
| In reply to | #173519 |
On 01/09/2023 15:09, Bart wrote: > On 01/09/2023 12:39, David Brown wrote: >> On 01/09/2023 12:35, Bart wrote: > >>> Object file written to: >>> >>> abc> gcc hello.c /abc/hello.o >>> abc> gcc /abc/hello.c /abc/hello.o >>> xyz> gcc /abc/hello.c /xyz/hello.o >>> >>> This looks wrong. >> >> It only looks wrong because you make it look wrong. Every time, the >> file is written to "./hello.o". Simple and consistent. > > And dangerous, since "." is variable. And it can't be consistent since > that third line writes it to xyz not abc. With bcc (excuse use of / > rather than \): > > > abc> bcc hello.c /abc/hello.obj > abc> bcc /abc/hello.c /abc/hello.obj > xyz> bcc /abc/hello.c /abc/hello.obj > > Position-independent compilation! > >>> Or "gcc does it, therefore it must be OK, and the model of how all >>> software must work" >> >> No one has /ever/ said anything of the sort. You are tilting at >> windmills again. >> >>> >>> If I give gcc 100 files to build, will it finish it in a few seconds, >>> or do I go and make a drink? Simply listing the same of each file >>> will give a useful indication of where it's up to and how until it's >>> done. >> >> I suggest you don't bother with gcc - just go and have that drink. >> Maybe you'll feel better. >> >>> >>> Presumably, you can't see the point of those progress bars you see in >>> GUIs? >> >> Presumably you are making stuff up again. > > And you're not answering the question. Progress bars obviously ARE > useful, but not for a compiler? > I presumed your question was rhetorical. Were you really asking something that stupid? (And that was a rhetorical question.) >>> Have I summed up your view correctly? >>> >> >> No, but that is only to be expected from you. > > Have I then summed up the capabilities of gcc correctly? No. > > That it either it says nothing, or spouts pages of nonsense. No. > > But then, you don't really care do you, as you mainly use such compilers > from inside a script, where its behaviour is carefully orchestrated. No. > > So the actual problems others experience are no skin off your nose. No. > > I'm glad that my own product is friendlier, helps with such problems, > and is amenable to being tweaked according to suggestions. > No. Were there more inaccuracies you want to make up? Any time you want to change from rant mode to listen mode, just let me know.
[toc] | [prev] | [next] | [standalone]
Page 17 of 18 — ← Prev page 1 … 15 16 [17] 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web