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 10 of 18 — ← Prev page 1 … 8 9 [10] 11 12 … 18 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-05 05:30 -0700 |
| Message-ID | <86bkegpztj.fsf@linuxsc.com> |
| In reply to | #173966 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: > A Turing machine is completely defined and has no run-time inputs; > everything is on the tape. This is wrong. A Turing machine is just the machine. The tape is separate. It would be pointless to talk about "Turing machines" if all a given "Turing machine" could do is one computation. > A C program that is all in one translation unit, and takes no > input from the environment, resembles a Turing Machine. A Turing machine is analogous to a program, with the tape being analogous to program input.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-05 17:16 +0000 |
| Message-ID | <20230905075103.116@kylheku.com> |
| In reply to | #173991 |
On 2023-09-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Kaz Kylheku <864-117-4973@kylheku.com> writes: > >> A Turing machine is completely defined and has no run-time inputs; >> everything is on the tape. > > This is wrong. A Turing machine is just the machine. The tape is > separate. Apologies for that. A term for what I'm referring to is "Turing machine configuration" (offered in _Introduction to the Theory of Computation_, 3rd ed, Michael Sipser). I picked up the synecdoche somewhere. > It would be pointless to talk about "Turing machines" > if all a given "Turing machine" could do is one computation. "Does this Turing machine configuration halt?" is a meaningful question. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you're posting from Google Groups, I don't see you!
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-06 08:47 -0700 |
| Message-ID | <86o7ifnw0g.fsf@linuxsc.com> |
| In reply to | #174016 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: > On 2023-09-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Kaz Kylheku <864-117-4973@kylheku.com> writes: >> >>> A Turing machine is completely defined and has no run-time inputs; >>> everything is on the tape. >> >> This is wrong. A Turing machine is just the machine. The tape is >> separate. > > Apologies for that. A term for what I'm referring to is > "Turing machine configuration" (offered in _Introduction to the > Theory of Computation_, 3rd ed, Michael Sipser). Not a term I'm familiar with. Seems like a poor choice of phrase. >> It would be pointless to talk about "Turing machines" >> if all a given "Turing machine" could do is one computation. > > "Does this Turing machine configuration halt?" is a > meaningful question. The question usually asked is "Does a given Turing machine halt when started on a blank tape?". Given a Turing machine T and input tape I, it's easy to construct a Turing machine T' such that T' halts when started on a blank tape if and only iff T halts when started on I. ISTM that the notion of a Turing machine configuration (whether by that name or a different one) isn't very useful.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-06 19:57 +0100 |
| Message-ID | <875y4nqgdv.fsf@bsb.me.uk> |
| In reply to | #174164 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Kaz Kylheku <864-117-4973@kylheku.com> writes: > >> On 2023-09-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> >>> Kaz Kylheku <864-117-4973@kylheku.com> writes: >>> >>>> A Turing machine is completely defined and has no run-time inputs; >>>> everything is on the tape. >>> >>> This is wrong. A Turing machine is just the machine. The tape is >>> separate. >> >> Apologies for that. A term for what I'm referring to is >> "Turing machine configuration" (offered in _Introduction to the >> Theory of Computation_, 3rd ed, Michael Sipser). > > Not a term I'm familiar with. Seems like a poor choice > of phrase. It's quite widely used but not exactly as Kaz seems to be suggesting. Siper uses it in the way I've seen other authors use it: "As a Turing machine computes, changes occur in the current state, the current tape contents, and the current head location. A setting of these three items is called a configuration of the Turing machine." A TM configuration represents the state of a computation. >>> It would be pointless to talk about "Turing machines" >>> if all a given "Turing machine" could do is one computation. >> >> "Does this Turing machine configuration halt?" is a >> meaningful question. > > The question usually asked is "Does a given Turing machine halt > when started on a blank tape?". Given a Turing machine T and > input tape I, it's easy to construct a Turing machine T' such > that T' halts when started on a blank tape if and only iff T > halts when started on I. ISTM that the notion of a Turing > machine configuration (whether by that name or a different one) > isn't very useful. True, but given the way it is actually defined it is very useful as a way to talk about the progress of a computation. Most authors will invent a notation for a configuration (often a pictorial one) to help in explanations. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-06 19:01 -0700 |
| Message-ID | <867cp2oi6i.fsf@linuxsc.com> |
| In reply to | #174179 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Kaz Kylheku <864-117-4973@kylheku.com> writes: >> >>> On 2023-09-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> Kaz Kylheku <864-117-4973@kylheku.com> writes: >>>> >>>>> A Turing machine is completely defined and has no run-time >>>>> inputs; everything is on the tape. >>>> >>>> This is wrong. A Turing machine is just the machine. The tape >>>> is separate. >>> >>> Apologies for that. A term for what I'm referring to is >>> "Turing machine configuration" (offered in _Introduction to the >>> Theory of Computation_, 3rd ed, Michael Sipser). >> >> Not a term I'm familiar with. Seems like a poor choice >> of phrase. > > It's quite widely used but not exactly as Kaz seems to be > suggesting. Siper uses it in the way I've seen other authors use > it: > > "As a Turing machine computes, changes occur in the current > state, the current tape contents, and the current head location. > A setting of these three items is called a configuration of the > Turing machine." > > A TM configuration represents the state of a computation. I see. That makes more sense. I still think the name is a little funny, but at least I see the point of the concept. >>>> It would be pointless to talk about "Turing machines" >>>> if all a given "Turing machine" could do is one computation. >>> >>> "Does this Turing machine configuration halt?" is a >>> meaningful question. >> >> The question usually asked is "Does a given Turing machine halt >> when started on a blank tape?". Given a Turing machine T and >> input tape I, it's easy to construct a Turing machine T' such >> that T' halts when started on a blank tape if and only iff T >> halts when started on I. ISTM that the notion of a Turing >> machine configuration (whether by that name or a different one) >> isn't very useful. > > True, but given the way it is actually defined it is very > useful as a way to talk about the progress of a computation. > [...] Yes. Thank you for the clarification.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-09-09 01:14 -0400 |
| Message-ID | <udgv0h$3ufb5$1@dont-email.me> |
| In reply to | #173966 |
On 9/5/23 02:49, Kaz Kylheku wrote: > On 2023-09-05, vallor <vallor@cultnix.org> wrote: ... >> 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: If the C standard mandated diagnosing unreachable code, that would require solving the Halting Problem, which is impossible. Because the C standard does not mandate diagnosing unreachable code, and allows implementations to issue arbitrary diagnostics for any reason they wish, an implementation of C is free to diagnose the easy cases, while leaving harder cases undiagnosed. That's why it's important to be aware of the Halting Problem, despite it being of mostly academic interest.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-09 05:22 +0000 |
| Message-ID | <20230908222015.25@kylheku.com> |
| In reply to | #174685 |
On 2023-09-09, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > On 9/5/23 02:49, Kaz Kylheku wrote: >> On 2023-09-05, vallor <vallor@cultnix.org> wrote: > ... >>> 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: > > If the C standard mandated diagnosing unreachable code, that would > require solving the Halting Problem, which is impossible. If the C standard mandated diagnosing unreachable code, it would require a crystal ball, which makes Turing-related difficulties moot ... being the point. Therefore, nobody in their right mind will do that; they will focus on that which can be done in a way that is practical and useful, reasonably easy to understand (and thus predict) and of the most benefit and least nuisance. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-05 12:51 +0100 |
| Message-ID | <ud74nj$1v8l5$1@dont-email.me> |
| In reply to | #173938 |
On 05/09/2023 02:38, 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?
Read my question again: if the programmer /knows/ it will never return.
Then they can choose to use a void function. (In the example given,
there was a need to match a non-void function.)
If you mean, whether a compiler can tell for sure whether it will reach
the end or not, then you're right, it can't:
int F(void) {
if (rand()!=12345) return 100;
}
I made a decision to require a return statement as the last or within a
branch of the last statement. That means this program fails as written.
That can be overridden because such programs exist in the wild. In this
case, what I can do (but haven't done and others don't do that I can
see), is to zero the register where a return value is expected, to give
at least predictable and repeatable behaviour.
You might say, that's an extra few bytes that might not be needed. But
compilers do seem to generate function epilogue code in this situation;
what's the point of that when the compiler assumes it cannot run into
the end because it would be UB?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-02 12:58 -0700 |
| Message-ID | <87v8cs73g7.fsf@nosuchdomain.example.com> |
| In reply to | #173662 |
Bart <bc@freeuk.com> writes:
[...]
> 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.
That's a constraint violation since C99. See N1570 6.8.5.4p1.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-02 16:29 +0000 |
| Message-ID | <20230902081556.522@kylheku.com> |
| In reply to | #173641 |
On 2023-09-02, Bart <bc@freeuk.com> wrote:
> 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.
Diagnostics are truths about a program.
So what you're saying is that you want to shutter yourself and the users
against the discovery of truths, and new kinds of truth.
I've experienced situations in which a new diagnostic added in
a new release of GCC uncovered a latent bug.
> 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.
Right, never has been, so that is what it is.
> 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.
That's right; a decision in a config script or any of the inputs
to those tools can change the content of a program.
If you don't like it, go complain to the author.
> 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
Yes, you've written about your taste, and nothing but your taste, many
times. It is well-known.
Most people who develop those chaotic programs are not reading this
newsgroup. They are not here, therefore even if they responded
to such complaints, they won't do so.
> far too open-ended. And it currently panders far too much to ancient
> legacy code and options in /all/ those languages, scripts and tools.
Old code has to build and work. Fact of life. People don't rewrite
milions of lines because the language has changed.
> 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.
That's, sort of, a variation of the Tu Quoque fallacy. If we are
discussing the correctness of some particular construct, we are not in
that moment concerned with the rest of the program; that is assumed to
be correct.
That that there could be bugs elsewhere in the program, in connection
with the language being loose, cannot be used as an excuse not to focus
on some part of it.
> (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.
That's original; nobody in the C world uses embedded scripting
languages for flexibility.
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-02 20:00 +0100 |
| Message-ID | <ud00of$grer$2@dont-email.me> |
| In reply to | #173671 |
On 02/09/2023 17:29, Kaz Kylheku wrote: > On 2023-09-02, Bart <bc@freeuk.com> wrote: > That's original; nobody in the C world uses embedded scripting > languages for flexibility. It won't be like mine. Note the words 'closely integrated', which means specific support within the host language. Most such attempts are dog's dinners. And have they made of the world of build systems any simpler, smaller or easier? Not that I've noticed!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-03 00:08 +0100 |
| Message-ID | <8734zwjhrb.fsf@bsb.me.uk> |
| In reply to | #173641 |
Bart <bc@freeuk.com> writes:
> 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.
Odd. I thought you used gcc's labels as values extension. Maybe you
mean you want gcc to use the latest version of GNU-C, the language not
entirely unlike standard C.
Anyway, it's clear that I would not want the compiler you want.
> 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.
No C source code is literally illegal. But to get closer to what you
might mean, that function definition violates no constraint in any
C standard to date.
> 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.
You are off in some fantasy world.
> 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
many, many, 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.
It must be very surprising to you (and possibly annoying) that a
language you consider to be so very deeply flawed has been so wildly
successful. I used to find it annoying when I was trying to teach
people to write programs using cleaner, higher-level languages[1], but I
never found it totally surprising because I understood something of the
social, economic and technical context in which C operated. I might
have taught concurrent and distributed systems using SR[2], but all the
protocols and systems in my research projects used C.
[1] There was a deep vein of "when do we learn proper programming in C"
in some of the classes.
[2] https://www2.cs.arizona.edu/sr/ (That makes me feel old. SR's
/successor/ is now obsolete.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-03 01:36 +0100 |
| Message-ID | <ud0kf6$ji9p$1@dont-email.me> |
| In reply to | #173692 |
On 03/09/2023 00:08, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> 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.
>
> You are off in some fantasy world.
You have a short memory.
Take the A68G project we recently discussed. Or Gzip. Try and build a
binary using only .c and .h files, and a C compiler. Try and /get/ the
.c and .h files! (Some will be generated by a script in a language that
isn't C.)
Thiago Adams is using a build system based on using C to provide the
scripting needs. That is good; a project still consists of .c files and
needs a C compiler. No extraneous language is needed.
>> 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.
>
> It must be very surprising to you (and possibly annoying) that a
> language you consider to be so very deeply flawed has been so wildly
> successful.
Successful by what measure? By seeing off all the competition; being
given massive dispensation by the OS; by generating a lot of employment
for people writing makefiles; by more people choosing to write free,
open source tools?
My own efforts have been usually directed at specific platforms and
applications so could be more streamlined and tidier with little need to
worry about legacy code.
And yet the end result is a language that can be just as useful and
general purpose as C.
(I could have done with an army of people writing optimising compilers
for diverse platforms, creating contents in the form of libraries, or
even just bindings.)
> I used to find it annoying when I was trying to teach
> people to write programs using cleaner, higher-level languages[1],
I'm not even talking about anything much higher level. 'C-level' is
fine, but even at that level, there is so much more that could have been
done better.
Look at this discussion about 'int fred(void){}', and the technical
reasons why that should be valid in a language.
Anywhere else such a possibility in a language would be immediately
dismissed; no arguments! But in C, every bad feature must be allowed,
with a long list of reasons why. The culture is just wrong.
And of course, as you have done, there will always be someone to whom
the feature is indispensable.
> but I
> never found it totally surprising because I understood something of the
> social, economic and technical context in which C operated.
C mostly passed me by for half of my career, and most of the active part
of it. As did Unix and Linux.
I did alright.
> I might
> have taught concurrent and distributed systems using SR[2], but all the
> protocols and systems in my research projects used C.
>
> [1] There was a deep vein of "when do we learn proper programming in C"
> in some of the classes.
I can see it appealing to the more subversive elements who don't like
the heavy discipline of those higher level languages.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-03 02:41 +0100 |
| Message-ID | <87edjgxcbh.fsf@bsb.me.uk> |
| In reply to | #173693 |
Bart <bc@freeuk.com> writes:
> On 03/09/2023 00:08, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> 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.
>> You are off in some fantasy world.
>
> You have a short memory.
>
> Take the A68G project we recently discussed. Or Gzip. Try and build a
> binary using only .c and .h files, and a C compiler. Try and /get/ the .c
> and .h files! (Some will be generated by a script in a language that isn't
> C.)
I didn't write any of those. What are you on about?
>>> 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.
>> It must be very surprising to you (and possibly annoying) that a
>> language you consider to be so very deeply flawed has been so wildly
>> successful.
>
> Successful by what measure?
Good question. I meant very widely learned and used. To what extent
that reflect success for the people who have learned and used it, or,
for that matter, the projects it was used on, is another question.
> Look at this discussion about 'int fred(void){}', and the technical reasons
> why that should be valid in a language.
> And of course, as you have done, there will always be someone to whom the
> feature is indispensable.
Spin. I never said that. I simply used it since it fit a very specific
situation at the time.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-02 17:49 +0200 |
| Message-ID | <ucvlim$fb08$2@dont-email.me> |
| In reply to | #173599 |
On 02/09/2023 02: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. And Ben's choice here would be unacceptable to me, and to a lot of other people, because I generally /do/ want some gcc extensions. (My job would be impossible without some of them.) And I can pretty much guarantee that Ben's preferences for warning options and other code generation options will be different than mine (especially since mine can vary a little between projects). That's why it is great that gcc has lots of flexibility, and can be adapted to different needs and preferences. One size does not fit all in the world of programming.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-01 18:32 +0000 |
| Message-ID | <20230901112550.821@kylheku.com> |
| In reply to | #173524 |
On 2023-09-01, Bart <bc@freeuk.com> wrote: > On 01/09/2023 14:53, Ben Bacarisse wrote: >> Is that true? #pragma GCC diagnostic "-Wno-xxxx" lines are not >> overruled by command line warning options, but there may be a way to >> force these to be ignored. > > Those don't always work. At least this doesn't: > > #pragma GCC diagnostic ignored "-Wbuiltin-declaration-mismatch" > > It works on Windows gcc but not WSL gcc. "WSL gcc" is not the designation of a version of GCC. Not all versions of GCC have the same -W options because, doh, new ones get added over time. Unfortunately, when you give a new -W option to an old GCC, it has a fit about an unrecognized option and bails. Projects that want to take advantage of new options, but still work with olde GCC's, have a slight problem. One approach is to detect what options work, in your ./configure script. -- 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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-01 18:59 +0000 |
| Message-ID | <DwqIM.79176$m8Ke.35724@fx08.iad> |
| In reply to | #173544 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: >On 2023-09-01, Bart <bc@freeuk.com> wrote: >> On 01/09/2023 14:53, Ben Bacarisse wrote: >>> Is that true? #pragma GCC diagnostic "-Wno-xxxx" lines are not >>> overruled by command line warning options, but there may be a way to >>> force these to be ignored. >> >> Those don't always work. At least this doesn't: >> >> #pragma GCC diagnostic ignored "-Wbuiltin-declaration-mismatch" >> >> It works on Windows gcc but not WSL gcc. > >"WSL gcc" is not the designation of a version of GCC. > >Not all versions of GCC have the same -W options because, doh, >new ones get added over time. > >Unfortunately, when you give a new -W option to an old GCC, >it has a fit about an unrecognized option and bails. > >Projects that want to take advantage of new options, but still >work with olde GCC's, have a slight problem. > >One approach is to detect what options work, in your ./configure script. Or in the Makefile if you don't use autoconf. GCC_HAS_GENERIC_TUNING := $(shell expr `$(CXX) -dumpversion | cut -f2 -d. ` \>= 2) GCC_HAS_MCRC32 := $(shell expr `$(CXX) -E -mcrc32 /dev/null 2>/dev/null; echo $$?` == 0) IS_GCC_MAJOR_VER_4 := $(shell if [ `$(CXX) -dumpversion | cut -f1 -d. ` -eq 4 ]; then echo 1; else echo 0; fi )
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-02 18:02 +0200 |
| Message-ID | <ucvma9$fb08$5@dont-email.me> |
| In reply to | #173554 |
On 01/09/2023 20:59, Scott Lurndal wrote: > Kaz Kylheku <864-117-4973@kylheku.com> writes: >> On 2023-09-01, Bart <bc@freeuk.com> wrote: >>> On 01/09/2023 14:53, Ben Bacarisse wrote: >>>> Is that true? #pragma GCC diagnostic "-Wno-xxxx" lines are not >>>> overruled by command line warning options, but there may be a way to >>>> force these to be ignored. >>> >>> Those don't always work. At least this doesn't: >>> >>> #pragma GCC diagnostic ignored "-Wbuiltin-declaration-mismatch" >>> >>> It works on Windows gcc but not WSL gcc. >> >> "WSL gcc" is not the designation of a version of GCC. >> >> Not all versions of GCC have the same -W options because, doh, >> new ones get added over time. >> >> Unfortunately, when you give a new -W option to an old GCC, >> it has a fit about an unrecognized option and bails. >> >> Projects that want to take advantage of new options, but still >> work with olde GCC's, have a slight problem. >> >> One approach is to detect what options work, in your ./configure script. > > Or in the Makefile if you don't use autoconf. > > GCC_HAS_GENERIC_TUNING := $(shell expr `$(CXX) -dumpversion | cut -f2 -d. ` \>= 2) > GCC_HAS_MCRC32 := $(shell expr `$(CXX) -E -mcrc32 /dev/null 2>/dev/null; echo $$?` == 0) > > IS_GCC_MAJOR_VER_4 := $(shell if [ `$(CXX) -dumpversion | cut -f1 -d. ` -eq 4 ]; then echo 1; else echo 0; fi ) > Or even better, since this is a pragma in the source code, have it wrapped in conditional compilation that checks first for gcc, then for the gcc version. Sure, it can be a bit ugly, but it only needs to be written once and copied out verbatim by the code generator (or put in a common header file for the rest of us), and godbolt.org makes it very easy to test with different gcc versions.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-03 15:54 +0000 |
| Message-ID | <z_1JM.580000$U3w1.56661@fx09.iad> |
| In reply to | #173667 |
David Brown <david.brown@hesbynett.no> writes: >On 01/09/2023 20:59, Scott Lurndal wrote: >> Kaz Kylheku <864-117-4973@kylheku.com> writes: >>> On 2023-09-01, Bart <bc@freeuk.com> wrote: >>>> On 01/09/2023 14:53, Ben Bacarisse wrote: >>>>> Is that true? #pragma GCC diagnostic "-Wno-xxxx" lines are not >>>>> overruled by command line warning options, but there may be a way to >>>>> force these to be ignored. >>>> >>>> Those don't always work. At least this doesn't: >>>> >>>> #pragma GCC diagnostic ignored "-Wbuiltin-declaration-mismatch" >>>> >>>> It works on Windows gcc but not WSL gcc. >>> >>> "WSL gcc" is not the designation of a version of GCC. >>> >>> Not all versions of GCC have the same -W options because, doh, >>> new ones get added over time. >>> >>> Unfortunately, when you give a new -W option to an old GCC, >>> it has a fit about an unrecognized option and bails. >>> >>> Projects that want to take advantage of new options, but still >>> work with olde GCC's, have a slight problem. >>> >>> One approach is to detect what options work, in your ./configure script. >> >> Or in the Makefile if you don't use autoconf. >> >> GCC_HAS_GENERIC_TUNING := $(shell expr `$(CXX) -dumpversion | cut -f2 -d. ` \>= 2) >> GCC_HAS_MCRC32 := $(shell expr `$(CXX) -E -mcrc32 /dev/null 2>/dev/null; echo $$?` == 0) >> >> IS_GCC_MAJOR_VER_4 := $(shell if [ `$(CXX) -dumpversion | cut -f1 -d. ` -eq 4 ]; then echo 1; else echo 0; fi ) >> > >Or even better, since this is a pragma in the source code, have it >wrapped in conditional compilation that checks first for gcc, then for >the gcc version. Sure, it can be a bit ugly, but it only needs to be >written once and copied out verbatim by the code generator (or put in a >common header file for the rest of us), and godbolt.org makes it very >easy to test with different gcc versions. > Generally I tend to eschew conditional compilation[*]. Not only is it unattractive, it also significantly increases the verification burden (multiplied by the number of predicates) and decreases significantly the readability and maintainability of the code. I've seen code where every fourth line is #if. Completely unreadable and very difficult to amend. [*] With the occasional exception isolated to a header file.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-03 19:50 +0200 |
| Message-ID | <ud2h13$10vhp$1@dont-email.me> |
| In reply to | #173798 |
On 03/09/2023 17:54, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 01/09/2023 20:59, Scott Lurndal wrote: >>> Kaz Kylheku <864-117-4973@kylheku.com> writes: >>>> On 2023-09-01, Bart <bc@freeuk.com> wrote: >>>>> On 01/09/2023 14:53, Ben Bacarisse wrote: >>>>>> Is that true? #pragma GCC diagnostic "-Wno-xxxx" lines are not >>>>>> overruled by command line warning options, but there may be a way to >>>>>> force these to be ignored. >>>>> >>>>> Those don't always work. At least this doesn't: >>>>> >>>>> #pragma GCC diagnostic ignored "-Wbuiltin-declaration-mismatch" >>>>> >>>>> It works on Windows gcc but not WSL gcc. >>>> >>>> "WSL gcc" is not the designation of a version of GCC. >>>> >>>> Not all versions of GCC have the same -W options because, doh, >>>> new ones get added over time. >>>> >>>> Unfortunately, when you give a new -W option to an old GCC, >>>> it has a fit about an unrecognized option and bails. >>>> >>>> Projects that want to take advantage of new options, but still >>>> work with olde GCC's, have a slight problem. >>>> >>>> One approach is to detect what options work, in your ./configure script. >>> >>> Or in the Makefile if you don't use autoconf. >>> >>> GCC_HAS_GENERIC_TUNING := $(shell expr `$(CXX) -dumpversion | cut -f2 -d. ` \>= 2) >>> GCC_HAS_MCRC32 := $(shell expr `$(CXX) -E -mcrc32 /dev/null 2>/dev/null; echo $$?` == 0) >>> >>> IS_GCC_MAJOR_VER_4 := $(shell if [ `$(CXX) -dumpversion | cut -f1 -d. ` -eq 4 ]; then echo 1; else echo 0; fi ) >>> >> >> Or even better, since this is a pragma in the source code, have it >> wrapped in conditional compilation that checks first for gcc, then for >> the gcc version. Sure, it can be a bit ugly, but it only needs to be >> written once and copied out verbatim by the code generator (or put in a >> common header file for the rest of us), and godbolt.org makes it very >> easy to test with different gcc versions. >> > > Generally I tend to eschew conditional compilation[*]. Not only is it > unattractive, it also significantly increases the verification burden > (multiplied by the number of predicates) and decreases significantly > the readability and maintainability of the code. > > I've seen code where every fourth line is #if. Completely > unreadable and very difficult to amend. > > [*] With the occasional exception isolated to a header file. I agree with your practice here. But one place where I think it does work well, is for such compiler-specific features. And yes, you put it all in a header file. In my business, it's not uncommon to see a header such as : // intrinsics.h #ifdef __GNUC__ #include "gcc_intrinsics.h" #endif #ifdef __IAR__ #include "iar_intrinsics.h" #endif etc.
[toc] | [prev] | [next] | [standalone]
Page 10 of 18 — ← Prev page 1 … 8 9 [10] 11 12 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web