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 11 of 19 — ← Prev page 1 … 9 10 [11] 12 13 … 19 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-25 17:14 -0700 |
| Message-ID | <10sjldl$1668o$8@kst.eternal-september.org> |
| In reply to | #397958 |
Michael S <already5chosen@yahoo.com> writes:
> On Sat, 25 Apr 2026 15:49:03 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Michael S <already5chosen@yahoo.com> writes:
[...]
>> > The following will also work just about everywhere, but it is UB
>> > according to the standard.
>> > uintptr_t u=0;
>> > P = *(void**)&u;
>>
>> Alignment issues could cause problems. Try that on a DS9000 and
>> literal demons will fly out of your nose.
>
> I don't know what is DS9000.
The DeathStation 9000, known to its friends as the DS9K, is a
mythical computer system from the earlier days of this newsgroup.
The name is, I think, a combination of "Death Star", "Workstation"
or perhaps "SPARCstation", and "HAL 9000".
Its C implementation is fully conforming and maximally perverse.
Evaluating `i=i++` reformats your hard drive. `malloc(0)` can
behave as if the size were some nonzero value; on the DS9K that
value is SIZE_MAX. qsort() is O(N factorial). So is bsearch().
So is putchar(). A straightforward iterative implementation of
the fibonacci function is "optimized" to a fully recursive version.
rand() always returns 4 (or 0 if called within 17.3 seconds of a full
Phobos as seen from Olympus Mons). CHAR_BIT is 41. sizeof (void*)
is 1. sizeof (int*) is 1023. Valid file names must contain at
least one occurrence of the character U+12120, CUNEIFORM SIGN GUD
TIMES KUR, represented in UTF-EBCDIC. `printf("%p\n", (void*)NULL)`
prints what appears to be the full system documentation to stdout,
but riddled with subtle factual errors.
Except on Tuesday.
--
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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-26 04:34 +0200 |
| Message-ID | <10sjtk1$3knhv$2@dont-email.me> |
| In reply to | #397961 |
On 2026-04-26 02:14, Keith Thompson wrote:
> Michael S <already5chosen@yahoo.com> writes:
>>
>> I don't know what is DS9000.
>
> The DeathStation 9000, known to its friends as the DS9K, is a
> mythical computer system from the earlier days of this newsgroup.
> The name is, I think, a combination of "Death Star", "Workstation"
> or perhaps "SPARCstation", and "HAL 9000".
>
> Its C implementation is fully conforming and maximally perverse.
> Evaluating `i=i++` reformats your hard drive. `malloc(0)` can
> behave as if the size were some nonzero value; on the DS9K that
> value is SIZE_MAX. qsort() is O(N factorial). So is bsearch().
> So is putchar(). A straightforward iterative implementation of
> the fibonacci function is "optimized" to a fully recursive version.
> rand() always returns 4 (or 0 if called within 17.3 seconds of a full
> Phobos as seen from Olympus Mons). CHAR_BIT is 41. sizeof (void*)
> is 1. sizeof (int*) is 1023. Valid file names must contain at
> least one occurrence of the character U+12120, CUNEIFORM SIGN GUD
> TIMES KUR, represented in UTF-EBCDIC. `printf("%p\n", (void*)NULL)`
> prints what appears to be the full system documentation to stdout,
> but riddled with subtle factual errors.
>
> Except on Tuesday.
LOL - great!
Now I understand why some folks here are so picky about certain
constructs where other folks expect (and factually observed) no
issues. :-)
Janis
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-04-25 18:08 -0700 |
| Message-ID | <10sjoi1$193fl$1@dont-email.me> |
| In reply to | #397948 |
On 4/25/2026 2:48 PM, Michael S wrote: [...] memcpy for dx12 buffers? ;^)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-04-25 17:20 -0700 |
| Message-ID | <86bjf6373z.fsf@linuxsc.com> |
| In reply to | #397947 |
Bart <bc@freeuk.com> writes:
> On 25/04/2026 21:52, Tim Rentsch wrote:
>
>> Bart <bc@freeuk.com> writes:
>>
>>>> [..questions about NULL == 0 ...]
>>>
>>> I expect that type matching would require both sides to be
>>> pointers. Then the '0' is presumably converted to whatever pattern is
>>> used for NULL.
>>>
>>> Although I always found it odd that, if P has a pointer type, then 'P
>>> = 0' is fine, but not 'P = 42'.
>>
>> Do you also find it odd that 'P = 0' is fine, but 'P = 0.0' is not?
>
> No, because a RHS of 0.0, 1.0, 2.0, 3.7 ... are all treated consistently.
>
> But when the RHS is an integer, then of all the possible integer
> values, 0 is a special case.
If P is a variable having pointer type, what do you think these
two statements are supposed to do?
P = !1;
P = !1.0;
Notice that in both cases the value of the right hand side is
an integer with a value of 0.
>>> Also, suppose you did want to assign actual address 0x0000000 to P
>>> using 'P = (T*)0'; what would happen here if NULL was non-zero?
>>
>> Assuming a declaration 'T *P;', do you really not know what
>> happens for a statement 'P = (T*)0;'?
>
> Usually nothing happens, because a null pointer value and an address
> of zero have the same bit-pattern.
>
> That's why I'm asking what happens when they don't: does it assume
> this is assigning a NULL (which needs to be 0x80000000 say), or some
> actual address of 0x00000000?
It sounds like you're confusing a compile-time notion and a
run-time notion. The symbol NULL is a compile-time construct,
either simply 0 (or equivalent), or (void*)0 (or equivalent).
Either expression, when evaluated at run-time, produces a bit
pattern that is a null pointer. Note, a null pointer, not a NULL
pointer. The identifier NULL is a purely compile-time notion,
and is a noun, not an adjective. The word 'null' is an adjective
modifying 'pointer', and indicates a run-time value that doesn't
point anywhere (sometimes this is said as "not the same as a
pointer to any object).
Note also that null pointers don't have to all use the same bit
pattern. On a 64-bit machine, an implementation could choose to
designate any bit pattern where the top two bits are different as
being a null pointer. Making this choice would have implications
for how pointer values are compared, but just in terms of the
bit-level representation it is workable, even if not especially
practical.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-04-26 01:47 +0100 |
| Message-ID | <10sjnba$18n5c$1@dont-email.me> |
| In reply to | #397963 |
On 26/04/2026 01:20, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 25/04/2026 21:52, Tim Rentsch wrote:
>>
>>> Bart <bc@freeuk.com> writes:
>>>
>>>>> [..questions about NULL == 0 ...]
>>>>
>>>> I expect that type matching would require both sides to be
>>>> pointers. Then the '0' is presumably converted to whatever pattern is
>>>> used for NULL.
>>>>
>>>> Although I always found it odd that, if P has a pointer type, then 'P
>>>> = 0' is fine, but not 'P = 42'.
>>>
>>> Do you also find it odd that 'P = 0' is fine, but 'P = 0.0' is not?
>>
>> No, because a RHS of 0.0, 1.0, 2.0, 3.7 ... are all treated consistently.
>>
>> But when the RHS is an integer, then of all the possible integer
>> values, 0 is a special case.
>
> If P is a variable having pointer type, what do you think these
> two statements are supposed to do?
>
> P = !1;
> P = !1.0;
>
> Notice that in both cases the value of the right hand side is
> an integer with a value of 0.
If the RHS reduces to a compile-time constant, then the same applies:
P = 42*2 - 12*7;
After taking such reductions into account, then '0' is still a special case.
>
>>>> Also, suppose you did want to assign actual address 0x0000000 to P
>>>> using 'P = (T*)0'; what would happen here if NULL was non-zero?
>>>
>>> Assuming a declaration 'T *P;', do you really not know what
>>> happens for a statement 'P = (T*)0;'?
>>
>> Usually nothing happens, because a null pointer value and an address
>> of zero have the same bit-pattern.
>>
>> That's why I'm asking what happens when they don't: does it assume
>> this is assigning a NULL (which needs to be 0x80000000 say), or some
>> actual address of 0x00000000?
>
> It sounds like you're confusing a compile-time notion and a
> run-time notion. The symbol NULL is a compile-time construct,
> either simply 0 (or equivalent), or (void*)0 (or equivalent).
> Either expression, when evaluated at run-time, produces a bit
> pattern that is a null pointer. Note, a null pointer, not a NULL
> pointer. The identifier NULL is a purely compile-time notion,
> and is a noun, not an adjective. The word 'null' is an adjective
> modifying 'pointer', and indicates a run-time value that doesn't
> point anywhere (sometimes this is said as "not the same as a
> pointer to any object).
>
> Note also that null pointers don't have to all use the same bit
> pattern. On a 64-bit machine, an implementation could choose to
> designate any bit pattern where the top two bits are different as
> being a null pointer. Making this choice would have implications
> for how pointer values are compared, but just in terms of the
> bit-level representation it is workable, even if not especially
> practical.
That's nothing new for x86 segmented mode, where there can be multiple
representations for the same address anyway.
The answer I guess was to strive for normalised representations.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-25 18:40 -0700 |
| Message-ID | <10sjqdt$19c5j$3@kst.eternal-september.org> |
| In reply to | #397963 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> It sounds like you're confusing a compile-time notion and a
> run-time notion. The symbol NULL is a compile-time construct,
> either simply 0 (or equivalent), or (void*)0 (or equivalent).
A small quibble, not relevant to the current discussion: (void*)0
is a null pointer constant, but not a valid expansion of NULL.
The expansion of NULL must be fully protected by parentheses, so
((void*)0) is a valid expansion.
One might also quibble about the meaning of "or equivalent".
0LL would not normally be considered equivalent to 0, but both are
valid NPCs and valid expansions of NULL.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-04-25 19:58 -0700 |
| Message-ID | <867bpu2zse.fsf@linuxsc.com> |
| In reply to | #397969 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > [...] > >> It sounds like you're confusing a compile-time notion and a >> run-time notion. The symbol NULL is a compile-time construct, >> either simply 0 (or equivalent), or (void*)0 (or equivalent). > > A small quibble, not relevant to the current discussion: (void*)0 > is a null pointer constant, but not a valid expansion of NULL. > The expansion of NULL must be fully protected by parentheses, so > ((void*)0) is a valid expansion. > > One might also quibble about the meaning of "or equivalent". > 0LL would not normally be considered equivalent to 0, but both are > valid NPCs and valid expansions of NULL. The point of saying "or equivalent" is to avoid such quibbling.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-25 15:39 -0700 |
| Message-ID | <10sjfrb$1668o$4@kst.eternal-september.org> |
| In reply to | #397943 |
Bart <bc@freeuk.com> writes:
> On 25/04/2026 20:00, Chris M. Thomasson wrote:
[...]
>> NULL == 0 is true
>> Even if NULL could be a strange code, non-zero. Does that boil it
>> down, or what did I miss here?
>
> I expect that type matching would require both sides to be
> pointers. Then the '0' is presumably converted to whatever pattern is
> used for NULL.
There's no need to speculate about things that are clearly specified in
the C standard. If you don't care about what the standard says, you can
sit back and let others answer.
> Although I always found it odd that, if P has a pointer type, then 'P
> = 0' is fine, but not 'P = 42'.
I don't disagree with it being odd, but the rules for simple assignment
treat a null pointer constant on the RHS as a special case. 0 is a null
pointer constant. 42 is not. (N3220 6.5.17.2 for anyone who's interested.)
> Also, suppose you did want to assign actual address 0x0000000 to P
> using 'P = (T*)0'; what would happen here if NULL was non-zero?
That would assign a null pointer value to P, regardless of how that's
represented, because 0 is a null pointer constant, and the conversion
to the pointer type T* yields a runtime null pointer value.
I honestly don't know whether you would or would not have been able
to figure that out yourself.
If (for some reason) you want to set P to all-bits-zero in a way that
works even if a null pointer is not represented as all-bits-zero,
you can use memset().
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-04-26 00:53 +0100 |
| Message-ID | <10sjk57$16eah$1@dont-email.me> |
| In reply to | #397952 |
On 25/04/2026 23:39, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 25/04/2026 20:00, Chris M. Thomasson wrote:
> [...]
>>> NULL == 0 is true
>>> Even if NULL could be a strange code, non-zero. Does that boil it
>>> down, or what did I miss here?
>>
>> I expect that type matching would require both sides to be
>> pointers. Then the '0' is presumably converted to whatever pattern is
>> used for NULL.
>
> There's no need to speculate about things that are clearly specified in
> the C standard. If you don't care about what the standard says, you can
> sit back and let others answer.
So, what's the answer?
> That would assign a null pointer value to P, regardless of how that's
> represented, because 0 is a null pointer constant, and the conversion
> to the pointer type T* yields a runtime null pointer value.
>
> I honestly don't know whether you would or would not have been able
> to figure that out yourself.
It is not obvious. Take these examples, on a system where NULL has the
underlying value 0x12345678:
char* p;
long long int a = 0, b = 1, c = 2;
p = 0;
p = 1;
p = 2;
p = a;
p = b;
p = c;
p = (char*) a;
p = (char*) b;
p = (char*) c;
Of the first group, only the zero is valid, and is converted internally
to 0x1234567.
None of the second group is valid.
All of the third group are valid: b and c presumably result in a value
of 0x00000001 and 0x00000002 respectively.
But what happens to to the value of 'a'? I assume that that results in
0x00000000 being assigned, without conversion to 0x12345678. Otherwise
every such assignment would need to be conditional at runtime.
If that is correct then:
{enum x = 0};
int y = 0;
p = (T*)x;
p = (T*)y;
will do different things when NULL is not all-bits zero internally, even
when both x and y are zero.
I consider this a quirk, and possibly a gotcha (if using your DS9000,
but then probably everything is on that).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-25 18:27 -0700 |
| Message-ID | <10sjpm4$19c5j$1@kst.eternal-september.org> |
| In reply to | #397959 |
Bart <bc@freeuk.com> writes:
> On 25/04/2026 23:39, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 25/04/2026 20:00, Chris M. Thomasson wrote:
>> [...]
>>>> NULL == 0 is true
>>>> Even if NULL could be a strange code, non-zero. Does that boil it
>>>> down, or what did I miss here?
>>>
>>> I expect that type matching would require both sides to be
>>> pointers. Then the '0' is presumably converted to whatever pattern is
>>> used for NULL.
>>
>> There's no need to speculate about things that are clearly specified
>> in the C standard. If you don't care about what the standard says,
>> you can sit back and let others answer.
>
> So, what's the answer?
I'm going to pretend that you're actually interested in knowing the
answer. I don't believe you are, but someone else might be.
In `NULL == 0`, NULL expands to a null pointer constant, which can
be of type void*, of some integer type, or of type nullptr_t in C23.
The RHS is a null pointer constant.
If NULL is of type void*, the operands compare equal and the result
is 1. The standard does not specify a conversion in this case.
If NULL is of some integer type, 0 is promoted from int to the
type of NULL if necessary, or NULL is promoted to int if necessary,
or no promotion is necessary if NULL is of type int. The operands
compare equal and the result is 1.
If NULL is of type nullptr_t, it's a comparison between an operand
of type nullptr_t and a null pointer constant. The operands compare
equal and the result is 1.
We already know you think this is too complicated. No need to say
it again.
>> That would assign a null pointer value to P, regardless of how that's
>> represented, because 0 is a null pointer constant, and the conversion
>> to the pointer type T* yields a runtime null pointer value.
>> I honestly don't know whether you would or would not have been able
>> to figure that out yourself.
>
> It is not obvious.
I didn't say it was obvious. I said that it's clearly specified in the
C standard.
The fact that NULL == 0 yields 1 is easily inferred from the
underlying principles on which the rules in the C standard
are implicitly based. In that sense, I consider it "obvoius",
but others might not. Demonstrating that it's true in all cases
requires a little work, which I've done above.
> Take these examples, on a system where NULL has the
> underlying value 0x12345678:
>
> char* p;
> long long int a = 0, b = 1, c = 2;
>
> p = 0;
> p = 1;
> p = 2;
>
> p = a;
> p = b;
> p = c;
>
> p = (char*) a;
> p = (char*) b;
> p = (char*) c;
>
> Of the first group, only the zero is valid, and is converted
> internally to 0x1234567.
Apparently you're using 0x1234567, which is a constant of some integer
type, to refer to the representation of a null pointer value.
I'm not sure just what you mean by "valid". `p = 0;` stores a null
pointer value in p. `p = 1;` and `p = 2;` are constraint violations.
> None of the second group is valid.
All three assignments in the second group are constraint violations.
> All of the third group are valid: b and c presumably result in a value
> of 0x00000001 and 0x00000002 respectively.
None of the assignments in the third group violate any constraint or
syntax rule. None of them have well defined behavior. (I haven't
bothered to track down whether the behavior is undefined,
implementation-defined, or unspecified.)
> But what happens to to the value of 'a'? I assume that that results in
> 0x00000000 being assigned, without conversion to 0x12345678. Otherwise
> every such assignment would need to be conditional at runtime.
Your assumption is not supported by the standard, though it's the most
likely behavior in practice.
The value of `a` is converted from long long int to char*; "the
result is implementation-defined, may not be correctly aligned, may
not point to an entity of the referenced type, and can produce an
indeterminate representation when stored into an object." A footnote
says that "The mapping functions for converting a pointer to an
integer or an integer to a pointer are intended to be consistent
with the addressing structure of the execution environment."
I don't know why you think such assignments would need to be conditional
at runtime. Perhaps if you explained your goal in converting the value
of a to a pointer type, we could help with code to achieve that goal.
The thing that you seem to find odd is that, when dealing with pointers,
an integer constant expression with the value 0 is treated specially,
but a non-constant integer expression with the value is 0 is not.
> If that is correct then:
>
> {enum x = 0};
> int y = 0;
>
> p = (T*)x;
> p = (T*)y;
>
> will do different things when NULL is not all-bits zero internally,
> even when both x and y are zero.
They may or may not do different things. If a null pointer value
is not represented as all-bits-zero, a conversion of a non-constant
0 value to a pointer type yields an implementation-defined result,
and that result could still be a null pointer value. (I have no
opinion on what it *should* be.)
> I consider this a quirk, and possibly a gotcha (if using your DS9000,
> but then probably everything is on that).
It's the way the language is defined.
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-04-26 02:41 +0100 |
| Message-ID | <10sjqg6$19efs$1@dont-email.me> |
| In reply to | #397967 |
On 26/04/2026 02:27, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 25/04/2026 23:39, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >>>> On 25/04/2026 20:00, Chris M. Thomasson wrote: >>> [...] >>>>> NULL == 0 is true >>>>> Even if NULL could be a strange code, non-zero. Does that boil it >>>>> down, or what did I miss here? >>>> >>>> I expect that type matching would require both sides to be >>>> pointers. Then the '0' is presumably converted to whatever pattern is >>>> used for NULL. >>> >>> There's no need to speculate about things that are clearly specified >>> in the C standard. If you don't care about what the standard says, >>> you can sit back and let others answer. >> >> So, what's the answer? > > I'm going to pretend that you're actually interested in knowing the > answer. I don't believe you are, but someone else might be. > > In `NULL == 0`, NULL expands to a null pointer constant, which can > be of type void*, of some integer type, or of type nullptr_t in C23. > The RHS is a null pointer constant. Why would that follow. As it is, it is just an integer literal or constant of value 0. It is only the context of being on the RHS or == when the LHS is pointer-related, which makes it a pointer constant. But this is the part I'm getting at: the LHS could be anything, so what is the process? I suggested that the '0' is converted according to NULL, ie. the LHS. >> But what happens to to the value of 'a'? I assume that that results in >> 0x00000000 being assigned, without conversion to 0x12345678. Otherwise >> every such assignment would need to be conditional at runtime. > > Your assumption is not supported by the standard, though it's the most > likely behavior in practice. > > The value of `a` is converted from long long int to char*; "the > result is implementation-defined, may not be correctly aligned, may > not point to an entity of the referenced type, and can produce an > indeterminate representation when stored into an object." A footnote > says that "The mapping functions for converting a pointer to an > integer or an integer to a pointer are intended to be consistent > with the addressing structure of the execution environment." > > I don't know why you think such assignments would need to be conditional > at runtime. Perhaps if you explained your goal in converting the value > of a to a pointer type, we could help with code to achieve that goal. Because at runtime it doesn't know whether 'a' contains 0, which could be converted to address 0x12345678, or something else, which just reinterprets the bits (at least with normal linear address spaces).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-25 19:03 -0700 |
| Message-ID | <10sjrov$19c5j$4@kst.eternal-september.org> |
| In reply to | #397970 |
Bart <bc@freeuk.com> writes:
> On 26/04/2026 02:27, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 25/04/2026 23:39, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> On 25/04/2026 20:00, Chris M. Thomasson wrote:
>>>> [...]
>>>>>> NULL == 0 is true
>>>>>> Even if NULL could be a strange code, non-zero. Does that boil it
>>>>>> down, or what did I miss here?
>>>>>
>>>>> I expect that type matching would require both sides to be
>>>>> pointers. Then the '0' is presumably converted to whatever pattern is
>>>>> used for NULL.
>>>>
>>>> There's no need to speculate about things that are clearly specified
>>>> in the C standard. If you don't care about what the standard says,
>>>> you can sit back and let others answer.
>>>
>>> So, what's the answer?
>> I'm going to pretend that you're actually interested in knowing the
>> answer. I don't believe you are, but someone else might be.
>> In `NULL == 0`, NULL expands to a null pointer constant, which can
>> be of type void*, of some integer type, or of type nullptr_t in C23.
>
>> The RHS is a null pointer constant.
>
> Why would that follow. As it is, it is just an integer literal or
> constant of value 0. It is only the context of being on the RHS or ==
> when the LHS is pointer-related, which makes it a pointer constant.
The RHS is 0. 0 is a null pointer constant. It really is that simple.
The language defines the term "null pointer constant". The constant 0
is by definition a null pointer constant. Though it may seem odd,
0 is a null pointer constant regardless of the context in which it
appears.
int n = 0;
That 0 is a null pointer constant, but that fact has no effect on the
semantics of the declaration.
It's also an octal constant, BTW.
> But this is the part I'm getting at: the LHS could be anything, so
> what is the process?
No, the LHS is NULL, not "anything". I'm discussing the expression
`NULL == 0`, not some other expression what whatever arbitrary changes
you might imagine.
> I suggested that the '0' is converted according to NULL, ie. the LHS.
I don't even know what "converted according to NULL" is supposed
to mean. I described exactly what happens according to the rules
of the language. If your suggestion, or expectation, or whatever,
is inconsistent with my description, or if you didn't understand it,
feel free to ask a specific question.
>>> But what happens to to the value of 'a'? I assume that that results in
>>> 0x00000000 being assigned, without conversion to 0x12345678. Otherwise
>>> every such assignment would need to be conditional at runtime.
>> Your assumption is not supported by the standard, though it's the
>> most
>> likely behavior in practice.
>> The value of `a` is converted from long long int to char*; "the
>> result is implementation-defined, may not be correctly aligned, may
>> not point to an entity of the referenced type, and can produce an
>> indeterminate representation when stored into an object." A footnote
>> says that "The mapping functions for converting a pointer to an
>> integer or an integer to a pointer are intended to be consistent
>> with the addressing structure of the execution environment."
>> I don't know why you think such assignments would need to be
>> conditional
>> at runtime. Perhaps if you explained your goal in converting the value
>> of a to a pointer type, we could help with code to achieve that goal.
>
> Because at runtime it doesn't know whether 'a' contains 0, which could
> be converted to address 0x12345678, or something else, which just
> reinterprets the bits (at least with normal linear address spaces).
Are you assuming that a conversion of an integer value to a pointer
type must just reinterpret the bits except in the special case
of a null pointer constant? The standard does not support that
assumption. The result of such a conversion (other than an NPC)
is implementation-defined.
In every C implementation I'm aware of, a null pointer is represented
as all-bits-zero, and integer-to-pointer conversions (with the same
size) just reinterpret the bits.
Given a conforming implementation that represents a null pointer
as the equivalent of 0xdeadbeef, converting a constant integer 0
to a pointer type must yield a null pointer value. Converting a
non-constant integer 0 to a pointer type might yield a null
pointer, or it might yield a pointer value with an all-bits-zero
representation, or it might do anything else specified and documented
by the implementation.
It's possible that a compiler implementer might specifically want
a conversion of a constant or non-constant 0 to a pointer type to
yield a null pointer, and all other integer-to-pointer conversions to
reinterpret the bits. In that case, sure, some conditional runtime
code could be needed to achieve that. I'm guessing that's what you
had in mind, but you didn't quite say so -- and your assumption is
not supported by the language.
memset() is probably the safest way to store all-bits-zero in a
pointer object, but I'm not sure why you'd even want to do that.
Again, if you can explain precisely what you want to accomplish,
we can probably help you with C code that will do what you want.
If you can explain *why*, we might be able to offer more advice.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-25 19:08 -0700 |
| Message-ID | <10sjs27$19c5j$5@kst.eternal-september.org> |
| In reply to | #397971 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> The RHS is 0. 0 is a null pointer constant. It really is that simple.
>
> The language defines the term "null pointer constant". The constant 0
> is by definition a null pointer constant. Though it may seem odd,
> 0 is a null pointer constant regardless of the context in which it
> appears.
>
> int n = 0;
>
> That 0 is a null pointer constant, but that fact has no effect on the
> semantics of the declaration.
>
> It's also an octal constant, BTW.
[...]
And to be clear, the language *could* have defined the term "null
pointer constant" so that a constant 0 in a non-pointer context is
not a null pointer constant. That would have made the definition of
the term substantially more complicated, with no particular benefit
that I can think of. The fact that a "null pointer constant"
can appear in a non-pointer context is probably worth a raised
eyebrow the first time you encounter it, but it doesn't create any
real problems.
--
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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-26 05:04 +0200 |
| Message-ID | <10sjvcp$3knhv$3@dont-email.me> |
| In reply to | #397972 |
On 2026-04-26 04:08, Keith Thompson wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > [...] >> The RHS is 0. 0 is a null pointer constant. It really is that simple. >> >> The language defines the term "null pointer constant". The constant 0 >> is by definition a null pointer constant. Though it may seem odd, >> 0 is a null pointer constant regardless of the context in which it >> appears. >> >> int n = 0; >> >> That 0 is a null pointer constant, but that fact has no effect on the >> semantics of the declaration. >> >> It's also an octal constant, BTW. > [...] > > And to be clear, the language *could* have defined the term "null > pointer constant" so that a constant 0 in a non-pointer context is > not a null pointer constant. That would have made the definition of > the term substantially more complicated, with no particular benefit > that I can think of. The fact that a "null pointer constant" > can appear in a non-pointer context is probably worth a raised > eyebrow the first time you encounter it, but it doesn't create any > real problems. This is indeed something that appears to me as strange. (And if you hadn't made the followup to self, I'd have asked.) Maybe it's - as I read your response - just a formal definition quirk. I've always seen the '0' as universal "standard representation" or universal "literal" for more that one type; for 'int', 'char', ..., and for '<type> *'. In context of pointers - to refer to Bart's repeated confusion - you may see the '0' as in other languages 'nil', 'null', 'none', ..., etc. I agree that the universal character of the literal '0' may confuse people, as least as long as they think it's an integer in the pointer context and wrongly assume a one-to-one correspondence with its binary representation. Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-04-26 12:32 +0100 |
| Message-ID | <10skt54$1hdqq$2@dont-email.me> |
| In reply to | #397978 |
On 26/04/2026 04:04, Janis Papanagnou wrote:
> On 2026-04-26 04:08, Keith Thompson wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> [...]
>>> The RHS is 0. 0 is a null pointer constant. It really is that simple.
>>>
>>> The language defines the term "null pointer constant". The constant 0
>>> is by definition a null pointer constant. Though it may seem odd,
>>> 0 is a null pointer constant regardless of the context in which it
>>> appears.
>>>
>>> int n = 0;
>>>
>>> That 0 is a null pointer constant, but that fact has no effect on the
>>> semantics of the declaration.
>>>
>>> It's also an octal constant, BTW.
>> [...]
>>
>> And to be clear, the language *could* have defined the term "null
>> pointer constant" so that a constant 0 in a non-pointer context is
>> not a null pointer constant. That would have made the definition of
>> the term substantially more complicated, with no particular benefit
>> that I can think of. The fact that a "null pointer constant"
>> can appear in a non-pointer context is probably worth a raised
>> eyebrow the first time you encounter it, but it doesn't create any
>> real problems.
>
> This is indeed something that appears to me as strange. (And if you
> hadn't made the followup to self, I'd have asked.)
>
> Maybe it's - as I read your response - just a formal definition quirk.
>
> I've always seen the '0' as universal "standard representation" or
> universal "literal" for more that one type; for 'int', 'char', ...,
> and for '<type> *'.
>
>
> In context of pointers - to refer to Bart's repeated confusion
It's not confusion. I'm saying it's an odd quirk in the language. So
that this may or may not be legal:
void* P = <any arbitrarily complex compile-time integer expression>;
depending on whether that expression yields the value zero. That might
not be obvious to whoever is reading the code, and it can vary when the
expression include some macro or enum value that is defined outside the
module.
There is also this version:
void* P = <the same arbitrarily complex runtime integer expression>;
Which is always invalid even when the result is also zero.
- you
> may see the '0' as in other languages 'nil', 'null', 'none', ..., etc.
Yes, I use 'nil' in mine, but that was a change I did 10 or 20 years ago.
Before that I believe it was even more lax than C, in allowing any
integer values, compile-time or runtime, to be assigned to pointers or
passed to functions expecting pointers. So at least there was no special
treatment of '0'.
Now 'nil' feels right, and using 0 (by far the most common value) for
nil pointers feels very wrong.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-26 15:13 +0200 |
| Message-ID | <10sl31j$1jecp$1@dont-email.me> |
| In reply to | #397987 |
On 26/04/2026 13:32, Bart wrote: > On 26/04/2026 04:04, Janis Papanagnou wrote: >> On 2026-04-26 04:08, Keith Thompson wrote: >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>> [...] >>>> The RHS is 0. 0 is a null pointer constant. It really is that simple. >>>> >>>> The language defines the term "null pointer constant". The constant 0 >>>> is by definition a null pointer constant. Though it may seem odd, >>>> 0 is a null pointer constant regardless of the context in which it >>>> appears. >>>> >>>> int n = 0; >>>> >>>> That 0 is a null pointer constant, but that fact has no effect on the >>>> semantics of the declaration. >>>> >>>> It's also an octal constant, BTW. >>> [...] >>> >>> And to be clear, the language *could* have defined the term "null >>> pointer constant" so that a constant 0 in a non-pointer context is >>> not a null pointer constant. That would have made the definition of >>> the term substantially more complicated, with no particular benefit >>> that I can think of. The fact that a "null pointer constant" >>> can appear in a non-pointer context is probably worth a raised >>> eyebrow the first time you encounter it, but it doesn't create any >>> real problems. >> >> This is indeed something that appears to me as strange. (And if you >> hadn't made the followup to self, I'd have asked.) >> >> Maybe it's - as I read your response - just a formal definition quirk. >> >> I've always seen the '0' as universal "standard representation" or >> universal "literal" for more that one type; for 'int', 'char', ..., >> and for '<type> *'. >> >> >> In context of pointers - to refer to Bart's repeated confusion > > It's not confusion. I'm saying it's an odd quirk in the language. So > that this may or may not be legal: > > void* P = <any arbitrarily complex compile-time integer expression>; > > depending on whether that expression yields the value zero. That might > not be obvious to whoever is reading the code, and it can vary when the > expression include some macro or enum value that is defined outside the > module. > Unfortunately, no language can stop people writing code that is not obvious to human readers. There are no implicit conversions from integers to pointers - if the integer constant expression does not have the value 0, it is not a null pointer or any other kind of pointer, so the initialisation is a constraint error. Conforming compilers have to issue a diagnostic about that. (To save you checking, gcc without flags only gave a warning up to gcc 14, after which it issued an error. This is, IMHO, 13 versions too slow for that change, but better late than never.) The whole point of the macro NULL is to help people write clearer code. C does not force its use, but people interested in writing clearer code should typically use NULL (or other symbols they define) rather than 0, and certainly of preference to integer constant expression calculations. C23 goes a step further, and has "nullptr" as a way to write a null pointer constant that is independent of integer constants or the number 0. This makes a bigger difference in C++, but it is still good to see it in C. (I've never liked shouting in my programming - I prefer "nullptr" to "NULL".) gcc (and no doubt other compilers) can be made to enforce the use of NULL or nullptr with "-Werror=zero-as-null-pointer-constant". This will, of course, complain about perfectly valid C code that uses 0 as a null pointer constant - but IMHO it is an improvement. > There is also this version: > > void* P = <the same arbitrarily complex runtime integer expression>; > > Which is always invalid even when the result is also zero. Yes. Only a constant integer expression of value 0 is a null pointer constant. It is a constraint error to assign an integer directly to a pointer - you always need an explicit type conversion such as a cast. > > - you >> may see the '0' as in other languages 'nil', 'null', 'none', ..., etc. > > Yes, I use 'nil' in mine, but that was a change I did 10 or 20 years ago. > "nil" is also used by Pascal and related languages. > Before that I believe it was even more lax than C, in allowing any > integer values, compile-time or runtime, to be assigned to pointers or > passed to functions expecting pointers. So at least there was no special > treatment of '0'. > > Now 'nil' feels right, and using 0 (by far the most common value) for > nil pointers feels very wrong. >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-04-26 16:27 +0300 |
| Message-ID | <20260426162714.000063fc@yahoo.com> |
| In reply to | #397988 |
On Sun, 26 Apr 2026 15:13:23 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 26/04/2026 13:32, Bart wrote: > > On 26/04/2026 04:04, Janis Papanagnou wrote: > >> On 2026-04-26 04:08, Keith Thompson wrote: > >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >>> [...] > >>>> The RHS is 0. 0 is a null pointer constant. It really is that > >>>> simple. > >>>> > >>>> The language defines the term "null pointer constant". The > >>>> constant 0 is by definition a null pointer constant. Though it > >>>> may seem odd, 0 is a null pointer constant regardless of the > >>>> context in which it appears. > >>>> > >>>> int n = 0; > >>>> > >>>> That 0 is a null pointer constant, but that fact has no effect > >>>> on the semantics of the declaration. > >>>> > >>>> It's also an octal constant, BTW. > >>> [...] > >>> > >>> And to be clear, the language *could* have defined the term "null > >>> pointer constant" so that a constant 0 in a non-pointer context is > >>> not a null pointer constant. That would have made the definition > >>> of the term substantially more complicated, with no particular > >>> benefit that I can think of. The fact that a "null pointer > >>> constant" can appear in a non-pointer context is probably worth a > >>> raised eyebrow the first time you encounter it, but it doesn't > >>> create any real problems. > >> > >> This is indeed something that appears to me as strange. (And if you > >> hadn't made the followup to self, I'd have asked.) > >> > >> Maybe it's - as I read your response - just a formal definition > >> quirk. > >> > >> I've always seen the '0' as universal "standard representation" or > >> universal "literal" for more that one type; for 'int', 'char', ..., > >> and for '<type> *'. > >> > >> > >> In context of pointers - to refer to Bart's repeated confusion > > > > It's not confusion. I'm saying it's an odd quirk in the language. > > So that this may or may not be legal: > > > > void* P = <any arbitrarily complex compile-time integer > > expression>; > > > > depending on whether that expression yields the value zero. That > > might not be obvious to whoever is reading the code, and it can > > vary when the expression include some macro or enum value that is > > defined outside the module. > > > > Unfortunately, no language can stop people writing code that is not > obvious to human readers. There are no implicit conversions from > integers to pointers - if the integer constant expression does not > have the value 0, it is not a null pointer or any other kind of > pointer, so the initialisation is a constraint error. Conforming > compilers have to issue a diagnostic about that. > > (To save you checking, gcc without flags only gave a warning up to > gcc 14, after which it issued an error. This is, IMHO, 13 versions > too slow for that change, but better late than never.) > You can't be serious, are you? gcc1 released in 1987. C code in style of K&R 1st edition (and worse) was a majority of Open Source corpus. And it remained like that for many years. Other C compilers could allow to themselves to be more strict, but not gcc or not any contender to role of cc on Unix-like system.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-26 17:19 +0200 |
| Message-ID | <10sladf$1lho0$2@dont-email.me> |
| In reply to | #397989 |
On 26/04/2026 15:27, Michael S wrote: > On Sun, 26 Apr 2026 15:13:23 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 26/04/2026 13:32, Bart wrote: >>> On 26/04/2026 04:04, Janis Papanagnou wrote: >>>> On 2026-04-26 04:08, Keith Thompson wrote: >>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>>>> [...] >>>>>> The RHS is 0. 0 is a null pointer constant. It really is that >>>>>> simple. >>>>>> >>>>>> The language defines the term "null pointer constant". The >>>>>> constant 0 is by definition a null pointer constant. Though it >>>>>> may seem odd, 0 is a null pointer constant regardless of the >>>>>> context in which it appears. >>>>>> >>>>>> int n = 0; >>>>>> >>>>>> That 0 is a null pointer constant, but that fact has no effect >>>>>> on the semantics of the declaration. >>>>>> >>>>>> It's also an octal constant, BTW. >>>>> [...] >>>>> >>>>> And to be clear, the language *could* have defined the term "null >>>>> pointer constant" so that a constant 0 in a non-pointer context is >>>>> not a null pointer constant. That would have made the definition >>>>> of the term substantially more complicated, with no particular >>>>> benefit that I can think of. The fact that a "null pointer >>>>> constant" can appear in a non-pointer context is probably worth a >>>>> raised eyebrow the first time you encounter it, but it doesn't >>>>> create any real problems. >>>> >>>> This is indeed something that appears to me as strange. (And if you >>>> hadn't made the followup to self, I'd have asked.) >>>> >>>> Maybe it's - as I read your response - just a formal definition >>>> quirk. >>>> >>>> I've always seen the '0' as universal "standard representation" or >>>> universal "literal" for more that one type; for 'int', 'char', ..., >>>> and for '<type> *'. >>>> >>>> >>>> In context of pointers - to refer to Bart's repeated confusion >>> >>> It's not confusion. I'm saying it's an odd quirk in the language. >>> So that this may or may not be legal: >>> >>> void* P = <any arbitrarily complex compile-time integer >>> expression>; >>> >>> depending on whether that expression yields the value zero. That >>> might not be obvious to whoever is reading the code, and it can >>> vary when the expression include some macro or enum value that is >>> defined outside the module. >>> >> >> Unfortunately, no language can stop people writing code that is not >> obvious to human readers. There are no implicit conversions from >> integers to pointers - if the integer constant expression does not >> have the value 0, it is not a null pointer or any other kind of >> pointer, so the initialisation is a constraint error. Conforming >> compilers have to issue a diagnostic about that. >> >> (To save you checking, gcc without flags only gave a warning up to >> gcc 14, after which it issued an error. This is, IMHO, 13 versions >> too slow for that change, but better late than never.) >> > > You can't be serious, are you? > gcc1 released in 1987. C code in style of K&R 1st edition (and worse) > was a majority of Open Source corpus. And it remained like that for > many years. > Other C compilers could allow to themselves to be more strict, but not > gcc or not any contender to role of cc on Unix-like system. > I understand why gcc has been lax (to use Bart's favourite term) in how it treats various things that are constraint violations, non-conformities, obvious or very likely errors in the code, etc. If gcc gives an error (or sometimes even just a warning) on code that used to compile, that causes irritation or failures for people trying to compiler older code - a particular problem when gcc is being used to install someone else's source code. But letting mistakes slide also means more people write code with these mistakes. (I don't think this particular case - initialising a pointer with an integer constant other than 0 - is either common or likely to stay unnoticed and cause harm.) I think the C world would have been better served by a gcc that was a lot stricter, a lot earlier on. It would have been better to force some C developers to fix their code in the early days, than to have more mistakes in released code later on.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-26 15:34 -0700 |
| Message-ID | <10sm3tr$1t8mo$2@kst.eternal-september.org> |
| In reply to | #397987 |
Bart <bc@freeuk.com> writes:
[...]
> It's not confusion. I'm saying it's an odd quirk in the language.
I agree that it's an odd quirk in the language.
> So that this may or may not be legal:
>
> void* P = <any arbitrarily complex compile-time integer expression>;
>
> depending on whether that expression yields the value zero. That might
> not be obvious to whoever is reading the code, and it can vary when
> the expression include some macro or enum value that is defined
> outside the module.
Yes, but no sane C programmer would write that other than for
deliberate obfuscation.
Yes, you can write valid but nearly illegible code in C. So what?
> There is also this version:
>
> void* P = <the same arbitrarily complex runtime integer expression>;
>
> Which is always invalid even when the result is also zero.
Yes.
Has this even caused a problem for you (or anyone else)?
If you want a null pointer constant, you can write something silly
like ('/'/'/'-'/'/'/') or ((unsigned long long)0x0p-42), or you
can just write 0, or (void*)0, or NULL, or nullptr in C23. If you
write some complicated expression that happens to be constant and
happens to evaluate to 0, the compiler has to treat it as a null
pointer constant, but you're writing bad code.
[...]
--
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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-27 19:30 +0200 |
| Message-ID | <10so6fi$3knhv$7@dont-email.me> |
| In reply to | #398011 |
On 2026-04-27 00:34, Keith Thompson wrote:
>
> If you want a null pointer constant, you can write something silly
> like ('/'/'/'-'/'/'/') [...]
Oh, I like that one! :-)
Janis
[toc] | [prev] | [next] | [standalone]
Page 11 of 19 — ← Prev page 1 … 9 10 [11] 12 13 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web