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 14 of 19 — ← Prev page 1 … 12 13 [14] 15 16 … 19 Next page →
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2026-04-22 16:09 +0000 |
| Message-ID | <10sarrf$29ko5$3@dont-email.me> |
| In reply to | #397804 |
On Wed, 22 Apr 2026 15:13:56 +0000, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>>On 22/04/2026 05:09, Tim Rentsch wrote:
>>> antispam@fricas.org (Waldek Hebisch) writes:
>>>
>>>> Bart <bc@freeuk.com> wrote:
>>>>
>>>>> On 19/04/2026 20:32, David Brown wrote:
>>>>>A
>>>>>> On 19/04/2026 19:47, Bart wrote:
>>>>>>
>>>>>>> Get the value of 'b',
>>>>>>
>>>>>> You can't do that. "b" has no value. "b" is indeterminate, and
>>>>>> using its value is UB - the code has no meaning right out of the
>>>>>> gate.
>
>>> The kinds of behavior Bart is asking about has been undefined
>>> behavior for just over 15 years, since 2011 ISO C.
>>
>>So what was it between 1972 and 2011?
>>
>
> Implementation specific. Depending on how the linker
> and run-time loader handled uninitialized data regions
> in the a.out file and when loading.
K&R is very specific about the initial value of automatic
variables:
1.10 Scope; External Variables
...
"Because automatic variables come and go with
function invocation, they do not retain their
values from one call to the next, and must be
explicitly set upon each entry. If they are
not set, they will contain garbage."
...
2.4 Declarations
...
"Automatic variables for which there is no
explicit initializer have undefined (i.e.
garbage) values."
...
4.9 Initialization
...
"In the absence of explicit initialization,
external and static variables are guaranteed
to be initialized to zero; automatic and
register variables have undefined (.e.e garbage)
values."
...
8.6 Initialization
...
"Static and external variables which are not
initialized are guaranteed to start off
as 0, automatic and register variables which
are not initialized are guaranteed to start
off as garbage."
...
So, for automatic and register variables at least,
even K&R defined that, before initialization, their
values were undefined.
--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-23 08:18 +0200 |
| Message-ID | <10scdj3$2qoh2$1@dont-email.me> |
| In reply to | #397810 |
On 22/04/2026 18:09, Lew Pitcher wrote: > On Wed, 22 Apr 2026 15:13:56 +0000, Scott Lurndal wrote: > >> Bart <bc@freeuk.com> writes: >>> On 22/04/2026 05:09, Tim Rentsch wrote: >>>> antispam@fricas.org (Waldek Hebisch) writes: >>>> >>>>> Bart <bc@freeuk.com> wrote: >>>>> >>>>>> On 19/04/2026 20:32, David Brown wrote: >>>>>> A >>>>>>> On 19/04/2026 19:47, Bart wrote: >>>>>>> >>>>>>>> Get the value of 'b', >>>>>>> >>>>>>> You can't do that. "b" has no value. "b" is indeterminate, and >>>>>>> using its value is UB - the code has no meaning right out of the >>>>>>> gate. >> >>>> The kinds of behavior Bart is asking about has been undefined >>>> behavior for just over 15 years, since 2011 ISO C. >>> >>> So what was it between 1972 and 2011? >>> >> >> Implementation specific. Depending on how the linker >> and run-time loader handled uninitialized data regions >> in the a.out file and when loading. > > K&R is very specific about the initial value of automatic > variables: > 1.10 Scope; External Variables > ... > "Because automatic variables come and go with > function invocation, they do not retain their > values from one call to the next, and must be > explicitly set upon each entry. If they are > not set, they will contain garbage." > ... > > 2.4 Declarations > ... > "Automatic variables for which there is no > explicit initializer have undefined (i.e. > garbage) values." > ... > > 4.9 Initialization > ... > "In the absence of explicit initialization, > external and static variables are guaranteed > to be initialized to zero; automatic and > register variables have undefined (.e.e garbage) > values." > ... > > 8.6 Initialization > ... > "Static and external variables which are not > initialized are guaranteed to start off > as 0, automatic and register variables which > are not initialized are guaranteed to start > off as garbage." > ... > > So, for automatic and register variables at least, > even K&R defined that, before initialization, their > values were undefined. > I don't see the use of uninitialised variables being undefined here. It just says their values are garbage (thus unspecified values, or possibly trap values). Indeed, it says they are /guaranteed/ to be garbage, which is a strange turn of phrase - it could be interpreted to mean an implementation is not allowed to zero-initialise them even if it wanted to. There's no doubt that use of the values of uninitialised local variables has been a bad idea - incorrect code - since early C. But UB is not just a case of "nothing good will happen".
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-04-23 01:56 -0700 |
| Message-ID | <10scmse$2t9pi$1@dont-email.me> |
| In reply to | #397826 |
On 4/22/2026 11:18 PM, David Brown wrote: > On 22/04/2026 18:09, Lew Pitcher wrote: >> On Wed, 22 Apr 2026 15:13:56 +0000, Scott Lurndal wrote: >> >>> Bart <bc@freeuk.com> writes: >>>> On 22/04/2026 05:09, Tim Rentsch wrote: >>>>> antispam@fricas.org (Waldek Hebisch) writes: >>>>> >>>>>> Bart <bc@freeuk.com> wrote: >>>>>> >>>>>>> On 19/04/2026 20:32, David Brown wrote: >>>>>>> A >>>>>>>> On 19/04/2026 19:47, Bart wrote: >>>>>>>> >>>>>>>>> Get the value of 'b', >>>>>>>> >>>>>>>> You can't do that. "b" has no value. "b" is indeterminate, and >>>>>>>> using its value is UB - the code has no meaning right out of the >>>>>>>> gate. >>> >>>>> The kinds of behavior Bart is asking about has been undefined >>>>> behavior for just over 15 years, since 2011 ISO C. >>>> >>>> So what was it between 1972 and 2011? >>>> >>> >>> Implementation specific. Depending on how the linker >>> and run-time loader handled uninitialized data regions >>> in the a.out file and when loading. >> >> K&R is very specific about the initial value of automatic >> variables: >> 1.10 Scope; External Variables >> ... >> "Because automatic variables come and go with >> function invocation, they do not retain their >> values from one call to the next, and must be >> explicitly set upon each entry. If they are >> not set, they will contain garbage." >> ... >> >> 2.4 Declarations >> ... >> "Automatic variables for which there is no >> explicit initializer have undefined (i.e. >> garbage) values." >> ... >> >> 4.9 Initialization >> ... >> "In the absence of explicit initialization, >> external and static variables are guaranteed >> to be initialized to zero; automatic and >> register variables have undefined (.e.e garbage) >> values." >> ... >> >> 8.6 Initialization >> ... >> "Static and external variables which are not >> initialized are guaranteed to start off >> as 0, automatic and register variables which >> are not initialized are guaranteed to start >> off as garbage." >> ... >> >> So, for automatic and register variables at least, >> even K&R defined that, before initialization, their >> values were undefined. >> > > I don't see the use of uninitialised variables being undefined here. It > just says their values are garbage (thus unspecified values, or possibly > trap values). Indeed, it says they are /guaranteed/ to be garbage, > which is a strange turn of phrase - it could be interpreted to mean an > implementation is not allowed to zero-initialise them even if it wanted to. > > There's no doubt that use of the values of uninitialised local variables > has been a bad idea - incorrect code - since early C. But UB is not > just a case of "nothing good will happen". > > int a; a can now be a result from a TRNG. a can be equal to GARBAGE, where GARBAGE = 0? ;^)
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-24 02:29 +0200 |
| Message-ID | <10sedh5$2b5i9$12@dont-email.me> |
| In reply to | #397810 |
On 2026-04-22 18:09, Lew Pitcher wrote: > > K&R is very specific about the initial value of automatic > variables: > [...] > > 4.9 Initialization > ... > "In the absence of explicit initialization, > external and static variables are guaranteed > to be initialized to zero; automatic and > register variables have undefined (.e.e garbage) > values." > ... I suppose for pointer variables that is not to be interpreted as NULL but as a "physical" (integer) zero; is that assumption correct? Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-23 18:18 -0700 |
| Message-ID | <10segdv$3dgcd$6@kst.eternal-september.org> |
| In reply to | #397889 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-04-22 18:09, Lew Pitcher wrote:
>> K&R is very specific about the initial value of automatic
>> variables:
>> [...]
>> 4.9 Initialization
>> ...
>> "In the absence of explicit initialization,
>> external and static variables are guaranteed
>> to be initialized to zero; automatic and
>> register variables have undefined (.e.e garbage)
>> values."
>> ...
>
> I suppose for pointer variables that is not to be interpreted
> as NULL but as a "physical" (integer) zero; is that assumption
> correct?
I don't think so.
That wording (which is a bit vague) appears in both K&R1 (1978)
and K&R2 (1989).
In K&R1, I get the impression that there was an implicit assumption
that null pointers are represented as all-bits-zero. It's likely
that the few implementations that existed at the time (the book
lists 4 of them) all worked that way.
Both K&R1 and K&R2 have an Appendix A titled "Reference Manual",
which is more formal. (I think most of the chapters where written
by Kernighan and the Reference Manual by Ritchie.)
In K&R2, Appendix A is clearer: "A static object not explicitly
initialized is initialized as if it (or its members) were assigned
the constant 0.", and later "If there are fewer initializers in
the list than members of the structure, the trailing members are
initialized with 0."
K&R2 is based on the 1989 ANSI C standard, which is even more
explicit, and makes it clear that 0 is a null pointer constant but
the representation of a null pointer can be anything.
--
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-24 03:57 +0200 |
| Message-ID | <10sein6$2b5i9$14@dont-email.me> |
| In reply to | #397896 |
On 2026-04-24 03:18, Keith Thompson wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-04-22 18:09, Lew Pitcher wrote: >>> K&R is very specific about the initial value of automatic >>> variables: >>> [...] >>> 4.9 Initialization >>> ... >>> "In the absence of explicit initialization, >>> external and static variables are guaranteed >>> to be initialized to zero; automatic and >>> register variables have undefined (.e.e garbage) >>> values." >>> ... >> >> I suppose for pointer variables that is not to be interpreted >> as NULL but as a "physical" (integer) zero; is that assumption >> correct? > > I don't think so. > > That wording (which is a bit vague) appears in both K&R1 (1978) > and K&R2 (1989). > > In K&R1, I get the impression that there was an implicit assumption > that null pointers are represented as all-bits-zero. It's likely > that the few implementations that existed at the time (the book > lists 4 of them) all worked that way. Probably. (And for those systems there's no ambiguity problem here.) > > Both K&R1 and K&R2 have an Appendix A titled "Reference Manual", > which is more formal. (I think most of the chapters where written > by Kernighan and the Reference Manual by Ritchie.) > > In K&R2, Appendix A is clearer: "A static object not explicitly > initialized is initialized as if it (or its members) were assigned > the constant 0.", and later "If there are fewer initializers in > the list than members of the structure, the trailing members are > initialized with 0." > > K&R2 is based on the 1989 ANSI C standard, which is even more > explicit, and makes it clear that 0 is a null pointer constant but > the representation of a null pointer can be anything. The K&R translation I have is from 1983 and is based on K&R1 with some additions (on the way towards K&R2 ?). It just mentions the universal 0 value for the null-pointer and that it's unique. It also speaks about the caveats of assigning different types of pointers and that they may cause addressing (access?) errors. For static variables it just says that they're initialized to zero as quoted above - but I think that formulation is not very clear - and they suggest to always initialize them explicitly anyway. Unfortunately the examples show just 'int' value and no pointers. I'd be curious to hear from someone who has access to a system where the null-pointer isn't implemented as binary 0 how a static pointer declaration gets initialized. Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-23 19:11 -0700 |
| Message-ID | <10sejgo$3dgcd$10@kst.eternal-september.org> |
| In reply to | #397901 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
> I'd be curious to hear from someone who has access to a system
> where the null-pointer isn't implemented as binary 0 how a static
> pointer declaration gets initialized.
So would I, but I'm not holding my breath.
static int np;
or
static int np = 0;
For an implementation where a null pointer is represented as
0xDEADBEEF, a static pointer declaration *must* store the bits
0xDEADBEEF in the pointer object, and the value of that pointer
object *must* compare equal to a constant 0 and to the NULL macro,
and to another null pointer of the same type -- if the implementation
is conforming.
I've worked with a compiler for a language other than C that
represented a null pointer as 1. (It was a Pascal m68k compiler, and
using an odd address caused most null pointer dereferences to trap.)
But it's entirely possible that there is no modern C compiler that
uses a representation other than all-bits-zero for null pointers.
Note also that different pointer types can, in principle, use
different representations for null pointers. If so, conversions
between pointer types require non-trivial code.
It's conceivable that a future C standard might require null
pointers to be represented as all-bits-zero. If the same is done
for floating-point (also not currently required), then memset
could become a safe way to initialize an object to logical zero.
Similar changes have been made in the past for behaviors that
were practically universal, such as requiring that all-bits-zero
is a representation of 0 for integer types (introduced post-C99)
and that all signed integers use 2's-complement (introduced in C23).
--
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-23 09:14 -0700 |
| Message-ID | <86a4ut4ps3.fsf@linuxsc.com> |
| In reply to | #397804 |
scott@slp53.sl.home (Scott Lurndal) writes: > IMO, most "undefined behavior" in the C specification was due to > implementation differences between the C compilers/linkers that > existed at the time. There are different kinds of undefined behavior. I think it is more common for differences between different tool sets to be put in the category of implemenation-defined behavior than undefined behavior. Some circumstances, such as indexing past the end of an array, are inherently undefined behavior, and really couldn't be anything else. In some cases a construct is labeled UB not because of differences in existing tools but because the ISO committee wanted to allow a level of freedom in future tool sets that is more than what IDB can provide. I haven't done any sort of systematic study, but my sense is that UB arising only from differences in existing implementations is more at the low end of the histogram than the high end.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-22 17:27 +0200 |
| Message-ID | <10sapd2$2a9eu$1@dont-email.me> |
| In reply to | #397801 |
On 22/04/2026 16:16, Bart wrote: > On 22/04/2026 05:09, Tim Rentsch wrote: >> antispam@fricas.org (Waldek Hebisch) writes: >> <snip> >>> You look at trivial example, where AFAICS the best answer is: >>> "Compiler follows general rules, why should it make exception for >>> this case?". Note that in this trivial case "interesting" >>> behaviour could happen on exotic hardware (probably disallowed >>> by C23 rules, but AFAICS legal for earlier C versions). >> >> The kinds of behavior Bart is asking about has been undefined >> behavior for just over 15 years, since 2011 ISO C. > > So what was it between 1972 and 2011? > In the C99 standard, J.2 "Undefined behavior", it says: -- The value of an object with automatic storage duration is used while it is indeterminate. The annexes are not normative AFAIUI - that is, they are intended to be accurate, but if there is a disagreement between something in an annex and something in the main text, the main text is considered correct. any such disagreements are usually fixed in later versions of the standard. Tim is better at "language lawyer" stuff than I am, but it seems to me that "int a, b; a = b;" is UB in C99. I don't have any older references conveniently on hand, but I do not think this has changed - though the wording in the standard has been improved a little over time.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-04-22 18:52 +0300 |
| Message-ID | <20260422185252.00001a9b@yahoo.com> |
| In reply to | #397801 |
On Wed, 22 Apr 2026 15:16:56 +0100
Bart <bc@freeuk.com> wrote:
> On 22/04/2026 05:09, Tim Rentsch wrote:
> > antispam@fricas.org (Waldek Hebisch) writes:
> >
> >>
> >> You look at trivial example, where AFAICS the best answer is:
> >> "Compiler follows general rules, why should it make exception for
> >> this case?". Note that in this trivial case "interesting"
> >> behaviour could happen on exotic hardware (probably disallowed
> >> by C23 rules, but AFAICS legal for earlier C versions).
> >
> > The kinds of behavior Bart is asking about has been undefined
> > behavior for just over 15 years, since 2011 ISO C.
>
> So what was it between 1972 and 2011?
>
My record at guessing exact meaning of Tim's statements is not
particularly good, but I'll try nevertheless.
Tim seems to suggest that function foo() below had defined behavior
(most likely of returning 1) in C90 and C99, then it became undefined in
C11 and C17 then again became defined in C23.
For years 1972 to 1989 Tim probably thinks that there is no sufficient
data to answer your question.
int foo(void) {
int a, b=a;
return a==b;
}
Naturally, I could be wrong and even not unlikely to be wrong.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-04-22 20:39 -0700 |
| Message-ID | <86v7di4a6c.fsf@linuxsc.com> |
| In reply to | #397808 |
Michael S <already5chosen@yahoo.com> writes: > On Wed, 22 Apr 2026 15:16:56 +0100 > Bart <bc@freeuk.com> wrote: > >> On 22/04/2026 05:09, Tim Rentsch wrote: >> >>> antispam@fricas.org (Waldek Hebisch) writes: >>> >>>> You look at trivial example, where AFAICS the best answer is: >>>> "Compiler follows general rules, why should it make exception for >>>> this case?". Note that in this trivial case "interesting" >>>> behaviour could happen on exotic hardware (probably disallowed >>>> by C23 rules, but AFAICS legal for earlier C versions). >>> >>> The kinds of behavior Bart is asking about has been undefined >>> behavior for just over 15 years, since 2011 ISO C. >> >> So what was it between 1972 and 2011? > > My record at guessing exact meaning of Tim's statements is not > particularly good, but I'll try nevertheless. > > Tim seems to suggest that function foo() below had defined behavior > (most likely of returning 1) in C90 and C99, then it became undefined in > C11 and C17 then again became defined in C23. > For years 1972 to 1989 Tim probably thinks that there is no sufficient > data to answer your question. I'm curious to know what you think of my answer now that I have written one. :)
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-04-23 13:15 +0300 |
| Message-ID | <20260423131509.00005e6d@yahoo.com> |
| In reply to | #397824 |
On Wed, 22 Apr 2026 20:39:39 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > > On Wed, 22 Apr 2026 15:16:56 +0100 > > Bart <bc@freeuk.com> wrote: > > > >> On 22/04/2026 05:09, Tim Rentsch wrote: > >> > >>> antispam@fricas.org (Waldek Hebisch) writes: > >>> > >>>> You look at trivial example, where AFAICS the best answer is: > >>>> "Compiler follows general rules, why should it make exception for > >>>> this case?". Note that in this trivial case "interesting" > >>>> behaviour could happen on exotic hardware (probably disallowed > >>>> by C23 rules, but AFAICS legal for earlier C versions). > >>> > >>> The kinds of behavior Bart is asking about has been undefined > >>> behavior for just over 15 years, since 2011 ISO C. > >> > >> So what was it between 1972 and 2011? > > > > My record at guessing exact meaning of Tim's statements is not > > particularly good, but I'll try nevertheless. > > > > Tim seems to suggest that function foo() below had defined behavior > > (most likely of returning 1) in C90 and C99, then it became > > undefined in C11 and C17 then again became defined in C23. > > For years 1972 to 1989 Tim probably thinks that there is no > > sufficient data to answer your question. > > I'm curious to know what you think of my answer now that I > have written one. :) I'd like to read an explanation of what exactly was changed or clarified in 2011 and again in 2024.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-23 12:50 +0200 |
| Message-ID | <10scti7$2ut9s$1@dont-email.me> |
| In reply to | #397838 |
On 23/04/2026 12:15, Michael S wrote: > On Wed, 22 Apr 2026 20:39:39 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Wed, 22 Apr 2026 15:16:56 +0100 >>> Bart <bc@freeuk.com> wrote: >>> >>>> On 22/04/2026 05:09, Tim Rentsch wrote: >>>> >>>>> antispam@fricas.org (Waldek Hebisch) writes: >>>>> >>>>>> You look at trivial example, where AFAICS the best answer is: >>>>>> "Compiler follows general rules, why should it make exception for >>>>>> this case?". Note that in this trivial case "interesting" >>>>>> behaviour could happen on exotic hardware (probably disallowed >>>>>> by C23 rules, but AFAICS legal for earlier C versions). >>>>> >>>>> The kinds of behavior Bart is asking about has been undefined >>>>> behavior for just over 15 years, since 2011 ISO C. >>>> >>>> So what was it between 1972 and 2011? >>> >>> My record at guessing exact meaning of Tim's statements is not >>> particularly good, but I'll try nevertheless. >>> >>> Tim seems to suggest that function foo() below had defined behavior >>> (most likely of returning 1) in C90 and C99, then it became >>> undefined in C11 and C17 then again became defined in C23. >>> For years 1972 to 1989 Tim probably thinks that there is no >>> sufficient data to answer your question. >> >> I'm curious to know what you think of my answer now that I >> have written one. :) > > I'd like to read an explanation of what exactly was changed or > clarified in 2011 and again in 2024. > I'd also appreciate some more detail for the first paragraph: [ Copied from the referred post written by Tim ] > Between 1989 and 2011 the behavior was either always undefined or > potentially undefined, depending on when, on what data types are > involved, on some implementation-specific choices, and on how one > reads some passages in the C standard that unfortunately were not > written as clearly as they might have been.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-04-23 08:46 -0700 |
| Message-ID | <86eck54r3g.fsf@linuxsc.com> |
| In reply to | #397838 |
Michael S <already5chosen@yahoo.com> writes: > On Wed, 22 Apr 2026 20:39:39 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Wed, 22 Apr 2026 15:16:56 +0100 >>> Bart <bc@freeuk.com> wrote: >>> >>>> On 22/04/2026 05:09, Tim Rentsch wrote: >>>> >>>>> antispam@fricas.org (Waldek Hebisch) writes: >>>>> >>>>>> You look at trivial example, where AFAICS the best answer is: >>>>>> "Compiler follows general rules, why should it make exception for >>>>>> this case?". Note that in this trivial case "interesting" >>>>>> behaviour could happen on exotic hardware (probably disallowed >>>>>> by C23 rules, but AFAICS legal for earlier C versions). >>>>> >>>>> The kinds of behavior Bart is asking about has been undefined >>>>> behavior for just over 15 years, since 2011 ISO C. >>>> >>>> So what was it between 1972 and 2011? >>> >>> My record at guessing exact meaning of Tim's statements is not >>> particularly good, but I'll try nevertheless. >>> >>> Tim seems to suggest that function foo() below had defined behavior >>> (most likely of returning 1) in C90 and C99, then it became >>> undefined in C11 and C17 then again became defined in C23. >>> For years 1972 to 1989 Tim probably thinks that there is no >>> sufficient data to answer your question. >> >> I'm curious to know what you think of my answer now that I >> have written one. :) > > I'd like to read an explanation of what exactly was changed or > clarified in 2011 and again in 2024. The main thing in C11 is that a specific scenario, related to the "Not a Thing" in Itanium, was spelled out and unambiguously labeled undefined behavior. The result wasn't so much of a change as it was a specific addition. I'm not paying much attention to C23 (which I guess was ratified in 2024). What I have read about C23 makes me think the people who are now responsible for the ISO C standard have lost the spirit of the original writings and original authors. Very sad.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-24 02:40 +0200 |
| Message-ID | <10see68$2b5i9$13@dont-email.me> |
| In reply to | #397808 |
On 2026-04-22 17:52, Michael S wrote:
>
> int foo(void) {
> int a, b=a;
Not relevant for how I write "C" programs but I'm curious;
is the order in the declaration sequential or collateral?
IOW; is it guaranteed to be equivalent to 'int a; int b=a;'
or could it also be interpreted as 'int b=a; int a;' ?
Janis
> return a==b;
> }
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-23 18:31 -0700 |
| Message-ID | <10seh6c$3dgcd$7@kst.eternal-september.org> |
| In reply to | #397891 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-04-22 17:52, Michael S wrote:
>> int foo(void) {
>> int a, b=a;
>
> Not relevant for how I write "C" programs but I'm curious;
> is the order in the declaration sequential or collateral?
> IOW; is it guaranteed to be equivalent to 'int a; int b=a;'
> or could it also be interpreted as 'int b=a; int a;' ?
>
> Janis
>
>> return a==b;
>> }
They're evaluated in order. The above has undefined behavior
because the value of "a" is used when it hasn't been initialized, but
this:
int a = 42, b = a;
sets both a and b to 42.
Annex C summarizes sequence points. It says that there is a sequence
point "Between the evaluation of a full expression and the next full
expression to be evaluated". Each of the two initilizers, 42 and a, is
a full expression. (Basically, a full expression is an expression
that's not part of a larger expression.)
--
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-22 20:37 -0700 |
| Message-ID | <86340m5ou8.fsf@linuxsc.com> |
| In reply to | #397801 |
Bart <bc@freeuk.com> writes: > On 22/04/2026 05:09, Tim Rentsch wrote: > >> antispam@fricas.org (Waldek Hebisch) writes: >> >>> Bart <bc@freeuk.com> wrote: >>> >>>> On 19/04/2026 20:32, David Brown wrote: >>>> >>>>> On 19/04/2026 19:47, Bart wrote: >>>>> >>>>>> Get the value of 'b', >>>>> >>>>> You can't do that. "b" has no value. "b" is indeterminate, and >>>>> using its value is UB - the code has no meaning right out of the >>>>> gate. >>>>> >>>>> When you use "b" in an expression, you are /not/ asking C to read >>>>> the bits and bytes stored at the address of the object "b". You >>>>> are asking for the /value/ of the object "b". How the compiler >>>>> gets that value is up to the compiler - it can read the memory, or >>>>> use a stored copy in a register, or use program analysis to know >>>>> what the value is in some other way. And if the object "b" does >>>>> not have a value, you are asking the impossible. >>>>> >>>>> Try asking a human "You have two numbers, b and c. Add them. >>>>> What is the answer?". >>>> >>>> You have two slates A and B which someone should have wiped clean >>>> then written a new number on each. >>>> >>>> But that part hasn't been done; they each still have an old number >>>> from their last use. >>>> >>>> You can still add them together, nothing bad will happen. It just >>>> may be the wrong answer if the purpose of the exercise was to find >>>> the sum of two specific new numbers. >>>> >>>> But the purpose may also be see how good they are adding. Or in >>>> following instructions. >>>> >>>>>> whatever it happens to be, add the value of 'c' scaled by 8, and >>>>>> store the result it into 'a'. The only things to consider are >>>>>> that some intermediate results may lose the top bits. >>>>>> >>>>>> Is 'a = b' equally undefined? If so that C is even crazy than >>>>>> I'd thought. >>>>> >>>>> If "a" or "b" are indeterminate, then using them is undefined. I >>>>> have two things - are they the same colour? How is that supposed >>>>> to make sense? >>>>> >>>>> You keep thinking of objects like "b" as a section of memory with >>>>> a bit pattern in it. Objects are not that simple in C - C is not >>>>> assembly. >>>> >>>> Why ISN'T it that simple? What ghastly thing would happen if it >>>> was? >>>> >>>> "b" will be some location in memory or it might be some register, >>>> and it WILL have a value. That value happens to be unknown until >>>> it is initialised. >>>> >>>> So accessing it will return garbage (unless you know exactly what >>>> you are doing then it may be something useful). >>>> >>>> My original example was something like 'a = b + c' (I think in my >>>> language), converted to my IL, then expressed in very low-level C. >>>> >>>> You were concerned that in that C, the values weren't initialised. >>>> How would that have affected the code that C compiler generated >>>> from that? >>> >>> You look at trivial example, where AFAICS the best answer is: >>> "Compiler follows general rules, why should it make exception for >>> this case?". Note that in this trivial case "interesting" >>> behaviour could happen on exotic hardware (probably disallowed >>> by C23 rules, but AFAICS legal for earlier C versions). >> >> The kinds of behavior Bart is asking about has been undefined >> behavior for just over 15 years, since 2011 ISO C. > > So what was it between 1972 and 2011? Between 1989 and 2011 the behavior was either always undefined or potentially undefined, depending on when, on what data types are involved, on some implementation-specific choices, and on how one reads some passages in the C standard that unfortunately were not written as clearly as they might have been. Between 1978 and 1989, the defining document for C was K&R's "The C Programming Language." K&R doesn't have a notion of undefined behavior; but, neither does it give a definition of what happens in such cases. I think it's fair to say that during this time period the behavior was "not defined", as opposed to being specifically "undefined behavior". K&R is written in an informal style, and is meant to be read as such. Between 1972 and 1978 Unix was not available to the general public, and I think for all practical purposes neither was C. Also AFAIAA there was no recognized defining document for C during that time. IIRC there were some papers written about C before 1978, but nothing like a real language manual. So the answer seems to be either that the question doesn't make sense or that everything is "undefined behavior" because there is no language manual that defines it. I think the key point is that, TTBOMK, nothing has been written to exclude the possibility of arbitrary (aka "undefined") behavior when reading uninitialized memory, perhaps not counting some special cases such as reading via type unsigned char.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-23 02:37 -0700 |
| Message-ID | <10scp8f$2u408$1@kst.eternal-september.org> |
| In reply to | #397823 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> Between 1972 and 1978 Unix was not available to the general public,
> and I think for all practical purposes neither was C. Also AFAIAA
> there was no recognized defining document for C during that time.
> IIRC there were some papers written about C before 1978, but nothing
> like a real language manual. So the answer seems to be either that
> the question doesn't make sense or that everything is "undefined
> behavior" because there is no language manual that defines it.
[...]
For the C history buffs, here are a few early papers on C:
C Reference Manual, Jan 15 1974, Dennis Ritchie
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/cman74.pdf
C Reference Manual, 1975, Dennis Ritchie
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/cman.pdf
Programming in C - A Tutorial, 1975(?), Brian Kernighan
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/ctut.pdf
The Development of the C Language, 1994, Dennis Ritchie
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf
Dennis Ritchie's home page
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/
has a number of other papers on early Unix, BCPL, B, and C.
--
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-23 06:46 -0700 |
| Message-ID | <86qzo54wn8.fsf@linuxsc.com> |
| In reply to | #397835 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > [...] > >> Between 1972 and 1978 Unix was not available to the general public, >> and I think for all practical purposes neither was C. Also AFAIAA >> there was no recognized defining document for C during that time. >> IIRC there were some papers written about C before 1978, but nothing >> like a real language manual. So the answer seems to be either that >> the question doesn't make sense or that everything is "undefined >> behavior" because there is no language manual that defines it. > > [...] > > For the C history buffs, here are a few early papers on C: > > C Reference Manual, Jan 15 1974, Dennis Ritchie > https://www.nokia.com/bell-labs/about/dennis-m-ritchie/cman74.pdf > > C Reference Manual, 1975, Dennis Ritchie > https://www.nokia.com/bell-labs/about/dennis-m-ritchie/cman.pdf > > Programming in C - A Tutorial, 1975(?), Brian Kernighan > https://www.nokia.com/bell-labs/about/dennis-m-ritchie/ctut.pdf > > The Development of the C Language, 1994, Dennis Ritchie > https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf > > Dennis Ritchie's home page > https://www.nokia.com/bell-labs/about/dennis-m-ritchie/ > has a number of other papers on early Unix, BCPL, B, and C. Thank you for the links. At some point I think I skimmed one of the cman papers but I had forgotten about it.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-04-19 16:54 +0300 |
| Message-ID | <20260419165406.0000708d@yahoo.com> |
| In reply to | #397671 |
On Sun, 19 Apr 2026 12:50:04 +0100
Bart <bc@freeuk.com> wrote:
> On 19/04/2026 11:17, David Brown wrote:
> > On 18/04/2026 17:08, Bart wrote:
>
> > (Yes, LLVM and the tools around it are big. It takes a lot of
> > effort to make use of them, but you get a lot in return. A "little
> > language" has to grow to a certain size in numbers of toolchain
> > developers and numbers of toolchain users before it can make sense
> > to move to LLVM.
>
> Actually lots of small projects use LLVM.
>
> But probably people don't realise it is like installing the engine
> from a container ship into your small family car.
>
>
> > But doing
> > so is still a fraction of the work compared to making a serious
> > optimising back-end for multiple targets.)
> >
> >> If it did, then it could have served another purpose for which C
> >> is currently used and is not ideal either, which is to express
> >> APIs of libraries. Currently that is too C-centric and it is a big
> >> task to tranlate into bindings for other languages.
> >>
> >> (For example, the headers for GTK2 include about 4000 C macro
> >> definitions.)
> >>
> >
> > And yet in practice C is it good enough for almost cases.
>
> It is not even good enough C. To get back to GTK2 (which I looked at
> in detail some years back), compiling this program:
>
> #include <gtk2.h>
>
> involved processing over 1000 #includes, some 550 discrete headers,
> 330K lines of declarations, with a bunch of -I options to tell it the
> dozen different folders it needs to go and look for those headers.
>
> I was looking at reducing the whole thing to one file - a set of
> bindings in my language for the functions, types etc that are exposed.
>
> This file would have been 25Kloc in my language (including those 4000
> headers; most would have been simple #defines, but many will have
> needed manual translation: macros can contain actual C code, not just
> declarations).
>
> HOWEVER... if such an exercise works for my language, why can't it
> work for C too? That is, reduce those 100s of header files and dozens
> of folders into a single 25Kloc file, specific to your platform.
>
> Think how much easier it would be to install, or employ, and how
> much faster to /compile/!
It would be faster to compile. Probably, meaningfully faster for
compiling large GUI project from scratch with very slow compiler like
gcc. Probably, not meaningfully faster in other situations.
It would not be easier to install or employ unless one happens to be as
stubborn as you are.
If I ever want to write code using GTK2 for hobby purpose, which is
extremely unlikely, then all I'd need to do is to type 'pacman -S
mingw-w64-ucrt-x86_64-gtk2' at msys2 command prompt. That's all.
For somebody on Debian/Ubuntu it likely would be 'apt-get install
gtk2'. RHEL/Fedora, MSVC command prompt or Mac it would be some other
magic incantation. Except that for the latter two it's probably not
available at all, so even easier.
The point is - it's already so easy that you can't really make it any
easier, at best the same.
>
> So why doesn't this happen? The equivalent exercise for SDL2 would
> reduce 50Kloc across 80 header files (at least these are in the same
> folder) to one 3Kloc file.
>
> > A C compiler expects code written in valid C. Compilers expect
> > code to be run - I don't think that is unreasonable.
>
> What's not valid about 'a = b + c'?
>
>
>
> > And when I use a compiler
> > to look at generated assembly for some C code (and I do that quite
> > often), I am using C code that has a meaning if it were to be run.
>
> I'm interested too, but if I compile this in godbolt:
>
> void F() {
> int a, b, c;
> a = b + c * 8;
> }
>
> then all the C compilers I tried generated code at -O0 which kept
> those variables in memory.
>
> What does the code look like when a/b/c are kept in registers? I've
> no idea, because at soon as you try -O1 and above, the whole
> expression is elided.
>
> If you stick 'static' in front, then the whole function disappears.
> This is not very useful when trying to compare code generation across
> compilers and languages!
>
> If I do something meaningful with 'a' to keep the expression alive,
> and initialise b and c, then the whole expression is reduced to a
> constant.
>
> What do you have to do see if the expression would be compiled to,
> for example, 'lea ra, [rb + rc*8]'?
>
Come on, I don't believe that you didn't know the answer that David
Brown gave you above. You were arguing because you like to argue.
[toc] | [prev] | [next] | [standalone]
Page 14 of 19 — ← Prev page 1 … 12 13 [14] 15 16 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web