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 11 of 18 — ← Prev page 1 … 9 10 [11] 12 13 … 18 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-03 21:25 +0000 |
| Message-ID | <SQ6JM.962841$TPw2.810813@fx17.iad> |
| In reply to | #173801 |
David Brown <david.brown@hesbynett.no> writes:
>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.
>
Sure. That's the extent of it for me, generally.
#if defined(__GNUC__)
#define ALWAYS_INLINE inline __attribute__((always_inline))
#define barrier() asm volatile ("":::"memory")
#define CACHE_LINE_ALIGNED __attribute__((aligned(64)))
#define _x_CONSTRUCTOR __attribute__((constructor))
#define likely(x) __builtin_expect(!!(x), 1)
#define PACKED __attribute__((__packed__))
#define unlikely(x) __builtin_expect(!!(x), 0)
#else /* defined(__gnuc__) */
#define ALWAYS_INLINE
#define barrier()
#define CACHE_LINE_ALIGNED
#define _x_CONSTRUCTOR
#define likely(x) (x)
#define PACKED
#define unlikely(x) (x)
#define __attribute__(x)
#define __asm__(x)
#warning notgcc
#endif /* defined(__gnuc__) */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-03 16:44 -0700 |
| Message-ID | <ud35pc$145st$1@dont-email.me> |
| In reply to | #173817 |
On 9/3/2023 2:25 PM, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> 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.
>>
>
> Sure. That's the extent of it for me, generally.
>
> #if defined(__GNUC__)
>
> #define ALWAYS_INLINE inline __attribute__((always_inline))
> #define barrier() asm volatile ("":::"memory")
One little nit pick, barrier should probably be named compiler_barrier?
Ahhh, shit, this brings back memories when threads and atomics, membars
were not std.
> #define CACHE_LINE_ALIGNED __attribute__((aligned(64)))
> #define _x_CONSTRUCTOR __attribute__((constructor))
> #define likely(x) __builtin_expect(!!(x), 1)
> #define PACKED __attribute__((__packed__))
> #define unlikely(x) __builtin_expect(!!(x), 0)
>
> #else /* defined(__gnuc__) */
>
> #define ALWAYS_INLINE
> #define barrier()
> #define CACHE_LINE_ALIGNED
> #define _x_CONSTRUCTOR
> #define likely(x) (x)
> #define PACKED
> #define unlikely(x) (x)
>
>
> #define __attribute__(x)
> #define __asm__(x)
>
> #warning notgcc
>
> #endif /* defined(__gnuc__) */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-03 11:47 -0700 |
| Message-ID | <86edjfqejo.fsf@linuxsc.com> |
| In reply to | #173798 |
scott@slp53.sl.home (Scott Lurndal) writes: > Generally I tend to eschew conditional compilation[*]. [...] > [*] With the occasional exception isolated to a header file. All sensible people do. In almost all cases such platform dependencies should be hidden and abstracted away well out of sight (such as in a header) of the main code body.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-01 18:16 +0000 |
| Message-ID | <20230901104929.850@kylheku.com> |
| In reply to | #173518 |
On 2023-09-01, Bart <bc@freeuk.com> wrote: > On 01/09/2023 13:08, Richard Harnden wrote: >> On 01/09/2023 12:01, Bart wrote: >>> On 01/09/2023 10:10, David Brown wrote: >>>> On 01/09/2023 00:18, Bart wrote: >>> >>> >>>>> And when there is a lot going on with gcc, you can get loads of >>>>> warnings and other crap scrolling up the screen. So, was there an >>>>> "error:" in there or not? I've no idea if it worked! >>>> >>>> Fix the problems in your source code (or choice of flags to the >>>> compiler) - if you are getting screenfuls of errors or warnings, it >>>> is irrelevant whether an output file was generated or not. >>> >>> 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 >> >> Don't worry about 10,000 warnings/errors; Fix the first one, and >> recompile. Rinse/Repeat. > > You're joking, right? Maybe some of them I need to do something about, > but most of them are irrelevant: > > cc.c:5363:5: warning: ISO C forbids initialization between function > pointer and 'void *' [-Wpedantic] > 5363 | &cc_genasm$stropndx, > | ^ The word "pedantic" is a slightly pejorative term. Someone in GCC, perhaps Richard Stallman himself, introduced this diagnostic category in order to capture certain overly nitpicky diagnostics required by ISO C. Mainly these are in areas in which GNU C differs, providing a nonconforming extension, like allowing a certain conversion. The extension is only noncoforming because the required diagnostic is not emitted; -Wpedantic makes it conforming. -Wpedantic is used by those who are looking to write maximally portable code that doesn't violate any ISO C constraint rule. Under -Wpedantic, you will not accidentally use a GNU C extension. If the code is relying on extensions like function pointer and object conversions, it makes sense not to use -Wpedantic. > You can't turn a 64-bit void* pointer on x64 into a 64-bit function > pointer? **** off! You obviously can, but ISO C requires a diagnostic. This is an extension that makes sense on systems in which code and data are in the same memory space, and the void * pointer is large enough to hold the function pointer. ISO C (a document you will likely only know about by word of mouth but not actually read) lists this in its Annex as a common extension. > Or unused labels. Or unused parameters (in a suite of functions that > must share the same set). > > How do I discover the important ones? By reading the GCC documentation, mainly. One approach would be to use -Wall and perhaps -Wextra. Then if you run into some bugs you can reactively check the compiler documentation to answeer the question "could the compiler have caught this issue?" Or you can proactively do this: go "shopping" through the documentation to get an idea of what kinds of diagnostics are available that look like they might be useful for your project. You can experiment with them to see whether they find something, and what the false positive ratio is like. > This is for generated code. The fact is, WHATEVER I do, somebody can > just ramp up the options further to make it show a diagnostic. If you trust your generated code, then disable warnings. Your compiler front end should have done all the diagnosis, and the C that is output is just being used as a "high level assembly language". You, the compiler writer, should have done the groundwork to validate that the way you're using the C language, with that specific compiler it is intended for, yields the correct behavior which implements the intent of your language. You should dictate all code generation and diagnosis options. Or else, you could write your compiler such that it outputs strictly conforming ISO C, intended to be compiled by any compiler with its highest or close-to-highest diagnostic levels. Identify a target set of compilers and test with all of them, working toward tweaking your generator to eliminate all warnings (without generating code variants specific to any of the compilers). That would mean that you don't get to convert function pointers and void *. Or you could target "almost strict ISO C, except that function pointers are converted to and from void *". > The simple solution is for me to stipulate the compile options, or for > me to control the process (by my backend invoking the compiler directly). That is wise. > > Apparently, you can do that with gcc: it's one positive, if bizarre, > aspect of it. What's bizarre about a tool having documented configuraton options which it obeys? > It's bizarre because *I*, as user, have to tell an actual C compiler how > to compile my code, what to treat seriously, and what to disregard. In the area of warnings, most warnings should be taken seriously. But warnings are a an area of active development. When GCC gets a new warning option, and people enable it, some people find that it is triggered hundreds of times in their code base. So, they want that warning, but at the same time are inundated with violations. The configurability lets people choose. E.g. a developer can be assigned to work (on a branch of the code) to fix the hundreds of instances of the new warning. So GCC is helpful to that workflow. The developer turns it on locally, gets the diagnostics and goes about fixing them, making one or more commits to the branch. Then when his branch is merged to the product trunk, the warning option can be turned on on the trunk. Make sense? Some projects turn all warnings into fatal errors. On such projects, the shiny new diagnostic option cannot be turned on. It won't simply cause a ream of nuisance messages in the build log, but fail the build. > In other words, I have to do half its job for it. Including finding out > whether it's has succeeded! I don't think GCC ever terminates normally, with a failed termination status, without emitting a diagnostic. (Maybe there is a special mode for that?) You must be running into a case where GCC is crashing (without having emitted any diagnostic), and you're running it from a command interpreter or other program which neglects to report that the child program has abended. Here is a dime, get a better command interpreter? -- 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 | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-01 17:48 +0000 |
| Message-ID | <20230901104426.371@kylheku.com> |
| In reply to | #173512 |
On 2023-09-01, Bart <bc@freeuk.com> wrote: > On 01/09/2023 10:10, David Brown wrote: >> On 01/09/2023 00:18, Bart wrote: > > >>> And when there is a lot going on with gcc, you can get loads of >>> warnings and other crap scrolling up the screen. So, was there an >>> "error:" in there or not? I've no idea if it worked! >> >> Fix the problems in your source code (or choice of flags to the >> compiler) - if you are getting screenfuls of errors or warnings, it is >> irrelevant whether an output file was generated or not. > > 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 Firstly, gcc is a front end to multiple languages, including multiple dialects to C. Some things which are fine in one dialect are errors in another. Everything you've ever done on any of your own compilers that was not a pure refactoring or code cleanup change, everything, always created a new dialect in which something worked that previously did not work, and for which a test case could be written which works with the changed compiler and fails with the previous one before the change. You can also tweak the diagnosis rules in GCC, so that something that is a warning can be treated as a fatal error. Users want this, and you will not pry it out of their hands. What have you ever done in any of your compilers to support a user whose code base uses your language, but from five years ago? -- 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-01 19:12 +0100 |
| Message-ID | <uct9hv$3v1lb$2@dont-email.me> |
| In reply to | #173536 |
On 01/09/2023 18:48, Kaz Kylheku wrote: > On 2023-09-01, Bart <bc@freeuk.com> wrote: >> On 01/09/2023 10:10, David Brown wrote: >>> On 01/09/2023 00:18, Bart wrote: >> >> >>>> And when there is a lot going on with gcc, you can get loads of >>>> warnings and other crap scrolling up the screen. So, was there an >>>> "error:" in there or not? I've no idea if it worked! >>> >>> Fix the problems in your source code (or choice of flags to the >>> compiler) - if you are getting screenfuls of errors or warnings, it is >>> irrelevant whether an output file was generated or not. >> >> 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 > > Firstly, gcc is a front end to multiple languages, including multiple > dialects to C. Some things which are fine in one dialect are errors > in another. > > Everything you've ever done on any of your own compilers that was > not a pure refactoring or code cleanup change, everything, > always created a new dialect in which something worked that > previously did not work, and for which a test case could be written > which works with the changed compiler and fails with the previous > one before the change. > > You can also tweak the diagnosis rules in GCC, so that something that is > a warning can be treated as a fatal error. > Users want this, and you will not pry it out of their hands. > > What have you ever done in any of your compilers to support a user > whose code base uses your language, but from five years ago? > The first two examples above are for the exact same program. For example, @options is '-Wall -Wextra -Wpedantic'; it is not defining a new dialect. While for errors, add -Werror, then you'll get a lot more than one! Is my program correct? Apparently gcc can't tell me; *I* have to tell *it*. You pretty much say that above. OK, *I* say then that if 'gcc prog.c' works with no notes, warnings or messages, then my program is fine.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-01 18:49 +0000 |
| Message-ID | <20230901114625.198@kylheku.com> |
| In reply to | #173540 |
On 2023-09-01, Bart <bc@freeuk.com> wrote: > Is my program correct? Apparently gcc can't tell me; *I* have to tell > *it*. You pretty much say that above. GCC can't tell you whether a program is correct, because it can't read your requirement specification, high level design or detailed design. It doesn't run your program, let alone execute test cases on it. > OK, *I* say then that if 'gcc prog.c' works with no notes, warnings or > messages, then my program is fine. Even if ./a.out segfaults? Yes, if the requirement specification for the program is "write me small program that segfaults on Unix". It would then be incorrect if it terminated normally. -- 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-01 21:33 +0100 |
| Message-ID | <ucthrb$gvk$2@dont-email.me> |
| In reply to | #173548 |
On 01/09/2023 19:49, Kaz Kylheku wrote: > On 2023-09-01, Bart <bc@freeuk.com> wrote: >> Is my program correct? Apparently gcc can't tell me; *I* have to tell >> *it*. You pretty much say that above. > > GCC can't tell you whether a program is correct, because it can't read > your requirement specification, high level design or detailed design. > It doesn't run your program, let alone execute test cases on it. > >> OK, *I* say then that if 'gcc prog.c' works with no notes, warnings or >> messages, then my program is fine. > > Even if ./a.out segfaults? Yes, if the requirement specification > for the program is "write me small program that segfaults on Unix". > It would then be incorrect if it terminated normally. > Ok, since you seem determined to misunderstand. Is my program a valid C program? The answer seems to depend on a lot more than just the source code submitted.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-01 21:09 +0000 |
| Message-ID | <20230901135123.702@kylheku.com> |
| In reply to | #173571 |
On 2023-09-01, Bart <bc@freeuk.com> wrote: > On 01/09/2023 19:49, Kaz Kylheku wrote: >> On 2023-09-01, Bart <bc@freeuk.com> wrote: >>> Is my program correct? Apparently gcc can't tell me; *I* have to tell >>> *it*. You pretty much say that above. >> >> GCC can't tell you whether a program is correct, because it can't read >> your requirement specification, high level design or detailed design. >> It doesn't run your program, let alone execute test cases on it. >> >>> OK, *I* say then that if 'gcc prog.c' works with no notes, warnings or >>> messages, then my program is fine. >> >> Even if ./a.out segfaults? Yes, if the requirement specification >> for the program is "write me small program that segfaults on Unix". >> It would then be incorrect if it terminated normally. >> > > Ok, since you seem determined to misunderstand. It's you who don't understand what "correct" means. When you start talking about correctness, the program's specification is involved. In fact that is all that is involved. A null pointer dereference or division by zero become correct if the specification says so. > Is my program a valid C program? The answer seems to depend on a lot > more than just the source code submitted. C is a family of languages with many dialects. An almost fifty-year-old family. C++ is a C dialect. Objective C is a C dialect. What does your question mean? Does your question mean "is this program a valid program in absolutely any C dialect that has ever existed, such that all its externally visible behaviors are the same?" That's not easy to answer, or practically useful; maybe you mean something else? gcc is a program that processes code in the C family and other families. It has dialect options, as well as customization that allow users create custom dialects, within certain obvious limits. A configuration of gcc processes one dialect, so it can tell you whether the program is acceptable under that dialect. -- 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-01 22:41 +0100 |
| Message-ID | <uctlpv$17t5$1@dont-email.me> |
| In reply to | #173582 |
On 01/09/2023 22:09, Kaz Kylheku wrote:
> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>> On 01/09/2023 19:49, Kaz Kylheku wrote:
>>> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>>>> Is my program correct? Apparently gcc can't tell me; *I* have to tell
>>>> *it*. You pretty much say that above.
>>>
>>> GCC can't tell you whether a program is correct, because it can't read
>>> your requirement specification, high level design or detailed design.
>>> It doesn't run your program, let alone execute test cases on it.
>>>
>>>> OK, *I* say then that if 'gcc prog.c' works with no notes, warnings or
>>>> messages, then my program is fine.
>>>
>>> Even if ./a.out segfaults? Yes, if the requirement specification
>>> for the program is "write me small program that segfaults on Unix".
>>> It would then be incorrect if it terminated normally.
>>>
>>
>> Ok, since you seem determined to misunderstand.
>
> It's you who don't understand what "correct" means.
>
> When you start talking about correctness, the program's specification
> is involved.
>
> In fact that is all that is involved. A null pointer dereference
> or division by zero become correct if the specification says so.
>
>> Is my program a valid C program? The answer seems to depend on a lot
>> more than just the source code submitted.
>
> C is a family of languages with many dialects. An almost fifty-year-old
> family. C++ is a C dialect. Objective C is a C dialect.
>
> What does your question mean?
>
> Does your question mean "is this program a valid program in absolutely
> any C dialect that has ever existed, such that all its externally
> visible behaviors are the same?"
Oh, FFS. We're not talking about C++, or Objective C.
But tell me what dialect of C my 'int fred(void){}' is a valid program
of. Then tell me why most C compilers are still compiling that dialect
by default in 2023.
And now tell me what dialect of C I need for that to be an INvalid program.
It sounds like you're clutching at straws to excuse all this crassness.
Fortran has been around longer than C. Do its latest compilers give
priority to being able to build code unchanged from the 60s and 70s?
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-01 22:34 +0000 |
| Message-ID | <20230901151959.699@kylheku.com> |
| In reply to | #173585 |
On 2023-09-01, Bart <bc@freeuk.com> wrote:
> On 01/09/2023 22:09, Kaz Kylheku wrote:
>> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>>> On 01/09/2023 19:49, Kaz Kylheku wrote:
>>>> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>>>>> Is my program correct? Apparently gcc can't tell me; *I* have to tell
>>>>> *it*. You pretty much say that above.
>>>>
>>>> GCC can't tell you whether a program is correct, because it can't read
>>>> your requirement specification, high level design or detailed design.
>>>> It doesn't run your program, let alone execute test cases on it.
>>>>
>>>>> OK, *I* say then that if 'gcc prog.c' works with no notes, warnings or
>>>>> messages, then my program is fine.
>>>>
>>>> Even if ./a.out segfaults? Yes, if the requirement specification
>>>> for the program is "write me small program that segfaults on Unix".
>>>> It would then be incorrect if it terminated normally.
>>>>
>>>
>>> Ok, since you seem determined to misunderstand.
>>
>> It's you who don't understand what "correct" means.
>>
>> When you start talking about correctness, the program's specification
>> is involved.
>>
>> In fact that is all that is involved. A null pointer dereference
>> or division by zero become correct if the specification says so.
>>
>>> Is my program a valid C program? The answer seems to depend on a lot
>>> more than just the source code submitted.
>>
>> C is a family of languages with many dialects. An almost fifty-year-old
>> family. C++ is a C dialect. Objective C is a C dialect.
>>
>> What does your question mean?
>>
>> Does your question mean "is this program a valid program in absolutely
>> any C dialect that has ever existed, such that all its externally
>> visible behaviors are the same?"
>
> Oh, FFS. We're not talking about C++, or Objective C.
Those are dialects of C. A program that doesn't compile as C++
isn't "valid C" by the definition of valid in any dialect whatsoever.
> But tell me what dialect of C my 'int fred(void){}' is a valid program
> of.
Right off the bat, it's not valid in anything that is before ANSI C.
Only compilers implementing ANSI C, or at least draft features of ANSI
C, would acdept (void), which is an ANSI C invention.
There are too many dialects of C, including ones I've never heard of, in
which that is potentially valid.
It is valid in C90 and in C99.
> Then tell me why most C compilers are still compiling that dialect
> by default in 2023.
Until quite recently, GCC defaulted to "gnu89": a GNU C dialect
resembling C90/ANSI C. I think it might now be handling "gnu99"
instead.
The C99 dialect of C is very popular; there is a lot of code written
in it.
A dialect based off c99 isn't a bad default choice.
(I think it would be better for gcc to refuse to do anything unless
the dialect is specified.)
> And now tell me what dialect of C I need for that to be an INvalid program.
I don't think the function requires a diagnostic in any standard C
dialect. There is no error unless the caller tries to capture the
return value.
Pretty much any gcc dialect, if given the -Werror=return-type
option rejects it.
That's included in -Wall, so if you use -Werror-all you get that
dialect also.
If you don't want that kind of code in your code base, there
is a solution.
> Fortran has been around longer than C. Do its latest compilers give
> priority to being able to build code unchanged from the 60s and 70s?
I strongly suspect, yes.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-01 15:51 -0700 |
| Message-ID | <87cyz17bj3.fsf@nosuchdomain.example.com> |
| In reply to | #173588 |
Kaz Kylheku <864-117-4973@kylheku.com> writes:
[...]
> Until quite recently, GCC defaulted to "gnu89": a GNU C dialect
> resembling C90/ANSI C. I think it might now be handling "gnu99"
> instead.
[...]
Recent versions of gcc default to "-std=gnu17".
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-02 14:06 +0100 |
| Message-ID | <ucvc0b$dv3l$1@dont-email.me> |
| In reply to | #173588 |
On 01/09/2023 23:34, Kaz Kylheku wrote: > On 2023-09-01, Bart <bc@freeuk.com> wrote: >> Fortran has been around longer than C. Do its latest compilers give >> priority to being able to build code unchanged from the 60s and 70s? > > I strongly suspect, yes. > Apparently not. These are the instructions attached to an old-style Fortran Hello program: C How to compile: C gfortran -std=legacy -c hello-world.f Notice the 'legacy' option. So, unlike most C compilers, you have to explicitly enable the ability to build old-style programs. This corresponds more or less with my '-old' option. Although that is mainly to allow things I would rather prohibit, but that can be encountered in existing code. Including, unfortunately, code written yesterday. Since one consequence of being lax by default is that it doesn't curtail the use of deprecated features.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-02 17:27 +0000 |
| Message-ID | <20230902102442.95@kylheku.com> |
| In reply to | #173647 |
On 2023-09-02, Bart <bc@freeuk.com> wrote: > On 01/09/2023 23:34, Kaz Kylheku wrote: >> On 2023-09-01, Bart <bc@freeuk.com> wrote: > >>> Fortran has been around longer than C. Do its latest compilers give >>> priority to being able to build code unchanged from the 60s and 70s? >> >> I strongly suspect, yes. >> > > Apparently not. These are the instructions attached to an old-style > Fortran Hello program: > > C How to compile: > C gfortran -std=legacy -c hello-world.f There are some old C programs that will need dialect options also. One program that needs a legacy option doesn't mean anything. The evolution of C has been marked by dogged adherence to backward compatibility. Not so sure about Fortran. Fortran has radically changed since its inception. It has some OOP features and operator overloading and such. Some features were obsoleted long ago, like hollerith strings. -- 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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-01 16:02 -0700 |
| Message-ID | <878r9p7b13.fsf@nosuchdomain.example.com> |
| In reply to | #173585 |
Bart <bc@freeuk.com> writes:
[...]
> But tell me what dialect of C my 'int fred(void){}' is a valid program
> of. Then tell me why most C compilers are still compiling that dialect
> by default in 2023.
[...]
Can you clarify what point you're making with `int fred(void){}`?
That's a valid function definition and translation unit in every version
of ISO C going back to C90, by which I mean that it does not violate any
constraint or syntax rule. (I presume we're not concerned with K&R C,
which didn't have void.) It is not a valid *program* for a hosted
implementation in any version of C, since it lacks a `main` function.
A compiler may reasonably warn about the fact that control reaches the
end of a non-void function, but the standard doesn't require a
diagnostic. Calling `fred` and not using the result is well defined.
Calling `fred` and attempting to use the result has undefined behavior.
No diagnostic is required, up to and including C23. (There are
historical reasons for this, which I won't go into.)
Note carefully that I am describing the requirements given by the C
standard, not expressing an opinion on whether they're good or bad.
Now, what was your point, and how does `int fred(void){}` illustrate it?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-02 01:50 +0100 |
| Message-ID | <ucu0tf$2mht$1@dont-email.me> |
| In reply to | #173594 |
On 02/09/2023 00:02, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> But tell me what dialect of C my 'int fred(void){}' is a valid program
>> of. Then tell me why most C compilers are still compiling that dialect
>> by default in 2023.
> [...]
>
> Can you clarify what point you're making with `int fred(void){}`?
>
> That's a valid function definition and translation unit in every version
> of ISO C going back to C90, by which I mean that it does not violate any
> constraint or syntax rule. (I presume we're not concerned with K&R C,
> which didn't have void.) It is not a valid *program* for a hosted
> implementation in any version of C, since it lacks a `main` function.
>
> A compiler may reasonably warn about the fact that control reaches the
> end of a non-void function, but the standard doesn't require a
> diagnostic. Calling `fred` and not using the result is well defined.
> Calling `fred` and attempting to use the result has undefined behavior.
> No diagnostic is required, up to and including C23. (There are
> historical reasons for this, which I won't go into.)
>
> Note carefully that I am describing the requirements given by the C
> standard, not expressing an opinion on whether they're good or bad.
>
> Now, what was your point, and how does `int fred(void){}` illustrate it?
I would have said it's obviously wrong.
But in this group, so many people have argued that black is white, or
vice versa, that nothing surprises me any more.
Imagine buying a car with no brakes. Oh, nothing wrong that, only if you
were to actually use the brakes! Then, it would have been up to me to
insist on having brakes in the first place, something I wouldn't have
thought was my responsibility.
This either really is that crazy, or everyone is in on a conspiracy to
wind me up.
> A compiler may reasonably warn about the fact that control reaches the
> end of a non-void function,
Why only warn? This should be a hard error. Fix it and move on.
> Calling `fred` and not using the result is well defined.
People say C is unsafe. Yes it is, but this nonsense makes it extra
unsafe for no good reason.
Suppose fred() is part of a library. Then who knows what code will be
calling it and whether that value is expected.
What possible point, what advantage, is there in defining a function's
return type, but not providing any value?
Look, I promised this guy I would overhaul at my C compiler. Fortunately
the task is interesting, and for now, it doesn't involving dealing with
much C code.
Otherwise, this crazy language, crazy compilers, crazy tools and the
crazy opinions of its adherents are seriously doing my head in.
I've given staggeringly bad examples of each, but nobody is fazed.
There's always some excuse. And if there is no actual reason, it's
because it's how it worked in 1974 so it has to be like that for eternity.
I'm going back to my own saner language and compilers that don't beat
about the bush:
func fred:int =
end
"Return value missing"
I can't proceed until I provide one, or change it to a function that
doesn't return a value.
Is there ... anything wrong with that?
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-02 01:12 +0000 |
| Message-ID | <20230901175635.91@kylheku.com> |
| In reply to | #173602 |
On 2023-09-02, Bart <bc@freeuk.com> wrote:
> On 02/09/2023 00:02, Keith Thompson wrote:
>> Now, what was your point, and how does `int fred(void){}` illustrate it?
>
> I would have said it's obviously wrong.
>
> But in this group, so many people have argued that black is white, or
> vice versa, that nothing surprises me any more.
It's a good idea to produce a diagnostic in cases when it's obvious
that the control graph of the function reaches the end without
hitting a return statement.
C allowing the return, provided that the caller doesn't use the
value, is a bit of a relic. Early C worked that way because
every function returned int, but not every function needed
to return anything. It's not a good feature today.
Keith seems to have mentioned that something had been done about it
in C23?
Anyway, compilers can diagnose it even though it's not required.
It would be significantly more difficult to work with C without
compilers that go beyond required diagnostics.
You can't just blindly diagnose this as a syntactic issue; i.e.
that the last statement of a function which returns a value isn't
a return statement.
We don't want this diagnosed:
int fred(void)
{
if (this)
return that;
else
return other;
}
Basically we want the last statement to to be a "tail statement",
which is defined as a return statement, or else a statement which
has a tail statement in every tail position.
The body of a loop is a tail statement if there is no break or goto out
of it.
A loop is a tail statement if its guard is a constant expression
evaluating to true.
A function call is a tail statement if it calls a function known
not to return: abort(), longjmp(), exit() and some others.
> Imagine buying a car with no brakes. Oh, nothing wrong that, only if you
Imagine buying a power transistor with no thermal shutoff.
Wait, that's pretty much all of them.
Engineering products and consumer products are different.
A transistor has good reasons for being the way it is; a language
allowing control flow to fall off the end without a return value
isn't such a good reason. We can't compare the justification.
It's still an engineering tool with a "safe operating area"
that you have to observe, and not comparable to a consumer product.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-01 19:13 -0700 |
| Message-ID | <8734zx8gpv.fsf@nosuchdomain.example.com> |
| In reply to | #173603 |
Kaz Kylheku <864-117-4973@kylheku.com> writes:
[...]
> C allowing the return, provided that the caller doesn't use the
> value, is a bit of a relic. Early C worked that way because
> every function returned int, but not every function needed
> to return anything. It's not a good feature today.
>
> Keith seems to have mentioned that something had been done about it
> in C23?
No, it's the same in C23.
N3096 6.9.1p12:
Unless otherwise specified, if the } that terminates the function
body is reached, and the value of the function call is used by the
caller, the behavior is undefined.
I think the "unles otherwise specified" refers to the special case rule
for falling off the end of main().
> Anyway, compilers can diagnose it even though it's not required.
>
> It would be significantly more difficult to work with C without
> compilers that go beyond required diagnostics.
>
> You can't just blindly diagnose this as a syntactic issue; i.e.
> that the last statement of a function which returns a value isn't
> a return statement.
>
> We don't want this diagnosed:
>
> int fred(void)
> {
> if (this)
> return that;
> else
> return other;
> }
>
> Basically we want the last statement to to be a "tail statement",
> which is defined as a return statement, or else a statement which
> has a tail statement in every tail position.
>
> The body of a loop is a tail statement if there is no break or goto out
> of it.
>
> A loop is a tail statement if its guard is a constant expression
> evaluating to true.
>
> A function call is a tail statement if it calls a function known
> not to return: abort(), longjmp(), exit() and some others.
[...]
To put it another way, the closing } of a non-void function (other
than main()) should be unreachable.
When C was first defined, and probably as late as 1989, it would
(arguably) have been unreasonable to require all C compilers to
do the kind of analysis needed to enforce this. Some more modern
languages do have requirement like this.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-02 11:57 +0100 |
| Message-ID | <ucv4e6$d0c9$1@dont-email.me> |
| In reply to | #173603 |
On 02/09/2023 02:12, Kaz Kylheku wrote:
> On 2023-09-02, Bart <bc@freeuk.com> wrote:
>> On 02/09/2023 00:02, Keith Thompson wrote:
>>> Now, what was your point, and how does `int fred(void){}` illustrate it?
>>
>> I would have said it's obviously wrong.
>>
>> But in this group, so many people have argued that black is white, or
>> vice versa, that nothing surprises me any more.
>
> It's a good idea to produce a diagnostic in cases when it's obvious
> that the control graph of the function reaches the end without
> hitting a return statement.
>
> C allowing the return, provided that the caller doesn't use the
> value, is a bit of a relic. Early C worked that way because
> every function returned int, but not every function needed
> to return anything. It's not a good feature today.
>
> Keith seems to have mentioned that something had been done about it
> in C23?
>
> Anyway, compilers can diagnose it even though it's not required.
>
> It would be significantly more difficult to work with C without
> compilers that go beyond required diagnostics.
>
> You can't just blindly diagnose this as a syntactic issue; i.e.
> that the last statement of a function which returns a value isn't
> a return statement.
>
> We don't want this diagnosed:
>
> int fred(void)
> {
> if (this)
> return that;
> else
> return other;
> }
>
> Basically we want the last statement to to be a "tail statement",
> which is defined as a return statement, or else a statement which
> has a tail statement in every tail position.
Diagnosing this fully is difficult. It requires analysis of the code to
be able to determine if control flow ever runs into the end of the
function, and then whether 'return' is executed when the last statement
in the function is complex.
However, my example is simple: there are clearly zero return statements;
at least one is needed for a value-returning function.
And a variation of my test is 'int fred{return;}'. Here, any return
obviously needs a value, and that is very easy to check.
gcc will report a warning here; clang an error; and tcc nothing.
You'd think this is a no-brainer.
(My own language compiler has no problem detecting whether a complex
last statement/expression yields a suitable return value, but it does no
analysis to detect whether that last expression is ever executed. So
sometimes a dummy return value is needed.
I do the same in my C compiler, but there you do encounter functions
with no final return <value>, which have to be allowed because they
always exit earlier. So I can't apply my check. But you need to use -old
to get away without that final return.)
>> Imagine buying a car with no brakes. Oh, nothing wrong that, only if you
>
> Imagine buying a power transistor with no thermal shutoff.
>
> Wait, that's pretty much all of them.
>
> Engineering products and consumer products are different.
>
> A transistor has good reasons for being the way it is; a language
> allowing control flow to fall off the end without a return value
> isn't such a good reason. We can't compare the justification.
If such a function was used in a library module within automotive
software that controlled the brakes, then yes there is justification.
Why make C even more crazily unsafe than it already is? You should have
to fight to allow unsafe code, not have to fight to make it safe!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-02 18:19 +0200 |
| Message-ID | <ucvna1$fb08$7@dont-email.me> |
| In reply to | #173646 |
On 02/09/2023 12:57, Bart wrote:
> On 02/09/2023 02:12, Kaz Kylheku wrote:
>> On 2023-09-02, Bart <bc@freeuk.com> wrote:
>>> On 02/09/2023 00:02, Keith Thompson wrote:
>>>> Now, what was your point, and how does `int fred(void){}` illustrate
>>>> it?
>>>
>>> I would have said it's obviously wrong.
>>>
>>> But in this group, so many people have argued that black is white, or
>>> vice versa, that nothing surprises me any more.
>>
>> It's a good idea to produce a diagnostic in cases when it's obvious
>> that the control graph of the function reaches the end without
>> hitting a return statement.
>>
>> C allowing the return, provided that the caller doesn't use the
>> value, is a bit of a relic. Early C worked that way because
>> every function returned int, but not every function needed
>> to return anything. It's not a good feature today.
>>
>> Keith seems to have mentioned that something had been done about it
>> in C23?
>>
>> Anyway, compilers can diagnose it even though it's not required.
>>
>> It would be significantly more difficult to work with C without
>> compilers that go beyond required diagnostics.
>>
>> You can't just blindly diagnose this as a syntactic issue; i.e.
>> that the last statement of a function which returns a value isn't
>> a return statement.
>>
>> We don't want this diagnosed:
>>
>> int fred(void)
>> {
>> if (this)
>> return that;
>> else
>> return other;
>> }
>>
>> Basically we want the last statement to to be a "tail statement",
>> which is defined as a return statement, or else a statement which
>> has a tail statement in every tail position.
>
> Diagnosing this fully is difficult. It requires analysis of the code to
> be able to determine if control flow ever runs into the end of the
> function, and then whether 'return' is executed when the last statement
> in the function is complex.
>
> However, my example is simple: there are clearly zero return statements;
> at least one is needed for a value-returning function.
By that definition, this version would be perfectly acceptable to you :
int fred(void) {
if (1 + 1 != 2) return 0;
}
>
> And a variation of my test is 'int fred{return;}'. Here, any return
> obviously needs a value, and that is very easy to check.
>
> gcc will report a warning here; clang an error; and tcc nothing.
That's a constraint error (section 6.8.6.4p1), so it requires a
diagnostic (regardless of whether or not "fred" is used, or how it is
used). A diagnostic can be an error or a warning. (I personally would
prefer an error here.)
>
> You'd think this is a no-brainer.
>
You'd be surprised how often reality is vastly more complicated than
what you think of as a "no-brainer". Your programming world is so small
and sheltered, and you never offer a thought to anyone else or their
needs and preferences, so you miss pretty much every nuance involved.
[toc] | [prev] | [next] | [standalone]
Page 11 of 18 — ← Prev page 1 … 9 10 [11] 12 13 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web