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 9 of 18 — ← Prev page 1 … 7 8 [9] 10 11 … 18 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-02 23:28 +0100 |
| Message-ID | <878r9ojjls.fsf@bsb.me.uk> |
| In reply to | #173604 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Saturday, 2 September 2023 at 01:14:36 UTC+1, Ben Bacarisse wrote: >> Bart <b...@freeuk.com> writes: >> >> > On 01/09/2023 19:07, Ben Bacarisse wrote: >> >> Bart <b...@freeuk.com> writes: >> >> >> >>> On 01/09/2023 14:53, Ben Bacarisse wrote: >> >>>> Bart <b...@freeuk.com> writes: >> >>>> >> >>>>> On 01/09/2023 13:08, Richard Harnden wrote: >> >>>>>> On 01/09/2023 12:01, Bart wrote: >> >>>> >> >>>>>>> We are talking about compilers like gcc where you make up your own rules >> >>>>>>> as to show strictly you want your program treated: >> >>>>>>> >> >>>>>>> gcc prog.c zero warnings, writes .exe >> >>>>>>> gcc @options prog.c 10000 warnings, but it still writes .exe >> >>>>>>> gcc @options prog.c 10000 warning and 1 error, no .exe >> >>>> >> >>>> Which would you choose as the one and only behaviour? >> >> No answer? I'll look at the rest of your post, if you decide to address >> >> this point... >> > You want an answer, I'd go with the first, since then the three compilers I >> > use the most work the same way. >> > >> > That's not completely satisfactory, >> It's totally unacceptable to me and, I suspect, a lot of other people. >> I usually don't want gcc extensions and I want to be able specify the >> ISO C standard to use at the very least. But I also want as much help >> spotting errors as the compiler can give me. >> > Generally gcc in default mode gives sensible warnings which either indicate > actual bugs, or odd programming which should be cleaned up. I don't find that to be the case. >> You say, dismissively, that one can "make up ones your rules" with gcc, >> so I am asking for you to say exactly what you don't want me to be able >> to ask for in terms of checking and/or its absence. Just how crippled >> and annoying would I find gcc to be if you were in charge? How much >> choice will you take away? >> > In most software, every option you provide represents a failure rather than > an enhancement. It's often a symptom of sloppy design - a lot of functions > need parameterising, and instead of doing the hard work and finding the > parameters to use, the designer just gives the job to the user. It's often a > symptom of design by programmers rather than user-interface people. > Programmers don't mind -gamma-correction=1.1, but it's a nightmare to > someone who just wants to watch telly. Interfaces should be designed for the target users. It is a nuisance to me that most GUI programs are not designed for people like me as the target user. Trivial example: the default PDF reader on my system is very capable, but of course I can't search for a regular expression as that would confuse the other users. Ditto the web browser. There was a time when users like me were better catered for. There were, in some desktop systems, "hidden" options to turn on some or all of this sort of "advanced stuff", but even this seems to be going out of fashion. > I suppose you could argue that a compiler is an exception to the > general rule that programmers shouldn't design interfaces. However it is covered by the better rule that interfaces should suit the target users. You can't satisfy everyone, of course, but people writing C programs have very different requirements to people watching television. > But the > general rule is that options make a program easier to write and harder > to use. I suspect that's one of your "general rules" where every suggested exception would be waved away, so instead I'll ask for your best example. What is, in your mind, the archetypal program that is easier to write and harder to use because of the options? That would help me to understand what point you are making here. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-02 20:09 -0700 |
| Message-ID | <f1a10620-2d2a-4b10-b570-c05adca2d17en@googlegroups.com> |
| In reply to | #173691 |
On Saturday, 2 September 2023 at 23:28:30 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > On Saturday, 2 September 2023 at 01:14:36 UTC+1, Ben Bacarisse wrote: > >> Bart <b...@freeuk.com> writes: > >> > >> > On 01/09/2023 19:07, Ben Bacarisse wrote: > >> >> Bart <b...@freeuk.com> writes: > >> >> > >> >>> On 01/09/2023 14:53, Ben Bacarisse wrote: > >> >>>> Bart <b...@freeuk.com> writes: > >> >>>> > >> >>>>> On 01/09/2023 13:08, Richard Harnden wrote: > >> >>>>>> On 01/09/2023 12:01, Bart wrote: > >> >>>> > >> >>>>>>> We are talking about compilers like gcc where you make up your own rules > >> >>>>>>> as to show strictly you want your program treated: > >> >>>>>>> > >> >>>>>>> gcc prog.c zero warnings, writes .exe > >> >>>>>>> gcc @options prog.c 10000 warnings, but it still writes .exe > >> >>>>>>> gcc @options prog.c 10000 warning and 1 error, no .exe > >> >>>> > >> >>>> Which would you choose as the one and only behaviour? > >> >> No answer? I'll look at the rest of your post, if you decide to address > >> >> this point... > >> > You want an answer, I'd go with the first, since then the three compilers I > >> > use the most work the same way. > >> > > >> > That's not completely satisfactory, > >> It's totally unacceptable to me and, I suspect, a lot of other people. > >> I usually don't want gcc extensions and I want to be able specify the > >> ISO C standard to use at the very least. But I also want as much help > >> spotting errors as the compiler can give me. > >> > > Generally gcc in default mode gives sensible warnings which either indicate > > actual bugs, or odd programming which should be cleaned up. > I don't find that to be the case. > >> You say, dismissively, that one can "make up ones your rules" with gcc, > >> so I am asking for you to say exactly what you don't want me to be able > >> to ask for in terms of checking and/or its absence. Just how crippled > >> and annoying would I find gcc to be if you were in charge? How much > >> choice will you take away? > >> > > In most software, every option you provide represents a failure rather than > > an enhancement. It's often a symptom of sloppy design - a lot of functions > > need parameterising, and instead of doing the hard work and finding the > > parameters to use, the designer just gives the job to the user. It's often a > > symptom of design by programmers rather than user-interface people. > > Programmers don't mind -gamma-correction=1.1, but it's a nightmare to > > someone who just wants to watch telly. > > Interfaces should be designed for the target users. It is a nuisance to > me that most GUI programs are not designed for people like me as the > target user. > > Trivial example: the default PDF reader on my system is very capable, > but of course I can't search for a regular expression as that would > confuse the other users. Ditto the web browser. > Exactly. Regular expressions are too hard to use. Unless you happen to be a programmer. In fact they're too hard for me to use - I seldom work with text so I almost never use regular expressions. Where I do it's a case of looking up the syntax. > > There was a time when users like me were better catered for. There > were, in some desktop systems, "hidden" options to turn on some or all > of this sort of "advanced stuff", but even this seems to be going out of > fashion. > Because programmers write programs, they often design user interfaces. However large professional software companies employ ergonomics experts, taking that job away from the programmers. So as you say, "advanced" options are often culled. All it takes is for the user to somehow acidentally set the program into advanced mode, and he can't use it, and that's an expensive call to technical support. > > > I suppose you could argue that a compiler is an exception to the > > general rule that programmers shouldn't design interfaces. > > However it is covered by the better rule that interfaces should suit the > target users. You can't satisfy everyone, of course, but people writing > C programs have very different requirements to people watching television. > No-one is going to deny that interfaces should suit the target users. But whilst true, it's not helpful. "Programmers shouldn't design interfaces" is more controversial (often they do, often there is no choice because unlike Microsoft, you are to small to have a "usability lab" all products have to go through) . So that makes it worth saying. > > > But the > > general rule is that options make a program easier to write and harder > > to use. > > I suspect that's one of your "general rules" where every suggested > exception would be waved away, so instead I'll ask for your best > example. What is, in your mind, the archetypal program that is easier > to write and harder to use because of the options? That would help me > to understand what point you are making here. > OK, let's take optimisation. If I were specifying a compiler, I'd say, "I want optimisation to be so fast that there is no noticeable diference between the speed of optimised and non-optimised builds. And I want stack trace information to be attached to the optimised build with no noticeable impact on the speed of execution, and for that information to be encrypted so that it doesn't assist reverse engineering". Now what's going to happen? Probably my engineers are going to say that this can't be achieved. Maybe by limiting the users to a conservative subset of C they can give the optimiser an easier job. But the optimisation problem incorporates the halting problem, there will always be some aggressive optimisations that take a long time. And stack trace information - unfortunately programmer tend to put trivial function calls in the inner loop. So I can maybe have some of what I'm asking for, but not fully, and I'll have to compromise on some of the other goals, like supporting fancy language constructs. So, reluctantly, I agree that I can't have what I want. So we'll need an option. Debug mode and release mode, maybe more. But the point is that the option represents a failure to achieve what we want. For sound technical reasons, but still a falure. The ideal compiler wouldn't need an option. And in fact the option is going to cause trouble. Because release mode is different to debug mode, you're going to get the occasional bug which manifests itself in release mode but not debug mode. And that bug will tend to be caught late and be difficult to track down. There's also the posibility that people willl accidentally ship executables compiled in "debug" mode. The compiler is a worse compiler because we've been forced to add the options, They represent failure, not enhancements.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-03 07:15 +0000 |
| Message-ID | <20230903000924.766@kylheku.com> |
| In reply to | #173700 |
On 2023-09-03, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > Because programmers write programs, they often design user interfaces. > However large professional software companies employ ergonomics > experts, taking that job away from the programmers. That used to make for better user interfaces and experiences. Nowadays, you would get a better UX if you let the programmers at it. But that would be bad. The purpose of bringing in professionals is deliberate degradation of the user experience in order to optimize for extracting value from the user. There is a word for this now: "enshittification". If the app is free (the market rate for most apps), then a good experience in that app that doesn't bring you $$$ isn't worth a damn to the app's vendor.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-03 03:03 -0700 |
| Message-ID | <4a326516-bb44-430f-a9e8-44a3328b3208n@googlegroups.com> |
| In reply to | #173728 |
On Sunday, 3 September 2023 at 08:15:28 UTC+1, Kaz Kylheku wrote: > On 2023-09-03, Malcolm McLean <malcolm.ar...@gmail.com> wrote: > > Because programmers write programs, they often design user interfaces. > > However large professional software companies employ ergonomics > > experts, taking that job away from the programmers. > That used to make for better user interfaces and experiences. Nowadays, > you would get a better UX if you let the programmers at it. But that > would be bad. > > The purpose of bringing in professionals is deliberate degradation > of the user experience in order to optimize for extracting value from > the user. > > There is a word for this now: "enshittification". > > If the app is free (the market rate for most apps), then a good > experience in that app that doesn't bring you $$$ isn't worth a > damn to the app's vendor. > Markets do sometimes throw up perverse incentives. But that's not why professional ergonmoics experts are employed, at least primarily.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-03 18:53 +0000 |
| Message-ID | <20230903115259.851@kylheku.com> |
| In reply to | #173743 |
On 2023-09-03, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > On Sunday, 3 September 2023 at 08:15:28 UTC+1, Kaz Kylheku wrote: >> If the app is free (the market rate for most apps), then a good >> experience in that app that doesn't bring you $$$ isn't worth a >> damn to the app's vendor. >> > Markets do sometimes throw up perverse incentives. > But that's not why professional ergonmoics experts are employed, at > least primarily. OTOH, if some find themselves *unemployed*, that could be why. :) -- 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-03 16:24 +0100 |
| Message-ID | <87r0nfwa8d.fsf@bsb.me.uk> |
| In reply to | #173700 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Saturday, 2 September 2023 at 23:28:30 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> > On Saturday, 2 September 2023 at 01:14:36 UTC+1, Ben Bacarisse wrote: >> >> Bart <b...@freeuk.com> writes: >> >> >> >> > On 01/09/2023 19:07, Ben Bacarisse wrote: >> >> >> Bart <b...@freeuk.com> writes: >> >> >> >> >> >>> On 01/09/2023 14:53, Ben Bacarisse wrote: >> >> >>>> Bart <b...@freeuk.com> writes: >> >> >>>> >> >> >>>>> On 01/09/2023 13:08, Richard Harnden wrote: >> >> >>>>>> On 01/09/2023 12:01, Bart wrote: >> >> >>>> >> >> >>>>>>> We are talking about compilers like gcc where you make up your own rules >> >> >>>>>>> as to show strictly you want your program treated: >> >> >>>>>>> >> >> >>>>>>> gcc prog.c zero warnings, writes .exe >> >> >>>>>>> gcc @options prog.c 10000 warnings, but it still writes .exe >> >> >>>>>>> gcc @options prog.c 10000 warning and 1 error, no .exe >> >> >>>> >> >> >>>> Which would you choose as the one and only behaviour? >> >> >> No answer? I'll look at the rest of your post, if you decide to address >> >> >> this point... >> >> > You want an answer, I'd go with the first, since then the three compilers I >> >> > use the most work the same way. >> >> > >> >> > That's not completely satisfactory, >> >> It's totally unacceptable to me and, I suspect, a lot of other people. >> >> I usually don't want gcc extensions and I want to be able specify the >> >> ISO C standard to use at the very least. But I also want as much help >> >> spotting errors as the compiler can give me. >> >> >> > Generally gcc in default mode gives sensible warnings which either indicate >> > actual bugs, or odd programming which should be cleaned up. >> I don't find that to be the case. >> >> You say, dismissively, that one can "make up ones your rules" with gcc, >> >> so I am asking for you to say exactly what you don't want me to be able >> >> to ask for in terms of checking and/or its absence. Just how crippled >> >> and annoying would I find gcc to be if you were in charge? How much >> >> choice will you take away? >> >> >> > In most software, every option you provide represents a failure rather than >> > an enhancement. It's often a symptom of sloppy design - a lot of functions >> > need parameterising, and instead of doing the hard work and finding the >> > parameters to use, the designer just gives the job to the user. It's often a >> > symptom of design by programmers rather than user-interface people. >> > Programmers don't mind -gamma-correction=1.1, but it's a nightmare to >> > someone who just wants to watch telly. >> >> Interfaces should be designed for the target users. It is a nuisance to >> me that most GUI programs are not designed for people like me as the >> target user. >> >> Trivial example: the default PDF reader on my system is very capable, >> but of course I can't search for a regular expression as that would >> confuse the other users. Ditto the web browser. >> > Exactly. Regular expressions are too hard to use. Unless you happen to > be a programmer. In fact they're too hard for me to use - I seldom > work with text so I almost never use regular expressions. Where I do > it's a case of looking up the syntax. I am not sure what part of my remark you are agreeing with. I'll take it that you agree that I am not well-catered for by modern "well-designed" user interfaces. >> There was a time when users like me were better catered for. There >> were, in some desktop systems, "hidden" options to turn on some or all >> of this sort of "advanced stuff", but even this seems to be going out of >> fashion. >> > Because programmers write programs, they often design user interfaces. > However large professional software companies employ ergonomics > experts, taking that job away from the programmers. Ergonomics experts often design interfaces that I find hard to use. To take one example, I want to use common key binding across applications, but the experts seem to think there is only one such set (and it comes from an OS I have not used for years), so I can't use the bindings my fingers "know" about. There are probably a few UI experts who really do know how to design easy to use, powerful interfaces that suit a wide rage of users with differing expectations and experience, but most of them just know how to make easy tasks easy for the most commonly encountered users. > So as you say, > "advanced" options are often culled. All it takes is for the user to somehow > acidentally set the program into advanced mode, and he can't use it, and > that's an expensive call to technical support. Yes, I know why it happens. Apparently, though, a solution that prevents accidents is beyond the wit of ergonomics experts. An expert who knows how to make tasks easy, should also know how to make some things well-nigh impossible by accident. >> > I suppose you could argue that a compiler is an exception to the >> > general rule that programmers shouldn't design interfaces. >> >> However it is covered by the better rule that interfaces should suit the >> target users. You can't satisfy everyone, of course, but people writing >> C programs have very different requirements to people watching television. >> > No-one is going to deny that interfaces should suit the target users. But > whilst true, it's not helpful. "Programmers shouldn't design interfaces" > is more controversial (often they do, often there is no choice because unlike > Microsoft, you are to small to have a "usability lab" all products have to > go through) . So that makes it worth saying. But it says very little because "programmers" are not a uniform group. For example, the HCI research team I used to work alongside was almost entirely made up of people who could be described as programmers. Sure, they were also psychologists, linguists and graphic designers, but they all had top-notch programming skills as well. >> > But the >> > general rule is that options make a program easier to write and harder >> > to use. >> >> I suspect that's one of your "general rules" where every suggested >> exception would be waved away, so instead I'll ask for your best >> example. What is, in your mind, the archetypal program that is easier >> to write and harder to use because of the options? That would help me >> to understand what point you are making here. >> > OK, let's take optimisation. > If I were specifying a compiler, I'd say, "I want optimisation to be so fast > that there is no noticeable diference between the speed of optimised and > non-optimised builds. And I want stack trace information to be attached to > the optimised build with no noticeable impact on the speed of execution, > and for that information to be encrypted so that it doesn't assist reverse > engineering". ... > So, reluctantly, I agree that I can't have what I want. So we'll need > an option. Debug mode and release mode, maybe more. I see. Now I know what you were getting at: options are sometimes a consequence of impossible specifications. That's not an interesting observation (to me) but it certainly does not constitute a general rule about programs. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-03 12:22 -0700 |
| Message-ID | <861qffqcxw.fsf@linuxsc.com> |
| In reply to | #173796 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Ergonomics experts often design interfaces that I find hard to > use. To take one example, I want to use common key binding across > applications, but the experts seem to think there is only one such > set (and it comes from an OS I have not used for years), so I > can't use the bindings my fingers "know" about. I'm curious to know more about the specifics here. What key bindings, which "one set to rule them all", what domain of applications followed that set? Also I'm curious to know how you know (or why you suspect) the choices were made by experts? What abilities or skills qualify them as experts? > There are probably a few UI experts who really do know how to > design easy to use, powerful interfaces that suit a wide rage of > users with differing expectations and experience, but most of them > just know how to make easy tasks easy for the most commonly > encountered users. I am not an expert, but I have three pieces of advice for anyone who wants to design a good user interface. 1. Get a copy of TOG on interface, and read it. (And read it again later.) 2. Follow Bill Atkinson's UI precepts: * "The user has lost the manual" * "... and didn't have time to read it before losing it" 3. Avoid anything that looks like a product from Microsoft, where it seems like everyone thinks user interfaces should use the same ideas and techniques as are used in video games.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-04 02:01 +0100 |
| Message-ID | <871qfewy2m.fsf@bsb.me.uk> |
| In reply to | #173814 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Ergonomics experts often design interfaces that I find hard to >> use. To take one example, I want to use common key binding across >> applications, but the experts seem to think there is only one such >> set (and it comes from an OS I have not used for years), so I >> can't use the bindings my fingers "know" about. > > I'm curious to know more about the specifics here. What key > bindings, which "one set to rule them all", what domain of > applications followed that set? I like to use Emacs keybindings. I can use them in bash and programs that use GNU readline which includes a lot of REPL programs like ghci, swipl, gp and so on. I can't use them in the Gnome browser. One big annoyance is not strictly to do with keys but is UI-related. I am used to having selected text available for immediate pasting with the middle button, but several applications have started to auto select text in certain situations and I loose my selection. > Also I'm curious to know how > you know (or why you suspect) the choices were made by experts? I don't. Maybe I should have put "experts" it scare quotes. I stated to notice the loss of configuration when Gnome got a team in to clean up the interface and develop a set of rules to simplify things for the average user. They may not have been experts, but the announcement suggested they were. > What abilities or skills qualify them as experts? Too big a topic. I hope you won't mind if I just don't even try to answer that. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-05 21:40 -0700 |
| Message-ID | <86sf7roqxh.fsf@linuxsc.com> |
| In reply to | #173849 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> >>> Ergonomics experts often design interfaces that I find hard to >>> use. To take one example, I want to use common key binding across >>> applications, but the experts seem to think there is only one such >>> set (and it comes from an OS I have not used for years), so I >>> can't use the bindings my fingers "know" about. >> >> I'm curious to know more about the specifics here. What key >> bindings, which "one set to rule them all", what domain of >> applications followed that set? > > I like to use Emacs keybindings. I can use them in bash and programs > that use GNU readline which includes a lot of REPL programs like ghci, > swipl, gp and so on. I can't use them in the Gnome browser. Clearly emacs needs to add M-x new-browser-frame . By the way, have you tried the Brave browser? I haven't yet but am thinking about it. (The question here is mostly rhetorical, feel free to duck it unless you really want to answer.) > One big annoyance is not strictly to do with keys but is UI-related. I > am used to having selected text available for immediate pasting with the > middle button, but several applications have started to auto select text > in certain situations and I loose my selection. Clearly a need for selection rings so ESC <middle button> would paste the second most recent selection, etc. More seriously, one-level-deep "clipboards" really bug me. I know one is a lot lot better than zero, but even just two or three would be a lot better than one. (And don't get me started on so-called "browser history".) >> Also I'm curious to know how >> you know (or why you suspect) the choices were made by experts? > > I don't. Maybe I should have put "experts" it scare quotes. I stated > to notice the loss of configuration when Gnome got a team in to clean up > the interface and develop a set of rules to simplify things for the > average user. They may not have been experts, but the announcement > suggested they were. I see. I've been trying different u/li/nux windowing systems recently, haven't found one yet that I really like (or at least can stand). I got a suggestion to try xfce, which I expect to do someday. >> What abilities or skills qualify them as experts? > > Too big a topic. I hope you won't mind if I just don't even try to > answer that. Don't mind at all. Probably I should mention that I am used to associating the word ergonomics with (mostly) physical attributes, and not so much with logical attributes like key bindings. Maybe the word has expanded its scope since I first learned it. That said, your answers here have been quite illuminating.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-06 17:06 +0100 |
| Subject | [OT] Re: bart again (UCX64) |
| Message-ID | <87edjbqoab.fsf_-_@bsb.me.uk> |
| In reply to | #174108 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>> >>>> Ergonomics experts often design interfaces that I find hard to >>>> use. To take one example, I want to use common key binding across >>>> applications, but the experts seem to think there is only one such >>>> set (and it comes from an OS I have not used for years), so I >>>> can't use the bindings my fingers "know" about. >>> >>> I'm curious to know more about the specifics here. What key >>> bindings, which "one set to rule them all", what domain of >>> applications followed that set? >> >> I like to use Emacs keybindings. I can use them in bash and programs >> that use GNU readline which includes a lot of REPL programs like ghci, >> swipl, gp and so on. I can't use them in the Gnome browser. > > Clearly emacs needs to add M-x new-browser-frame . :-) > By the way, have you tried the Brave browser? Because you mentioned it, just now. It's exactly like chrome but with various blockers and some pestering about a rewards scheme. I'll keep it for a while to see what I think. >> One big annoyance is not strictly to do with keys but is UI-related. I >> am used to having selected text available for immediate pasting with the >> middle button, but several applications have started to auto select text >> in certain situations and I loose my selection. > > Clearly a need for selection rings so ESC <middle button> would > paste the second most recent selection, etc. > > More seriously, one-level-deep "clipboards" really bug me. I > know one is a lot lot better than zero, but even just two or > three would be a lot better than one. Yes. But I'd still prefer it if applications did not clobber my selection. I run Gpaste to give me a full selection history, but I'd rather not have to use it at all. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-03 18:02 -0700 |
| Message-ID | <e17448fc-5b70-4141-bc0a-1c601a1f9927n@googlegroups.com> |
| In reply to | #173796 |
On Sunday, 3 September 2023 at 16:24:50 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > On Saturday, 2 September 2023 at 23:28:30 UTC+1, Ben Bacarisse wrote: > >> Malcolm McLean <malcolm.ar...@gmail.com> writes: > > Ergonomics experts often design interfaces that I find hard to use. To > take one example, I want to use common key binding across applications, > but the experts seem to think there is only one such set (and it comes > from an OS I have not used for years), so I can't use the bindings my > fingers "know" about. > > There are probably a few UI experts who really do know how to design > easy to use, powerful interfaces that suit a wide rage of users with > differing expectations and experience, but most of them just know how to > make easy tasks easy for the most commonly encountered users. > It's a new discipline, so some basic mistakes are still made. For instance Microsoft released Windows 8, which had a mobile-phone style interface. Completely unsuitable and unusable for a personal computer. It was swiftly withdraw. But that such a large company could have made such a blunder with its central product tells you how immature the field really is. One problem is that, with many software packages, a few routine and basic tasks are easy, and can be done without training. But anything more complicated is very difficult. We spend a fortune making documents and training videos for our products, and we still haven't got it right. > > > No-one is going to deny that interfaces should suit the target users. But > > whilst true, it's not helpful. "Programmers shouldn't design interfaces" > > is more controversial (often they do, often there is no choice because unlike > > Microsoft, you are to small to have a "usability lab" all products have to > > go through) . So that makes it worth saying. > But it says very little because "programmers" are not a uniform group. > For example, the HCI research team I used to work alongside was almost > entirely made up of people who could be described as programmers. Sure, > they were also psychologists, linguists and graphic designers, but they > all had top-notch programming skills as well. > A programmer can also wear another hat, that's true. > > > So, reluctantly, I agree that I can't have what I want. So we'll need > > an option. Debug mode and release mode, maybe more. > I see. Now I know what you were getting at: options are sometimes a > consequence of impossible specifications. That's not an interesting > observation (to me) but it certainly does not constitute a general rule > about programs. > As it happens the natural specification of a compiler - take in a file in the source language and produce the best program which does the same thing in the target language - is one which cannot be achieved for theoretical as well as practical reasons. But that's not essential to my point. It also applies to specifications which are possible but difficult to achieve. And to poor design decisions which may not be under the control of the program, for example it is impossible to distinguish big-endian from little endian UTF-16 without a byte order mark, so it's necessary to provide an option to the user if you are to support every possible input. Of course a well designed program will use a heuristic, but it's not that easy to design, and lazy implementers will just rely on the option.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-02 10:39 +0100 |
| Message-ID | <ucuvtc$cbnk$1@dont-email.me> |
| In reply to | #173599 |
On 02/09/2023 01:14, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 01/09/2023 19:07, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 01/09/2023 14:53, Ben Bacarisse wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>>
>>>>>> On 01/09/2023 13:08, Richard Harnden wrote:
>>>>>>> On 01/09/2023 12:01, Bart wrote:
>>>>>
>>>>>>>> We are talking about compilers like gcc where you make up your own rules
>>>>>>>> as to show strictly you want your program treated:
>>>>>>>>
>>>>>>>> gcc prog.c zero warnings, writes .exe
>>>>>>>> gcc @options prog.c 10000 warnings, but it still writes .exe
>>>>>>>> gcc @options prog.c 10000 warning and 1 error, no .exe
>>>>>
>>>>> Which would you choose as the one and only behaviour?
>>> No answer? I'll look at the rest of your post, if you decide to address
>>> this point...
>
>> You want an answer, I'd go with the first, since then the three compilers I
>> use the most work the same way.
>>
>> That's not completely satisfactory,
>
> It's totally unacceptable to me and, I suspect, a lot of other people.
> I usually don't want gcc extensions and I want to be able specify the
> ISO C standard to use at the very least. But I also want as much help
> spotting errors as the compiler can give me.
>
>> since there are aspects of the C language I think are too unsafe, but:
>>
>> * Have to be passed because they are legal C
>>
>> * Cannot reliably be detected by a compiler
>>
>> * Are too extensively used in legacy code to be just outlawed.
>
> Yet you want to stop people from having hundreds of helpful diagnostics.
>
> I suspect you don't mean what you seem to have said -- that gcc should
> always behave in it's default mode. But if that is not what you meant
> to say then you have not answered the question at all.
>
> You say, dismissively, that one can "make up ones your rules" with gcc,
> so I am asking for you to say exactly what you don't want me to be able
> to ask for in terms of checking and/or its absence. Just how crippled
> and annoying would I find gcc to be if you were in charge? How much
> choice will you take away?
>
It seems you want a tool different from what I have in mind. I want a
straightforward compiler that defaults to the latest version of a
language, that does not allow user-specified variations.
But it sounds like the C standard itself gives too much leeway in this
matter anyway. There is apparently no one C language that says that 'int
fred(void){}' must be illegal.
It also seems like your programs are't even fully specified by the C
code you write: as well as dozens of compiler options, pragmas and
attributes within the code, scripts using Bash, Make and M4 are
involved, plus whatever further languages and config tools might be
dragged in, or piled on top.
This is on top of whatever mini-DSLs might be created with the
preprocessor. And on top of the variations made possibly by the
language's loosely defined type system.
As I've said many times, this is too chaotic for my taste. It is just
far too open-ended. And it currently panders far too much to ancient
legacy code and options in /all/ those languages, scripts and tools.
Funny how discussions here often focus on some exact wording in the C
standard, while the rest of it leaves gaping holes in the spec large
enough to drive a bus through.
(I've working on a new systems language where instead of there being
exactly one, fixed language that needs nothing else to build projects,
there will a closely integrated, embedded scripting language.
I thought having two languages in one would be too outre, but it is
nothing on C, or rather that vague, sprawling mess of languages,
dialects and tools that I've described.)
Anyway, I think I've given you an idea of where I stand.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-09-02 07:33 -0700 |
| Message-ID | <5JHIM.574995$qnnb.462524@fx11.iad> |
| In reply to | #173641 |
On 9/2/23 2:39 AM, Bart wrote:
> There is apparently no one C language that says that 'int fred(void){}'
> must be illegal.
You seem a bit stuck on this.
What simple rule would you add to make it actually a diagnosable condition?
You can't just require a return statement at the end of functions,
because some code might not reach the end of the function to "fall off",
so that would be forcing unreachable code.
You can't require a return statement if the end was reachable, because
that is a condition that can't always be determined.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-02 16:26 +0100 |
| Message-ID | <ucvk6s$f6nb$1@dont-email.me> |
| In reply to | #173661 |
On 02/09/2023 15:33, Richard Damon wrote:
> On 9/2/23 2:39 AM, Bart wrote:
>> There is apparently no one C language that says that 'int
>> fred(void){}' must be illegal.
>
> You seem a bit stuck on this.
It's the example I've been using to show the diverse responses from
compilers. That is, Pass, Fail, Warn.
(I thought UB refered to undefined behaviour of the program, not the
compiler!)
> What simple rule would you add to make it actually a diagnosable condition?
A simple one would be that be a non-void function should have at least
one 'return' statement. It won't catch all cases of running into the end
of the function, but will catch some.
I posted also the example 'int fred(void){return;}', which gcc takes a
bit more seriously, but still not enough to fail the program. This one
is very easy to check.
> You can't just require a return statement at the end of functions,
> because some code might not reach the end of the function to "fall off",
> so that would be forcing unreachable code.
>
> You can't require a return statement if the end was reachable, because
> that is a condition that can't always be determined.
This is what I do in my languages: the last expression in a function (as
it is expression-based), must yield a suitable return value. A dummy
value is needed in some cases.
That's not possible to enforce in C because of existing practice. I try
to do it, and it requires the legacy option to allow a missing return value.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-09-02 09:03 -0700 |
| Message-ID | <r1JIM.297958$uLJb.27694@fx41.iad> |
| In reply to | #173662 |
On 9/2/23 8:26 AM, Bart wrote:
> On 02/09/2023 15:33, Richard Damon wrote:
>> On 9/2/23 2:39 AM, Bart wrote:
>>> There is apparently no one C language that says that 'int
>>> fred(void){}' must be illegal.
>>
>> You seem a bit stuck on this.
>
> It's the example I've been using to show the diverse responses from
> compilers. That is, Pass, Fail, Warn.
A compiler that "fails" this program is non-conforming.
A compiler is allowed to "warn" about anything it wants, and that just
becomes a "Quality of Implementation" Issue.
>
> (I thought UB refered to undefined behaviour of the program, not the
> compiler!)
Nope, some UB refers to "compiler" behavior. Some "errors" are allowed
to not be diagnosed (normally because diagnosing them isn't easy to
define) but some system might do the extra work to allow them to find them.
Some sorts of errors get found later, like a link time.
>
>> What simple rule would you add to make it actually a diagnosable
>> condition?
>
> A simple one would be that be a non-void function should have at least
> one 'return' statement. It won't catch all cases of running into the end
> of the function, but will catch some.
But there can be perfectly valid functions that don't meet that requirement.
In fact, most of the programs I write have such a function, called main.
These programs all are started and will NEVER end, in part because they
don't have anything to exit to (they run on machines without an OS).
>
> I posted also the example 'int fred(void){return;}', which gcc takes a
> bit more seriously, but still not enough to fail the program. This one
> is very easy to check.
So, you don't think implmentations should be allowed to provide extensions?
>
>> You can't just require a return statement at the end of functions,
>> because some code might not reach the end of the function to "fall
>> off", so that would be forcing unreachable code.
>>
>> You can't require a return statement if the end was reachable, because
>> that is a condition that can't always be determined.
>
> This is what I do in my languages: the last expression in a function (as
> it is expression-based), must yield a suitable return value. A dummy
> value is needed in some cases.
So, you language forces unneeded code. That's ok.
You also don't need to support the old code that C tries to. Back before
void was added, so functions always had a return value, even if not
specified, but it was allowed to just fall off the end without a return
to do nothing.
>
> That's not possible to enforce in C because of existing practice. I try
> to do it, and it requires the legacy option to allow a missing return
> value.
Yep, one of the advantages of being willing to throw out old code.
One guiding principle of the C Standard Committee is to try to respect
the validity of the existing code base of applications and library.
This does result in some things that might seem sub-optimal if you are
just looking at new stuff.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-02 19:22 +0100 |
| Message-ID | <ucvuhq$gmlg$1@dont-email.me> |
| In reply to | #173668 |
On 02/09/2023 17:03, Richard Damon wrote:
> On 9/2/23 8:26 AM, Bart wrote:
>>> What simple rule would you add to make it actually a diagnosable
>>> condition?
>>
>> A simple one would be that be a non-void function should have at least
>> one 'return' statement. It won't catch all cases of running into the
>> end of the function, but will catch some.
>
> But there can be perfectly valid functions that don't meet that
> requirement.
>
> In fact, most of the programs I write have such a function, called main.
A special exception has to be made for main. (Note that Pico C doesn't
have that exception, but it is a very small compiler.)
> These programs all are started and will NEVER end, in part because they
> don't have anything to exit to (they run on machines without an OS).
If you have a function that you know will never return (becauses it
stays in a loop, or terminates, here or in a nested function), then why
would you give it a return type in the first place?
Maybe /that/ is the thing that should be pointed out, and maybe that is
also the error that has been made.
>>
>> I posted also the example 'int fred(void){return;}', which gcc takes a
>> bit more seriously, but still not enough to fail the program. This one
>> is very easy to check.
>
> So, you don't think implmentations should be allowed to provide extensions?
A meaningless, dangerous extension? No. What exactly would be the
purpose of it? To avoid having to write a superfluous:
return 0;
to satisfy the language's type system? Such a statement will likely be
elided by the compiler's optimiser anyway, or at least the instruction
to load the return value.
Since I would expect the compiler to inject a return instruction in the
generated code. (For this reason, a return statement at the end of a
void function can be optional.)
>>
>>> You can't just require a return statement at the end of functions,
>>> because some code might not reach the end of the function to "fall
>>> off", so that would be forcing unreachable code.
>>>
>>> You can't require a return statement if the end was reachable,
>>> because that is a condition that can't always be determined.
>>
>> This is what I do in my languages: the last expression in a function
>> (as it is expression-based), must yield a suitable return value. A
>> dummy value is needed in some cases.
>
> So, you language forces unneeded code. That's ok.
My languages allow early returns from a function; some don't.
But for functions which return a type T, they require that the body of
the function yields a value of type T.
So it is somewhat stricter type checking. Type checking doesn't pay heed
to control flow within the function. If it did, and that allowed you to
not have a proper type for the function body, it could mean that when
you later comment out this early return:
return x
that the rest of function, which could terminate with complex if, case
or switch statement, could now fail a type check. It is better that it
complies no matter what.
> You also don't need to support the old code that C tries to. Back before
> void was added, so functions always had a return value, even if not
> specified, but it was allowed to just fall off the end without a return
> to do nothing.
That explains a lot. Then the solution is easy: require '-std=legacy'
like Fortran does to compile ancient programs.
If people say there old makefiles that would need tweaking, THEN FIX
THOSE MAKEFILES, rather than allow generations of programmers to keep
writing both sloppy, dangerous code, and sloppy makefiles that make
assumptions.
> Yep, one of the advantages of being willing to throw out old code.
I don't throw it out; I require an option like the one I suggested.
> One guiding principle of the C Standard Committee is to try to respect
> the validity of the existing code base of applications and library.
Sure, but is the guiding principle also that compilers mustn't be
allowed to require an option to support existing code written to older,
less safe standards?
Because so many people use compilers without a set of options to specify
the language standard, dialect and level of strictness, it means nothing
stops them continuing to write old-style unsafe code. Which in turn
makes it harder to deprecate such code, as there's so much of it.
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2023-09-05 01:38 +0000 |
| Message-ID | <ud60pq$1mf0p$1@dont-email.me> |
| In reply to | #173677 |
On Sat, 2 Sep 2023 19:22:50 +0100, Bart <bc@freeuk.com> wrote in <ucvuhq$gmlg$1@dont-email.me>: > If you have a function that you know will never return (becauses it > stays in a loop, or terminates, here or in a nested function), then why > would you give it a return type in the first place? Isn't asking a C compiler to watch for interminable loops and such things akin to trying to solve the halting problem? I mean, I'm not the smartest person in the room by far, but even I know that this is, perhaps, a bit far-out... ...or is it? I could be mistaken. -- -v
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-09-04 20:05 -0700 |
| Message-ID | <zVwJM.204220$JG_b.95531@fx39.iad> |
| In reply to | #173938 |
On 9/4/23 6:38 PM, vallor wrote: > On Sat, 2 Sep 2023 19:22:50 +0100, Bart <bc@freeuk.com> wrote in > <ucvuhq$gmlg$1@dont-email.me>: > >> If you have a function that you know will never return (becauses it >> stays in a loop, or terminates, here or in a nested function), then why >> would you give it a return type in the first place? > > Isn't asking a C compiler to watch for interminable loops and > such things akin to trying to solve the halting problem? > > I mean, I'm not the smartest person in the room by far, but even > I know that this is, perhaps, a bit far-out... > > ...or is it? I could be mistaken. > I think the proposal to have it look to see if something might happen was limited to evaluating CONSTANT values. I seem to remember that a loop with a non-constant-expression control expression allowed the complier to assume the loop will eventually end, and thus if the loop had no observable effects, could be optimized away, even if it turns out that the condition could never be met. Thus, it doesn't become a Halting Problem analysis, as loop termination becomes "correctly" predicted syntactic means.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-06 16:45 -0700 |
| Message-ID | <86jzt2oogh.fsf@linuxsc.com> |
| In reply to | #173941 |
Richard Damon <Richard@Damon-Family.org> writes: > On 9/4/23 6:38 PM, vallor wrote: > >> On Sat, 2 Sep 2023 19:22:50 +0100, Bart <bc@freeuk.com> wrote in >> <ucvuhq$gmlg$1@dont-email.me>: >> >>> If you have a function that you know will never return (becauses >>> it stays in a loop, or terminates, here or in a nested function), >>> then why would you give it a return type in the first place? >> >> Isn't asking a C compiler to watch for interminable loops and >> such things akin to trying to solve the halting problem? >> >> I mean, I'm not the smartest person in the room by far, but even >> I know that this is, perhaps, a bit far-out... >> >> ...or is it? I could be mistaken. > > I think the proposal to have it look to see if something might > happen was limited to evaluating CONSTANT values. > > I seem to remember that a loop with a non-constant-expression > control expression allowed the complier to assume the loop will > eventually end, and thus if the loop had no observable effects, > could be optimized away, even if it turns out that the condition > could never be met. > > Thus, it doesn't become a Halting Problem analysis, as loop > termination becomes "correctly" predicted syntactic means. You're right that what the C standard says about while() and for() loops is only for constant control expressions (along with some other criteria, all of which are easily staticly checkable), and so is not a halting problem problem. I have the sense though that what is being asked about is whether arbitrary code in a function body might reach the closing brace without having done a return, which is equivalent to the halting problem.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-05 06:49 +0000 |
| Message-ID | <20230904234329.835@kylheku.com> |
| In reply to | #173938 |
On 2023-09-05, vallor <vallor@cultnix.org> wrote: > On Sat, 2 Sep 2023 19:22:50 +0100, Bart <bc@freeuk.com> wrote in ><ucvuhq$gmlg$1@dont-email.me>: > >> If you have a function that you know will never return (becauses it >> stays in a loop, or terminates, here or in a nested function), then why >> would you give it a return type in the first place? > > Isn't asking a C compiler to watch for interminable loops and > such things akin to trying to solve the halting problem? The Halting Problem is academic. The main reasons why you can't accurately determine reachability in C programs are practical: - the compiler doesn't have the entire program, only a translation unit. Whenever the reachability calculation depends on the result of an external function, or value of an external variable or other object whose manipulation is not entirely visible in the current translation unit, a prudent assumption has to be made. - there are also run-time inputs. A Turing machine is completely defined and has no run-time inputs; everything is on the tape. A C program that is all in one translation unit, and takes no input from the environment, resembles a Turing Machine. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you're posting from Google Groups, I don't see you!
[toc] | [prev] | [next] | [standalone]
Page 9 of 18 — ← Prev page 1 … 7 8 [9] 10 11 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web