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 4 of 18 — ← Prev page 1 2 3 [4] 5 6 … 18 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-01 02:40 +0100 |
| Message-ID | <ucrfep$3gcdi$1@dont-email.me> |
| In reply to | #173459 |
On 01/09/2023 02:09, Paul Edwards wrote:
> On Friday, September 1, 2023 at 8:44:20 AM UTC+8, Bart wrote:
>
>> You're sort of missing the point. Is it really that hard to do:
>>
>> puts("Compilation failed");
>> exit(1);
>
> That is already being done - an error message is printed
> when there is an error.
>
> What is not being done is:
>
> puts("Compilation succeeded");
> exit(0);
>
> So on Windows - if there was a crash - not a deliberate
> exit - you don't know if it was successful or not.
Where this is an issue: I can't tell whether a program has failed or
passed, I will put in such a message.
On my compilers, on a 20-year-old one it says:
Compilation Complete
On recent ones, a terminating message is not shown (or it is subtle,
like adding a full-stop when done, or it needs -v).
Because they usually finish instantly, I can tell if there has been a
crash because it takes a second or so to terminate.
> But if Windows had the ability to display "crashed", the
> same as that Unix option, you would know.
It used to say that; I've no idea why it doesn't do so now.
>
> P.S. I have replied to your email - please check your spam folder if
> you didn't receive it, or return the conversation to here if we are
> having communication issues.
OK.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-01 01:29 +0000 |
| Message-ID | <20230831182232.547@kylheku.com> |
| In reply to | #173458 |
On 2023-09-01, Bart <bc@freeuk.com> wrote:
> Are you so averse to 'verbosity' then a one-line message reporting a
> failure cannot be tolerated?
I don't know about Keith, but I don't want to see "compilation failed",
bcause I want to see something else.
I want to see specific diagnostics, pinpointed to locations in the
file.
If there is nothing to diagnose, then the compilation should be
successful.
If there is something to diagnose, the failed message is redundant.
If all the diagnostics are warning: then we have success; if any
of them are error: then not.
What is your repro test case for a quiet gcc run that has failed?
(I missed it).
What I don't want is diagnostics on *success*:
C:\> copy hello.txt con
Hello
1 file(s) copied
Yikes. I said copy the content sof hello.txt to con, and it copied
that plus something else I didn't ask for.
--
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-08-31 20:28 -0700 |
| Message-ID | <87y1hq7et3.fsf@nosuchdomain.example.com> |
| In reply to | #173458 |
Bart <bc@freeuk.com> writes:
> On 01/09/2023 00:46, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 31/08/2023 23:07, Scott Lurndal wrote:
>> [...]
>>>> If it doesn't say anything, it worked. If it doesn't work it will
>>>> say something. If your really want to know what it's doing, use
>>>> -v.
>>>
>>> <Literally both face palms on face>
>>>
>>> If it doesn't say anything, it worked? Since Windows 10, a crashing
>>> program doesn't say anything; it silently fails.
>> [...]
>> If gcc fails, it returns a status that indicates failure. If you're
>> using a Bourne-like shell, you can examine the value of $?. In a
>> Windows command shell, `echo %errorlevel%`. In PowerShell, $? is True
>> or False, and $LASTEXITCODE is the status value.
>> I've configured bash to show me any non-zero exit value after
>> running a
>> command. I don't know whether you can do that on Windows.
>
> You're sort of missing the point.
No, I'm making a different point. I was *explaining* to you how gcc
behaves.
I don't think I've ever seen you learn something and be happy about it.
I find that bizarre.
> Is it really that hard to do:
>
> puts("Compilation failed");
> exit(1);
>
> rather than:
>
> exit(1);
No, of course it's not hard to do. gcc doesn't do that, but for
reasons that have nothing to do with any difficulty of implementing it.
And you're angry at me for not being angry about it.
I won't cause you further pain by trying to explain the reasons.
> Are you so averse to 'verbosity' then a one-line message reporting a
> failure cannot be tolerated?
No.
In another message in this thread, I wrote:
I acknowledge that you prefer tools to be verbose, and that you have
perfectly valid reasons to want a compiler to show what it's doing
and for a file copying program to print the name of each file as
it's copying it.
I believe you are capable of understanding that. You choose to pretend
that you don't.
> I find it bizarre that you like your programs so silent that you need
> to employ external means to find if they ran successfully or not!
I'm sure you do.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-01 11:10 +0200 |
| Message-ID | <ucs9pb$3nd9i$1@dont-email.me> |
| In reply to | #173450 |
On 01/09/2023 00:18, Bart wrote: > On 31/08/2023 23:07, Scott Lurndal wrote: >> Bart <bc@freeuk.com> writes: >>> On 31/08/2023 18:36, David Brown wrote: >>> >>>> Nor is it helpful for the compiler to tell me what it is doing - >>> >>> If the compiler is doing multiple files, especially a slow compiler, >>> then it is highly useful to know where it's up to, or what it's stuck >>> on. >> >> $ ps -ef | grep gcc >> >>> >>> But this seems to be a Linux thing: if I do 'cp *.c dest', then nothing >>> is output, until you get the prompt back. So, did work, did it copy >>> anything, was it one big file, or lots of small ones? >> >> If it doesn't say anything, it worked. If it doesn't work it will >> say something. If your really want to know what it's doing, use >> -v. > > > <Literally both face palms on face> > > If it doesn't say anything, it worked? Yes. > Since Windows 10, a crashing > program doesn't say anything; it silently fails. A decent OS will tell you if something has crashed. > > 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. I certainly fail to see how the situation would be improved by a message at the start saying "Compiling hello.c to hello.o" ! When you have lots of errors or warnings like this, some suggestions are: 1. Use a terminal that lets you scroll back to the start. Try something other than Window's amateur terminal - or at least, change the default settings from tiny scroll buffer to something useful. 2. Pipe the output into "less" (or "more", if you are limited to Window's own tools). 3. Use an editor or IDE from this century - then all your errors or warnings will be shown in your source code, so that you go straight to the problems. 4. Use "-fmax-errors=5" to stop after the first 5 errors, or "-Wfatal-errors" to halt on any problems, or "-Werror" to make warnings into errors (combine with "-fmax-errors="). These are all documented, unsurprisingly, under "Options to Request or Suppress Warnings". > > I have to see if there is a recent .exe just created. > > Or sometimes I get a clue by there being a pause after the last message, > meaning it's doing the rest of it. > > (Or maybe it's just crashed.) You'll get a message if there is a crash. > > Or I have to supply options to tell it to stop after one error (I have > to find it first). See above. Or try google - it tends to be far more efficient than whining and moaning. > > Or I have to capture the output twice (first with >, second after I've > remembered it's 2>), so that I can use a text editor to search for > "error:" strings. > > What an effing palaver. What do you expect to get if you have lots of errors in your code? A pat on the back and a Blue Peter badge? > > gcc is not the only program like that, but it seems typical of where it > came from. > > >>> The defaults are backwards. >> >> No. > > Delude yourself if you like. > I bet you were in the army cadets when you were a kid, and your mum would watch the parade and tell people how everyone else is out of step except for her little Bart. Is that why you refuse to acknowledge other people think differently from you?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-01 12:01 +0100 |
| Message-ID | <ucsg9u$3ofr6$1@dont-email.me> |
| In reply to | #173503 |
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
In the first two cases, the .exe runs fine. I've just asked it to be
more picky. It's telling the difference between the last two that is the
problem. The one error is buried in those warnings. There is no summary
at the end.
This is where you need to use half a dozen ways to figure out:
DID IT WORK?
DID IT NOT WORK?
Because the compiler, aften 30,000 lines of output, decides it would be
too verbose to print a one-line summary.
With bcc, in order to more easily detect a silent crash, I added a
confirmation message, but it is subtle (it was for my use).
bcc prog.c
Compiling prog.c to prog.exe
When it finished it adds a full-stop:
Compiling prog.c to prog.exe.
If there was an error, it will report the error and stop. There is only
the one error, and there are no warnings.
With lccwin32, if there are any errors or warnings, it will summarise as:
2 errors, 0 warnings
It's really not hard.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-01 13:20 +0200 |
| Message-ID | <ucshdt$3ogjc$1@dont-email.me> |
| In reply to | #173512 |
On 01/09/2023 13: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 > > In the first two cases, the .exe runs fine. I've just asked it to be > more picky. It's telling the difference between the last two that is the > problem. The one error is buried in those warnings. There is no summary > at the end. > > This is where you need to use half a dozen ways to figure out: > > DID IT WORK? > > DID IT NOT WORK? I think a more interesting question here is "Do you want it to work?" And the answer, of course, is "No" - you don't want it to work, you don't want to know how to get it to work, or how to find out what went wrong. If you ever listened to advice, suggestions or help, or tried to make things work rather than working so hard to get failures, you might accidentally discover that gcc is usable after all. And that would be just terrible for you. You have such a strong emotional investment in the idea that you are always right, all your opinions are the best, your languages and tools are perfect, while all other languages and tools are utterly useless and all other opinions are completely wrong, that contradictory evidence would be devastating. It must be very difficult for you, being so fragile.
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.com> |
|---|---|
| Date | 2023-09-01 13:08 +0100 |
| Message-ID | <ucsk81$3p2kg$1@dont-email.me> |
| In reply to | #173512 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-01 13:39 +0100 |
| Message-ID | <ucsm1u$3pb1c$1@dont-email.me> |
| In reply to | #173516 |
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,
| ^
You can't turn a 64-bit void* pointer on x64 into a 64-bit function
pointer? **** off!
Or unused labels. Or unused parameters (in a suite of functions that
must share the same set).
How do I discover the important ones?
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.
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).
Apparently, you can do that with gcc: it's one positive, if bizarre,
aspect of it.
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 other words, I have to do half its job for it. Including finding out
whether it's has succeeded!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-01 15:29 +0200 |
| Message-ID | <ucsp0c$3pmm2$1@dont-email.me> |
| In reply to | #173518 |
On 01/09/2023 14:39, Bart 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, > | ^ > > You can't turn a 64-bit void* pointer on x64 into a 64-bit function > pointer? **** off! > > > Or unused labels. Or unused parameters (in a suite of functions that > must share the same set). > > How do I discover the important ones? > > 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. > > 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). > > Apparently, you can do that with gcc: it's one positive, if bizarre, > aspect of it. > > 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 other words, I have to do half its job for it. Including finding out > whether it's has succeeded! If you ever decide you want to learn C, you can always ask here for help. The same applies if you ever decide you want to learn how to use gcc (though of course some people here will say it is off-topic). All that will be asked of you, is that you ask politely and listen to the answers, and do your best to understand. It's not actually very hard.
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.com> |
|---|---|
| Date | 2023-09-01 14:32 +0100 |
| Message-ID | <ucsp6b$3pog4$1@dont-email.me> |
| In reply to | #173518 |
On 01/09/2023 13:39, Bart 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: No. 10,000 warnings is ridiculus. > > cc.c:5363:5: warning: ISO C forbids initialization between function > pointer and 'void *' [-Wpedantic] > 5363 | &cc_genasm$stropndx, > | ^ > > You can't turn a 64-bit void* pointer on x64 into a 64-bit function > pointer? **** off! You could use actual function pointers that have the correct signature? You don't really call every function thru one single void*? > > > Or unused labels. Or unused parameters (in a suite of functions that > must share the same set). So, shut the warning up. Otherwise it's just noise. Most people say: (void) unused_var; > > How do I discover the important ones? By fixing the unimportant ones. > > 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. Maybe fix the generator to produce correct code in the first place? > > 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). > > Apparently, you can do that with gcc: it's one positive, if bizarre, > aspect of it. > > 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 other words, I have to do half its job for it. Including finding out > whether it's has succeeded!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-01 18:14 +0200 |
| Message-ID | <uct2li$3rhet$1@dont-email.me> |
| In reply to | #173521 |
On 01/09/2023 15:32, Richard Harnden wrote: > On 01/09/2023 13:39, Bart 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: > > No. 10,000 warnings is ridiculus. Yes. It's because he does silly things (like using "void *" for function pointers), and because he views warnings as all or nothing - for Bart, it's either "gcc" or "gcc -Wall -Wextra", just as optimisation is always either "-O0" or "-O3". Taking advice, reading manuals, or knowing what he is doing are not his specialities. > >> >> cc.c:5363:5: warning: ISO C forbids initialization between function >> pointer and 'void *' [-Wpedantic] >> 5363 | &cc_genasm$stropndx, >> | ^ >> >> You can't turn a 64-bit void* pointer on x64 into a 64-bit function >> pointer? **** off! > > You could use actual function pointers that have the correct signature? He has been told countless times that, at the very least, "void*(void)" would be hugely better. > You don't really call every function thru one single void*? Yes, he converts pretty much everything to "void*". > >> >> >> Or unused labels. Or unused parameters (in a suite of functions that >> must share the same set). In C23, unused parameters can be left unnamed - though apparently that is an abomination in Bart's eyes. > > So, shut the warning up. Otherwise it's just noise. > Most people say: > (void) unused_var; Or use -Wno-unused-parameters -Wno-unused-labels, etc. Or use #pragma GCC diagnostic ignored "-Wunused". Or stop generating unused labels. There are plenty of possibilities. > >> >> How do I discover the important ones? > > By fixing the unimportant ones. > >> >> 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. > > Maybe fix the generator to produce correct code in the first place? And if the generator produces things like extra unused labels (it's not uncommon), it could also generate pragmas to disable those warnings even if the user had enabled them at the command line. It would also make a great deal of sense to have pragmas for "-fwrapv" and "-fno-strict-aliasing", since Bart's code generator requires these. > >> >> 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). >> >> Apparently, you can do that with gcc: it's one positive, if bizarre, >> aspect of it. >> >> 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 other words, I have to do half its job for it. Including finding >> out whether it's has succeeded! >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-01 19:01 +0100 |
| Message-ID | <uct8ss$3v1lb$1@dont-email.me> |
| In reply to | #173521 |
On 01/09/2023 14:32, Richard Harnden wrote:
> On 01/09/2023 13:39, Bart wrote:
>> You're joking, right? Maybe some of them I need to do something about,
>> but most of them are irrelevant:
>
> No. 10,000 warnings is ridiculus.
>
>>
>> cc.c:5363:5: warning: ISO C forbids initialization between function
>> pointer and 'void *' [-Wpedantic]
>> 5363 | &cc_genasm$stropndx,
>> | ^
>>
>> You can't turn a 64-bit void* pointer on x64 into a 64-bit function
>> pointer? **** off!
>
> You could use actual function pointers that have the correct signature?
> You don't really call every function thru one single void*?
>
>>
>>
>> Or unused labels. Or unused parameters (in a suite of functions that
>> must share the same set).
>
> So, shut the warning up. Otherwise it's just noise.
> Most people say:
> (void) unused_var;
I don't want to, and I shouldn't need to.
Here I'm using C as a portable assembler. In assembly, you don't need to
care about unused labels, unused parameters, or having a function
pointer in the same 64-bit register as an integer.
Generating C is supposed to make some things easier. It's not supposed
to make things harder!
If I compile my generated C with any of:
bcc prog
tcc prog.c
gcc prog.c -oprog
it works perfectly.
Unless there's actually something wrong with prog.c. In that case:
* Why doesn't gcc show any errors?
* Why not even warnings?
* Why is it generating an executable?
If the famous gcc thinks my program is OK, then that suits me fine.
If interpreting a 64-bit address as a function rather than object
pointer is such a no-no, then where's the hard error?
WHY is it letting such a serious infringement through?
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-01 18:53 +0000 |
| Message-ID | <20230901114952.369@kylheku.com> |
| In reply to | #173538 |
On 2023-09-01, Bart <bc@freeuk.com> wrote: > If I compile my generated C with any of: > > bcc prog > tcc prog.c > gcc prog.c -oprog > > it works perfectly. > > Unless there's actually something wrong with prog.c. In that case: > > * Why doesn't gcc show any errors? Because, in general, determining that "something is wrong" with a program is equivalent in difficulty to the Halting Problem, **and** being able to tell that something is wrong requires understanding the requirements specification for the program. > * Why not even warnings? You've not specified -W, and the program doesn't violate any syntax rulews or constraint rules of GNU C (the default dialect). > * Why is it generating an executable? That compiler have you written that emits diagnostics and fails to generate an executable whenever "something is wrong" with the program, and how did you do it? -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-01 14:53 +0100 |
| Message-ID | <871qfiknil.fsf@bsb.me.uk> |
| In reply to | #173518 |
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? >> 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, > | ^ > > You can't turn a 64-bit void* pointer on x64 into a 64-bit function > pointer? You asked for the program to be checked 'pedantically' and now you are complaining about that. If you don't want to know if your code violates any of C's rules, why ask? > Or unused labels. Or unused parameters (in a suite of functions that must > share the same set). > > How do I discover the important ones? It's up to you. That's the whole point. When I was porting code to a machine with distinct code and data address formats, I would have loved a warning like the one above, but the C compiler was not that helpful. Only you know if you want your code to be highly portable or not; gcc can't possibly know. > 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. 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. Anyway, why do you mind? The person ramping up the options is probably doing so for some reason, but even it's just for fun of it, it's on them. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-01 15:57 +0100 |
| Message-ID | <ucsu3s$3qfrk$1@dont-email.me> |
| In reply to | #173523 |
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? > >>> 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, >> | ^ >> >> You can't turn a 64-bit void* pointer on x64 into a 64-bit function >> pointer? > > You asked for the program to be checked 'pedantically' and now you are > complaining about that. If you don't want to know if your code violates > any of C's rules, why ask? This is what happened in 2014 when I first posted some generated C code here. People would apply all sorts of advanced warning levels. But was there an actual bug in my program or not? If there was, why wasn't it caught with 'gcc prog.c' and why did it proceed to generate an executable? (The object/function pointer issue wasn't of great interest. In both the source language and known targets the conversion (actually, a no-op) is well-defined. Only some C compilers get uppity about it. There might have reason to do so on some exotic architecture, but then, you can get around it by a double-conversion via an intermediate integer, then those reasons appear to go out the window. My generated code can also contains lots of usused labels. I'm sure that one is not dangerous. But if people are applying their own compile options, they can also apply the ones to shut up those warnings.) >> Or unused labels. Or unused parameters (in a suite of functions that must >> share the same set). >> >> How do I discover the important ones? > > It's up to you. That's the whole point. When I was porting code to a > machine with distinct code and data address formats, I would have loved > a warning like the one above, but the C compiler was not that helpful. > Only you know if you want your code to be highly portable or not; gcc > can't possibly know. Then it needs a -Wportable check. >> 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. > > 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. In any case I would now stipulate the essential options, leaving only ones like -o and -O to the user. > Anyway, why do you mind? The person ramping up the options is probably > doing so for some reason, but even it's just for fun of it, it's on > them. It's an example of gcc hiding a potential needle in a haystack of warnings and notes. Was there anything important in there like an actual 'error:' line?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-01 19:07 +0100 |
| Message-ID | <87v8ctkbsj.fsf@bsb.me.uk> |
| In reply to | #173524 |
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... -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-01 19:27 +0100 |
| Message-ID | <uctaf3$3v98j$1@dont-email.me> |
| In reply to | #173539 |
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...
I'm not the compiler. It's supposed to tell me if my program passes.
There are apparently millions of possibilities, from zero errors to
1000s, for example if you apply -Werror.
Yes, it would be great if exam papers worked like that, you can choose
how strictly they should be marked!
But it's somewhat worrying here.
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, 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.
In mine, I deal with the last by having a legacy option (called -old)
that needs to be invoked for existing programs. But unlike ones like
gcc, that is not the default; the option must be specified.
So my product works with two dialects, old and new.
But its behaviour, given one of those, is unequivocal:
bcc prog zero errors, writes .exe
or:
bcc prog exactly one error (as it stops compilation),
no .exe produced
Given that I have a short memory, and can only fix one error at a time,
that is reasonable.
Also time to restart compilation is not an issue; it's not as though it
is an overnight build using punched cards and you have to find as many
things wrong as possible during each attempt.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-01 18:55 +0000 |
| Message-ID | <20230901115322.184@kylheku.com> |
| In reply to | #173543 |
On 2023-09-01, Bart <bc@freeuk.com> wrote: > 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... > > I'm not the compiler. It's supposed to tell me if my program passes. Passes what? The regression test suite? Is that what your own compilers do; build the program and run a test suite? Do they propose and generate the test suite, or does the hapless programmer actually have to provide one? -- 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:27 +0100 |
| Message-ID | <ucthg8$gvk$1@dont-email.me> |
| In reply to | #173552 |
On 01/09/2023 19:55, Kaz Kylheku wrote: > On 2023-09-01, Bart <bc@freeuk.com> wrote: >> 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... >> >> I'm not the compiler. It's supposed to tell me if my program passes. > > Passes what? The regression test suite? > > Is that what your own compilers do; build the program and run a > test suite? So, what the hell does gcc actually do? gcc or any of its ilk since all seem to want to emulate it. I'm genuinely interested. It seems incredibly laid-back about the whole business. Sometimes a program is OK, sometimes it isn't, sometimes it fails, depending on how how much of a bribe - sorry, a set of options - that you give it. MY compilers check that an input sourcefile for language L has a valid syntax, can fully resolve name references, obeys the type rules of the language, and does various other bits and pieces. If anything fails, it stops. If that's all OK according to the language rules, it will produce an executable. It doesn't do any speculative analysis. It can't tell whether logic or design bugs exist or not. It doesn't get involved in what you do with the executable, or what tests you might choose to perform. It just does what is expected of a COMPILER - a tool to turn source code into runnable binary code as instructed by program statements within that source code. So how does gcc manage to do pretty much what it likes, including either compiling a program with no errors or warnings, or compiling the SAME PROGRAM with fatal errors?
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-01 20:46 +0000 |
| Message-ID | <20230901133548.87@kylheku.com> |
| In reply to | #173570 |
On 2023-09-01, Bart <bc@freeuk.com> wrote: > MY compilers check that an input sourcefile for language L has a valid > syntax, Which valid syntax? As of the last night's commit which added new syntax? What if I have code that uses last year's syntax, and for the time being want to keep it that way (not have newer syntax creeping in accidentally?) Oh shit! Look, someone likes your language and has written their own implementation. It has a few differences and extensions. Users are starting to use them and complaining they don't work in the original. Do you support those, unconditionally? > can fully resolve name references, obeys the type rules of the > language, and does various other bits and pieces. Do your compilers target PPC? I have a project that runs on big endian PPC64. Also ported it to Loongarch: this new ISA from China. SPARC? MIPS? RISCV? Oh wait yes; thanks to GCC ... > So how does gcc manage to do pretty much what it likes, including either > compiling a program with no errors or warnings, or compiling the SAME > PROGRAM with fatal errors? By supporting forty years of C revisions, plus its dialect, plus having flexible code generation and diagnosis options, that the users want and depend on. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
Page 4 of 18 — ← Prev page 1 2 3 [4] 5 6 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web