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 15 of 18 — ← Prev page 1 … 13 14 [15] 16 17 18 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-07 15:16 -0700 |
| Message-ID | <87tts51ve5.fsf@nosuchdomain.example.com> |
| In reply to | #174333 |
Bart <bc@freeuk.com> writes:
[...]
> Yes, in main(), it ensures the return value is 0, instead of being
> undefined. But it's not bothered about that for fred(), although it
> could have done the same.
>
> Why the special dispensation for main(), and not for user functions?
> And don't say because the Standard stipulates; it could have
> stipulated for user functions too!
The rule is that "reaching the } that terminates the main function
returns a value of 0". This applies only if main is defined with a
return type of int (an implementation may permit other return types).
It applies only to hosted implementations. This was introduced in
C99, borrowed from C++; in C90, falling off the end of main would
return an undefined result.
I was never happy about this rule. It's an unnecessary special case.
But it doesn't break any existing code, and gives meaning to some code
that previously returned an undefined result -- a meaning that is very
probably what was intended. For example, the "hello, world" program in
K&R2 has no return statement. I accept the rule and sometimes take
advantage of it (since I don't worry about pre-C99 compilers).
The reasons for *not* doing this for functions other than main seem
fairly obvious to me. The main() function is unique. A return value
of 0 from main has a language-defined meaning: it indicates that the
program terminated successfully. No other user-defined function has
a language-defined meaning for any returned value. Semantically,
the main() function almost always does things that have side effects.
Other functions are more commonly called primarily for their return
values, and letting the language assign an arbitrary default return
value that may or may not have a meaning would be a bad idea.
Finally, this function:
int absolute_value(int n) {
if (n < 0) return -n;
}
has a bug. A compiler is not required to diagnose it but many (most?)
compilers will warn about it with the right options. If reaching the
closing } implicitly returned 0, a compiler would have no basis to warn
about a missing return value.
--
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-07 23:48 +0100 |
| Message-ID | <uddjvd$358rc$1@dont-email.me> |
| In reply to | #174432 |
On 07/09/2023 23:16, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> Finally, this function:
>
> int absolute_value(int n) {
> if (n < 0) return -n;
> }
>
> has a bug. A compiler is not required to diagnose it but many (most?)
> compilers will warn about it with the right options. If reaching the
> closing } implicitly returned 0, a compiler would have no basis to warn
> about a missing return value.
>
I said: "It needn't affect how such things need to be reported."
Implicitly returning 0 doesn't affect diagnostics.
But if people choose to ignore warnings, or choose not to see warnings,
then if the function runs into }, it will consistently return 0.
In this example, that happens to be the wrong result for most positive
values of n, and the bug is obvious. By not returning zero, it is quite
likely it will return the correct result: the value of a positive n
which happens to be loaded into the register used to return a value.
You will not suspect a bug. But on another machine/compiler/set of
options (where maybe n is tested in memory, or resides in a different
register), it will go wrong.
So returning zero makes the bug more obvious in this case.
As it happens, if I run this program:
#include <stdio.h>
int absolute_value(int n) {
if (n<0) return -n;
}
int main(void) {
printf("%d\n", absolute_value(123));
}
Both bcc-old and tcc show '123'. But 'gcc -std=c11 -Wpedantic', which
reports no diagnostic, shows -1887184072. With -O1/2/3, it shows 0.
gcc-O0 on rextester.com with showed -2019228064. Clang-O2 there showed
-123, and Clang-O0 was 0.
bcc without -old gives a hard error.
Which would be better: some random choice of one of these values when n>=0:
123 # the right answer!
-1887184072
0
-2019228064
-123
or consistently this:
0
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-07 17:16 -0700 |
| Message-ID | <878r9h1ptw.fsf@nosuchdomain.example.com> |
| In reply to | #174438 |
Bart <bc@freeuk.com> writes:
> On 07/09/2023 23:16, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>
>> Finally, this function:
>> int absolute_value(int n) {
>> if (n < 0) return -n;
>> }
>> has a bug. A compiler is not required to diagnose it but many
>> (most?)
>> compilers will warn about it with the right options. If reaching the
>> closing } implicitly returned 0, a compiler would have no basis to warn
>> about a missing return value.
>
> I said: "It needn't affect how such things need to be reported."
>
> Implicitly returning 0 doesn't affect diagnostics.
It should.
Suppose C29 adds a rule that reaching the closing } of an int function
does an implicit `return 0;`. (I'm restricting it to int for now just
for simplicity; presumably it would apply to all non-void functions.)
Then this:
int sign(int n) {
if (n < 0) return -1;
if (n > 0) return +1;
}
is a perfectly valid C29 implementation of a sign() function.
It correctly returns -1 for a negatve argument, +1 for a positive
argument, and 0 for a zero argument.
Are you suggesting that a C29 compiler would still be required
to issue a warning? If not, are you suggesting that a "good"
C compiler *should* issue a warning? For code that conforms to
the C29 standard, with completely defined behavior?
C already says that reaching the end of main implicitly returns 0.
Should a compiler warn about a program that takes advantage of that?
Should a conforming compiler be *required* to do so?
The C standard does not require non-fatal warnings (except for a
#warning directive, new in C23). A conforming compiler can treat
every violation of a syntax rule or constraint as a fatal error,
and not issue any other diagnostics.
> But if people choose to ignore warnings, or choose not to see
> warnings, then if the function runs into }, it will consistently
> return 0.
>
> In this example, that happens to be the wrong result for most positive
> values of n, and the bug is obvious. By not returning zero, it is
> quite likely it will return the correct result: the value of a
> positive n which happens to be loaded into the register used to return
> a value.
>
> You will not suspect a bug. But on another machine/compiler/set of
> options (where maybe n is tested in memory, or resides in a different
> register), it will go wrong.
>
> So returning zero makes the bug more obvious in this case.
Returning zero hides the bug if zero is a likely correct result.
Suppose a function returns zero on success, non-zero on failure (a
common convention in some contexts). Implicitly returning zero will
hide bugs.
> As it happens, if I run this program:
[snip]
> Which would be better: some random choice of one of these values when n>=0:
>
> 123 # the right answer!
> -1887184072
> 0
> -2019228064
> -123
>
> or consistently this:
>
> 0
Arbitrary and varying results give you a better chance of diagnosing the
error. Some compilers, in debug mode, set uninitialized memory to some
recognizable pattern that's unlikely to be valid; your proposed rule
would make that illegal.
Diagnosing the failure to return a value at compile time is ideal. It's
not possible to diagnose it perfectly, but many compilers can be made to
do a decent job. "gcc -Wall" warns "control reaches end of non-void
function" for your sample program (which I snipped in this followup).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-08 11:16 +0200 |
| Message-ID | <udeoos$3dal1$1@dont-email.me> |
| In reply to | #174333 |
On 07/09/2023 16:55, Bart wrote:
> On 07/09/2023 15:28, Ben Bacarisse wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>>> Do you have in mind examples of situations in which false positives
>>> would cause problems, or even just irk the programmer?
>>
>> Well I'd be irked by having to write a 'return 0;' there just to shut
>> the compiler up. But, to be clear, it's a tiny irk.
>
> Having to do so at the end of main() must have irked enough people that
> most C compilers allow it to be left out.
>
> But, in the case of main, they also do something special; for this program:
>
> int fred(void) {}
> int main(void) {}
>
<snip>
>
> Yes, in main(), it ensures the return value is 0, instead of being
> undefined. But it's not bothered about that for fred(), although it
> could have done the same.
>
> Why the special dispensation for main(), and not for user functions? And
> don't say because the Standard stipulates; it could have stipulated for
> user functions too!
>
It doesn't matter what the standard /could/ have stipulated - it only
matters what it /does/ stipulate.
But the answer, as is usually the case for such oddities in C, is "for
historical reasons".
(In many systems, the C language and C compiler has very little control
about how "main" is called, and what happens when "main" returns. This
is different from all other user functions.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-08 10:51 +0100 |
| Message-ID | <udeqqq$3dhqr$2@dont-email.me> |
| In reply to | #174507 |
On 08/09/2023 10:16, David Brown wrote:
> On 07/09/2023 16:55, Bart wrote:
>> On 07/09/2023 15:28, Ben Bacarisse wrote:
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>>> Do you have in mind examples of situations in which false positives
>>>> would cause problems, or even just irk the programmer?
>>>
>>> Well I'd be irked by having to write a 'return 0;' there just to shut
>>> the compiler up. But, to be clear, it's a tiny irk.
>>
>> Having to do so at the end of main() must have irked enough people
>> that most C compilers allow it to be left out.
>>
>> But, in the case of main, they also do something special; for this
>> program:
>>
>> int fred(void) {}
>> int main(void) {}
>>
> <snip>
>>
>> Yes, in main(), it ensures the return value is 0, instead of being
>> undefined. But it's not bothered about that for fred(), although it
>> could have done the same.
>>
>> Why the special dispensation for main(), and not for user functions?
>> And don't say because the Standard stipulates; it could have
>> stipulated for user functions too!
>>
>
> It doesn't matter what the standard /could/ have stipulated - it only
> matters what it /does/ stipulate.
>
> But the answer, as is usually the case for such oddities in C, is "for
> historical reasons".
>
> (In many systems, the C language and C compiler has very little control
> about how "main" is called, and what happens when "main" returns. This
> is different from all other user functions.)
The internal details don't matter to the user. The way main() is defined
and used should be identical to any other function.
Actually, on Windows, the existence of a function like this is an illusion:
int main(int n, char** args) {}
The entry point to a program in any language doesn't provide those two
(or sometimes three) arguments already set up, as it probably does on Linux.
It has to be emulated.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-08 13:00 +0200 |
| Message-ID | <udeuru$3eac2$1@dont-email.me> |
| In reply to | #174519 |
On 08/09/2023 11:51, Bart wrote:
> On 08/09/2023 10:16, David Brown wrote:
>> On 07/09/2023 16:55, Bart wrote:
>>> On 07/09/2023 15:28, Ben Bacarisse wrote:
>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>
>>>>> Do you have in mind examples of situations in which false positives
>>>>> would cause problems, or even just irk the programmer?
>>>>
>>>> Well I'd be irked by having to write a 'return 0;' there just to shut
>>>> the compiler up. But, to be clear, it's a tiny irk.
>>>
>>> Having to do so at the end of main() must have irked enough people
>>> that most C compilers allow it to be left out.
>>>
>>> But, in the case of main, they also do something special; for this
>>> program:
>>>
>>> int fred(void) {}
>>> int main(void) {}
>>>
>> <snip>
>>>
>>> Yes, in main(), it ensures the return value is 0, instead of being
>>> undefined. But it's not bothered about that for fred(), although it
>>> could have done the same.
>>>
>>> Why the special dispensation for main(), and not for user functions?
>>> And don't say because the Standard stipulates; it could have
>>> stipulated for user functions too!
>>>
>>
>> It doesn't matter what the standard /could/ have stipulated - it only
>> matters what it /does/ stipulate.
>>
>> But the answer, as is usually the case for such oddities in C, is "for
>> historical reasons".
>>
>> (In many systems, the C language and C compiler has very little
>> control about how "main" is called, and what happens when "main"
>> returns. This is different from all other user functions.)
>
> The internal details don't matter to the user. The way main() is defined
> and used should be identical to any other function.
I too would prefer consistency here - I see no reason why falling off
the end of main() should act as "return 0;", except to standardise
existing old practice.
However, the way main() is defined and used is /not/ identical to other
functions - it is special in some ways, because it is the starting point
for a C program, and leaving the initial call to the function is the end
of the program. The ways you can declare it is also pre-determined,
unlike for any other user function. The effect of exiting main() is
different for the initial call, and any recursive calls. All in all,
main() is not a normal function - having it implicitly return 0 is just
one small part of that.
<https://en.cppreference.com/w/c/language/main_function>
(For fun, click the link at the bottom to look at main() in C++. It has
even more restrictions.)
>
> Actually, on Windows, the existence of a function like this is an illusion:
>
> int main(int n, char** args) {}
>
> The entry point to a program in any language doesn't provide those two
> (or sometimes three) arguments already set up, as it probably does on
> Linux.
>
> It has to be emulated.
>
I would think this depends on the C runtime library, which is part of
the C implementation. Hosted environments are required to provide the
"program parameters" in argc and argv - that is mandated by the
standard. However, it is entirely up to the environment to say what the
"program parameters" are. And a Windows C implementation could choose
to say there are never any parameters - "argc" is always 0, while "argv"
is a pointer such that "argv[argc]" is a null pointer. That's
sufficient to fulfil the requirements. There is no C standard rule
saying that it has to be command-line parameters.
(For freestanding implementations - such as bare-metal embedded systems,
you don't even have to have a "main()" function. Sometimes another name
is used for the main function, or there is support for functions run
before main() starts. And in most embedded systems, argc will be 0 and
argv will have a single null pointer entry, though you usually just use
"int main(void)".)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-08 13:05 +0100 |
| Message-ID | <udf2mq$3esn8$1@dont-email.me> |
| In reply to | #174543 |
On 08/09/2023 12:00, David Brown wrote:
> On 08/09/2023 11:51, Bart wrote:
>> Actually, on Windows, the existence of a function like this is an
>> illusion:
>>
>> int main(int n, char** args) {}
>>
>> The entry point to a program in any language doesn't provide those two
>> (or sometimes three) arguments already set up, as it probably does on
>> Linux.
>>
>> It has to be emulated.
>>
>
> I would think this depends on the C runtime library, which is part of
> the C implementation. Hosted environments are required to provide the
> "program parameters" in argc and argv - that is mandated by the
> standard.
The Windows hosted environment knows nothing at all about argc and argv,
and provides no such parameters.
At the entry point to an EXE programs, only a stack has been set up, and
the stack contains the return address. (However I never use that; my
main() functions in either language end in a call to exit().)
The C parameters argc and argv can be obtained with calling
__getmainargs() from msvcrt.dll. Or can be manually parsed by called the
WinAPI function GetCommandLine().
However, it is entirely up to the environment to say what the
> "program parameters" are. And a Windows C implementation could choose
> to say there are never any parameters - "argc" is always 0, while "argv"
> is a pointer such that "argv[argc]" is a null pointer. That's
> sufficient to fulfil the requirements. There is no C standard rule
> saying that it has to be command-line parameters.
As I said, those don't exist at all. They are just a C artefact. In
Linux, where there isn't really a clear demarcation between OS, and the
C language, headers, compilers and runtime, I expect the OS will provide
those arguments to the entry point of a program in any language.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-08 16:11 +0200 |
| Message-ID | <udfa2u$3fta8$2@dont-email.me> |
| In reply to | #174562 |
On 08/09/2023 14:05, Bart wrote:
> On 08/09/2023 12:00, David Brown wrote:
>> On 08/09/2023 11:51, Bart wrote:
>
>>> Actually, on Windows, the existence of a function like this is an
>>> illusion:
>>>
>>> int main(int n, char** args) {}
>>>
>>> The entry point to a program in any language doesn't provide those
>>> two (or sometimes three) arguments already set up, as it probably
>>> does on Linux.
>>>
>>> It has to be emulated.
>>>
>>
>> I would think this depends on the C runtime library, which is part of
>> the C implementation. Hosted environments are required to provide the
>> "program parameters" in argc and argv - that is mandated by the standard.
>
> The Windows hosted environment knows nothing at all about argc and argv,
> and provides no such parameters.
If it is a C compiler, then it /must/ do so. It can, as I said, fix
argc at 0 and argv as a pointer to a null pointer. But it must provide
at least these if it is a C compiler.
It can allow other implementation-defined options as well.
>
> At the entry point to an EXE programs, only a stack has been set up, and
> the stack contains the return address. (However I never use that; my
> main() functions in either language end in a call to exit().)
>
> The C parameters argc and argv can be obtained with calling
> __getmainargs() from msvcrt.dll. Or can be manually parsed by called the
> WinAPI function GetCommandLine().
>
It's allowable to provide such functions as a way to get the actual
program parameters. It's a stupid design contrary to common behaviour
and expectations, but it is allowed. (Providing extra functions to get
the parameters in different ways - different character encodings,
different wildcard treatment, etc., is absolutely fine.)
> However, it is entirely up to the environment to say what the
>> "program parameters" are. And a Windows C implementation could choose
>> to say there are never any parameters - "argc" is always 0, while
>> "argv" is a pointer such that "argv[argc]" is a null pointer. That's
>> sufficient to fulfil the requirements. There is no C standard rule
>> saying that it has to be command-line parameters.
>
> As I said, those don't exist at all. They are just a C artefact.
We are talking about C. Call this a "C artefact" if you like, though I
don't really know what you mean (many other languages have a similar
system). A hosted C implementation has to support "main" as described
in the standard.
> In
> Linux, where there isn't really a clear demarcation between OS, and the
> C language, headers, compilers and runtime, I expect the OS will provide
> those arguments to the entry point of a program in any language.
>
Of course there are very clear distinctions here - except in your own
misunderstandings.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-09 00:56 +0000 |
| Message-ID | <20230908174838.664@kylheku.com> |
| In reply to | #174562 |
On 2023-09-08, Bart <bc@freeuk.com> wrote: > The Windows hosted environment knows nothing at all about argc and argv, > and provides no such parameters. Using Microsoft's tools, Windows programs can be compiled without an ISO C main, using a winMain function instead. That makes the C implementation "freestanding" to some extent. ISO C say that programs in a "conforming hosted" implementation start with a main function. In a freestanding implementation, the startup function is implementation-defined. Freestanding implementations can implement any subset of the Library. For instance in spite of main not being the startup function, all of <stdio.h> can work fine. > > At the entry point to an EXE programs, only a stack has been set up, and > the stack contains the return address. (However I never use that; my > main() functions in either language end in a call to exit().) > > The C parameters argc and argv can be obtained with calling > __getmainargs() from msvcrt.dll. Or can be manually parsed by called the > WinAPI function GetCommandLine(). > > However, it is entirely up to the environment to say what the >> "program parameters" are. And a Windows C implementation could choose >> to say there are never any parameters - "argc" is always 0, while "argv" >> is a pointer such that "argv[argc]" is a null pointer. That's >> sufficient to fulfil the requirements. There is no C standard rule >> saying that it has to be command-line parameters. > > As I said, those don't exist at all. They are just a C artefact. In > Linux, where there isn't really a clear demarcation between OS, and the > C language, headers, compilers and runtime, I expect the OS will provide > those arguments to the entry point of a program in any language. It does, but that entry point isn't simply main. In Linux, dynamically linked programs compiled with glibc are ELF executables, which are "run" by the "interpreter" indicated in their header. Just like a script file indicates an interpreter like #!/bin/sh or #!/usr/bin/python3, an ELF executable has a header in which a field indicates the interpreter like /lib/ld-linux.so.2. The kernel maps that program into memory and passes it the executable as an argument (or perhaps an open descriptor?) ld-linux.so.2 attaches the shared libraries which that program needs, and performs their initialization. Only then is the entry point in the executable invoked. That entry point isn't main(), but some _start function or whatever. I think it's not found by symbol but by a hard numeric offset field in the program header. That offset is just jumped to basically. Something like that. By the time main() is called, stuff has happened. In C++ you can have objects at file scope which can have constructors; those will be called before main does, and they can rely on the library having been initialized. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-09 00:47 +0000 |
| Message-ID | <20230908075118.577@kylheku.com> |
| In reply to | #174543 |
On 2023-09-08, David Brown <david.brown@hesbynett.no> wrote: > On 08/09/2023 11:51, Bart wrote: >> The internal details don't matter to the user. The way main() is defined >> and used should be identical to any other function. > > I too would prefer consistency here - I see no reason why falling off > the end of main() should act as "return 0;", except to standardise > existing old practice. I don't believe there was an old practice. The practice was one of hordes of programmers being ignorant of the concept of a termination status. This was done in C because C++ did it. C++ did it probably because they thought it's one more way to improve the C subset of C++ to make a better C. By adopting such a rule at the language level, you can fix countless broken programs that return a pseudo-random termination status; they just have to be recompiled with an implementation that has picked up the rule. I think that if C and C++ hadn't adopted this rule, we would still have many programs out there returning garbage termination status. Still, it's strange because C and C++ languages are not normally of the kind that try to save the end user from programmer ignorance. In the big picture, in which so many things can go wrong in developing a complex application, fixing the broken return of main is a like fart in a hurricane. --- main is not such a different function in C. It can be a perfectly ordinary function. What is special about it is that it can have one of two standard type signatures. However, that can be handled transparently in many implementations, because it is commonly de facto safe to pass more arguments to a function than it takes. The ISO C <stdarg.h> feature came from something called <varargs.h> which was entirely predicated on passing a variable number of arguements to a function, prior to the existence of prototype declarations and the ... ellipsis. SowWhen it comes to C, main can be just an external function which is linked to by the "CRT" module by name, and that module can assume that it is int main(int, char **). (Except on implementations which have calling conventions whereby the callee cleans up the stack and such.) It is rather in C++ that main is more special. C++ has type safe linkage, and so int main(void) looks different from int main(int, char **). In actual implementations, this is done by encoding the type into the symbol name, which is informally called "name mangling". C++ implementations likely disable name mangling for main so that it is more easy to link to. In C++, main is not required to be recursively invokable; and it is probably for that reason. The definition of main is also a declaration. But since main is specially handled, that declaration may not actually be suitable for calling it. That is to say, if the C++ program calls main, that might generate a reference to the mangled name which doesn't actually exists. Perhaps since C++ main is already special, it was an easier decision in C++ to put in the rule regarding the implicit return. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-09 18:49 +0200 |
| Message-ID | <udi7md$52sl$2@dont-email.me> |
| In reply to | #174656 |
On 09/09/2023 02:47, Kaz Kylheku wrote: > On 2023-09-08, David Brown <david.brown@hesbynett.no> wrote: >> On 08/09/2023 11:51, Bart wrote: >>> The internal details don't matter to the user. The way main() is defined >>> and used should be identical to any other function. >> >> I too would prefer consistency here - I see no reason why falling off >> the end of main() should act as "return 0;", except to standardise >> existing old practice. > > I don't believe there was an old practice. > > The practice was one of hordes of programmers being ignorant of the > concept of a termination status. > OK - so it was standardising practice by new, ignorant programmers. That sounds entirely plausible to me. > This was done in C because C++ did it. I know C++ standardised it first. > > C++ did it probably because they thought it's one more way to improve > the C subset of C++ to make a better C. > > By adopting such a rule at the language level, you can fix countless > broken programs that return a pseudo-random termination status; > they just have to be recompiled with an implementation that has picked > up the rule. > Fair enough. > I think that if C and C++ hadn't adopted this rule, we would still have > many programs out there returning garbage termination status. > > Still, it's strange because C and C++ languages are not normally of the > kind that try to save the end user from programmer ignorance. In the > big picture, in which so many things can go wrong in developing a > complex application, fixing the broken return of main is a like fart in > a hurricane. > > --- > > main is not such a different function in C. It can be a perfectly > ordinary function. What is special about it is that it can have one > of two standard type signatures. There are a few other differences, though main() in C is not as special as main() in C++. > > However, that can be handled transparently in many implementations, > because it is commonly de facto safe to pass more arguments to a > function than it takes. Yes. > > The ISO C <stdarg.h> feature came from something called <varargs.h> > which was entirely predicated on passing a variable number of > arguements to a function, prior to the existence of prototype > declarations and the ... ellipsis. > > SowWhen it comes to C, main can be just an external function which is > linked to by the "CRT" module by name, and that module can assume that > it is int main(int, char **). (Except on implementations which have > calling conventions whereby the callee cleans up the stack and such.) > > It is rather in C++ that main is more special. C++ has type safe > linkage, and so int main(void) looks different from int main(int, char > **). In actual implementations, this is done by encoding the type into > the symbol name, which is informally called "name mangling". > > C++ implementations likely disable name mangling for main so > that it is more easy to link to. Indeed they do. In effect, "main" is declared as though it were an extern "C" function, so that it is accessible from the C++ startup code. (But you are not allowed to declare it yourself in any way.) > > In C++, main is not required to be recursively invokable; You are not allowed to call it at all, or even take its address - so no recursion is allowed. > and it is > probably for that reason. The definition of main is also a declaration. > But since main is specially handled, that declaration may not actually > be suitable for calling it. That is to say, if the C++ program calls > main, that might generate a reference to the mangled name which doesn't > actually exists. > Some C++ compilers call global constructors and static initialisation functions from library code before main() is started. Others inject that code into the generation of the main() function, as though it appeared immediately after the opening braces of main(). That would not be an option if main() could be called recursively. (Global destructors can similarly be injected into the end of main()). > Perhaps since C++ main is already special, it was an easier decision > in C++ to put in the rule regarding the implicit return. > Certainly it made some things easier, and it definitely made the choice of default return value easy to pick!
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-09-09 10:27 -0700 |
| Message-ID | <NV1LM.206233$KJXf.118553@fx05.iad> |
| In reply to | #174731 |
On 9/9/23 9:49 AM, David Brown wrote: > Some C++ compilers call global constructors and static initialisation > functions from library code before main() is started. Others inject > that code into the generation of the main() function, as though it > appeared immediately after the opening braces of main(). That would not > be an option if main() could be called recursively. (Global destructors > can similarly be injected into the end of main()). This was how it HAD to be done in CFront, that took C++ code and generated C code from it, to be given to the C compiler to be compiled and run. CFront couldn't (portably) change the pre-main behavior, so injected it in the front of main.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-10 12:06 +0200 |
| Message-ID | <udk4eb$hkp5$2@dont-email.me> |
| In reply to | #174738 |
On 09/09/2023 19:27, Richard Damon wrote: > On 9/9/23 9:49 AM, David Brown wrote: >> Some C++ compilers call global constructors and static initialisation >> functions from library code before main() is started. Others inject >> that code into the generation of the main() function, as though it >> appeared immediately after the opening braces of main(). That would >> not be an option if main() could be called recursively. (Global >> destructors can similarly be injected into the end of main()). > > This was how it HAD to be done in CFront, that took C++ code and > generated C code from it, to be given to the C compiler to be compiled > and run. > > CFront couldn't (portably) change the pre-main behavior, so injected it > in the front of main. Sounds reasonable. I have seen it done in other C++ compilers that did not use CFront, though I can't remember off-hand which compiler it was (it was some microcontroller compiler).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-08 05:03 -0700 |
| Message-ID | <87ledgna6o.fsf@nosuchdomain.example.com> |
| In reply to | #174519 |
Bart <bc@freeuk.com> writes:
[...]
> Actually, on Windows, the existence of a function like this is an illusion:
>
> int main(int n, char** args) {}
>
> The entry point to a program in any language doesn't provide those two
> (or sometimes three) arguments already set up, as it probably does on
> Linux.
>
> It has to be emulated.
We're talking about software. It's *all* an illusion.
--
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-08 13:39 +0100 |
| Message-ID | <udf4mo$3f62i$1@dont-email.me> |
| In reply to | #174561 |
On 08/09/2023 13:03, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> Actually, on Windows, the existence of a function like this is an illusion:
>>
>> int main(int n, char** args) {}
>>
>> The entry point to a program in any language doesn't provide those two
>> (or sometimes three) arguments already set up, as it probably does on
>> Linux.
>>
>> It has to be emulated.
>
> We're talking about software. It's *all* an illusion.
>
Huh?
My point is that on Linux, the arguments are set up, ready to use, on
the actual entry point to your program.
On Windows, they're not.
If you're an implementer, then on Windows you have to make arrangements
so that it looks like the OS does indeed provide those arguments.
It might involve adding extra calls inside a main() which is compiled
with no parameters, or renaming the user's main to '$main', say, and
using a new main(void) which calls $main(n, args).
You might think this is a small matter, since /somebody/ has to write
code to obtain that information, and you don't care if it is somebody
implementing the C language, or implementing the OS leader.
*I* care because it's my responsibility to do it.
I am also somewhat annoyed when people assume that every OS gives the C
language, among all others, special dispensation in kindly providing C's
argc and argv to all programs, regardless of what language they happen
to be written in.
That only happens on Linux and related OSes.
[toc] | [prev] | [next] | [standalone]
| From | candycanearter07 <no@thanks.net> |
|---|---|
| Date | 2023-09-08 07:49 -0500 |
| Message-ID | <udf58l$3f19e$2@dont-email.me> |
| In reply to | #174568 |
On 9/8/23 07:39, Bart wrote:
> On 08/09/2023 13:03, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> Actually, on Windows, the existence of a function like this is an
>>> illusion:
>>>
>>> int main(int n, char** args) {}
>>>
>>> The entry point to a program in any language doesn't provide those two
>>> (or sometimes three) arguments already set up, as it probably does on
>>> Linux.
>>>
>>> It has to be emulated.
>>
>> We're talking about software. It's *all* an illusion.
>>
>
> Huh?
>
> My point is that on Linux, the arguments are set up, ready to use, on
> the actual entry point to your program.
>
> On Windows, they're not.
>
> If you're an implementer, then on Windows you have to make arrangements
> so that it looks like the OS does indeed provide those arguments.
>
> It might involve adding extra calls inside a main() which is compiled
> with no parameters, or renaming the user's main to '$main', say, and
> using a new main(void) which calls $main(n, args).
>
> You might think this is a small matter, since /somebody/ has to write
> code to obtain that information, and you don't care if it is somebody
> implementing the C language, or implementing the OS leader.
>
> *I* care because it's my responsibility to do it.
>
> I am also somewhat annoyed when people assume that every OS gives the C
> language, among all others, special dispensation in kindly providing C's
> argc and argv to all programs, regardless of what language they happen
> to be written in.
>
> That only happens on Linux and related OSes.
>
The magic of standards is that you don't need to worry about the
underlying os messiness. With that said, I didn't know about the
arguments issue, that's neat.
--
--
user <candycane> is generated from /dev/urandom
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-09 01:07 +0000 |
| Message-ID | <20230908180434.597@kylheku.com> |
| In reply to | #174570 |
On 2023-09-08, candycanearter07 <no@thanks.net> wrote: > The magic of standards is that you don't need to worry about the > underlying os messiness. With that said, I didn't know about the > arguments issue, that's neat. Congratulation on your correct attribution and quoting via T-bird. That's pretty much a Usenet first. In my memory, nobody who has ever been told about things like this in any newsgroup I've ever read has ever done anything to alter their behavior or software configuration. From QWK packet processing to T-bird is a bit of a jump there. You would probably rather enjoy text-mode clients like strn, tin, slrn, ... maybe Emacs' Gnus? -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-09 18:51 +0200 |
| Message-ID | <udi7qa$52sl$3@dont-email.me> |
| In reply to | #174660 |
On 09/09/2023 03:07, Kaz Kylheku wrote: > On 2023-09-08, candycanearter07 <no@thanks.net> wrote: >> The magic of standards is that you don't need to worry about the >> underlying os messiness. With that said, I didn't know about the >> arguments issue, that's neat. > > Congratulation on your correct attribution and quoting via T-bird. > > That's pretty much a Usenet first. In my memory, nobody who has ever > been told about things like this in any newsgroup I've ever read has > ever done anything to alter their behavior or software configuration. > It's not a first - but it is definitely rare, and is, I think, the speediest case I have seen. Welcome to the group, Candy!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-08 16:35 +0200 |
| Message-ID | <udfbfu$3g6s5$1@dont-email.me> |
| In reply to | #174568 |
On 08/09/2023 14:39, Bart wrote:
> On 08/09/2023 13:03, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> Actually, on Windows, the existence of a function like this is an
>>> illusion:
>>>
>>> int main(int n, char** args) {}
>>>
>>> The entry point to a program in any language doesn't provide those two
>>> (or sometimes three) arguments already set up, as it probably does on
>>> Linux.
>>>
>>> It has to be emulated.
>>
>> We're talking about software. It's *all* an illusion.
>>
>
> Huh?
>
> My point is that on Linux, the arguments are set up, ready to use, on
> the actual entry point to your program.
>
> On Windows, they're not.
>
> If you're an implementer, then on Windows you have to make arrangements
> so that it looks like the OS does indeed provide those arguments.
>
Then that is your responsibility. As the C implementer, you have to
implement C - based on whatever facilities provided by the target OS.
Surely that is an obvious tautology?
> It might involve adding extra calls inside a main() which is compiled
> with no parameters, or renaming the user's main to '$main', say, and
> using a new main(void) which calls $main(n, args).
>
> You might think this is a small matter, since /somebody/ has to write
> code to obtain that information, and you don't care if it is somebody
> implementing the C language, or implementing the OS leader.
>
> *I* care because it's my responsibility to do it.
Exactly - it is /your/ responsibility. Don't shirk it.
You can complain to the twats that wrote the OS that you use, if you
like. Or you can put the calls to "get_commandline_args" (or whatever
it is) in your C runtime startup code that runs before calling main().
That's what other implementers do.
You can lookup the startup code for glibc or newlib on Linux, and you'll
see that although these parameters are on the stack when the code jumps
to "_start", they must be taken off the stack and arranged correctly
according to the C ABI before calling main().
Writing a Windows C startup might be more difficult - call the
"get_commandline_args" functions, transform them into standard formats,
and pass the results on to main. You know how to do all that.
Or be lazy (and still compliant), and do :
void _start(void) {
char * argv[] = { 0 };
exit(main(0, argv));
}
>
> I am also somewhat annoyed when people assume that every OS gives the C
> language, among all others, special dispensation in kindly providing C's
> argc and argv to all programs, regardless of what language they happen
> to be written in.
You are only annoyed because you misunderstand the situation.
It does not matter what the OS does, or how C-friendly it might be. The
job of a C implementer is to make a C implementation, for C code. Their
job in the C startup code is to take whatever the OS gives them, and
turn it into a standards-compliant call to main(). It's no different
from implementing Pascal, Rust, Ada, or any other standardised language.
People writing Ada implementations have to make sure the program
parameters are available via the Ada.Commmand_Line module, using
whatever mechanism the OS provides for getting that. They do this
without complaining that the OS is not Ada-friendly.
>
> That only happens on Linux and related OSes.
>
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-09 01:04 +0000 |
| Message-ID | <20230908175615.579@kylheku.com> |
| In reply to | #174568 |
On 2023-09-08, Bart <bc@freeuk.com> wrote:
> On 08/09/2023 13:03, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> Actually, on Windows, the existence of a function like this is an illusion:
>>>
>>> int main(int n, char** args) {}
>>>
>>> The entry point to a program in any language doesn't provide those two
>>> (or sometimes three) arguments already set up, as it probably does on
>>> Linux.
>>>
>>> It has to be emulated.
>>
>> We're talking about software. It's *all* an illusion.
>>
>
> Huh?
>
> My point is that on Linux, the arguments are set up, ready to use, on
> the actual entry point to your program.
In Linux, the arguments are real at the OS level in that they are
individual strings, and are passed from the parent process that way.
In Windows, there is only single command argument string.
Language implementations which support command arguments must provide
the run-time code to parse them out from a single string.
There is more than one way to do that, which can lead to
misunderstandings between programs.
Microsoft describes an algorithm in MSDN. That algorithm is the one used
for the main() function in Microsoft Visual C programs (that are built
with a main; i.e. console applications).
It behooves implementors of command line parsing (or synthesis!) on
Windows to follow that same algorithm/encoding.
There is no hard rule which means that having a main function implies
console application, whereas winMain is a GUI application.
There is a bit in the program header which indicates whether a console
window is created for a program. That's the important thing.
It can be toggled after a program is built.
My TXR langauge for Windows installs two executables: txr.exe and
txr-win.exe. They are the same and both internally have a main(int,
char **). The second one doesn't have a console window come up.
With either of them you can call Win32 APIs to create windows,
with a WndProc callback function to handle events and all that.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
Page 15 of 18 — ← Prev page 1 … 13 14 [15] 16 17 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web