Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #397525 > unrolled thread
| Started by | wij <wyniijj5@gmail.com> |
|---|---|
| First post | 2026-04-14 22:47 +0800 |
| Last post | 2026-04-18 11:33 +0200 |
| Articles | 20 on this page of 365 — 21 participants |
Back to article view | Back to comp.lang.c
A thought of C wij <wyniijj5@gmail.com> - 2026-04-14 22:47 +0800
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-14 18:45 +0100
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-15 02:41 +0800
Re: A thought of C Jonathan Lamothe <jonathan@jlamothe.net> - 2026-04-14 15:56 -0400
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-14 22:41 +0100
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-15 00:20 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-15 00:33 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-15 09:57 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-15 15:43 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-16 09:10 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:12 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:12 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:20 -0700
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-16 06:28 -0400
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-16 14:03 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-16 22:13 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-16 14:33 -0700
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-16 20:26 -0400
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-17 12:27 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-17 14:37 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-17 16:37 +0300
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-17 15:54 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-17 14:49 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-17 16:45 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-17 17:42 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-17 10:22 -0700
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-18 03:41 +0800
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-18 15:37 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-18 16:08 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-18 17:35 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-19 13:44 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-19 16:06 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-18 17:35 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-18 18:29 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-19 12:17 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-19 12:50 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-19 14:17 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-19 15:28 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-19 17:47 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-19 18:47 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-19 21:32 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 00:36 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-20 08:25 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 12:45 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-20 15:02 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 15:32 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-20 18:04 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-20 10:50 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 20:50 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-20 14:30 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 23:09 +0100
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-22 05:01 +0200
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-22 04:53 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-20 10:48 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 21:13 +0100
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-20 20:27 +0000
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-20 15:04 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 09:00 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-20 14:59 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 23:36 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-20 18:22 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 11:01 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 13:44 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 13:48 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 15:43 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 16:01 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 18:03 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 09:19 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 18:51 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 13:16 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-22 01:01 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 19:53 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-22 09:40 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-22 13:01 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-22 14:23 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 00:52 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-22 19:26 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 11:30 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 13:12 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-23 15:12 +0300
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-23 14:18 +0000
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-23 17:35 +0300
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-23 10:32 -0400
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-23 17:45 +0300
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 13:43 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 16:40 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 17:42 +0100
Re: A thought of C DFS <nospam@dfs.com> - 2026-04-25 10:38 -0400
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 15:16 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-23 13:50 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 04:43 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 13:33 +0100
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-23 14:22 +0000
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-23 17:39 +0300
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 17:02 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 14:40 +0200
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-23 14:17 +0000
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-23 19:42 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 22:04 +0100
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-23 23:15 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-24 01:06 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 17:57 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-24 08:27 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-24 01:33 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-24 11:27 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-24 13:11 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-24 14:55 +0300
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-24 14:05 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-24 17:26 +0300
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-24 10:09 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-24 10:14 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-23 16:10 +0200
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 08:25 +0200
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-23 17:41 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 20:19 +0100
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-25 23:04 +0000
time measurements (Re: A thought of C) Michael S <already5chosen@yahoo.com> - 2026-04-26 12:34 +0300
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 09:03 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 08:58 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 12:40 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 22:56 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 15:07 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 10:28 +0200
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 10:13 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-21 11:51 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 22:13 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-22 14:28 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-22 14:29 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 09:22 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-23 02:03 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-23 02:07 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 11:30 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-23 14:06 -0700
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-21 00:39 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 02:34 +0100
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-21 23:41 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-22 12:49 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 10:01 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 12:12 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 13:57 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-21 15:55 +0300
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 14:49 +0100
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-21 18:44 +0300
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 18:06 +0200
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-21 21:24 -0700
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-22 13:02 +0300
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-23 08:07 -0700
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-21 21:12 -0700
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-22 12:48 +0300
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-22 04:36 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 20:13 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-22 15:14 +0100
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-22 17:56 +0300
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-22 17:12 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-22 18:21 +0300
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-22 17:57 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-22 19:16 +0300
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-22 21:42 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-22 14:33 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 00:22 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-22 18:59 -0700
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-23 11:07 +0800
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 09:47 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-22 23:16 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 10:58 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 03:43 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 12:48 +0200
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-23 10:42 -0400
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 16:30 +0100
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-23 09:21 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 17:27 +0100
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-25 14:19 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 17:25 -0700
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-23 21:17 -0400
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-23 14:08 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 23:18 +0100
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-24 01:31 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 17:51 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 18:19 -0700
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-23 21:34 -0400
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-24 04:26 +0200
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-24 20:26 -0400
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 18:21 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 18:21 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 18:20 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 18:23 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 18:27 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-24 18:57 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 20:26 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-24 23:03 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 23:50 -0700
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-25 12:04 -0400
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-25 12:00 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-25 21:24 +0100
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-25 13:52 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-25 22:27 +0100
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-26 00:48 +0300
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 15:49 -0700
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-26 02:24 +0300
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-25 20:07 -0400
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 17:14 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-26 04:34 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-25 18:08 -0700
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-25 17:20 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-26 01:47 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 18:40 -0700
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-25 19:58 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 15:39 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-26 00:53 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 18:27 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-26 02:41 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 19:03 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 19:08 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-26 05:04 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-26 12:32 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-26 15:13 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-26 16:27 +0300
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-26 17:19 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-26 15:34 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-27 19:30 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-26 12:14 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-26 15:23 -0700
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-26 20:02 -0400
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-26 04:24 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 20:05 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-26 05:16 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 21:26 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-26 17:51 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 15:31 -0700
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-25 20:19 -0400
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-25 18:11 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 18:34 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-26 20:58 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-24 18:44 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 20:24 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-24 23:01 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 23:49 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 20:26 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 09:42 +0200
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-20 13:49 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 18:34 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-20 22:57 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 23:03 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 10:53 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 02:56 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 14:10 +0200
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-21 21:04 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-22 08:28 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 11:31 +0100
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-21 14:27 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 15:38 +0100
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-21 15:38 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 17:55 +0100
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-21 17:28 +0000
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-22 11:13 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-21 19:11 +0300
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-21 21:09 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-22 15:16 +0100
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-22 15:13 +0000
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-22 18:26 +0300
Re: A thought of C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-04-22 16:09 +0000
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 08:18 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-23 01:56 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-24 02:29 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 18:18 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-24 03:57 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 19:11 -0700
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-23 09:14 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-22 17:27 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-22 18:52 +0300
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-22 20:39 -0700
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-23 13:15 +0300
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 12:50 +0200
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-23 08:46 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-24 02:40 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 18:31 -0700
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-22 20:37 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 02:37 -0700
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-23 06:46 -0700
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-19 16:54 +0300
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-19 16:02 +0100
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-20 00:49 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 17:17 +0100
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-26 22:57 +0000
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-27 02:55 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-27 02:06 +0100
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-29 02:00 +0100
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-29 04:31 +0000
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-19 15:36 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-17 10:25 -0700
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-17 16:30 -0400
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-15 12:20 +0800
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-15 11:21 +0100
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-15 19:52 +0800
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-15 14:24 +0100
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 00:40 +0800
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-14 15:31 -0700
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-15 12:15 +0800
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-14 21:46 -0700
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-15 14:05 +0800
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-15 10:24 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-15 11:46 +0100
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-15 20:21 +0800
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-15 20:26 +0800
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-15 15:38 +0200
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 00:58 +0800
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-15 22:11 +0200
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 05:38 +0800
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-15 15:48 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:31 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-16 09:13 +0200
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-16 04:43 +0000
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-16 09:23 +0200
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-16 14:38 +0000
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-16 17:05 +0200
Re: A thought of C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-04-16 15:11 +0000
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-16 17:43 +0200
Re: A thought of C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-04-16 16:23 +0000
Re: A thought of C cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-16 19:48 +0000
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-16 19:04 +0000
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-16 19:01 +0000
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-15 15:34 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:29 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-15 15:06 +0100
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 05:12 +0800
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-15 23:52 +0100
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 07:30 +0800
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-16 00:50 +0100
Re: A thought of C Jonathan Lamothe <jonathan@jlamothe.net> - 2026-04-15 20:17 -0400
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-16 09:35 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:37 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:40 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:47 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-16 13:19 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-16 14:28 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:34 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-15 15:12 -0700
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 07:22 +0800
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-15 16:52 -0700
[meta] signature quote (was Re: A thought of C) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-16 03:13 +0200
Re: A thought of C 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-04-15 07:00 +0200
Re: A thought of C makendo <makendo@makendo.invalid> - 2026-04-15 21:40 +0800
Re: A thought of C Jonathan Lamothe <jonathan@jlamothe.net> - 2026-04-15 10:51 -0400
Re: A thought of C makendo <makendo@makendo.invalid> - 2026-04-16 12:44 +0800
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 01:11 +0800
Re: A thought of C 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-04-15 20:23 +0200
Re: A thought of C "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-04-15 21:01 +0100
Re: A thought of C 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-04-15 22:40 +0200
Re: A thought of C "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-04-16 11:38 +0100
Re: A thought of C "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-04-30 11:31 +0100
Re: A thought of C Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-19 07:41 +0000
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-15 17:14 -0700
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 09:27 +0800
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-15 19:04 -0700
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 18:42 +0800
Re: A thought of C gazelle@shell.xmission.com (Kenny McCormack) - 2026-04-16 13:10 +0000
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 22:21 +0800
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-16 17:03 +0200
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 22:14 +0800
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-18 22:17 +0800
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-21 06:29 +0800
Re: A thought of C Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-24 02:27 +0000
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-16 04:05 +0200
Re: A thought of C cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-16 11:24 +0000
Re: A thought of C Rosario19 <Ros@invalid.invalid> - 2026-04-18 11:33 +0200
Page 9 of 19 — ← Prev page 1 … 7 8 [9] 10 11 … 19 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-22 18:59 -0700 |
| Message-ID | <10sbue0$2mtc2$1@kst.eternal-september.org> |
| In reply to | #397817 |
Bart <bc@freeuk.com> writes:
>> Bart <bc@freeuk.com> writes:
[...]
>>> So, what does language say about it again? Remind me! Or better, tell
>>> the compiler.
>> I've already told you what the language says about it. I quoted
>> the section of the ISO C standard that says explicitly that the
>> behavior is undefined. N3220 6.3.2.1p2, last sentence.
>> The compiler's behavior is consistent with that requirment.
>> You cannot possibly have forgotten this. Why do you pretend?
>
> Nobody seems to have a problem with gcc being lax about this (or with
> it allowing its users to let it be lax).
gcc is not being lax. gcc is behaving in a matter that is consistent
with the requirements of the C standard. The code in question has
undefined behavior.
You know and understand all of that.
> Everybody seems to have a problem with /me/ being lax about it.
Not everybody, but I certainly do.
> Does anyone have any actual examples of very bad things happening with
> a program like the above?
>
> From what I can see, with -O0 it just moves 32 bits from one part of
> the allocated stack frame to another. And with -O1 and above, the code
> is elided anyway.
>
> Not exactly the end of the world.
The behavior is undefined. You know exactly what that means, but you
pretend not to.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-04-23 11:07 +0800 |
| Message-ID | <123656496c4082f2016670332e01faeae22cf7e0.camel@gmail.com> |
| In reply to | #397820 |
On Wed, 2026-04-22 at 18:59 -0700, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > > > Bart <bc@freeuk.com> writes: > [...] > > > > So, what does language say about it again? Remind me! Or better, tell > > > > the compiler. > > > I've already told you what the language says about it. I quoted > > > the section of the ISO C standard that says explicitly that the > > > behavior is undefined. N3220 6.3.2.1p2, last sentence. > > > The compiler's behavior is consistent with that requirment. > > > You cannot possibly have forgotten this. Why do you pretend? > > > > Nobody seems to have a problem with gcc being lax about this (or with > > it allowing its users to let it be lax). > > gcc is not being lax. gcc is behaving in a matter that is consistent > with the requirements of the C standard. The code in question has > undefined behavior. > > You know and understand all of that. > > > Everybody seems to have a problem with /me/ being lax about it. > > Not everybody, but I certainly do. > > > Does anyone have any actual examples of very bad things happening with > > a program like the above? > > > > From what I can see, with -O0 it just moves 32 bits from one part of > > the allocated stack frame to another. And with -O1 and above, the code > > is elided anyway. > > > > Not exactly the end of the world. > > The behavior is undefined. You know exactly what that means, but you > pretend not to. 1. 'The language' must see the 'C program' as it is, i.e. every component in this case must map to some assembly code (or 'portable assembly'). 2. 'optimiztion' is a heigher level concept, nothing to do with 'The language'. 3. If the code is defined as undefined, why it can be justified to optimize? So, the 'undefined' is but the C standard's concept, maybe about compiler spec... Because the real thing is that the development of C had been always buttom-up.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-23 09:47 +0200 |
| Message-ID | <10scird$2pv83$3@dont-email.me> |
| In reply to | #397822 |
On 23/04/2026 05:07, wij wrote: > On Wed, 2026-04-22 at 18:59 -0700, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >>>> Bart <bc@freeuk.com> writes: >> [...] >>>>> So, what does language say about it again? Remind me! Or better, tell >>>>> the compiler. >>>> I've already told you what the language says about it. I quoted >>>> the section of the ISO C standard that says explicitly that the >>>> behavior is undefined. N3220 6.3.2.1p2, last sentence. >>>> The compiler's behavior is consistent with that requirment. >>>> You cannot possibly have forgotten this. Why do you pretend? >>> >>> Nobody seems to have a problem with gcc being lax about this (or with >>> it allowing its users to let it be lax). >> >> gcc is not being lax. gcc is behaving in a matter that is consistent >> with the requirements of the C standard. The code in question has >> undefined behavior. >> >> You know and understand all of that. >> >>> Everybody seems to have a problem with /me/ being lax about it. >> >> Not everybody, but I certainly do. >> >>> Does anyone have any actual examples of very bad things happening with >>> a program like the above? >>> >>> From what I can see, with -O0 it just moves 32 bits from one part of >>> the allocated stack frame to another. And with -O1 and above, the code >>> is elided anyway. >>> >>> Not exactly the end of the world. >> >> The behavior is undefined. You know exactly what that means, but you >> pretend not to. > > 1. 'The language' must see the 'C program' as it is, i.e. every component in > this case must map to some assembly code (or 'portable assembly'). Nonsense. If you want an access (read or write) in C to map to an access in the generated code, use "volatile". Other than that, it is all "as if". > 2. 'optimiztion' is a heigher level concept, nothing to do with 'The language'. It is correct that the C standard does not bother much about optimisation (though there are some features that exist specifically to allow better optimisations). But it does not in any way restrict optimisations - implementations can optimise as little or as much as they like, as long as they don't affect the defined semantics of the code. > 3. If the code is defined as undefined, why it can be justified to optimize? > When there is no defined behaviour in the source code, the compiler can generate absolutely any object code and it will be fine for the task. > So, the 'undefined' is but the C standard's concept, maybe about compiler spec... > Because the real thing is that the development of C had been always buttom-up. >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-04-22 23:16 -0700 |
| Message-ID | <10scdfo$2qma4$1@dont-email.me> |
| In reply to | #397820 |
On 4/22/2026 6:59 PM, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >>> Bart <bc@freeuk.com> writes: > [...] >>>> So, what does language say about it again? Remind me! Or better, tell >>>> the compiler. >>> I've already told you what the language says about it. I quoted >>> the section of the ISO C standard that says explicitly that the >>> behavior is undefined. N3220 6.3.2.1p2, last sentence. >>> The compiler's behavior is consistent with that requirment. >>> You cannot possibly have forgotten this. Why do you pretend? >> >> Nobody seems to have a problem with gcc being lax about this (or with >> it allowing its users to let it be lax). > > gcc is not being lax. gcc is behaving in a matter that is consistent > with the requirements of the C standard. The code in question has > undefined behavior. > > You know and understand all of that. > >> Everybody seems to have a problem with /me/ being lax about it. > > Not everybody, but I certainly do. > >> Does anyone have any actual examples of very bad things happening with >> a program like the above? >> >> From what I can see, with -O0 it just moves 32 bits from one part of >> the allocated stack frame to another. And with -O1 and above, the code >> is elided anyway. >> >> Not exactly the end of the world. > > The behavior is undefined. You know exactly what that means, but you > pretend not to. > Right. A compiler has the right to say we define that undefined behavior in this and that way. Read the manual. Also, be sure to read how to turn it on or off. Want an error, want a warning, or want our flag where we define said undefined behavior in our favor... ;^)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-04-23 10:58 +0100 |
| Message-ID | <10scqh1$2u305$1@dont-email.me> |
| In reply to | #397820 |
On 23/04/2026 02:59, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >>> Bart <bc@freeuk.com> writes: > [...] >>>> So, what does language say about it again? Remind me! Or better, tell >>>> the compiler. >>> I've already told you what the language says about it. I quoted >>> the section of the ISO C standard that says explicitly that the >>> behavior is undefined. N3220 6.3.2.1p2, last sentence. >>> The compiler's behavior is consistent with that requirment. >>> You cannot possibly have forgotten this. Why do you pretend? >> >> Nobody seems to have a problem with gcc being lax about this (or with >> it allowing its users to let it be lax). > > gcc is not being lax. gcc is behaving in a matter that is consistent > with the requirements of the C standard. The code in question has > undefined behavior. > You know and understand all of that. No, I don't. So what is the concrete effect of all that on the behaviour of gcc and the behaviour of the code it generates? If something bad happens (what would that be exactly), whose fault would that, mine or the compiler's? Are you suggesting that because something is tagged as UB, that it literally gives a compiler a licence to do anything? If so, how is that not being lax by either language, compiler, or both? I'm starting to suspect that either nobody knows the answer, or they do, but are chary of either blaming the compiler or criticising the language spec, and are trying to shift the blame to the user. > The behavior is undefined. You know exactly what that means, but you > pretend not to. And yet, the behaviour I have observed is nothing remarkable: some undefined bit patterns get used; zero is assumed; or code is just elided. Again, do you have any real-life, practical examples of bad or unusual things happening? If you had to put money on whether some outcode is either one of those three I listed, or something else, which would you go for?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-23 03:43 -0700 |
| Message-ID | <10sct58$2uqco$1@kst.eternal-september.org> |
| In reply to | #397837 |
Bart <bc@freeuk.com> writes:
> On 23/04/2026 02:59, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>>> Bart <bc@freeuk.com> writes:
>> [...]
>>>>> So, what does language say about it again? Remind me! Or better, tell
>>>>> the compiler.
>>>> I've already told you what the language says about it. I quoted
>>>> the section of the ISO C standard that says explicitly that the
>>>> behavior is undefined. N3220 6.3.2.1p2, last sentence.
>>>> The compiler's behavior is consistent with that requirment.
>>>> You cannot possibly have forgotten this. Why do you pretend?
>>>
>>> Nobody seems to have a problem with gcc being lax about this (or with
>>> it allowing its users to let it be lax).
>> gcc is not being lax. gcc is behaving in a matter that is consistent
>> with the requirements of the C standard. The code in question has
>> undefined behavior.
>
>> You know and understand all of that.
>
> No, I don't.
I don't believe you. (That's actually a compliment.)
[...]
> Are you suggesting that because something is tagged as UB, that it
> literally gives a compiler a licence to do anything?
As far as the C standard is concerned, yes, that's exactly what it
means.
What do you think it means? If the C standard imposes no requirements
on a program's behavior, what requirements do you think it imposes?
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-23 12:48 +0200 |
| Message-ID | <10sctem$2ut9t$1@dont-email.me> |
| In reply to | #397837 |
On 23/04/2026 11:58, Bart wrote: > On 23/04/2026 02:59, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >>>> Bart <bc@freeuk.com> writes: >> [...] >>>>> So, what does language say about it again? Remind me! Or better, tell >>>>> the compiler. >>>> I've already told you what the language says about it. I quoted >>>> the section of the ISO C standard that says explicitly that the >>>> behavior is undefined. N3220 6.3.2.1p2, last sentence. >>>> The compiler's behavior is consistent with that requirment. >>>> You cannot possibly have forgotten this. Why do you pretend? >>> >>> Nobody seems to have a problem with gcc being lax about this (or with >>> it allowing its users to let it be lax). >> >> gcc is not being lax. gcc is behaving in a matter that is consistent >> with the requirements of the C standard. The code in question has >> undefined behavior. > >> You know and understand all of that. > > No, I don't. This has all been explained to you countless times over years (decades even) in c.l.c. > > So what is the concrete effect of all that on the behaviour of gcc and > the behaviour of the code it generates? It may be nothing, it may be anything at all - that's what UB means. Typically you don't see much in the way of "UB based optimisation" in a very small test function, except perhaps that some code gets elided. More often you see the effects when there is more complex code, or when code is copied or moved around for inter-procedural optimisations such as inlining. > > If something bad happens (what would that be exactly), whose fault would >  that, mine or the compiler's? Your fault. Without a shadow of a doubt. > > Are you suggesting that because something is tagged as UB, that it > literally gives a compiler a licence to do anything? > I can't answer for Keith, but I can tell you that yes, compilers can do anything they want in the face of UB that they know is being "executed". Haven't you heard of nasal daemons? > If so, how is that not being lax by either language, compiler, or both? > It is not about being lax. Programming is a cooperative task between the programmer and the implementation. The standard forms the contract. The compiler promises to make object code that implements the source code, according to the semantics defined in the language standard (plus any additional implementation-specific details or extensions), while the programmer promises to follow the rules of the language - including that their program will not try to execute any UB. The compiler is only bound as long as the programmer fulfils his or her part. > I'm starting to suspect that either nobody knows the answer, or they do, > but are chary of either blaming the compiler or criticising the language > spec, and are trying to shift the blame to the user. > > > >> The behavior is undefined. You know exactly what that means, but you >> pretend not to. > > And yet, the behaviour I have observed is nothing remarkable: some > undefined bit patterns get used; zero is assumed; or code is just elided. > That's the fun of UB - the compiler can do anything it wants, including what the programmer thought the code meant. (And compilers try to do that in many cases, unless that conflicts with making more efficient runtime code when UB is not executed.) You can't determine that a piece of code is free of UB by compiling it and doing some successful tests. Testing can reveal the presence of bugs, not their absence. > Again, do you have any real-life, practical examples of bad or unusual > things happening? > For the case of trying to read uninitialised variables? I think it is fairly unlikely to have very bad effects, other than fail to give the programmer the results they expected. You might get code that has an uninitialised bool to execute code that is conditional on it being true, and also code that is conditional on it being false. A more likely scenario is the code acts oddly and gives strange results depending on the circumstances when it is called and what happens to lie in particular registers or uninitialised stack memory. More serious problems occur when compilers - correctly - optimise on the assumption that UB does not occur and the programmer has - incorrectly - written tests or checks that depend on their imagined semantics for the code. > If you had to put money on whether some outcode is either one of those > three I listed, or something else, which would you go for? > > >
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-04-23 10:42 -0400 |
| Message-ID | <10sdb5h$2mkm2$2@dont-email.me> |
| In reply to | #397837 |
On 23/04/2026 11:58, Bart wrote: ... > Are you suggesting that because something is tagged as UB, that it > literally gives a compiler a licence to do anything? "behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this document imposes no requirements." (3.5.3p1). What exactly do you think "no requirements" means? What could it possibly mean other than "license to do anything"?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-04-23 16:30 +0100 |
| Message-ID | <10sddv7$34el0$1@dont-email.me> |
| In reply to | #397859 |
On 23/04/2026 15:42, James Kuyper wrote: > On 23/04/2026 11:58, Bart wrote: > ... >> Are you suggesting that because something is tagged as UB, that it >> literally gives a compiler a licence to do anything? > "behavior, upon use of a nonportable or erroneous program construct or > of erroneous data, for which this document imposes no requirements." > (3.5.3p1). > > What exactly do you think "no requirements" means? What could it > possibly mean other than "license to do anything"? So the effect is that the compiler can be 'lax' in being able to do what it likes, including not reporting it and not refusing to fail te program. KT said: "the compiler is not being lax". I was responding to that. If it is not being lax, then I'd like to what 'being lax' would look like for this compiler.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-04-23 09:21 -0700 |
| Message-ID | <865x5h4phd.fsf@linuxsc.com> |
| In reply to | #397865 |
Bart <bc@freeuk.com> writes: > On 23/04/2026 15:42, James Kuyper wrote: > >> On 23/04/2026 11:58, Bart wrote: >> ... >> >>> Are you suggesting that because something is tagged as UB, that it >>> literally gives a compiler a licence to do anything? >> >> "behavior, upon use of a nonportable or erroneous program construct or >> of erroneous data, for which this document imposes no requirements." >> (3.5.3p1). >> >> What exactly do you think "no requirements" means? What could it >> possibly mean other than "license to do anything"? > > So the effect is that the compiler can be 'lax' in being able to do > what it likes, including not reporting it and not refusing to fail te > program. > > KT said: "the compiler is not being lax". I was responding to that. > > If it is not being lax, then I'd like to what 'being lax' would look > like for this compiler. What "being lax" means, for any compiler and not just this one, is not being faithful to what the C standard requires of a conforming implementation.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-04-23 17:27 +0100 |
| Message-ID | <10sdha6$35moe$1@dont-email.me> |
| In reply to | #397868 |
On 23/04/2026 17:21, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 23/04/2026 15:42, James Kuyper wrote:
>>
>>> On 23/04/2026 11:58, Bart wrote:
>>> ...
>>>
>>>> Are you suggesting that because something is tagged as UB, that it
>>>> literally gives a compiler a licence to do anything?
>>>
>>> "behavior, upon use of a nonportable or erroneous program construct or
>>> of erroneous data, for which this document imposes no requirements."
>>> (3.5.3p1).
>>>
>>> What exactly do you think "no requirements" means? What could it
>>> possibly mean other than "license to do anything"?
>>
>> So the effect is that the compiler can be 'lax' in being able to do
>> what it likes, including not reporting it and not refusing to fail te
>> program.
>>
>> KT said: "the compiler is not being lax". I was responding to that.
>>
>> If it is not being lax, then I'd like to what 'being lax' would look
>> like for this compiler.
>
> What "being lax" means, for any compiler and not just this one,
> is not being faithful to what the C standard requires of a
> conforming implementation.
So the buck passes to the language being lax.
I tried running the 'a = b' with a, b unitialised, under Go. But that
language states that uninitialised variables are simply zeroed.
Still, that means that this is a valid program that compiles and runs:
var a int
var b int
a = b
fmt.Printf("%d\n", a);
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-04-25 14:19 -0700 |
| Message-ID | <86jytu3fh5.fsf@linuxsc.com> |
| In reply to | #397869 |
Bart <bc@freeuk.com> writes: > On 23/04/2026 17:21, Tim Rentsch wrote: > >> Bart <bc@freeuk.com> writes: >> >>> On 23/04/2026 15:42, James Kuyper wrote: >>> >>>> On 23/04/2026 11:58, Bart wrote: >>>> ... >>>> >>>>> Are you suggesting that because something is tagged as UB, that it >>>>> literally gives a compiler a licence to do anything? >>>> >>>> "behavior, upon use of a nonportable or erroneous program construct or >>>> of erroneous data, for which this document imposes no requirements." >>>> (3.5.3p1). >>>> >>>> What exactly do you think "no requirements" means? What could it >>>> possibly mean other than "license to do anything"? >>> >>> So the effect is that the compiler can be 'lax' in being able to do >>> what it likes, including not reporting it and not refusing to fail te >>> program. >>> >>> KT said: "the compiler is not being lax". I was responding to that. >>> >>> If it is not being lax, then I'd like to what 'being lax' would look >>> like for this compiler. >> >> What "being lax" means, for any compiler and not just this one, >> is not being faithful to what the C standard requires of a >> conforming implementation. > > So the buck passes to the language being lax. It seems that when you say "being lax" what you mean is a behavior that is either something you don't expect or something you don't like. Probably most people have a different understanding about that.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-23 17:25 -0700 |
| Message-ID | <10sedal$3dgcd$3@kst.eternal-september.org> |
| In reply to | #397865 |
Bart <bc@freeuk.com> writes:
> On 23/04/2026 15:42, James Kuyper wrote:
>> On 23/04/2026 11:58, Bart wrote:
>> ...
>>> Are you suggesting that because something is tagged as UB, that it
>>> literally gives a compiler a licence to do anything?
>> "behavior, upon use of a nonportable or erroneous program construct or
>> of erroneous data, for which this document imposes no requirements."
>> (3.5.3p1).
>> What exactly do you think "no requirements" means? What could it
>> possibly mean other than "license to do anything"?
>
> So the effect is that the compiler can be 'lax' in being able to do
> what it likes, including not reporting it and not refusing to fail te
> program.
Yes, that's exactly what it means! Dare we hope that you actually
understand?
> KT said: "the compiler is not being lax". I was responding to that.
>
> If it is not being lax, then I'd like to what 'being lax' would look
> like for this compiler.
The word "lax" is vague enough that you and I will likely never
agree on whether C or gcc is "lax" or not. I suggest we don't try.
(There are features of C that I personally dislike, and I might
call them "lax", but I don't wish to start another argument by
going into specifics.)
If gcc encounters something like `i = i++ + ++i;` in code that
will always be executed, the standard imposes no requirements on
the treatment of that code. No diagnostic is required. The code
can be rejected at compile time, or it can crash at run time, or
it can quietly store any arbitrary value in i, or it can reformat
your hard drive (the latter is unlikely in practice).
#include <stdjoke.h>
It can even make demons fly out of your nose.
None of these violate the C standard.
Do you understand that that's what the C standard says?
No need to repeat that you hate it. We all know that. Do you
understand that that's what the C standard says?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-04-23 21:17 -0400 |
| Message-ID | <10segaf$3e0le$1@dont-email.me> |
| In reply to | #397865 |
Bart <bc@freeuk.com> writes: > On 23/04/2026 15:42, James Kuyper wrote: >> On 23/04/2026 11:58, Bart wrote: >> ... >>> Are you suggesting that because something is tagged as UB, that it >>> literally gives a compiler a licence to do anything? >> "behavior, upon use of a nonportable or erroneous program construct or >> of erroneous data, for which this document imposes no requirements." >> (3.5.3p1). >> What exactly do you think "no requirements" means? What could it >> possibly mean other than "license to do anything"? > > So the effect is that the compiler can be 'lax' in being able to do > what it likes, including not reporting it and not refusing to fail te > program. . > KT said: "the compiler is not being lax". I was responding to that. > > If it is not being lax, then I'd like to what 'being lax' would look > like for this compiler. In this context, I would call a compiler lax if it failed to meet requirements. When there are no requirements, how can a compiler fail to meet them? The basic rule of undefined behavior is that when you write such code, you are asking the implementation to do whatever it wants to do. In general, that's a mistake. However, if you know what the implementation wants to do with such code, and it's also what you want the code to do, and you don't need your code to be portable to other implementations, then there's nothing wrong with such code. For instance, the thing that renders the behavior undefined might be a syntax error that, on this implementation, triggers the use of an extension. If you write code relying upon that extension, there's no problem, so long as your code needn't be portable to implementations that don't support that extension.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-04-23 14:08 -0700 |
| Message-ID | <10se1pa$3b5kb$2@dont-email.me> |
| In reply to | #397837 |
On 4/23/2026 2:58 AM, Bart wrote: > On 23/04/2026 02:59, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >>>> Bart <bc@freeuk.com> writes: >> [...] >>>>> So, what does language say about it again? Remind me! Or better, tell >>>>> the compiler. >>>> I've already told you what the language says about it. I quoted >>>> the section of the ISO C standard that says explicitly that the >>>> behavior is undefined. N3220 6.3.2.1p2, last sentence. >>>> The compiler's behavior is consistent with that requirment. >>>> You cannot possibly have forgotten this. Why do you pretend? >>> >>> Nobody seems to have a problem with gcc being lax about this (or with >>> it allowing its users to let it be lax). >> >> gcc is not being lax. gcc is behaving in a matter that is consistent >> with the requirements of the C standard. The code in question has >> undefined behavior. > >> You know and understand all of that. > > No, I don't. > > So what is the concrete effect of all that on the behaviour of gcc and > the behaviour of the code it generates? > > If something bad happens (what would that be exactly), whose fault would >  that, mine or the compiler's? > > Are you suggesting that because something is tagged as UB, that it > literally gives a compiler a licence to do anything? > > If so, how is that not being lax by either language, compiler, or both? > > I'm starting to suspect that either nobody knows the answer, or they do, > but are chary of either blaming the compiler or criticising the language > spec, and are trying to shift the blame to the user. > > > >> The behavior is undefined. You know exactly what that means, but you >> pretend not to. > > And yet, the behaviour I have observed is nothing remarkable: some > undefined bit patterns get used; zero is assumed; or code is just elided. > > Again, do you have any real-life, practical examples of bad or unusual > things happening? > > If you had to put money on whether some outcode is either one of those > three I listed, or something else, which would you go for? > > > Do you think that NULL must be 0? Keep in mind, NULL can be 0xDEADBEEF if a platform deemed it that way.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-04-23 23:18 +0100 |
| Message-ID | <10se5r1$3c90c$1@dont-email.me> |
| In reply to | #397881 |
On 23/04/2026 22:08, Chris M. Thomasson wrote: > On 4/23/2026 2:58 AM, Bart wrote: >> On 23/04/2026 02:59, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >>>>> Bart <bc@freeuk.com> writes: >>> [...] >>>>>> So, what does language say about it again? Remind me! Or better, tell >>>>>> the compiler. >>>>> I've already told you what the language says about it. I quoted >>>>> the section of the ISO C standard that says explicitly that the >>>>> behavior is undefined. N3220 6.3.2.1p2, last sentence. >>>>> The compiler's behavior is consistent with that requirment. >>>>> You cannot possibly have forgotten this. Why do you pretend? >>>> >>>> Nobody seems to have a problem with gcc being lax about this (or with >>>> it allowing its users to let it be lax). >>> >>> gcc is not being lax. gcc is behaving in a matter that is consistent >>> with the requirements of the C standard. The code in question has >>> undefined behavior. >> >>> You know and understand all of that. >> >> No, I don't. >> >> So what is the concrete effect of all that on the behaviour of gcc and >> the behaviour of the code it generates? >> >> If something bad happens (what would that be exactly), whose fault >> would   that, mine or the compiler's? >> >> Are you suggesting that because something is tagged as UB, that it >> literally gives a compiler a licence to do anything? >> >> If so, how is that not being lax by either language, compiler, or both? >> >> I'm starting to suspect that either nobody knows the answer, or they >> do, but are chary of either blaming the compiler or criticising the >> language spec, and are trying to shift the blame to the user. >> >> >> >>> The behavior is undefined. You know exactly what that means, but you >>> pretend not to. >> >> And yet, the behaviour I have observed is nothing remarkable: some >> undefined bit patterns get used; zero is assumed; or code is just elided. >> >> Again, do you have any real-life, practical examples of bad or unusual >> things happening? >> >> If you had to put money on whether some outcode is either one of those >> three I listed, or something else, which would you go for? >> >> >> > > Do you think that NULL must be 0? Keep in mind, NULL can be 0xDEADBEEF > if a platform deemed it that way. Let me put in another way: suppose you had a struct with dozens of members including nested structs. Members have types including integers, floats and pointers. You want to quickly clear a struct index X so that all ints are 0, floats are 0.0 and pointers are NULL. Would you simply do 'memset(&X, 0, sizeof(X))' or would you painstakingly initialise each member one by one?
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-24 01:31 +0200 |
| Message-ID | <10sea4p$2b5i9$11@dont-email.me> |
| In reply to | #397882 |
On 2026-04-24 00:18, Bart wrote: > On 23/04/2026 22:08, Chris M. Thomasson wrote: >> >> Do you think that NULL must be 0? Keep in mind, NULL can be 0xDEADBEEF >> if a platform deemed it that way. > > Let me put in another way: suppose you had a struct with dozens of > members including nested structs. > > Members have types including integers, floats and pointers. > > You want to quickly clear a struct index X so that all ints are 0, > floats are 0.0 and pointers are NULL. > > Would you simply do 'memset(&X, 0, sizeof(X))' or would you > painstakingly initialise each member one by one? Neither. (At least not by individual assignments one by one.) You've seen by Chris' sample that you cannot rely on NULL being represented by an _integer value_ 0. So you should know already that you cannot initialize a "semantic" (higher-level) complex object by a low-level function; at least I would *not* expect that your 'memset' approach would be a valid solution that fits your intention. - My approach would be to use an initializer list, where the compiler could associate the correct values to the respective types, including the 0 as generic pointer value for "C" pointers to be correctly "translated" (to 0xdeadbeef or whatever it might be on one platform or the other). (Note that the compiler might optimize that in efficient ways anyway, no need to "optimize" by using an inappropriate wrong approach.) Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-23 17:51 -0700 |
| Message-ID | <10seeq1$3dgcd$4@kst.eternal-september.org> |
| In reply to | #397882 |
Bart <bc@freeuk.com> writes:
> On 23/04/2026 22:08, Chris M. Thomasson wrote:
[...]
>> Do you think that NULL must be 0? Keep in mind, NULL can be
>> 0xDEADBEEF if a platform deemed it that way.
An integer constant expression with the value 0 is by definition a
null pointer constant. Converting such an expression to a pointer
type yields a null pointer. The representation of a null pointer
is *typically* all-bits-zero, but can in principle be anything.
`ptr = 0;` stores a null pointer in ptr, however it's represented.
> Let me put in another way: suppose you had a struct with dozens of
> members including nested structs.
>
> Members have types including integers, floats and pointers.
>
> You want to quickly clear a struct index X so that all ints are 0,
> floats are 0.0 and pointers are NULL.
>
> Would you simply do 'memset(&X, 0, sizeof(X))' or would you
> painstakingly initialise each member one by one?
To initialize it to logical zero, I'd write:
struct index X = {0};
or possibly
struct index X = {};
if I can rely on C23 support.
To zero the structure after initialization I'd write:
X = (struct index){0};
(possibly omitting the 0 if I can rely on C23 support). This assumes
at least C99 support, which is a reasonable assumption these days.
I *might* resort to memset() in some circumstances (none that I
can think of off the top of my head, but it's plausible), but I'd
probably add a comment pointing out the caveats.
There might be other circumstances in which it's advantageous
to assume that null pointers are represented as all-bits-zero.
I'd be willing to rely on that assumption, but I'd document it.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-04-24 18:19 -0700 |
| Message-ID | <10sh4r6$ge59$1@dont-email.me> |
| In reply to | #397892 |
On 4/23/2026 5:51 PM, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 23/04/2026 22:08, Chris M. Thomasson wrote:
> [...]
>>> Do you think that NULL must be 0? Keep in mind, NULL can be
>>> 0xDEADBEEF if a platform deemed it that way.
>
> An integer constant expression with the value 0 is by definition a
> null pointer constant. Converting such an expression to a pointer
> type yields a null pointer. The representation of a null pointer
> is *typically* all-bits-zero, but can in principle be anything.
> `ptr = 0;` stores a null pointer in ptr, however it's represented.
>
>> Let me put in another way: suppose you had a struct with dozens of
>> members including nested structs.
>>
>> Members have types including integers, floats and pointers.
>>
>> You want to quickly clear a struct index X so that all ints are 0,
>> floats are 0.0 and pointers are NULL.
>>
>> Would you simply do 'memset(&X, 0, sizeof(X))' or would you
>> painstakingly initialise each member one by one?
>
> To initialize it to logical zero, I'd write:
> struct index X = {0};
> or possibly
> struct index X = {};
> if I can rely on C23 support.
>
> To zero the structure after initialization I'd write:
> X = (struct index){0};
> (possibly omitting the 0 if I can rely on C23 support). This assumes
> at least C99 support, which is a reasonable assumption these days.
>
> I *might* resort to memset() in some circumstances (none that I
> can think of off the top of my head, but it's plausible), but I'd
> probably add a comment pointing out the caveats.
>
> There might be other circumstances in which it's advantageous
> to assume that null pointers are represented as all-bits-zero.
> I'd be willing to rely on that assumption, but I'd document it.
>
Under the covers, 0 = whatewver_the_platform_deems_as _null?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-04-23 21:34 -0400 |
| Message-ID | <10sehaa$3e0ld$1@dont-email.me> |
| In reply to | #397882 |
On 23/04/2026 22:08, Chris M. Thomasson wrote: [...] > Do you think that NULL must be 0? Keep in mind, NULL can be > 0xDEADBEEF if a platform deemed it that way. "An integer constant expression with the value 0, such an expression cast to type void *, or the predefined constant nullptr is called a null pointer constant." (6.3.3.3p3) NULL is required to expand to a null pointer constant (7.22.1p4). 0xDEADBEEF doesn't have a value of 0, contains no cast, and is not nullptr. Therefore, it doesn't qualify. I suspect you're thinking of something that must be described somewhat differently than what you said. When a null pointer constant appears in certain contexts, it gets converted to a null pointer. A null pointer (as opposed to a null pointer constant) may have a representation that does not have all bits 0. However, if NULL is an integer expression, that expression must have a value of 0, though the manner in which it obtains that value can be as complicated as you wish. It could, for instance, be (0xDEADBEEF - 033653337357).
[toc] | [prev] | [next] | [standalone]
Page 9 of 19 — ← Prev page 1 … 7 8 [9] 10 11 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web