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 5 of 18 — ← Prev page 1 … 3 4 [5] 6 7 … 18 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-01 22:29 +0100 |
| Message-ID | <uctl33$13ie$1@dont-email.me> |
| In reply to | #173574 |
On 01/09/2023 21:46, Kaz Kylheku wrote:
> 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.
>
So you freely admit that C is a mess, and so are its compilers.
And yet, it is possible to create a compiler that gives the common-sense
results that one would expect. Except I'm not seeing it.
What do you expect the results of compiling this program with -c to be:
int fred(void){}
Here are the results I get:
Warnings Errors
gcc - -
tcc - -
clang 1 -
msvc 1 -
gcc -Wall 1 -
lccwin32 1 -
bcc - 1
The problem with that function, in case you haven't spotted it, is that
it does not return an 'int' value.
Yet, not one of those compilers other than bcc stops you creating an
executable containing a call to that function.
That can be serious, especially if the return type was a pointer.
This is just incredible. You can spout all the nonsense you like about
the long history of C, but there is no excuse for a compiler in 2023 to
pass code like that with default behaviour.
You have to give gcc -Wall to even get it to warn.
Yet, everyone here will either defend it to the death, or just brush it
off and say, Of couse, you have to provide the right options to get the
compiler to do its job properly.
(BTW, which option do you need to force a hard error on that program,
which doesn't also fail on unused lables?)
I would say, WHY doesn't it do its job anyway? WHY doesn't it operate in
a safer mode by default?
I can get my bcc to pass that program, but I have to specify -old, and
that is only so that existing can be compiled.
But why do so many existing programs have such code? Could it possibly
be because compilers have always allowed it? So the practice is
perpetuated instead of curtailed.
There is something very, very wrong with the culture of both C, and its
retinue of compilers.
Yes, I want a simple universal language that exists on every platform. I
just wish it was something better than this.
And BTW, WTF does it have to do with being to run on PPC? Does that
machine magically conjure the expected return value out of thin air. Or
are just trying to belittle my own efforts?
No doubt you, DB, KT, and everyone else will insist it is still my
fault. How about admitting that things are not as they should be?
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-01 22:19 +0000 |
| Message-ID | <20230901150200.880@kylheku.com> |
| In reply to | #173583 |
On 2023-09-01, Bart <bc@freeuk.com> wrote:
> On 01/09/2023 21:46, Kaz Kylheku wrote:
>> 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?
Not good at answering the tough questions.
>>
>>> 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.
>
> So you freely admit that C is a mess, and so are its compilers.
Absolutely.
> And yet, it is possible to create a compiler that gives the common-sense
> results that one would expect.
That no one's actual production code base would expect, but go on.
> What do you expect the results of compiling this program with -c to be:
>
> int fred(void){}
>
> Here are the results I get:
>
> Warnings Errors
>
> gcc - -
> tcc - -
> clang 1 -
> msvc 1 -
> gcc -Wall 1 -
> lccwin32 1 -
> bcc - 1
>
>
> The problem with that function, in case you haven't spotted it, is that
> it does not return an 'int' value.
That's a noteworthy fact. If a caller tries to use the return
value, there is a problem.
The C dialect/descendant which makes this an error is C++.
> Yet, not one of those compilers other than bcc stops you creating an
> executable containing a call to that function.
ISO C doesn't require implementations to fail to translate a program,
even if it contains syntax errors and constraint violations that a
conforming implementation must diagnose.
>
> That can be serious, especially if the return type was a pointer.
>
> This is just incredible. You can spout all the nonsense you like about
> the long history of C, but there is no excuse for a compiler in 2023 to
> pass code like that with default behaviour.
There is no excuse for a software engineer to be using a compiler
with default behavior. Not in 2023 or 1993.
> You have to give gcc -Wall to even get it to warn.
So why dontcha?
Wait, check this out. I can out-complain you!
You have to give gc **another c** before it even accepts C programs. That's
how much of a mess it is!
Here is what I get on Ubuntu 18:
$ cat hello.c
#include <stdio.h>
int main(void)
{
puts("hello, world!");
return 0;
}
$ gc hello.c
Error: hello.c: syntax error in line 3 near 'int'
$ gcc hello.c
$ ./a.out
hello, world!
Incredible! gc, in its default mode, cannot recognize a valid C program;
emitting bogus diagnostics. We have to add another c.
How do they live with it?
> Yet, everyone here will either defend it to the death, or just brush it
> off and say, Of couse, you have to provide the right options to get the
> compiler to do its job properly.
>
> (BTW, which option do you need to force a hard error on that program,
> which doesn't also fail on unused lables?)
$ gcc -Wall falloff.c -c
falloff.c: In function ‘func’:
falloff.c:1:18: warning: label ‘label’ defined but not used [-Wunused-label]
int func(void) { label: ; }
^~~~~
falloff.c:1:1: warning: control reaches end of non-void function [-Wreturn-type]
int func(void) { label: ; }
^~~
Okay, GCC's friendly diagnosis is telling me that the first warning
is the result of -Wunused-label. Thus:
$ gcc -Wall -Wno-unused-label falloff.c -c
falloff.c: In function ‘func’:
falloff.c:1:1: warning: control reaches end of non-void function [-Wreturn-type]
int func(void) { label: ; }
^~~
Full disclosure: I'm an idiot too, but I have a nephew here who is
starting grade 5 next week who helped me with this!
By the way, in human-written code, you probably want to remove
unused labels.
In generated code, get all your diagnostics from your own front-end,
and operate the C compiler quietly.
> I would say, WHY doesn't it do its job anyway? WHY doesn't it operate in
> a safer mode by default?
>
> I can get my bcc to pass that program, but I have to specify -old, and
> that is only so that existing can be compiled.
-old? What a mess, it's like you have multiple languages in one.
Which one is the real 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-03 13:56 +0100 |
| Message-ID | <ud1vqi$tuos$1@dont-email.me> |
| In reply to | #173586 |
On 01/09/2023 23:19, Kaz Kylheku wrote:
> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>> And yet, it is possible to create a compiler that gives the common-sense
>> results that one would expect.
>
> That no one's actual production code base would expect, but go on.
And the reason for that is...?
I would speculate that because anything goes, THAT's why there are so
many diverse code bases.
Take this program:
void fred(void){}; void bill(void)
There's an extraneous ";" that the grammar says shouldn't be there, so
it's a syntax error.
Should a compiler fail it or not? I decided mine should. That's quite
petty, but then the fix is trivial. And it means that issue will never
come up again with other compilers.
Most compilers say nothing, or at best can be coaxed into a warning.
But why be so wishy-washy? Other make it legal, or report an error.
What will probably happen is that C27x makes it legal. So all those
compilers being over-lax, suddenly start doing the right thing.
It's almost like the C standard being defined by poor common practice in
compilers. That is not the way to define a language.
>> Yet, not one of those compilers other than bcc stops you creating an
>> executable containing a call to that function.
>
> ISO C doesn't require implementations to fail to translate a program,
> even if it contains syntax errors and constraint violations that a
> conforming implementation must diagnose.
Why not? Is possible that reason for that, is that so many
implementations would not fail such code? So adding that requirement
means those would no longer conform.
Effectively it is condoning poor practice.
>> That can be serious, especially if the return type was a pointer.
>>
>> This is just incredible. You can spout all the nonsense you like about
>> the long history of C, but there is no excuse for a compiler in 2023 to
>> pass code like that with default behaviour.
>
> There is no excuse for a software engineer to be using a compiler
> with default behavior. Not in 2023 or 1993.
OK. So you tell me how a software engineer SHOULD invoke that compiler then.
Then tell me why the compiler doesn't the compiler doesn't just do that
ANYWAY?
Because at this point, 0% of software engineers will be using those
default options. So 100% of them will be typing in the exact same reams
of options for no good reason.
>> You have to give gcc -Wall to even get it to warn.
>
> So why dontcha?
>
> Wait, check this out. I can out-complain you!
>
> You have to give gc **another c** before it even accepts C programs. That's
> how much of a mess it is!
You'll have to explain what gc is.
>> (BTW, which option do you need to force a hard error on that program,
>> which doesn't also fail on unused lables?)
>
> $ gcc -Wall falloff.c -c
> falloff.c: In function ‘func’:
> falloff.c:1:18: warning: label ‘label’ defined but not used [-Wunused-label]
> int func(void) { label: ; }
> ^~~~~
> falloff.c:1:1: warning: control reaches end of non-void function [-Wreturn-type]
> int func(void) { label: ; }
> ^~~
>
> Okay, GCC's friendly diagnosis is telling me that the first warning
> is the result of -Wunused-label. Thus:
>
> $ gcc -Wall -Wno-unused-label falloff.c -c
> falloff.c: In function ‘func’:
> falloff.c:1:1: warning: control reaches end of non-void function [-Wreturn-type]
> int func(void) { label: ; }
> ^~~
>
> Full disclosure: I'm an idiot too, but I have a nephew here who is
> starting grade 5 next week who helped me with this!
>
> By the way, in human-written code, you probably want to remove
> unused labels.
If they really will be unused. Not just temporarily so during this one
compilation of 100s of versions of the source code.
> In generated code, get all your diagnostics from your own front-end,
> and operate the C compiler quietly.
>
>> I would say, WHY doesn't it do its job anyway? WHY doesn't it operate in
>> a safer mode by default?
>>
>> I can get my bcc to pass that program, but I have to specify -old, and
>> that is only so that existing can be compiled.
>
> -old? What a mess, it's like you have multiple languages in one.
>
> Which one is the real one?
The one accepted without using -old. But it is also my subset of the
language.
I thought mine was poorly defined as there is no standard or spec; I
think it is still better defined than C!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-03 15:31 +0100 |
| Message-ID | <8734zvxra0.fsf@bsb.me.uk> |
| In reply to | #173764 |
Bart <bc@freeuk.com> writes:
> Take this program:
>
> void fred(void){}; void bill(void)
This program has two syntax errors. The one you are talking about and
the missing ; or missing compound statement as the end of the line.
> There's an extraneous ";" that the grammar says shouldn't be there, so it's
> a syntax error.
>
> Should a compiler fail it or not?
The standard says that it should be reported.
> Most compilers say nothing, or at best can be coaxed into a warning.
More rhetorical spin. For gcc and clang (to take tho I can easily test)
if you ask them to check for standard C syntax, they both tell you the ;
should not be there. Both, by default, implement a whole bunch of
extensions. It's not "coaxing" to tell a tool to do what you want.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-03 16:05 +0100 |
| Message-ID | <ud27cn$vb5v$1@dont-email.me> |
| In reply to | #173788 |
On 03/09/2023 15:31, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> Take this program:
>>
>> void fred(void){}; void bill(void)
>
> This program has two syntax errors.
Sorry, I found that when I tested the above but forgot to update the post.
> The one you are talking about and
> the missing ; or missing compound statement as the end of the line.
>
>> There's an extraneous ";" that the grammar says shouldn't be there, so it's
>> a syntax error.
>>
>> Should a compiler fail it or not?
>
> The standard says that it should be reported.
And yet the first four compilers I tried don't do that.
>> Most compilers say nothing, or at best can be coaxed into a warning.
>
> More rhetorical spin. For gcc and clang (to take tho I can easily test)
> if you ask them to check for standard C syntax,
Clearly, many people don't do so. Or if they do, they ignore the warnings.
> they both tell you the ;
> should not be there.
But, they will still produce an executable. Not much of an incentive is it?
Both, by default, implement a whole bunch of
> extensions. It's not "coaxing" to tell a tool to do what you want.
The upshot is that there will still be codebases that may contain that
extra ";", which can bite later when compiled more strictly.
With my suggestion to fix it at an early stage, no codebase created
using that approach will have the extra semicolon.
This is a trivial infringement of syntax. But if the grammar says it's
wrong, then let the compilation fail.
In C, semicolons are critical: an extra or missing semicolon in
executable code can lead to serious bugs. So encourage discipline it
getting them right.
This current approach of not particularly caring seems all too typical.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-04 03:17 +0100 |
| Message-ID | <87pm2yvg0m.fsf@bsb.me.uk> |
| In reply to | #173793 |
Bart <bc@freeuk.com> writes:
> On 03/09/2023 15:31, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> Take this program:
>>>
>>> void fred(void){}; void bill(void)
>> This program has two syntax errors.
>
> Sorry, I found that when I tested the above but forgot to update the post.
>
>> The one you are talking about and
>> the missing ; or missing compound statement as the end of the line.
>>
>>> There's an extraneous ";" that the grammar says shouldn't be there, so it's
>>> a syntax error.
>>>
>>> Should a compiler fail it or not?
>> The standard says that it should be reported.
>
> And yet the first four compilers I tried don't do that.
Most programs that claim to be C compilers are not C compilers. For
example, nether the gcc nor clang command (run just like that) is a C
compiler. Both can be turned into one by simply providing a couple of
flags. I suspect, because you know this perfectly well, that you
deliberately did not run the program though a C compiler but through a
C-plus-some-set-of-extensions compiler.
Of course, compilers also have bugs. If you found an actual C compiler
that does not spot that error, then I hope you reported the bug.
>>> Most compilers say nothing, or at best can be coaxed into a warning.
>> More rhetorical spin. For gcc and clang (to take tho I can easily test)
>> if you ask them to check for standard C syntax,
>
> Clearly, many people don't do so. Or if they do, they ignore the
> warnings.
Most people who want to have C's rules applied, rather than some other
related set of rules, will learn how to do that. You appear to be an
exception. You want to know what C does or does not require (mainly so
you can complain about it) but you refuse to run a C compiler.
>> they both tell you the ;
>> should not be there.
>
> But, they will still produce an executable. Not much of an incentive is it?
>
> Both, by default, implement a whole bunch of
>> extensions. It's not "coaxing" to tell a tool to do what you want.
>
> The upshot is that there will still be codebases that may contain that
> extra ";", which can bite later when compiled more strictly.
>
> With my suggestion to fix it at an early stage, no codebase created using
> that approach will have the extra semicolon.
I think such errors should be fixed. You, of all people, should run
code through a C compiler and not a C-plus-extensions compiler.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-04 10:34 +0100 |
| Message-ID | <ud48b0$1co8f$1@dont-email.me> |
| In reply to | #173853 |
On 04/09/2023 03:17, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 03/09/2023 15:31, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> Take this program:
>>>>
>>>> void fred(void){}; void bill(void)
>>> This program has two syntax errors.
>>
>> Sorry, I found that when I tested the above but forgot to update the post.
>>
>>> The one you are talking about and
>>> the missing ; or missing compound statement as the end of the line.
>>>
>>>> There's an extraneous ";" that the grammar says shouldn't be there, so it's
>>>> a syntax error.
>>>>
>>>> Should a compiler fail it or not?
>>> The standard says that it should be reported.
>>
>> And yet the first four compilers I tried don't do that.
>
> Most programs that claim to be C compilers are not C compilers. For
> example, nether the gcc nor clang command (run just like that) is a C
> compiler.
Ha ha ha!
And here /you/ go around the same loop!
Oh, you know the product that we've been hailing as the flagship C
compiler for that few thousand posts, well it isn't really a C compiler
anyway!
So what exactly is a C compiler? What does it do? Don't bother answering.
Next I fully expect you will say that C isn't really a language. From
what I've gleaned here, it isn't. It's a collection of suggestions and
recommendations as to how an input file might be processed.
There's so much gaslighting going on here that I'm almost starting to
question my own ideas.
/My/ idea of a compiler is a simple box, with a single Go button. You
feed in a tape at one side representing source code and it writes a tape
on the other with a runnable program. When it's finished a green light
flashes. The output tape I can subsequently feed into a computer to execute.
If there's a problem with the input, a red light flashes, and no output
tape is produced.
It's almost like a consumer product that anyone can use.
Now, what would gcc look like when expressed like that? How many
thousands of buttons and lights would it have? What actual language
would be accepted? How many colours of errors lights would there be? I
know there is no green light.
How big would it be? Would it be one huge box, or would be contain other
boxes? How many different languages could it deal with?
One more thing about this box: if you don't set the dials for the title
of the output take, it will overwrite the same tape it producted a
minute ago! And of course the buttons, switches and dials all reset
themselves each time.
If we turn our attention to the question of building a program
comprising many input tapes, I would use pretty much the same simple
box. You would use another giant box with yet another 1000 buttons
called 'make', and perhaps even more boxes.
So excuse me for trying to tidy up the notions of 'language' and
'compiler' into small, simple, consumer-like concepts and tools.
I don't know what I was thinking.
> Both can be turned into one by simply providing a couple of
> flags.
Sure, prepare a special tape containing the preferred settings for those
thousands of switches. And somebody else can feed in their own tape, so
that same program tape P produces a different result.
Now if you want someone else to be able to produce the same output tape,
they will need:
* The same language tape of course
* Your extra settings tape
* The exact same make, model and version of box
Remember my remark about your program not being defined purely by the C
source code?
> Most people who want to have C's rules applied, rather than some other
> related set of rules, will learn how to do that. You appear to be an
> exception. You want to know what C does or does not require (mainly so
> you can complain about it) but you refuse to run a C compiler.
Who's to say what a C compiler is? You seem unwilling to accept my idea
of it which is outlined above. But we have to accept yours?
>>> they both tell you the ;
>>> should not be there.
>>
>> But, they will still produce an executable. Not much of an incentive is it?
>>
>> Both, by default, implement a whole bunch of
>>> extensions. It's not "coaxing" to tell a tool to do what you want.
>>
>> The upshot is that there will still be codebases that may contain that
>> extra ";", which can bite later when compiled more strictly.
>>
>> With my suggestion to fix it at an early stage, no codebase created using
>> that approach will have the extra semicolon.
>
> I think such errors should be fixed. You, of all people, should run
> code through a C compiler and not a C-plus-extensions compiler.
So, what is a C compiler again? Why can't I can't just download a 'C
compiler' and run it, why does everyone have to create their own custom
compilers for a language which ought to be the same for everyone?
That is, a language designated as C90, C99, C11 or C23. C23 is new, but
can somebody actually download a C11 compiler and have it compile strict
C11 code without first having to set up a 'C11' program on all those
switches?
Will that 'C11' compiler fail my crashing program?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-04 03:07 -0700 |
| Message-ID | <a25da57c-ae11-4e37-a844-661fa3f303abn@googlegroups.com> |
| In reply to | #173870 |
On Monday, 4 September 2023 at 10:34:39 UTC+1, Bart wrote: > > So what exactly is a C compiler? What does it do? Don't bother answering. > A compiler takes a program written in one language and translates it into another language. As the author of many languages yourself, you should know that basic defintion. > > Next I fully expect you will say that C isn't really a language. From > what I've gleaned here, it isn't. It's a collection of suggestions and > recommendations as to how an input file might be processed. > The problem is that if we extend C in a small way, for example to speed things up a bit by making 32 bit pointers "near" pointers and 64-bit pointers "far" pointers, the we've got what is technically a different language. Pointer declarations which would be syntax errors in original C are now legal, whilst a handful of legal C programs which use "far" or "near" as identifiers will break. But it isn't really a different language. It's just a slightly incompatible extension. Because gcc is written by volunteers, it's far more fun to implement new features than to write a compiler for a language where someone else has taken all the decisions. So gcc has a lot of extensions. > > There's so much gaslighting going on here that I'm almost starting to > question my own ideas. > > /My/ idea of a compiler is a simple box, with a single Go button. You > feed in a tape at one side representing source code and it writes a tape > on the other with a runnable program. When it's finished a green light > flashes. The output tape I can subsequently feed into a computer to execute. > > If there's a problem with the input, a red light flashes, and no output > tape is produced. > > It's almost like a consumer product that anyone can use. > > Now, what would gcc look like when expressed like that? How many > thousands of buttons and lights would it have? What actual language > would be accepted? How many colours of errors lights would there be? I > know there is no green light. > > How big would it be? Would it be one huge box, or would be contain other > boxes? How many different languages could it deal with? > > One more thing about this box: if you don't set the dials for the title > of the output take, it will overwrite the same tape it producted a > minute ago! And of course the buttons, switches and dials all reset > themselves each time. > A C compiler translates C into another language, almost always directly executable machine code. So the specification for a C compiler is "take a C source file and produce the executable that has the same behaviour". But of course we want more than that. We want "produce the best executable with the same behaviour". That's the rub. It's not so much that there are minor and usually unimportant trade-offs to be had between code size, memory usage, and execution speed. It's that a compiler can't actually produce the "best" executable, because optimisation isn't a computable problem (there's no Turing machine which reads a C source as input and outputs the fastest equivalent machine code as output it's mathematically impossible). So you have to ask the user. The most basic option a compiler usually has is release vs debug. But it's only necessary because of techncial limitations. Then you've got other options like "signed chars" which are necessary because of poor design decisions taken early in C's history. Then you've got options like "warning level" or "treat warnings as errors" which are cop-outs by the compiler designers and in a good compiler wouldn't be provided at all. (The concept of a warning which is only sometimes worth issuing is a strange one). The options do represent failures. But some of those failures are inherent problems in what you are asking the compiler to do. gcc of course has a ridiculous number of options and many of them could and should be culled, but you'd still be left with a substantial number which carry their weight.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-04 11:43 +0100 |
| Message-ID | <ud4ccn$1dub0$1@dont-email.me> |
| In reply to | #173875 |
On 04/09/2023 11:07, Malcolm McLean wrote: > On Monday, 4 September 2023 at 10:34:39 UTC+1, Bart wrote: >> >> So what exactly is a C compiler? What does it do? Don't bother answering. >> > A compiler takes a program written in one language and translates it into > another language. As the author of many languages yourself, you should know > that basic defintion. Yes, but what is a /C/ compiler? Because apparently: BB: > For example, nether the gcc nor clang command (run just like that) is a C compiler. Those (run just like that) will take an input and translate it into an about. But that is not compiling C according to BB. Here's a novel idea, how about taking those products (run just like that) and making them C compilers. Trustworthy ones.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-04 04:21 -0700 |
| Message-ID | <20a53e7c-6952-432e-8147-9004ab5ea79cn@googlegroups.com> |
| In reply to | #173880 |
On Monday, 4 September 2023 at 11:43:49 UTC+1, Bart wrote: > On 04/09/2023 11:07, Malcolm McLean wrote: > > On Monday, 4 September 2023 at 10:34:39 UTC+1, Bart wrote: > >> > >> So what exactly is a C compiler? What does it do? Don't bother answering. > >> > > A compiler takes a program written in one language and translates it into > > another language. As the author of many languages yourself, you should know > > that basic defintion. > Yes, but what is a /C/ compiler? Because apparently: > > BB: > > For example, nether the gcc nor clang command (run just like that) is > a C compiler. > Those (run just like that) will take an input and translate it into an > about. But that is not compiling C according to BB. > Yes, because in BB's world, a grammar either defines C, or a subset of C, or a superset of C, or a different language to C.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-04 17:16 +0100 |
| Message-ID | <8734ztvrqi.fsf@bsb.me.uk> |
| In reply to | #173881 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 4 September 2023 at 11:43:49 UTC+1, Bart wrote:
>> On 04/09/2023 11:07, Malcolm McLean wrote:
>> > On Monday, 4 September 2023 at 10:34:39 UTC+1, Bart wrote:
>> >>
>> >> So what exactly is a C compiler? What does it do? Don't bother answering.
>> >>
>> > A compiler takes a program written in one language and translates it into
>> > another language. As the author of many languages yourself, you should know
>> > that basic defintion.
>> Yes, but what is a /C/ compiler? Because apparently:
>>
>> BB:
Bart, you asked me not to reply to that question so I didn't. Given
that you don't want me to reply, I would appreciate it if you left me
out of the discussion.
>> > For example, nether the gcc nor clang command (run just like that) is
>> a C compiler.
>> Those (run just like that) will take an input and translate it into an
>> about. But that is not compiling C according to BB.
>>
> Yes, because in BB's world, a grammar either defines C, or a subset of C,
> or a superset of C, or a different language to C.
It's more than just the grammar, the defined semantics matter as well,
but that's the gist of it. I'd hope that you also define a programming
language as a grammar plus semantics. That's why names like C99 and GNU
C are used -- they name different languages.
Do you know that gcc (with no other flags or options) will report no
syntax errors for this source code:
PROGRAM HELLO
WRITE (*,*) 'Hello world'
END
? Is it only in "my world" that the plain gcc command is not a C
compiler?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-04 18:33 +0100 |
| Message-ID | <ud54co$1ij02$1@dont-email.me> |
| In reply to | #173891 |
On 04/09/2023 17:16, Ben Bacarisse wrote:
> Do you know that gcc (with no other flags or options) will report no
> syntax errors for this source code:
>
> PROGRAM HELLO
> WRITE (*,*) 'Hello world'
> END
>
> ? Is it only in "my world" that the plain gcc command is not a C
> compiler?
Your comments are misleading:
--------------------------------------
c:\c>type c.c
PROGRAM HELLO
WRITE (*,*) 'Hello world'
END
c:\c>gcc c.c
c.c:1:7: error: unknown type name 'PROGRAM'
1 | PROGRAM HELLO
| ^~~~~~~
c.c:2:7: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'WRITE'
2 | WRITE (*,*) 'Hello world'
| ^~~~~
c.c:2:19: warning: character constant too long for its type
2 | WRITE (*,*) 'Hello world'
| ^~~~~~~~~~~~~
c:\c>ren c.c c.ext
c:\c>gcc c.ext
C:\tdm\bin\ld.exe:c.ext: file format not recognized; treating as linker
script
C:\tdm\bin\ld.exe:c.ext:1: syntax error
collect2.exe: error: ld returned 1 exit status
c:\c>ren c.ext c.ftn
c:\c>gcc c.ftn
gcc: error: c.ftn: Fortran compiler not installed on this system
--------------------------------------
I didn't use the -x option as you said it would work without options.
But apparently it needs some input to tell it the language. That appears
to be the file extension.
That's clever, but so what? I can do that too:
c:\c>bcc c.ftn
Error: Fortran compiler not available
Stopping
I don't however want a Swiss army knife type of compiler that marshalls
each type of file into the appropriate tool. Isn't that more the OS's job?
Since people are always talking about wrappers around gcc to more
precisely pinpoint the task, why can't they write their own wrappers to
to this kind of dispatch too?
Of course, when /you/ have to, it's not so much fun is it?
I quite like the idea that I can do this:
mm prog compile .m
aa prog assemble .asm
bcc prog compile .c
mc prog transpile .m to C
ms prog Run .m
rather than:
gcc prog.m
gcc prog.asm
gcc prog.c
gcc prog.m -transpile
gcc prog.m -run
Because why not go further:
gcc prog.mp3
gcc prog.html
gcc makefile.mk
etc
You see my point? 'gcc' is too general.
My stuff is controlled by the names of the executables. You want to have
a minimal number of executables controlled by file extension (the famous
file extensions that in Linux are supposed to be optional!)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-05 01:33 +0100 |
| Message-ID | <87o7ihsbkf.fsf@bsb.me.uk> |
| In reply to | #173894 |
Bart <bc@freeuk.com> writes: > On 04/09/2023 17:16, Ben Bacarisse wrote: > >> Do you know that gcc (with no other flags or options) will report no >> syntax errors for this source code: >> PROGRAM HELLO >> WRITE (*,*) 'Hello world' >> END >> ? Is it only in "my world" that the plain gcc command is not a C >> compiler? > > Your comments are misleading: But none the less accurate. Annoying, isn't it? Shall we make a pact and both agree to make only clear and not at all misleading comments? You first. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-04 15:27 +0200 |
| Message-ID | <ud4m0v$1g6en$1@dont-email.me> |
| In reply to | #173875 |
On 04/09/2023 12:07, Malcolm McLean wrote: > On Monday, 4 September 2023 at 10:34:39 UTC+1, Bart wrote: >> >> So what exactly is a C compiler? What does it do? Don't bother answering. >> > A compiler takes a program written in one language and translates it into > another language. As the author of many languages yourself, you should know > that basic defintion. That's not what he is asking. You can't say what a "C compiler" is until you understand what "C" is. It is the language defined by the C standards. Technically, only the current standard (C17) defines C, as it replaces previous standards - but in practice it is reasonable to talk about a "C99 compiler", a "C17 compiler", etc., with a "C compiler" commonly regarded as meaning at least a C99 compiler, since the changes to the language after C99 were relatively small. (The upcoming C23 has big changes again.) So a "C compiler" is a compiler which will accept the language as defined by the standards, and issue diagnostics as required for syntax or constraint errors. It can issue other diagnostics, but should not fail to compile source that is valid according to the C standards. Other things useful for compiling C code, including a standard library, headers, OS/System headers, an assembler, a linker, utilities such as "make", editors, IDEs, debuggers, profilers, linters - these are not part of a C compiler, but may be packaged alongside for user convenience. It is usually fine to have a much looser meaning of "C compiler", as a tool for compiling a language roughly like C - perhaps with extra restrictions, perhaps with extra extensions, perhaps stricter or perhaps more lenient. But in this discussion, since Bart wants to know exactly what is allowed or not allowed in C and how a C compiler should behave, we have to use a strict definition of the language. There is nothing to suggest that a "C compiler" must be a single program, nor that it should be run using a simple command-line interface. I have used several dozen C compilers through the years - I don't know of any that were even reasonably strict and compliant C compilers without an appropriate selection of flags or options. >> >> Next I fully expect you will say that C isn't really a language. From >> what I've gleaned here, it isn't. It's a collection of suggestions and >> recommendations as to how an input file might be processed. >> > The problem is that if we extend C in a small way, for example to speed things > up a bit by making 32 bit pointers "near" pointers and 64-bit pointers "far" > pointers, the we've got what is technically a different language. Pointer > declarations which would be syntax errors in original C are now legal, whilst > a handful of legal C programs which use "far" or "near" as identifiers will > break. > But it isn't really a different language. It's just a slightly incompatible extension. If a compiler silently accepts "int * far p;", or "far int * p;", or whatever syntax you are suggesting, then it is not a C compiler in the context of this discussion, because a C compiler will at least issue a diagnostic here. Your hypothetical extended C compiler might be a more useful tool, and it would often be referred to as a "C compiler", but in this discussion branch, it is not. > > Because gcc is written by volunteers, it's far more fun to implement new features > than to write a compiler for a language where someone else has taken all the > decisions. So gcc has a lot of extensions. For the past two decades, the great majority of work on gcc has been done by professionals who have been paid for that work, by companies such as Intel, ARM, Red Hat, IBM, Google, and others. What you describe was more accurate in the 1980's and 1990's - and many of gcc's extensions have since been standardised. Since those days, the solid majority of gcc extensions have been within the reserved namespaces, such as __builtin* functions and __attribute__'s. There is, however, a tendency to allow new features of later C standards to be accepted by default even if those newer C standards are not picked. Since its early days, gcc has by default accepted a language that only approximately conforms to any of the C standards. If you want it to act as a C compiler, you need to give it the appropriate flags (specify the standard you want with "-std=c11", "-std=c17", etc., and either "-Wpedantic" or "-pedantic-errors"). >> >> There's so much gaslighting going on here that I'm almost starting to >> question my own ideas. When everyone else is saying something different than you, you /should/ be questioning your own ideas. >> >> /My/ idea of a compiler is a simple box, with a single Go button. You >> feed in a tape at one side representing source code and it writes a tape >> on the other with a runnable program. When it's finished a green light >> flashes. The output tape I can subsequently feed into a computer to execute. That's not how real-world compilers work - at least, not when the language must cover such a huge variety of usages as C. It's okay for a small or limited language with simple tools and a very restricted set of usages. And it might be acceptable for a byte-compiler that targets a single virtual machine. So yes, question your ideas.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-04 17:18 +0100 |
| Message-ID | <87wmx5ud22.fsf@bsb.me.uk> |
| In reply to | #173870 |
Bart <bc@freeuk.com> writes:
> On 04/09/2023 03:17, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 03/09/2023 15:31, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> Take this program:
>>>>>
>>>>> void fred(void){}; void bill(void)
>>>> This program has two syntax errors.
>>>
>>> Sorry, I found that when I tested the above but forgot to update the post.
>>>
>>>> The one you are talking about and
>>>> the missing ; or missing compound statement as the end of the line.
>>>>
>>>>> There's an extraneous ";" that the grammar says shouldn't be there, so it's
>>>>> a syntax error.
>>>>>
>>>>> Should a compiler fail it or not?
>>>> The standard says that it should be reported.
>>>
>>> And yet the first four compilers I tried don't do that.
>> Most programs that claim to be C compilers are not C compilers. For
>> example, nether the gcc nor clang command (run just like that) is a C
>> compiler.
>
> Ha ha ha!
>
> And here /you/ go around the same loop!
>
> Oh, you know the product that we've been hailing as the flagship C compiler
> for that few thousand posts, well it isn't really a C compiler anyway!
>
> So what exactly is a C compiler? What does it do? Don't bother
> answering.
OK.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-04 16:26 +0000 |
| Message-ID | <20230904092343.829@kylheku.com> |
| In reply to | #173870 |
On 2023-09-04, Bart <bc@freeuk.com> wrote: > On 04/09/2023 03:17, Ben Bacarisse wrote: >> Most programs that claim to be C compilers are not C compilers. For >> example, nether the gcc nor clang command (run just like that) is a C >> compiler. > > Ha ha ha! > > And here /you/ go around the same loop! gcc, when invoked on a .c file with no arguments, is a C compiler, for some version of GNU C. It is not an ISO C compiler. "C" does not mean "ISO C", unless the debate has been explicitly restricted that way. -- 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-04 19:33 +0100 |
| Message-ID | <87r0ndu6tf.fsf@bsb.me.uk> |
| In reply to | #173893 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: > On 2023-09-04, Bart <bc@freeuk.com> wrote: >> On 04/09/2023 03:17, Ben Bacarisse wrote: >>> Most programs that claim to be C compilers are not C compilers. For >>> example, nether the gcc nor clang command (run just like that) is a C >>> compiler. >> >> Ha ha ha! >> >> And here /you/ go around the same loop! > > gcc, when invoked on a .c file with no arguments, is a C compiler, > for some version of GNU C. It is not an ISO C compiler. > > "C" does not mean "ISO C", unless the debate has been explicitly > restricted that way. Note, though, that this is exactly what has happened in this thread. Bart's complaints about gcc's defaults are largely based on what "C" permits, says or requires and gcc's failure to allow, honour or insist on. For a long while I went along with the idea that "C" can mean many things, but that's not how Bart uses the term. In fact, that's one of his big whinging topics -- C is what you care to make it. So I changed my usage and posted the remark above. He found it worthy of mockery, but did not want me to respond. Go figure. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-04 19:17 +0000 |
| Message-ID | <20230904121509.86@kylheku.com> |
| In reply to | #173902 |
On 2023-09-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > For a long while I went along with the idea that "C" can mean many > things, but that's not how Bart uses the term. In fact, that's one of > his big whinging topics -- C is what you care to make it. So I changed > my usage and posted the remark above. He found it worthy of mockery, > but did not want me to respond. Go figure. C is a language family, like Lisp. Some people mean "Clojure" when they are sayhing Lisp, some mean "Racket" or "Emacs Lisp". Bart will just have to be patiently educated in the differences among: - language family - language dialect - language standard - language implementation - language reference manual -- 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-04 20:48 +0100 |
| Message-ID | <87fs3tu3cs.fsf@bsb.me.uk> |
| In reply to | #173903 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: > On 2023-09-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >> For a long while I went along with the idea that "C" can mean many >> things, but that's not how Bart uses the term. In fact, that's one of >> his big whinging topics -- C is what you care to make it. So I changed >> my usage and posted the remark above. He found it worthy of mockery, >> but did not want me to respond. Go figure. > > C is a language family, like Lisp. Some people mean "Clojure" > when they are sayhing Lisp, some mean "Racket" or "Emacs Lisp". Yes. > Bart will just have to be patiently educated in the differences among: > > - language family > - language dialect > - language standard > - language implementation > - language reference manual How's that going? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-04 21:25 +0100 |
| Message-ID | <ud5efg$1k757$1@dont-email.me> |
| In reply to | #173904 |
On 04/09/2023 20:48, Ben Bacarisse wrote: > Kaz Kylheku <864-117-4973@kylheku.com> writes: > >> On 2023-09-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >>> For a long while I went along with the idea that "C" can mean many >>> things, but that's not how Bart uses the term. In fact, that's one of >>> his big whinging topics -- C is what you care to make it. So I changed >>> my usage and posted the remark above. He found it worthy of mockery, >>> but did not want me to respond. Go figure. >> >> C is a language family, like Lisp. Some people mean "Clojure" >> when they are sayhing Lisp, some mean "Racket" or "Emacs Lisp". > > Yes. Examples of versions of the C family which have their own identities? I think it's clear we're not talking about distinct languages like Objective-C or C++. If you're going to include those, then you're clutching at straws.
[toc] | [prev] | [next] | [standalone]
Page 5 of 18 — ← Prev page 1 … 3 4 [5] 6 7 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web