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 14 of 18 — ← Prev page 1 … 12 13 [14] 15 16 … 18 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-07 14:51 -0700 |
| Message-ID | <87y1hh1wjq.fsf@nosuchdomain.example.com> |
| In reply to | #174360 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> David Brown <david.brown@hesbynett.no> writes:
>> With C11, you can write :
>>
>> _Noreturn void abort_with_error_message(const char *);
>>
>> So you don't have to wait until C23 (unless you really want the attribute
>> syntax).
>
> I somehow missed that in C11. Thanks.
C11 added the _Noreturn keyword and the <stdnoreturn.h> header, which
defines a macro `noreturn` that expands to `_Noreturn`.
C23 makes all that obsolescent, and introduces attributes, including
[[noreturn]].
--
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 | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-08 00:46 -0700 |
| Message-ID | <29b9dd04-cb79-4195-b2ee-0a91287c19c5n@googlegroups.com> |
| In reply to | #174430 |
On Thursday, 7 September 2023 at 22:52:07 UTC+1, Keith Thompson wrote: > Ben Bacarisse <ben.u...@bsb.me.uk> writes: > > David Brown <david...@hesbynett.no> writes: > >> With C11, you can write : > >> > >> _Noreturn void abort_with_error_message(const char *); > >> > >> So you don't have to wait until C23 (unless you really want the attribute > >> syntax). > > > > I somehow missed that in C11. Thanks. > C11 added the _Noreturn keyword and the <stdnoreturn.h> header, which > defines a macro `noreturn` that expands to `_Noreturn`. > > C23 makes all that obsolescent, and introduces attributes, including > [[noreturn]]. > Exactly. You use the whizzy new feature, and in the next version of the compiler it is obsolete. Typical.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-08 11:06 +0200 |
| Message-ID | <udeo66$3dafd$1@dont-email.me> |
| In reply to | #174496 |
On 08/09/2023 09:46, Malcolm McLean wrote: > On Thursday, 7 September 2023 at 22:52:07 UTC+1, Keith Thompson wrote: >> Ben Bacarisse <ben.u...@bsb.me.uk> writes: >>> David Brown <david...@hesbynett.no> writes: >>>> With C11, you can write : >>>> >>>> _Noreturn void abort_with_error_message(const char *); >>>> >>>> So you don't have to wait until C23 (unless you really want the attribute >>>> syntax). >>> >>> I somehow missed that in C11. Thanks. >> C11 added the _Noreturn keyword and the <stdnoreturn.h> header, which >> defines a macro `noreturn` that expands to `_Noreturn`. >> >> C23 makes all that obsolescent, and introduces attributes, including >> [[noreturn]]. >> > Exactly. You use the whizzy new feature, and in the next version of the > compiler it is obsolete. Typical. "obsolescent" does not mean "obsolete". It means that the feature might, in the future, be a likely candidate for being made "obsolete". Thus function declarations of the form "int foo();" meaning "foo make take some parameters, but I'm not saying how many or what type" have been "obsolescent" since C90 (after function prototypes were introduced). But they were not "obsolete" until C23, when the meaning was changed to be the same as "int foo(void);", just like in C++. The C standards committee has taken the decision (for better or worse - I'm sure opinions will vary) that [[attribute]] syntax is an important feature going forward, and that it gives a flexible and convenient structure for new features in the future. In particular, it means things like "_Noreturn" can be added to the language without needing new keywords, without conflicting with user identifiers, without needing awkward _Reserved naming style, and without adding new standard headers that exist only to provide neater names. Marking "_Noreturn" (and <stdnoreturn.h>) as "obsolescent" and replaced by "[[noreturn]]" is just an indication that the attribute style is what the C committee sees as becoming standard practice in the future, and code written to C23 should move to that practice for consistency. So "_Noreturn" will probably be supported for the next 33 years before being actually "obsolete". And even then, you will be able to define a macro "#define _Noreturn [[noreturn]]".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-08 10:19 +0200 |
| Message-ID | <udeldr$3crce$2@dont-email.me> |
| In reply to | #174360 |
On 07/09/2023 18:02, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> With C11, you can write : >> >> _Noreturn void abort_with_error_message(const char *); >> >> So you don't have to wait until C23 (unless you really want the attribute >> syntax). > > I somehow missed that in C11. Thanks. > When writing that post, I first thought _Noreturn was from C17 - I had to look it up to see it was in C11. (Many of these kinds of things are standardisations of extensions in gcc and clang - and since my code normally does not have to be portable beyond gcc, I have been using things like "__attribute__((noreturn))" since long before C11.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-07 15:55 +0100 |
| Message-ID | <udco9q$31af8$1@dont-email.me> |
| In reply to | #174325 |
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) {}
gcc, with noise removed, produces this x64 code:
fred:
push rbp
mov rbp, rsp
nop
pop rbp
ret
main:
push rbp
mov rbp, rsp
mov eax, 0
pop rbp
ret
Can you spot the difference between the two functions?
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!
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-07 15:16 +0000 |
| Message-ID | <hPlKM.1033922$SuUf.95361@fx14.iad> |
| In reply to | #174333 |
Bart <bc@freeuk.com> writes:
>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) {}
>
>
>gcc, with noise removed, produces this x64 code:
>
> fred:
> push rbp
> mov rbp, rsp
> nop
> pop rbp
> ret
>
> main:
> push rbp
> mov rbp, rsp
>
> mov eax, 0
> pop rbp
> ret
>
>Can you spot the difference between the two functions?
>
>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.
When I compile that with gcc[-O2], I get:
0000000000400400 <main>:
400400: f3 c3 repz retq
400402: 66 90 xchg %ax,%ax
00000000004004f0 <fred>:
4004f0: f3 c3 repz retq
4004f2: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
4004f9: 00 00 00
4004fc: 0f 1f 40 00 nopl 0x0(%rax)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-07 17:02 +0100 |
| Message-ID | <udcs63$31tj2$1@dont-email.me> |
| In reply to | #174336 |
On 07/09/2023 16:16, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> 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) {}
>>
>>
>> gcc, with noise removed, produces this x64 code:
>>
>> fred:
>> push rbp
>> mov rbp, rsp
>> nop
>> pop rbp
>> ret
>>
>> main:
>> push rbp
>> mov rbp, rsp
>>
>> mov eax, 0
>> pop rbp
>> ret
>>
>> Can you spot the difference between the two functions?
>>
>> 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.
>
> When I compile that with gcc[-O2], I get:
>
> 0000000000400400 <main>:
> 400400: f3 c3 repz retq
> 400402: 66 90 xchg %ax,%ax
> 00000000004004f0 <fred>:
> 4004f0: f3 c3 repz retq
> 4004f2: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
> 4004f9: 00 00 00
> 4004fc: 0f 1f 40 00 nopl 0x0(%rax)
Which means what? A failed attempt to bamboozle Bart?
On godbolt.org using -O2, the latest MSVC, Clang, Zig CC, gcc and icc
compilers for x64 show clear instructions that clear eax for main(), not
so for fred().
On PowerPC, main has a 'li 3,0' instruction that doesn't appear in fred.
On MIPS, it is 'mov $2, $0'.
On one ARM64 compiler, it has 'mov r0, #0'.
So clearly, there is a pattern of the compiler inserting code to clear
the return value from main().
Which is very convenient in avoiding the user having to write 'return
0;' in ONE function in an entire application, never mind the 1000s of
user functions that could benefit from that, but are left to return
garbage if control falls off the end of the function.
But back to your nonsense: F3 C3 means 'ret', as does 'C3'. It would be
useful to show the whole of that main() function to see what you've left
out.
(What value does your main() actually return if you run into the end?
/Does/ it actually run into the end? And if it is zero, how does it get
there?
Also, why is your code generating such crap?)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-07 16:15 +0000 |
| Message-ID | <QGmKM.1037686$SuUf.891563@fx14.iad> |
| In reply to | #174359 |
Bart <bc@freeuk.com> writes:
>On 07/09/2023 16:16, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> 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) {}
>>>
>>>
>>> gcc, with noise removed, produces this x64 code:
>>>
>>> fred:
>>> push rbp
>>> mov rbp, rsp
>>> nop
>>> pop rbp
>>> ret
>>>
>>> main:
>>> push rbp
>>> mov rbp, rsp
>>>
>>> mov eax, 0
>>> pop rbp
>>> ret
>>>
>>> Can you spot the difference between the two functions?
>>>
>>> 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.
>>
>> When I compile that with gcc[-O2], I get:
>>
>> 0000000000400400 <main>:
>> 400400: f3 c3 repz retq
>> 400402: 66 90 xchg %ax,%ax
>> 00000000004004f0 <fred>:
>> 4004f0: f3 c3 repz retq
>> 4004f2: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
>> 4004f9: 00 00 00
>> 4004fc: 0f 1f 40 00 nopl 0x0(%rax)
>
>Which means what? A failed attempt to bamboozle Bart?
It means that different compilers (the above was GCC 4.8.3)
do different things even between versions.
GCC 9.3.0
0000000000400460 <fred>:
400460: c3 retq
400461: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
400468: 00 00 00
40046b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
0000000000400360 <main>:
400360: 31 c0 xor %eax,%eax
400362: c3 retq
400363: 90 nop
But ultimately, nobody but you cares what code is generated
in your contrived example.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-07 17:51 +0100 |
| Message-ID | <udcv24$32b9d$1@dont-email.me> |
| In reply to | #174365 |
On 07/09/2023 17:15, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 07/09/2023 16:16, Scott Lurndal wrote:
>>> When I compile that with gcc[-O2], I get:
>>>
>>> 0000000000400400 <main>:
>>> 400400: f3 c3 repz retq
>>> 400402: 66 90 xchg %ax,%ax
>>> 00000000004004f0 <fred>:
>>> 4004f0: f3 c3 repz retq
>>> 4004f2: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
>>> 4004f9: 00 00 00
>>> 4004fc: 0f 1f 40 00 nopl 0x0(%rax)
>>
>> Which means what? A failed attempt to bamboozle Bart?
>
> It means that different compilers (the above was GCC 4.8.3)
> do different things even between versions.
OK, up to the last 4.x.y gcc version, both functions generate only:
rep ret
for their bodies. That is, just two bytes of code. The rest of what you
posted above is just whatever garbage happened to follow.
From gcc 5.1 upwards, main includes code to zero eax before returning.
> GCC 9.3.0
>
> 0000000000400460 <fred>:
> 400460: c3 retq
I see it eventually dropped that 'rep' prefix.
> 400461: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
> 400468: 00 00 00
> 40046b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
This is garbage.
> 0000000000400360 <main>:
> 400360: 31 c0 xor %eax,%eax
> 400362: c3 retq
> 400363: 90 nop
Other more garbage, or padding. In either case, these bytes are not
relevant to anything.
>
>
> But ultimately, nobody but you cares what code is generated
> in your contrived example.
Then you've missed the point of it, which is that compilers (at least
since version 5 in the case of gcc), ensure that main returns 0 if it
falls off the end of the function. But they don't anything do like that
anywhere else.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-07 17:24 +0000 |
| Message-ID | <oHnKM.340816$ens9.67069@fx45.iad> |
| In reply to | #174378 |
Bart <bc@freeuk.com> writes: >On 07/09/2023 17:15, Scott Lurndal wrote: >> Bart <bc@freeuk.com> writes: >>> On 07/09/2023 16:16, Scott Lurndal wrote: > >>>> When I compile that with gcc[-O2], I get: >>>> >>>> 0000000000400400 <main>: >>>> 400400: f3 c3 repz retq >>>> 400402: 66 90 xchg %ax,%ax >>>> 00000000004004f0 <fred>: >>>> 4004f0: f3 c3 repz retq >>>> 4004f2: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) >>>> 4004f9: 00 00 00 >>>> 4004fc: 0f 1f 40 00 nopl 0x0(%rax) >>> >>> Which means what? A failed attempt to bamboozle Bart? >> >> It means that different compilers (the above was GCC 4.8.3) >> do different things even between versions. > >OK, up to the last 4.x.y gcc version, both functions generate only: > > rep ret > >for their bodies. That is, just two bytes of code. The rest of what you >posted above is just whatever garbage happened to follow. Correction. It is not "garbage". Those are some of the many forms of NOP instructions generated to align the starting PC of the next function.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-07 21:53 +0100 |
| Message-ID | <uddd7i$34d6h$1@dont-email.me> |
| In reply to | #174380 |
On 07/09/2023 18:24, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 07/09/2023 17:15, Scott Lurndal wrote: >>> Bart <bc@freeuk.com> writes: >>>> On 07/09/2023 16:16, Scott Lurndal wrote: >> >>>>> When I compile that with gcc[-O2], I get: >>>>> >>>>> 0000000000400400 <main>: >>>>> 400400: f3 c3 repz retq >>>>> 400402: 66 90 xchg %ax,%ax >>>>> 00000000004004f0 <fred>: >>>>> 4004f0: f3 c3 repz retq >>>>> 4004f2: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) >>>>> 4004f9: 00 00 00 >>>>> 4004fc: 0f 1f 40 00 nopl 0x0(%rax) >>>> >>>> Which means what? A failed attempt to bamboozle Bart? >>> >>> It means that different compilers (the above was GCC 4.8.3) >>> do different things even between versions. >> >> OK, up to the last 4.x.y gcc version, both functions generate only: >> >> rep ret >> >> for their bodies. That is, just two bytes of code. The rest of what you >> posted above is just whatever garbage happened to follow. > > Correction. It is not "garbage". But it's not part of preceding function's body, and it is wrong to show them as such or to try to diassemble them. > Those are some of the many > forms of NOP instructions generated to align the starting PC of the > next function. I assume it is considered more efficient, in that part of a cpu which speculatively decodes future instructions, to have fewer longer instructions, rather than multiple single byte ones. But it is still confusing to present them, especially given the missing bytes in addresses 400404 to 4004ef. It's also not clear why main has its next function starting at an address which is a multiple of 4 (?), but both main and fred start at a multiple of 16.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-07 21:34 +0000 |
| Message-ID | <olrKM.758936$qnnb.249769@fx11.iad> |
| In reply to | #174415 |
Bart <bc@freeuk.com> writes: >On 07/09/2023 18:24, Scott Lurndal wrote: >> Bart <bc@freeuk.com> writes: >>> On 07/09/2023 17:15, Scott Lurndal wrote: >>>> Bart <bc@freeuk.com> writes: >>>>> On 07/09/2023 16:16, Scott Lurndal wrote: >>> >>>>>> When I compile that with gcc[-O2], I get: >>>>>> >>>>>> 0000000000400400 <main>: >>>>>> 400400: f3 c3 repz retq >>>>>> 400402: 66 90 xchg %ax,%ax >>>>>> 00000000004004f0 <fred>: >>>>>> 4004f0: f3 c3 repz retq >>>>>> 4004f2: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) >>>>>> 4004f9: 00 00 00 >>>>>> 4004fc: 0f 1f 40 00 nopl 0x0(%rax) >>>>> >>>>> Which means what? A failed attempt to bamboozle Bart? >>>> >>>> It means that different compilers (the above was GCC 4.8.3) >>>> do different things even between versions. >>> >>> OK, up to the last 4.x.y gcc version, both functions generate only: >>> >>> rep ret >>> >>> for their bodies. That is, just two bytes of code. The rest of what you >>> posted above is just whatever garbage happened to follow. >> >> Correction. It is not "garbage". > >But it's not part of preceding function's body, and it is wrong to show >them as such or to try to diassemble them. > >> Those are some of the many >> forms of NOP instructions generated to align the starting PC of the >> next function. > >I assume it is considered more efficient, in that part of a cpu which >speculatively decodes future instructions, to have fewer longer >instructions, rather than multiple single byte ones. > >But it is still confusing to present them, especially given the missing >bytes in addresses 400404 to 4004ef. They're missing because the intervening CRT functionality wasn't relevent and I elided it when posting. > >It's also not clear why main has its next function starting at an >address which is a multiple of 4 (?), but both main and fred start at a >multiple of 16. See comment immediately above. As it happens, the function after main wasn't written in C, it's the ELF entry point. 0000000000400404 <_start>: 400404: 31 ed xor %ebp,%ebp 400406: 49 89 d1 mov %rdx,%r9 400409: 5e pop %rsi 40040a: 48 89 e2 mov %rsp,%rdx 40040d: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp 400411: 50 push %rax 400412: 54 push %rsp 400413: 49 c7 c0 70 05 40 00 mov $0x400570,%r8 40041a: 48 c7 c1 00 05 40 00 mov $0x400500,%rcx 400421: 48 c7 c7 00 04 40 00 mov $0x400400,%rdi 400428: e8 b3 ff ff ff callq 4003e0 <__libc_start_main@plt> 40042d: f4 hlt 40042e: 66 90 xchg %ax,%ax
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-07 17:25 +0000 |
| Message-ID | <wInKM.340817$ens9.252129@fx45.iad> |
| In reply to | #174378 |
Bart <bc@freeuk.com> writes: >On 07/09/2023 17:15, Scott Lurndal wrote: >> Bart <bc@freeuk.com> writes: >>> On 07/09/2023 16:16, Scott Lurndal wrote: > >> >> But ultimately, nobody but you cares what code is generated >> in your contrived example. > >Then you've missed the point of it, which is that compilers (at least >since version 5 in the case of gcc), ensure that main returns 0 if it >falls off the end of the function. But they don't anything do like that >anywhere else. If there's a point at all there, it is that gcc is broken when it generates an implicit return value of success (zero), in my opinion.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-07 21:37 +0100 |
| Message-ID | <uddc9g$348as$1@dont-email.me> |
| In reply to | #174381 |
On 07/09/2023 18:25, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 07/09/2023 17:15, Scott Lurndal wrote: >>> Bart <bc@freeuk.com> writes: >>>> On 07/09/2023 16:16, Scott Lurndal wrote: >> > >>> >>> But ultimately, nobody but you cares what code is generated >>> in your contrived example. >> >> Then you've missed the point of it, which is that compilers (at least >> since version 5 in the case of gcc), ensure that main returns 0 if it >> falls off the end of the function. But they don't anything do like that >> anywhere else. > > If there's a point at all there, it is that gcc is broken when it > generates an implicit return value of success (zero), in my opinion. Well, it's good that you have a bold opinion. But I don't think it will be popular, and is unlikely to be practical. It means a program like hello.c from K&R2 will probably return a failure code. If I remove the zeroing from the code gcc produces for 'hello.c', then it does in fact fail. (The failure code is likely to be the number of characters output.) Further, I can't get gcc to warn me about reaching the end of 'main' without a suitable return or exit call, as it does for all other functions.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-07 21:02 +0000 |
| Message-ID | <kTqKM.216832$QQFb.154651@fx38.iad> |
| In reply to | #174411 |
Bart <bc@freeuk.com> writes:
>On 07/09/2023 18:25, Scott Lurndal wrote:
> > Bart <bc@freeuk.com> writes:
> >> On 07/09/2023 17:15, Scott Lurndal wrote:
> >>> Bart <bc@freeuk.com> writes:
> >>>> On 07/09/2023 16:16, Scott Lurndal wrote:
> >>
> >
> >>>
> >>> But ultimately, nobody but you cares what code is generated
> >>> in your contrived example.
> >>
> >> Then you've missed the point of it, which is that compilers (at least
> >> since version 5 in the case of gcc), ensure that main returns 0 if it
> >> falls off the end of the function. But they don't anything do like that
> >> anywhere else.
> >
> > If there's a point at all there, it is that gcc is broken when it
> > generates an implicit return value of success (zero), in my opinion.
>
>Well, it's good that you have a bold opinion. But I don't think it will
>be popular, and is unlikely to be practical.
>
>It means a program like hello.c from K&R2 will probably return a failure
>code.
>
>If I remove the zeroing from the code gcc produces for 'hello.c', then
>it does in fact fail. (The failure code is likely to be the number of
>characters output.)
Which, for that program, may be exactly what the programmer
intended. The number of characters output is an interesting
datum which a shell script could potentially make use of.
While the exit value can be treated as a success/failure
indication, it can also be used to pass arbitrary
integer data to the parent process (which isn't necessarily
a shell process).
Now I agree that an explicit return is better than relying on
the compiler to treat UB in any particular fashion.
And -Wall -Werror will fail to compile that code.
$ cc -Wall -Werror -o /tmp/x /tmp/xx.c
/tmp/xx.c: In function 'fred':
/tmp/xx.c:1:4: error: control reaches end of non-void function [-Werror=return-type]
int fred(void) {}
^
/tmp/xx.c: In function 'main':
/tmp/xx.c:2:4: error: control reaches end of non-void function [-Werror=return-type]
int main(void) {}
^
cc1: all warnings being treated as errors
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-07 16:14 -0700 |
| Message-ID | <87ledh1spx.fsf@nosuchdomain.example.com> |
| In reply to | #174381 |
scott@slp53.sl.home (Scott Lurndal) writes:
[...]
> If there's a point at all there, it is that gcc is broken when it
> generates an implicit return value of success (zero), in my opinion.
That behavior is explicitly required (for main, and only for main) by
the ISO C standard starting in C99. See 5.1.2.2.3p1.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-07 16:09 -0700 |
| Message-ID | <87pm2t1sy6.fsf@nosuchdomain.example.com> |
| In reply to | #174378 |
Bart <bc@freeuk.com> writes:
[...]
> OK, up to the last 4.x.y gcc version, both functions generate only:
>
> rep ret
>
> for their bodies. That is, just two bytes of code. The rest of what
> you posted above is just whatever garbage happened to follow.
>
> From gcc 5.1 upwards, main includes code to zero eax before returning.
Yes, and that's completely unsurprising once you look at the history.
The rule that falling off the end of main implicitly returns 0 was added
in C99. In C90, the return status is undefined. (On various systems,
I've seen 0, 1, and 41.)
All gcc-4.* versions default to "-std=gnu89" or "-std=gnu90" if no
standard is specified.
All gcc-5.* versions default to "-std=gnu11" if no standard is specified.
I expect that "gcc-4 -std=gnu90" and "gcc-5 -std=gnu90" will behave the
same way with respect to falling off the end of main (generating code
that returns an arbitrary status).
I expect that "gcc-4 -std=gnu99" and "gcc-5 -std=gnu99" will behave the
same way with respect to falling off the end of main (generating code
that returns a status of 0).
[...]
> Then you've missed the point of it, which is that compilers (at least
> since version 5 in the case of gcc), ensure that main returns 0 if it
> falls off the end of the function. But they don't anything do like
> that anywhere else.
Which is exactly the behavior I want and expect.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-07 17:34 +0100 |
| Message-ID | <87msxyndqx.fsf@bsb.me.uk> |
| In reply to | #174333 |
Bart <bc@freeuk.com> writes: > 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. That seems unlikely but I don't know the reason. It never irked me because, unlike the case we are talking about (which you cut from the reply), the return statement was not unnecessary (at least in the environment I used). Maybe there was a lot of code running on systems where people tended to ignore the returned value so it got left off a lot? Anyway, it's not the same as the case in question because the return used to be important. > Why the special dispensation for main(), and not for user functions? I would guess because there is always only one main function. It is inherently special, so there is negligible cost to any special treatment. Having to provide a value for every function, including those that don't need one (like the example you cut), is the kind of thing other languages usually do. Even thought the cost might be very, very low it still feels un-C-like. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-07 17:22 +0000 |
| Message-ID | <yFnKM.340815$ens9.236857@fx45.iad> |
| In reply to | #174372 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >Bart <bc@freeuk.com> writes: > >> 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. > >That seems unlikely but I don't know the reason. I suspect historical inertia dating back to the early C compilers. Given that on unix, the return value from main is made available to the parent process via the wait/waitid/waitpid system calls, programmers were generally good about putting a return statement into the main() function regardless of whether the compiler warned about it or not. To that end, the recent gcc behavior of explicitly returning zero when the return statement is missing is, in my mind, bogus, as it potentially masks bugs and would indicate successful completion regardless of the actually success/failure of the application. That said, I always use -Wall -Werror when compiling with gcc.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-09-07 11:44 -0700 |
| Message-ID | <0SoKM.1180697$TPw2.266560@fx17.iad> |
| In reply to | #174333 |
On 9/7/23 7:55 AM, Bart wrote: > 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! > As to many things, ancient history, which is WHY the Standard so stipulates. main() is special, as it interfaces with the Operating System, which started out a being Unix. Returning 0 there was a "Successful" return, and was very common, so the early compilers were designed to assume running off the end of main was a successful completion. For other functions, falling off the end was often because they didn't have anything to return, so forcing the return of 0 would just be the waste of an instruction, and for the size of machines back then, that could be a significant cost. Note, "void" hadn't been invented yet, so functions without a return type were just implicitly considered to return an int (since that was the cheapest), and normally the omition of the type was a signal that it didn't actually return anything (but some code used the DEFINED behavior of it being considered int). ANSI C89/ISO C90 continued this behavior, and ISO C99 removed the implicit int, as it was decided that programs using it were simple to fix, and really should be fixed. Making falling of the end of a non-void function is a lot harder to fix, as reliably detecting that this is actually being done can be hard, and for some return types, forcing a return value expensive (and unclear what it should be), thus this hasn't been made an error. Most implementations can be made to give a warning on this (or even put into a non-conforming mode to reject it) so the cost to programmers for allowing it isn't that high (C is built on the assumption that programmers know what they are doing and know how to use their tools). With the C11 _Noreturn and C23 [[noreturn]] attributes, it is possible to now come up with rules to allow detecting most of the cases where the fall thorough can't happen, so perhaps it could be revisited, and see if the advantages out weigh the breakage, but that isn't clear cut.
[toc] | [prev] | [next] | [standalone]
Page 14 of 18 — ← Prev page 1 … 12 13 [14] 15 16 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web