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 3 of 18 — ← Prev page 1 2 [3] 4 5 … 18 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-31 16:17 +0100 |
| Message-ID | <ucqaub$3bcsk$1@dont-email.me> |
| In reply to | #173404 |
On 31/08/2023 15:30, Bart wrote: > On 31/08/2023 13:36, David Brown wrote: >> On 31/08/2023 12:58, Bart wrote: >>> On 30/08/2023 23:54, Paul Edwards wrote: >>>> Hi Bart. >>>> >>>> Next error I have is: >>>> >>>> cc64 -c -out:cclib/cclib.obj cclib/cclib.i >>>> Compiling cclib/cclib.i to cclib/cclib.obj >>> >>> >>> BTW the -out option is not needed here. The output file uses the same >>> filename and the same path, just the extension is changed. >>> >>> So the generated .obj file is in the same folder as the .c or .i >>> source file. The same applies when generating executables; you can >>> compile code remotely. >>> >>> Other C compilers may be different; gcc for example applies the right >>> extension, but the object file (or executable) is written to the >>> current directory. And others tend to copy gcc. >>> >> >> Putting object files (or other generated files) in the same directory >> as the source files is okay for small projects. If you've only got a >> half-dozen source files, it can be tidy to keep them all in the same >> directory. >> >> If you are doing something bigger you almost invariably want to keep >> the source tree and the generated files in separate directories. It >> makes it much easier to see what's changed, to clean out object files, >> to track source in a revision control system of some kind, to find the >> source files amongst all the generated files, etc. Details, of >> course, vary by person and project - too many directories and >> subdirectories makes it hard to keep an overview of the files, as does >> too few directories. This is known as "out of tree builds", and is >> the norm for most projects above a certain size. >> >> So whatever your default here - whether it is generating the object >> file in the same directory as the source file, or generating it in the >> current directory - it will be convenient in some cases, and >> completely wrong in other cases. > > But putting it in the current directory is sloppy. The current location > can be arbitrary (or it might not be writeable): > > c:\random>gcc \proj1\foo.c > c:\random>gcc \proj2\bar.c > > Here, both compilations generate a.exe. But to cap that, both end up in > c:\random; the second overwrites the first, something you might be > unaware of. > > If I do: > > c:\random>gcc \proj1\foo.c > c:\random>gcc \proj2\bar.c > > then there are three differences from gcc: This is not necessarily a typo due to forgetting to change 'gcc' to 'bcc'. I could have decided to rename 'bcc.exe' to 'gcc.exe' for this test.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-31 19:36 +0200 |
| Message-ID | <ucqj27$3con1$1@dont-email.me> |
| In reply to | #173404 |
On 31/08/2023 16:30, Bart wrote: > On 31/08/2023 13:36, David Brown wrote: >> On 31/08/2023 12:58, Bart wrote: >>> On 30/08/2023 23:54, Paul Edwards wrote: >>>> Hi Bart. >>>> >>>> Next error I have is: >>>> >>>> cc64 -c -out:cclib/cclib.obj cclib/cclib.i >>>> Compiling cclib/cclib.i to cclib/cclib.obj >>> >>> >>> BTW the -out option is not needed here. The output file uses the same >>> filename and the same path, just the extension is changed. >>> >>> So the generated .obj file is in the same folder as the .c or .i >>> source file. The same applies when generating executables; you can >>> compile code remotely. >>> >>> Other C compilers may be different; gcc for example applies the right >>> extension, but the object file (or executable) is written to the >>> current directory. And others tend to copy gcc. >>> >> >> Putting object files (or other generated files) in the same directory >> as the source files is okay for small projects. If you've only got a >> half-dozen source files, it can be tidy to keep them all in the same >> directory. >> >> If you are doing something bigger you almost invariably want to keep >> the source tree and the generated files in separate directories. It >> makes it much easier to see what's changed, to clean out object files, >> to track source in a revision control system of some kind, to find the >> source files amongst all the generated files, etc. Details, of >> course, vary by person and project - too many directories and >> subdirectories makes it hard to keep an overview of the files, as does >> too few directories. This is known as "out of tree builds", and is >> the norm for most projects above a certain size. >> >> So whatever your default here - whether it is generating the object >> file in the same directory as the source file, or generating it in the >> current directory - it will be convenient in some cases, and >> completely wrong in other cases. > > But putting it in the current directory is sloppy. The current location > can be arbitrary (or it might not be writeable): > > c:\random>gcc \proj1\foo.c > c:\random>gcc \proj2\bar.c > So don't do that. Make sure you are in the appropriate directory, then compile - or give the output file name directly. As I said, whatever default you use, it will be wrong sometimes. > Here, both compilations generate a.exe. But to cap that, both end up in > c:\random; the second overwrites the first, something you might be > unaware of. If you are not aware of that, you'll learn pretty quickly! > > If I do: > > c:\random>gcc \proj1\foo.c > c:\random>gcc \proj2\bar.c > > then there are three differences from gcc: > > (1) The executables are called foo.exe and bar.exe respectively > (2) They are written to their respective folders > (3) The compiler will report exactly what it is doing so there > are fewer surprises: > > Compiling \proj1\foo.c to \proj2\foo.exe > > You can use -v with gcc, but it is not helpful! Nor is it helpful for the compiler to tell me what it is doing - generally I know what it is doing - it is doing what I told it to do. It is only if it can't do that (due to some error) that I want to be told. Again, different defaults suit different uses and different people. Plenty of gcc's defaults are inappropriate for me, and I think should be different - but your compiler's defaults are no better. You only /think/ that your compiler's defaults are good, because they suit you personally - don't expect them to be ideal for anyone else. For any big program, excluding ones they write themselves to use themselves, some of the default settings will be sub-optimal or unusable. So your compiler's defaults are not worse than any others, nor are they better - except for your own personal tastes. > >> So IMHO it's a good habit to have an "-out" (or equivalent) option in >> your build files - then you know exactly where things are going. >> >> People who use "make" have simple and common shortcuts for this. >> Since you prefer not to use "make" or any alternative build system, >> you might want to at least add an option to specify an output >> directory. Then, for example, "cc64 -c -outdir:build src/file.c" > > Actually I have exactly that option, called '-outpath', but in my main > compilers; I haven't put it into bcc because bcc is an older project. > Fair enough. Do you also have a "-quiet" option to hide non-essential messages? That's also something I like in compilers and other tools, if it is not the default - though again, preferences vary.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-31 20:26 +0100 |
| Message-ID | <ucqpgp$3dnop$1@dont-email.me> |
| In reply to | #173410 |
On 31/08/2023 18:36, David Brown wrote: > On 31/08/2023 16:30, Bart wrote: >> On 31/08/2023 13:36, David Brow >> But putting it in the current directory is sloppy. The current >> location can be arbitrary (or it might not be writeable): >> >> c:\random>gcc \proj1\foo.c >> c:\random>gcc \proj2\bar.c >> > > So don't do that. > > Make sure you are in the appropriate directory, then compile - or give > the output file name directly. As I said, whatever default you use, it > will be wrong sometimes. But it's an extra thing that could be easily have been done right. Compilers work for us, not us for them. Suppose gcc decided to put the output files in a root directory, or some place where it would be a very bad idea to write or overwrite a file. You can't just fob people off with 'So don't do that'; it needs to be fixed. But then neither can you further fob them off with: 'It's always done that, and further, one person in 1000, or some makefile from 1974, depends on it, so we can't change it, ever'. >> Here, both compilations generate a.exe. But to cap that, both end up >> in c:\random; the second overwrites the first, something you might be >> unaware of. > > If you are not aware of that, you'll learn pretty quickly! It may not have crossed your mind, or if it had, your might assume that two distinct a.exe files were produced. >> >> If I do: >> >> c:\random[gcc \proj1\foo.c >> c:\random>gcc \proj2\bar.c >> >> then there are three differences from gcc: >> >> (1) The executables are called foo.exe and bar.exe respectively >> (2) They are written to their respective folders >> (3) The compiler will report exactly what it is doing so there >> are fewer surprises: >> >> Compiling \proj1\foo.c to \proj2\foo.exe >> >> You can use -v with gcc, but it is not helpful! > > Nor is it helpful for the compiler to tell me what it is doing - If the compiler is doing multiple files, especially a slow compiler, then it is highly useful to know where it's up to, or what it's stuck on. 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 I do 'copy *.c test' on Windows, it shows each file copied, and it tells how many files were copied in all. The 'cp' command needs '-v' to force to show what it's doing. The defaults are backwards. > generally I know what it is doing - it is doing what I told it to do. It > is only if it can't do that (due to some error) that I want to be told. > > Again, different defaults suit different uses and different people. > Plenty of gcc's defaults are inappropriate for me, and I think should be > different - but your compiler's defaults are no better. You only > /think/ that your compiler's defaults are good, because they suit you > personally No, they make more sense for casual use from a command line for anybody. > Do you also have a "-quiet" option to hide non-essential messages? > That's also something I like in compilers and other tools, if it is not > the default - though again, preferences vary. Yes, I think it's -q. If a lot of files are being processed, then you might want to turn it off (or if timing, it can make a small difference). However gcc's -v option generates 40 times as much output as my compiler without -q. So it's either far too verbose, or not enough.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-31 13:17 -0700 |
| Message-ID | <87o7in7yqm.fsf@nosuchdomain.example.com> |
| In reply to | #173423 |
Bart <bc@freeuk.com> writes:
[...]
> 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.
>
> 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 I do 'copy *.c test' on Windows, it shows each file copied, and it
> tells how many files were copied in all. The 'cp' command needs '-v'
> to force to show what it's doing.
>
> The defaults are backwards.
[...]
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.
Please acknowledge that others have valid preferences that differ from
yours. I'm not even asking you to understand why, or to like it, just
that different valid preferences exist.
Or don't. Up to you.
--
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 | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2023-08-31 21:43 +0000 |
| Subject | Verbosity in command output (Was: bart again (UCX64)) |
| Message-ID | <ucr1h9$9tnt$1@news.xmission.com> |
| In reply to | #173431 |
In article <87o7in7yqm.fsf@nosuchdomain.example.com>, Keith Thompson <Keith.S.Thompson+u@gmail.com> 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. > >Please acknowledge that others have valid preferences that differ from >yours. I'm not even asking you to understand why, or to like it, just >that different valid preferences exist. Yes, but... The problem with this form of argumentation is that it fails to acknowledge the difference between actual constructive belief and mere defense of the status quo. I.e., one often (and by "often", I mean almost universally) gets the impression that people who criticize posters like "Bart" aren't doing so out of a genuine belief that they are right and Bart is wrong, but rather out of general fear of change (i;e., the fear of the cognitive dissonance that acceptance of Bart's ideas would cause them). I get this a lot in the responses I get to my own posts. -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/Noam
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-31 23:31 +0000 |
| Subject | Re: Verbosity in command output (Was: bart again (UCX64)) |
| Message-ID | <20230831161756.139@kylheku.com> |
| In reply to | #173442 |
On 2023-08-31, Kenny McCormack <gazelle@shell.xmission.com> wrote: > In article <87o7in7yqm.fsf@nosuchdomain.example.com>, > Keith Thompson <Keith.S.Thompson+u@gmail.com> 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. >> >>Please acknowledge that others have valid preferences that differ from >>yours. I'm not even asking you to understand why, or to like it, just >>that different valid preferences exist. > > Yes, but... > > The problem with this form of argumentation is that it fails to acknowledge > the difference between actual constructive belief and mere defense of the > status quo. > > I.e., one often (and by "often", I mean almost universally) gets the > impression that people who criticize posters like "Bart" aren't doing so > out of a genuine belief that they are right and Bart is wrong, but rather I genuinely believe that I'm right when I say that 1. The environment is infinitely flexible; you can shape it to work how you want. 2. There is no unanimous agreement that its default behaviors and conventions are the "correct" ones. 3. Talk about how default behaviors and conventions should be otherwise is largely unproductive. Refere to (1). > out of general fear of change (i;e., the fear of the cognitive dissonance > that acceptance of Bart's ideas would cause them). Not really. In the world of C an Unix, there are enough loonies that over the years you end up working with a large number of different preferences for this and that. Most people who have weird or alternative preferences just code them up into their build system instead of complaining that Their Way isn't the default one imposed on everyone else, so that everyone else should customize, rather than they. Bart could easily do the same: make Unix and Linux suit his preferences by writing scripts that work with his conventions and translate that to suitable invocations of the tools. If you want "gcc foo/bar.c" o produce a program "foo/bar", you can just have a wrapper. Etc. Now, of course, setting up your own environment how you like doesn't fix other people's projects that you're trying to build. Building other people's projects can suck. It sucks not just for Bart but for the rest of us who don't mind the defaults and conventions. FOSS projects are written by volunteers. They don't owe you anything, including a build system that works how you would like. It's sad that people do counterproductive things to their programs, like vandalize their build systems with Autoconf, just because that's what others have done and they read about it in some blog or tutorial. Most FOSS maintainers don't read this newsgroup so you literally don't achive a thing by complaining here about how FOSS projects are hard bo build. If you think that some FOSS program is really useful to you and you regularly engage its build system, which sucks, you can contribute a better one. Better to ask first whether they would be interested, before wasting your time. -- 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 | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-31 21:36 -0700 |
| Subject | Re: Verbosity in command output (Was: bart again (UCX64)) |
| Message-ID | <1504cba3-fafa-4ab8-a807-b15b287baef6n@googlegroups.com> |
| In reply to | #173454 |
On Friday, 1 September 2023 at 00:32:03 UTC+1, Kaz Kylheku wrote: > > Building other people's projects can suck. It sucks not just for > Bart but for the rest of us who don't mind the defaults and conventions. > > FOSS projects are written by volunteers. They don't owe you anything, > including a build system that works how you would like. > > It's sad that people do counterproductive things to their programs, like > vandalize their build systems with Autoconf, just because that's what > others have done and they read about it in some blog or tutorial. > Bart's basic complaint is right. It's too hard to build many projects, and if the build system breaks, it's too hard to fix it. Or the build requires an unacceptable installation of dependencies into your global workspace. Generally big projects are OK. They are well maintained, and when people complain of glitches in the build system, they are ironed out. But small projects are very likely to have build issues.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-01 17:22 +0000 |
| Subject | Re: Verbosity in command output (Was: bart again (UCX64)) |
| Message-ID | <20230901100809.710@kylheku.com> |
| In reply to | #173483 |
On 2023-09-01, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > On Friday, 1 September 2023 at 00:32:03 UTC+1, Kaz Kylheku wrote: >> >> Building other people's projects can suck. It sucks not just for >> Bart but for the rest of us who don't mind the defaults and conventions. >> >> FOSS projects are written by volunteers. They don't owe you anything, >> including a build system that works how you would like. >> >> It's sad that people do counterproductive things to their programs, like >> vandalize their build systems with Autoconf, just because that's what >> others have done and they read about it in some blog or tutorial. >> > Bart's basic complaint is right. It is off topic and misdirected, though. > It's too hard to build many projects, and That's the fault of those projects, whose maintainers don't read this newsgroup, and wouldn't change anything if they did. So the complaining is completely useless. It's like joining a cooking club, to complain about restaurant prices, or the design of mixers and spatulas. Probably a few regulars here work on some open source projects that Bart might find hard to build. Without a - comphrehensive, realistic proposal; - accompanied by a patch; - that works on all supported platforms; - and can be easily extended to new platforms; - and is demonstrably better than the current system; I wouldn't lift a finger. Fixing a build system is just risk that's not even in the program. Breaking builds will make your program look immature; possibly a deal breaker for a prospective user. -- 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-08-31 23:07 +0100 |
| Message-ID | <ucr2vf$3f0l6$1@dont-email.me> |
| In reply to | #173431 |
On 31/08/2023 21:17, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> 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.
>>
>> 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 I do 'copy *.c test' on Windows, it shows each file copied, and it
>> tells how many files were copied in all. The 'cp' command needs '-v'
>> to force to show what it's doing.
>>
>> The defaults are backwards.
> [...]
>
> I acknowledge that you prefer tools to be verbose,
Not at all. 'Verbose' might refer to the approx 5KB of output I get from
'gcc hello.c -v', as shown below.
I don't want that at all. What I'm asking for is more of an
acknowledgement and confirmation of what I'm asked the tool to do. That
seems reasonable enough to me.
Typing 'bcc hello' simply gives me this:
Compiling hello.c to hello.exe
Presumably you consider /that/ verbose? If so then what do you call all
that crap below!
--------------------------------
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: /gcc-13.2.0/configure --prefix=/w64devkit
--with-sysroot=/w64devkit/x86_64-w64-mingw32
--with-native-system-header-dir=/include --target=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --enable-static --disable-shared --with-pic
--with-gmp-include=/deps/include --with-gmp-lib=/deps/lib
--with-mpc-include=/deps/include --with-mpc-lib=/deps/lib
--with-mpfr-include=/deps/include --with-mpfr-lib=/deps/lib
--enable-languages=c,c++ --enable-libgomp --enable-threads=posix
--enable-version-specific-runtime-libs --disable-dependency-tracking
--disable-multilib --disable-nls --disable-win32-registry
--enable-mingw-wildcard CFLAGS_FOR_TARGET=-Os CXXFLAGS_FOR_TARGET=-Os
LDFLAGS_FOR_TARGET=-s CFLAGS=-Os CXXFLAGS=-Os LDFLAGS=-s
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/cc1.exe -quiet -v
-iprefix C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/ -isysroot
C:/tdm/bin/../x86_64-w64-mingw32 -D_REENTRANT hello.c -quiet -dumpdir a-
-dumpbase hello.c -dumpbase-ext .c -mtune=generic -march=x86-64 -version
-o C:\Users\xxxxx\AppData\Local\Temp\ccHzEGHk.s
GNU C17 (GCC) version 13.2.0 (x86_64-w64-mingw32)
compiled by GNU C version 13.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory
"C:/tdm/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.2.0/include"
ignoring nonexistent directory
"C:/tdm/bin/../x86_64-w64-mingw32/w64devkit/lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../include"
ignoring duplicate directory
"C:/tdm/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.2.0/include-fixed"
ignoring duplicate directory
"C:/tdm/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory
"C:/tdm/bin/../x86_64-w64-mingw32/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/include
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/include-fixed
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/include
End of search list.
Compiler executable checksum: 055af4833c5f81a4fd6295dedebfeca6
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
as -v -o C:\Users\xxxxx\AppData\Local\Temp\ccDDjtgp.o
C:\Users\xxxxx\AppData\Local\Temp\ccHzEGHk.s
GNU assembler version 2.40 (x86_64-w64-mingw32) using BFD version (GNU
Binutils) 2.40
COMPILER_PATH=C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/;C:/tdm/bin/../libexec/gcc/
LIBRARY_PATH=C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/;C:/tdm/bin/../lib/gcc/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../lib/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a.'
C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/collect2.exe
-plugin
C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/liblto_plugin.dll
-plugin-opt=C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/lto-wrapper.exe
-plugin-opt=-fresolution=C:\Users\xxxxx\AppData\Local\Temp\cc9Tr00r.res
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex
-plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lkernel32
-plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32
-plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32
-plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt
-plugin-opt=-pass-through=-lkernel32
--sysroot=C:/tdm/bin/../x86_64-w64-mingw32 -m i386pep -Bdynamic
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/crtbegin.o
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0
-LC:/tdm/bin/../lib/gcc
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../lib
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../..
C:\Users\xxxxx\AppData\Local\Temp\ccDDjtgp.o -lmingw32 -lgcc -lmoldname
-lmingwex -lmsvcrt -lkernel32 -lpthread -ladvapi32 -lshell32 -luser32
-lkernel32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lkernel32
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/crtend.o
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a.'
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-31 15:32 -0700 |
| Message-ID | <87fs3y971r.fsf@nosuchdomain.example.com> |
| In reply to | #173445 |
Bart <bc@freeuk.com> writes:
> On 31/08/2023 21:17, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> 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.
>>>
>>> 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 I do 'copy *.c test' on Windows, it shows each file copied, and it
>>> tells how many files were copied in all. The 'cp' command needs '-v'
>>> to force to show what it's doing.
>>>
>>> The defaults are backwards.
>> [...]
>> I acknowledge that you prefer tools to be verbose,
>
> Not at all. 'Verbose' might refer to the approx 5KB of output I get
> from 'gcc hello.c -v', as shown below.
Your preference is for tools to be more verbose than what a lot of other
people prefer.
Printing one line of output for a successful compilation or file copy is
more verbose than printing nothing.
> I don't want that at all. What I'm asking for is more of an
> acknowledgement and confirmation of what I'm asked the tool to
> do. That seems reasonable enough to me.
And I just acknowledged that your preference is valid.
> Typing 'bcc hello' simply gives me this:
>
> Compiling hello.c to hello.exe
>
> Presumably you consider /that/ verbose? If so then what do you call
> all that crap below!
I consider that more verbose than my own preference, which is for it to
print nothing on success. If gcc printed the one-line status report
that you prefer, it wouldn't particularly bother me, but I'm content
with its current behavior.
Let me clarify: I have no preference for what bcc should print, since I
don't use it. If I did, I probably wouldn't bother to figure out how to
suppress the "Compiling ..." message.
I suppose it would be nice if gcc had an option to print output that's
less verbose than what it prints with "-v", perhaps one terse line for
each program it invokes. Since I'm not a gcc maintainer, I'm not in a
position to do anything about it. Since the current behavior doesn't
bother me, I'm not going to ask the gcc maintainers to do anything about
it.
The point of my previous post was to ask you to acknowledge that others
may have valid preferences that differ from yours. You refuse to do
so. Got 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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-31 22:05 +0000 |
| Message-ID | <298IM.249420$f7Ub.232897@fx47.iad> |
| In reply to | #173423 |
Bart <bc@freeuk.com> writes: >On 31/08/2023 18:36, David Brown wrote: >> On 31/08/2023 16:30, Bart wrote: >>> On 31/08/2023 13:36, David Brow > >>> But putting it in the current directory is sloppy. The current >>> location can be arbitrary (or it might not be writeable): >>> >>> c:\random>gcc \proj1\foo.c >>> c:\random>gcc \proj2\bar.c >>> >> >> So don't do that. >> >> Make sure you are in the appropriate directory, then compile - or give >> the output file name directly. As I said, whatever default you use, it >> will be wrong sometimes. > >But it's an extra thing that could be easily have been done right. >Compilers work for us, not us for them. > >Suppose gcc decided to put the output files in a root directory, or some >place where it would be a very bad idea to write or overwrite a file. Why do you thing gcc would "decide" to do anything? You do understand that non-root users cannot "put the output files in a root directory", right? And developers don't run as root. Linux is far more secure than windows.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-31 22:07 +0000 |
| Message-ID | <aa8IM.249421$f7Ub.27491@fx47.iad> |
| In reply to | #173423 |
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. >The defaults are backwards. No.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-31 23:18 +0100 |
| Message-ID | <ucr3kb$3f58o$1@dont-email.me> |
| In reply to | #173444 |
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? Since Windows 10, a crashing program doesn't say anything; it silently fails. 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! 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.) Or I have to supply options to tell it to stop after one error (I have to find it first). 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-31 23:03 +0000 |
| Message-ID | <Z_8IM.346673$Fgta.108925@fx10.iad> |
| In reply to | #173450 |
Bart <bc@freeuk.com> writes:
>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? Since Windows 10, a crashing
>program doesn't say anything; it silently fails.
You're talking about building unix/linux tools. On *nix, a crashing program
_will_ say something (if not directly, then indirectly via the
shell return status $?).
$ cc -o /tmp/a /tmp/a.c
$ /tmp/a
Memory fault
$ printf '0x%x\n' $(( $? ))
0x10b <----- Signal 11 (SIGSEGV)
$ cat /tmp/a.c
int
main(int argc, const char **argv, const char **envp)
{
const char *cp = (const char *)0;
return *cp;
}
https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_13
>
>And when there is a lot going on with gcc, you can get loads of warnings
>and other crap scrolling up the screen.\
Acually, I don't get any warnings. -Wall -Werror.
$ pwd
/work/ws/vsim/20220509/vsim
$ make -s HUSHCOMPILE=@
VSIM_BUILT
COMPILE bct.cpp
COMPILE command_table.cpp
COMPILE contention_protocol.cpp
COMPILE dcp.cpp
COMPILE dcp_header.cpp
COMPILE disassembler.cpp
COMPILE ebcdic.cpp
COMPILE file_logger.cpp
COMPILE mcs.cpp
COMPILE mux_logger.cpp
COMPILE netport.cpp
COMPILE osdep.cpp
COMPILE pollselect.cpp
COMPILE pool.cpp
COMPILE protocol.cpp
COMPILE serialport.cpp
COMPILE station.cpp
COMPILE syslog_logger.cpp
COMPILE thread.cpp
COMPILE timer.cpp
COMPILE timer_manager.cpp
COMPILE dlp.cpp
COMPILE iocb.cpp
COMPILE card_unit.cpp
COMPILE tape_unit.cpp
COMPILE disk_unit.cpp
COMPILE file_card_unit.cpp
COMPILE file_tape_unit.cpp
COMPILE st_tape_unit.cpp
COMPILE file_disk_unit.cpp
COMPILE fips_tape_dlp.cpp
COMPILE gcr_dlp.cpp
COMPILE scsi_disk_dlp.cpp
COMPILE 5n_dlp.cpp
COMPILE odt_dlp.cpp
COMPILE uniline_dlp.cpp
COMPILE htseq_dlp.cpp
COMPILE card_reader_dlp.cpp
COMPILE train_printer_dlp.cpp
COMPILE ssp_dlp.cpp
COMPILE ssp.cpp
COMPILE qwik_dlp.cpp
COMPILE buffered_printer_dlp.cpp
COMPILE card_punch_dlp.cpp
COMPILE ht_dcp_dlp.cpp
COMPILE ht_dpdc_dlp.cpp
COMPILE isc_dlp.cpp
COMPILE scsi_tape_dlp.cpp
COMPILE telcom_dlp.cpp
BUILD ../../lib/libdlp_5n.so
BUILD ../../lib/libdlp_buffered_printer.so
BUILD ../../lib/libdlp_fips_tape.so
BUILD ../../lib/libdlp_gcr.so
BUILD ../../lib/libdlp_ht_dcp.so
BUILD ../../lib/libdlp_ht_dpdc.so
BUILD ../../lib/libdlp_htseq.so
BUILD ../../lib/libdlp_isc.so
BUILD ../../lib/libdlp_qwik.so
BUILD ../../lib/libdlp_punch.so
BUILD ../../lib/libdlp_reader.so
BUILD ../../lib/libdlp_scsi_disk.so
BUILD ../../lib/libdlp_scsi_tape.so
BUILD ../../lib/libdlp_ssp.so
BUILD ../../lib/libdlp_telcom.so
BUILD ../../lib/libdlp_tpr.so
BUILD ../../lib/libdlp_odt.so
BUILD ../../lib/libdlp_uniline.so
COMPILE system.cpp
COMPILE blt.cpp
COMPILE memory.cpp
COMPILE processor.cpp
COMPILE processor_rd.cpp
COMPILE index_register.cpp
COMPILE operand.cpp
COMPILE misc_ops.cpp
COMPILE arith_ops.cpp
COMPILE compare_ops.cpp
COMPILE branch_ops.cpp
COMPILE move_ops.cpp
COMPILE search_ops.cpp
COMPILE omega_ops.cpp
COMPILE hardware_call.cpp
COMPILE time_ops.cpp
COMPILE environment.cpp
COMPILE environment_table.cpp
COMPILE kernel_data_area.cpp
COMPILE float.cpp
COMPILE mop.cpp
COMPILE toggles.cpp
COMPILE intflags.cpp
HOSTCOMPILE makedigits
COMPILE digits.cpp
COMPILE add.cpp
COMPILE sub.cpp
COMPILE op_acm.cpp
COMPILE op_add.cpp
COMPILE op_and.cpp
COMPILE op_asp.cpp
COMPILE op_ate.cpp
COMPILE op_b2d.cpp
COMPILE op_bct.cpp
COMPILE op_brt.cpp
COMPILE op_brv.cpp
COMPILE op_brv_reva.cpp
COMPILE op_bst.cpp
COMPILE op_cio.cpp
COMPILE op_cio_reva.cpp
COMPILE op_cpn.cpp
COMPILE op_cps.cpp
COMPILE op_d2b.cpp
COMPILE op_dec.cpp
COMPILE op_edt.cpp
COMPILE op_ext.cpp
COMPILE op_hbk.cpp
COMPILE op_hbr.cpp
COMPILE op_hcl.cpp
COMPILE op_hsh.cpp
COMPILE op_iad.cpp
COMPILE op_ias.cpp
COMPILE op_idl.cpp
COMPILE op_iio.cpp
COMPILE op_ild.cpp
COMPILE op_ils.cpp
COMPILE op_imi.cpp
COMPILE op_ims.cpp
COMPILE op_imu.cpp
COMPILE op_inc.cpp
COMPILE op_ioc.cpp
COMPILE op_ioc_reva.cpp
COMPILE op_ipc.cpp
COMPILE op_iss.cpp
COMPILE op_ist.cpp
COMPILE op_isu.cpp
COMPILE op_ker.cpp
COMPILE op_lix.cpp
COMPILE op_lok.cpp
COMPILE op_mls.cpp
COMPILE op_mop.cpp
COMPILE op_mvc.cpp
COMPILE op_mvd.cpp
COMPILE op_mvl.cpp
COMPILE op_mvr.cpp
COMPILE op_mvs.cpp
COMPILE op_mvw.cpp
COMPILE op_not.cpp
COMPILE op_ntr.cpp
COMPILE op_orr.cpp
COMPILE op_piq.cpp
COMPILE op_raa.cpp
COMPILE op_rad.cpp
COMPILE op_ras.cpp
COMPILE op_rds.cpp
COMPILE op_rdt.cpp
COMPILE op_rdv.cpp
COMPILE op_ret.cpp
COMPILE op_rld.cpp
COMPILE op_rms.cpp
COMPILE op_rmu.cpp
COMPILE op_rss.cpp
COMPILE op_rst.cpp
COMPILE op_rsu.cpp
COMPILE op_sde.cpp
COMPILE op_sea.cpp
COMPILE op_six.cpp
COMPILE op_sll.cpp
COMPILE op_slt.cpp
COMPILE op_smf.cpp
COMPILE op_spio.cpp
COMPILE op_sst.cpp
COMPILE op_srd.cpp
COMPILE op_stb.cpp
COMPILE op_stt.cpp
COMPILE op_sub.cpp
COMPILE op_sze.cpp
COMPILE op_trn.cpp
COMPILE op_tst.cpp
COMPILE op_ven.cpp
COMPILE op_whr.cpp
COMPILE analyze.cpp
COMPILE base.cpp
COMPILE breakpoint.cpp
COMPILE cf.cpp
COMPILE channel.cpp
COMPILE clear.cpp
COMPILE command.cpp
COMPILE control.cpp
COMPILE delete.cpp
COMPILE dis.cpp
COMPILE dump.cpp
COMPILE exchange.cpp
COMPILE haltwait.cpp
COMPILE iocbdump.cpp
COMPILE iodump.cpp
COMPILE load.cpp
COMPILE mem.cpp
COMPILE mp.cpp
COMPILE quit.cpp
COMPILE rle.cpp
COMPILE run.cpp
COMPILE save.cpp
COMPILE search.cpp
COMPILE so.cpp
COMPILE start.cpp
COMPILE state.cpp
COMPILE status.cpp
COMPILE step.cpp
COMPILE stop.cpp
COMPILE table.cpp
COMPILE to.cpp
COMPILE trace.cpp
COMPILE main.cpp
COMPILE hub.cpp
CONVERT td830.bdf
CONVERT td830B.bdf
COMPILE main.cpp
COMPILE t27.cpp
COMPILE env.cpp
COMPILE menu.cpp
COMPILE vsim_dcomm.cpp
COMPILE tapecopy.c
COMPILE tapedump.c
COMPILE vdir.c
COMPILE ebc2asc.c
COMPILE deblock.c
COMPILE tapeconvert.c
COMPILE main.cpp
COMPILE b974.cpp
COMPILE rw_alfa.cpp
COMPILE rw_arap.cpp
COMPILE rw_cdat.cpp
COMPILE rw_clab.cpp
COMPILE rw_cnst.cpp
COMPILE rw_corp.cpp
COMPILE rw_ctim.cpp
COMPILE rw_cuid.cpp
COMPILE rw_data.cpp
COMPILE rw_dlab.cpp
COMPILE rw_dom.cpp
COMPILE rw_envf.cpp
COMPILE rw_eqiv.cpp
COMPILE rw_infl.cpp
COMPILE rw_kats.cpp
COMPILE rw_lngh.cpp
COMPILE rw_mod.cpp
COMPILE rw_numr.cpp
COMPILE rw_orig.cpp
COMPILE rw_para.cpp
COMPILE rw_pict.cpp
COMPILE rw_proc.cpp
COMPILE rw_ptnm.cpp
COMPILE rw_scon.cpp
COMPILE rw_stak.cpp
COMPILE rw_stru.cpp
COMPILE rw_sync.cpp
COMPILE rw_urts.cpp
COMPILE rw_var.cpp
COMPILE op_default.cpp
COMPILE op_lix.cpp
COMPILE op_vv.cpp
COMPILE op_vvvv.cpp
COMPILE op_aaaaaa.cpp
COMPILE op_afbf_aaaaaa.cpp
COMPILE op_afbf_aaaaaa_bbbbbb.cpp
COMPILE op_afbf_aaaaaa_bbbbbb_cccccc.cpp
COMPILE assembler.cpp
COMPILE codegen.cpp
COMPILE field_length.cpp
COMPILE icm5.cpp
COMPILE line.cpp
COMPILE lister.cpp
COMPILE main.cpp
COMPILE memimage.cpp
COMPILE symbol.cpp
COMPILE symbol_table.cpp
COMPILE linker.cpp
COMPILE lmain.cpp
COMPILE main.cpp
COMPILE so.cpp
COMPILE to.cpp
COMPILE submit.cpp
COMPILE help.cpp
COMPILE spo.cpp
COMPILE quit.cpp
COMPILE rje.cpp
COMPILE main.cpp
$ file vsim
vsim: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=e863f72a2f645bf4c00a77935a1433e39967e7a7, not stripped
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-31 16:46 -0700 |
| Message-ID | <87bkem93mr.fsf@nosuchdomain.example.com> |
| In reply to | #173450 |
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.
--
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-01 01:44 +0100 |
| Message-ID | <ucrc4l$3g1tr$1@dont-email.me> |
| In reply to | #173456 |
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. Is it really that hard to do:
puts("Compilation failed");
exit(1);
rather than:
exit(1);
Are you so averse to 'verbosity' then a one-line message reporting a
failure cannot be tolerated?
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 think the most output I've had from a compiler was nearly 30,000 lines
of warnings and notes. But no errors; it had produced a working
executable. However that was not obvious.
So despite being so verbose (pointlessly so, since WTH am I supposed to
do with all that output) I still wasn't sure whether it had worked.
I guess, yet another wrapper needed to take care of yet another task
that is the compiler's job? I might as well write my own compiler! (Oh,
wait...)
[toc] | [prev] | [next] | [standalone]
| From | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| Date | 2023-08-31 18:09 -0700 |
| Message-ID | <d8f07da2-08d7-453c-9535-7383836e84f4n@googlegroups.com> |
| In reply to | #173458 |
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.
But if Windows had the ability to display "crashed", the
same as that Unix option, you would know.
I personally run everything under "pdmake" and any non-zero
exit code - or Windows crash - causes pdmake to complain and
terminate.
BFN. Paul.
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.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-08-31 18:11 -0700 |
| Message-ID | <ucrdn4$3g5mo$1@dont-email.me> |
| In reply to | #173459 |
On 8/31/2023 6:09 PM, 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.
You mean blue screen?
>
> But if Windows had the ability to display "crashed", the
> same as that Unix option, you would know.
>
> I personally run everything under "pdmake" and any non-zero
> exit code - or Windows crash - causes pdmake to complain and
> terminate.
>
> BFN. Paul.
>
>
> 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.
[toc] | [prev] | [next] | [standalone]
| From | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| Date | 2023-08-31 18:14 -0700 |
| Message-ID | <7a533b56-cb21-4fbc-b3a7-f2f5b7c704fen@googlegroups.com> |
| In reply to | #173460 |
On Friday, September 1, 2023 at 9:11:15 AM UTC+8, Chris M. Thomasson wrote:
> On 8/31/2023 6:09 PM, 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.
> You mean blue screen?
Real life example on Windows 10:
printf("before\n");
ggg = hashtab->max_load_factor * hashtab->size;
printf("after\n");
C:\devel\pdos\pdmake>pdmake --help
before
C:\devel\pdos\pdmake>
Did my program work?
Looks fine to me. No error message.
BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-01 01:38 +0000 |
| Message-ID | <20230831183028.538@kylheku.com> |
| In reply to | #173461 |
On 2023-09-01, Paul Edwards <mutazilah@gmail.com> wrote:
> Real life example on Windows 10:
>
> printf("before\n");
> ggg = hashtab->max_load_factor * hashtab->size;
> printf("after\n");
>
> C:\devel\pdos\pdmake>pdmake --help
> before
>
> C:\devel\pdos\pdmake>
>
>
> Did my program work?
>
> Looks fine to me. No error message.
That's a garbage OS / shell problem.
A reasonable job control language must inform you if a job
terminateed abnormally ("abended" in old graybeard language).
You should never have to put in inane chatter into programs
just to confirm that they worked.
It's better to fix that in one place (the command interpreter)
rather than in millions of programs.
--
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 3 of 18 — ← Prev page 1 2 [3] 4 5 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web