Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #391822 > unrolled thread
| Started by | Alexis <flexibeast@gmail.com> |
|---|---|
| First post | 2025-04-02 16:59 +1100 |
| Last post | 2025-04-11 13:51 -0700 |
| Articles | 20 on this page of 458 — 25 participants |
Back to article view | Back to comp.lang.c
"A diagram of C23 basic types" Alexis <flexibeast@gmail.com> - 2025-04-02 16:59 +1100
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-02 06:02 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-03 01:20 -0500
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-03 20:35 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-04 04:27 -0500
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-02 09:02 +0200
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-02 07:32 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-03 05:43 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 09:38 +0200
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-03 10:15 +0200
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-03 04:17 -0500
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-03 03:28 -0500
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-02 11:33 +0200
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-02 20:53 -0700
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-02 10:57 +0100
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-02 10:14 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-02 15:35 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-02 14:05 +0000
Re: "A diagram of C23 basic types" Thiago Adams <thiago.adams@gmail.com> - 2025-04-02 11:12 -0300
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-02 15:12 +0000
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-02 16:33 +0100
Re: "A diagram of C23 basic types" Muttley@dastardlyhq.com - 2025-04-02 15:51 +0000
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-02 16:20 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-02 23:31 +0200
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-02 23:32 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-03 03:02 +0200
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 13:42 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-03 19:32 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 09:49 +0200
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-03 13:21 -0500
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-03 01:10 +0100
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-03 05:09 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-02 23:12 -0700
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-03 01:28 -0500
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-03 19:37 +0000
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-03 21:48 +0100
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-04 02:57 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-09 12:49 +0300
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-09 15:01 +0200
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-09 12:26 -0500
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-09 20:11 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-10 09:53 +0200
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-10 11:37 +0300
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-12 05:43 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-12 10:10 -0400
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-12 17:21 +0200
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-12 14:27 -0500
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-10 10:07 +0000
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-10 12:08 +0100
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-10 12:48 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-12 05:44 +0000
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-10 12:42 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-10 15:06 +0200
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-10 15:29 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-10 16:55 +0200
C implementation headers [was Re: "A diagram of C23 basic types"] scott@slp53.sl.home (Scott Lurndal) - 2025-04-10 15:17 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-10 13:47 -0500
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-09 14:56 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-12 05:42 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-12 13:46 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-09 13:14 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-09 15:01 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-14 02:10 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-14 04:08 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-02 09:34 -0800
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-02 16:15 -0800
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-10 11:42 +0300
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-14 01:59 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-14 12:44 +0300
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-05 16:25 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-05-06 11:26 +0300
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 06:08 -0700
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-09 20:38 +0000
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-04-04 03:05 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 21:06 -0700
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-04-04 12:39 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-08 02:36 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 14:30 -0700
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-03 23:32 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-04 14:07 +0300
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-04 02:55 +0000
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-03 08:55 +0000
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 13:43 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 11:45 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 09:57 +0200
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-04 02:54 +0000
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-03 08:46 +0000
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 14:14 +0000
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-04 09:42 +0000
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-04 13:42 +0000
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-04 14:10 +0000
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-04 14:27 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-04 03:01 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 21:05 -0700
Re: "A diagram of C23 basic types" candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-04-07 17:30 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-07 21:49 +0200
Re: "A diagram of C23 basic types" candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-04-08 18:40 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-14 04:33 +0000
Re: "A diagram of C23 basic types" candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-04-14 17:40 +0000
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-14 17:46 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-15 09:41 +0200
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-14 13:36 -0500
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-14 15:15 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-14 22:33 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-14 15:56 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-14 23:41 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-14 17:57 -0700
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-14 23:25 -0400
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-15 04:11 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-15 10:06 -0400
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-15 15:56 -0700
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-15 17:04 -0700
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-15 20:53 -0400
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-17 17:56 +0200
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-19 09:46 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-19 17:15 +0200
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-19 23:15 +0300
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-21 20:34 +0200
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-21 14:28 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-22 01:07 +0300
Re: "A diagram of C23 basic types" candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-04-22 19:30 +0000
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-05 16:40 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-22 00:28 +0300
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-15 22:58 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-15 21:02 -0400
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-16 07:42 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-15 00:00 -0500
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-15 14:08 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-15 12:29 -0500
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-15 18:57 -0400
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-15 23:01 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-15 17:10 -0700
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-16 02:11 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-15 23:00 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-14 18:46 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-15 04:14 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-15 10:19 -0400
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-15 14:28 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-15 12:17 -0700
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-15 16:20 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-17 03:03 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-16 22:34 -0700
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-16 22:38 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-15 23:10 +0000
Re: "A diagram of C23 basic types" dave_thompson_2@comcast.net - 2025-07-29 10:49 -0400
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-07-29 21:18 -0400
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-14 19:43 -0500
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-15 04:15 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-15 00:40 -0500
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-15 19:22 +0200
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-15 12:54 -0500
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-15 19:10 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-15 19:54 -0500
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-18 20:03 +0200
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-15 22:56 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-15 23:48 -0500
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-16 07:41 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-18 20:10 +0200
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-15 14:10 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-15 13:00 -0500
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-15 16:42 -0700
Re: "A diagram of C23 basic types" candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-04-16 14:00 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-16 12:48 -0700
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-16 20:04 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-16 16:10 -0500
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-04-16 23:13 +0100
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-16 16:31 -0700
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-04-17 01:05 +0100
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-17 01:26 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-17 23:18 +0000
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-04-28 07:52 +0100
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-30 23:57 +0000
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-05-01 06:17 +0100
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-16 16:11 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-17 23:16 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-29 02:10 +0200
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-28 19:20 -0700
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-29 08:37 +0200
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-29 13:14 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-28 23:34 -0400
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-29 08:44 +0200
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-30 23:58 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-30 17:15 -0700
Re: "A diagram of C23 basic types" candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-04-29 05:10 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-29 01:24 -0400
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-29 13:02 -0500
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-04-29 19:25 +0100
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-29 19:00 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-08 02:27 +0000
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-07 19:02 +0100
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-07 21:12 +0300
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-07 19:18 +0100
Re: "A diagram of C23 basic types" G <g@nowhere.invalid> - 2025-04-07 18:41 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-07 22:14 +0200
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-07 23:49 +0300
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-07 23:18 +0200
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-07 22:37 -0400
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-07 22:46 +0100
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-07 23:57 +0100
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-07 16:01 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-08 11:45 +0300
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-08 11:37 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-08 10:25 +0200
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-18 02:39 +0000
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-18 12:49 +0100
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-19 00:16 +0000
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-04-07 20:29 +0100
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-07 22:30 +0200
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-04-07 22:26 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-08 10:29 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-08 10:54 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-08 14:20 +0300
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-08 14:25 -0400
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-08 21:29 +0300
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-08 13:39 +0200
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-04-08 13:00 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-08 16:55 +0200
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-08 19:25 +0200
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-08 14:32 -0400
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-08 20:53 +0300
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-08 22:30 +0300
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-09 09:01 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-09 12:23 +0300
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-09 10:08 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-09 13:32 +0300
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-09 11:00 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-09 13:04 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-09 15:24 +0200
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-09 12:35 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-09 11:02 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-09 14:33 +0300
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-09 15:09 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-01 00:01 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-09 15:16 +0200
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-09 16:56 +0300
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-09 18:19 +0200
Re: "A diagram of C23 basic types" Richard Harnden <richard.nospam@gmail.invalid> - 2025-04-09 18:32 +0100
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-09 15:09 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-09 13:17 -0700
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-08 14:34 -0400
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-09 09:00 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-08 02:29 +0000
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-02 16:18 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-04 02:53 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-02 17:28 +0300
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-02 15:17 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-02 16:59 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-02 15:26 +0000
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-02 16:38 +0100
Re: "A diagram of C23 basic types" Muttley@dastardlyhq.com - 2025-04-02 15:53 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-02 19:29 +0200
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-02 19:26 +0100
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-02 18:48 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-02 17:41 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 10:16 +0200
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 03:27 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 15:23 +0200
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 13:48 +0000
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-02 21:00 -0700
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 13:51 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 11:47 -0700
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 18:54 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 12:37 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-04 03:27 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-04 03:14 -0700
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-02 18:51 +0000
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-02 21:06 -0700
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-03 05:11 -0500
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-03 09:23 -0700
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-03 23:19 +0200
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-14 05:46 -0700
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-04-03 22:00 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-06 19:33 -0700
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-07 04:09 +0000
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-30 08:12 -0700
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-04-07 18:31 +0000
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-07 18:55 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-07 14:19 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-30 09:45 -0700
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-30 17:41 +0000
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 05:59 -0700
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-05-08 13:42 +0000
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 08:33 -0700
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-07 14:35 -0400
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-08 10:39 +0200
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-08 14:14 -0400
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-09 15:29 +0200
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-30 08:37 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 10:23 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 10:04 +0200
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-02 23:24 +0300
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 10:59 +0200
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-03 13:49 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 15:40 +0200
Re: "A diagram of C23 basic types" Thiago Adams <thiago.adams@gmail.com> - 2025-04-03 11:11 -0300
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 16:49 +0200
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-03 16:44 +0300
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 16:58 +0200
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-03 23:39 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 12:52 +0200
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-07 06:46 -0700
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-03 15:59 +0100
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 15:26 +0000
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-03 16:52 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 13:31 +0200
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 11:31 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 20:51 +0200
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 12:29 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-14 01:46 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 11:19 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 20:54 +0200
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-02 16:16 +0000
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-03 08:45 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 11:41 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-03 11:07 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 15:58 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-04 09:40 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 13:39 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-04 14:10 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 17:12 +0200
Re: "A diagram of C23 basic types" Muttley@dastardlyhq.com - 2025-04-04 16:11 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-04 12:52 -0700
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-04 04:43 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 15:34 +0200
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-03 14:45 +0300
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 16:03 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-02 19:23 +0200
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-02 18:04 +0000
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-03 08:49 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 15:16 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-03 13:22 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-02 23:43 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 11:03 +0200
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-04 04:50 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 15:38 +0200
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-04 15:14 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 17:26 +0200
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-02 18:02 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-03 00:35 -0400
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-03 06:21 +0000
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 13:53 +0000
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-04-02 14:12 +0000
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-02 15:16 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-02 13:09 -0700
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-03 08:51 +0000
Re: "A diagram of C23 basic types" Opus <ifonly@youknew.org> - 2025-04-03 15:05 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-03 13:19 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-03 16:27 +0300
Re: "A diagram of C23 basic types" Opus <ifonly@youknew.org> - 2025-04-03 21:13 +0200
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-06 03:31 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 11:15 -0700
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-03 16:01 -0700
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-04 09:43 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-04 03:25 -0700
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-04 10:28 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-04 03:31 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 15:46 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-04 14:02 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 17:28 +0200
Re: "A diagram of C23 basic types" Muttley@dastardlyhq.com - 2025-04-04 16:12 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 19:25 +0200
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-04 12:18 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-05 17:34 +0200
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-05 17:10 -0500
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-04-04 18:49 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-04 21:08 -0400
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-04 19:15 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-05 17:36 +0200
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-08 02:39 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-07 23:26 -0400
Re: "A diagram of C23 basic types" Philipp Klaus Krause <pkk@spth.de> - 2025-04-05 19:56 +0200
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-08 14:32 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-08 16:57 +0200
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-08 16:47 +0100
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-08 16:08 +0000
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-08 11:05 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-09 11:20 +0300
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-09 11:32 +0100
Re: "A diagram of C23 basic types" Ike Naar <ike@sdf.org> - 2025-04-09 08:53 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-08 14:46 -0700
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-08 23:34 +0100
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-08 17:33 -0700
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-08 22:47 -0400
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-08 21:36 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-08 23:12 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-09 10:55 +0300
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-09 13:52 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-10 11:50 +0300
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-11 12:27 -0400
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-14 01:24 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-14 12:55 +0300
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-06 06:56 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-06 13:25 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 08:37 -0700
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-05-08 15:48 +0000
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-08 16:32 +0000
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 22:53 -0700
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-05-08 14:09 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-05-08 16:52 +0200
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 08:49 -0700
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-09 11:21 +0100
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-09 15:03 -0700
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-09 21:32 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-08 22:58 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-08 15:36 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-03 15:02 +0300
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-03 13:06 -0500
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-27 12:05 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-28 16:27 +0300
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-29 13:38 -0500
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-06 15:06 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-26 09:01 +0000
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-06-26 13:27 +0100
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-27 00:39 +0000
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-06-27 02:40 +0100
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-26 19:33 -0700
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-06-28 14:16 -0500
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-15 19:41 +0000
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-07-16 03:55 +0100
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-20 00:16 +0000
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-07-20 07:58 +0100
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-07-20 11:28 +0200
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-29 04:44 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-06-29 17:13 +0300
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-06-26 12:51 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-26 13:23 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-26 23:58 +0000
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-06-27 03:51 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-06-27 13:44 +0200
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-06-27 14:01 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-06-26 15:57 +0200
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-06-26 16:10 +0100
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-26 12:31 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-06-26 23:59 +0300
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-06-26 21:09 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-26 17:10 -0700
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-06-27 04:33 +0200
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-27 17:56 -0700
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-06-29 05:03 +0200
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-06-28 23:18 -0400
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-28 20:37 -0700
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-06-29 20:48 +0200
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-06-30 21:59 -0400
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-28 20:51 -0700
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-06-29 20:40 +0200
Re: "A diagram of C23 basic types" - correction Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-06-29 20:52 +0200
Re: "A diagram of C23 basic types" - correction "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-29 12:14 -0700
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-06-27 14:02 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-06-27 14:52 +0300
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-06-27 20:48 +0200
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-28 23:59 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-06-29 09:23 -0400
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-29 00:56 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-07-29 21:13 -0400
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-11 09:34 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-11 12:48 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-11 09:48 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-11 13:51 -0700
Page 16 of 23 — ← Prev page 1 … 14 15 [16] 17 18 … 23 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-04-07 06:46 -0700 |
| Message-ID | <86h630dqz2.fsf@linuxsc.com> |
| In reply to | #391952 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > On 03.04.2025 16:58, David Brown wrote: > >> [...] >> >> I know people can use pre-processor conditional compilation based on >> __STDC_VERSION__ to complain if code is compiled with an unexpected or >> unsupported standard, but few people outside of library header authors >> actually do that. I'd really like : >> >> #pragma STDC VERSION C17 >> >> to force the compiler to use the equivalent of "-std=c17 >> -pedantic-errors" in gcc. > > (I understand the wish to have that #pragma supported.) It never will be, for reasons that are quite obvious.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-03 15:59 +0100 |
| Message-ID | <vsm7p1$t7nv$1@dont-email.me> |
| In reply to | #391918 |
On 03/04/2025 14:44, Michael S wrote:
> On Thu, 3 Apr 2025 13:49:48 +0100
> bart <bc@freeuk.com> wrote:
>
>> On 03/04/2025 09:59, David Brown wrote:
>>>
>>> It is bold, perhaps, but there are certainly good reasons.
>>
>> Perhaps go bolder and drop the need to explicitly include those 30 or
>> so standard headers. It's ridiculous having to micro-manage the
>> availablity of fundamental language features ('uint8_t' for example!)
>> in every module.
>
> I don't find it ridiculous.
How far would it have to go before you found it so: 60 headers instead
of 30; 120 headers? One header for each function/macro/type?
If you were to use my language, then everything that is part of the
language, plus functions of the standard library, is available without
needing to specify anything. That makes it a joy to use.
Other languages (not C++) are similar for core features, but they do
tend to require explicit imports for standard libraries. I don't however
believe they need 30 different headers or imports to cover everything
that those provide in C.
Coding in C, you're debugging someone's module say, and you need print
something, so you need stdio.h included at the top. Then you detect some
error and need to do exit(1); now you need stdlib.h. Then you want to do
strcpy() or memcpy(), and you need string.h!
(At some point, you decide you don't need those debug prints, but now
what, do you have to get rid of those includes? It's just a pointless,
annoying dance.)
>
>>
>> When I suggested this is the past, people were up in arms about the
>> overheads of having to compile all those headers (in 2017, they were
>> 3-5KB lines in all for gcc on Windows/Linux).
>>
>
> Overhead is a smaller concern. Name clashes are bigger concern.
Examples? Somebody would be foolhardy to use names like 'printf' or
'exit' for their own, unrelated functions. (Compilers will anyway warn
about that.)
But I suggested this was done in a 'new' compiler mode used for
compiling fresh source code, not legacy code.
>> Yet the same people think nothing of using libraries like SDL2 (50K
>> lines of headers) or GTK2 (350K lines).
>>
>>> This does mean that some pre-C23 code will be incompatible with
>>> C23.
>>
>> This was also my view in the past, to draw a line under 'old' C and
>> to start using 'new' C.
>>
>> I understand C23 mode will be enabled by a compiler option
>> (-std=c23);
>
> In 2025.
> An expectations are, however, that several years down the road it would
> be a default. Then people would have to specify compiler options in
> order to get older standard. And at some point older standards will be
> dropped. Not only K&r and C90. C99 will be dropped as well. Not that I
> expect to live that long.
>
>> the same method could have been used to enable all std
>> headers, and for that to be the default.
>>
>> Hello World then becomes this one-liner:
>>
>> int main() {puts("Hello, World!");}
> Somehow I don't feel excited by the prospect.
It's an example of not having to specify '#include <stdio.h>'; i/o 'just
works'.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-04-03 15:26 +0000 |
| Message-ID | <6NxHP.363009$l0_4.293847@fx43.iad> |
| In reply to | #391928 |
bart <bc@freeuk.com> writes: >On 03/04/2025 14:44, Michael S wrote: >> Overhead is a smaller concern. Name clashes are bigger concern. > >Examples? Somebody would be foolhardy to use names like 'printf' or >'exit' for their own, unrelated functions. (Compilers will anyway warn >about that.) I've written my own printf and exit implementations in the past. Not all C code has a runtime that provides those name.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-03 16:52 +0100 |
| Message-ID | <vsmaro$10v9o$1@dont-email.me> |
| In reply to | #391929 |
On 03/04/2025 16:26, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> On 03/04/2025 14:44, Michael S wrote: > >>> Overhead is a smaller concern. Name clashes are bigger concern. >> >> Examples? Somebody would be foolhardy to use names like 'printf' or >> 'exit' for their own, unrelated functions. (Compilers will anyway warn >> about that.) > > I've written my own printf and exit implementations in the > past. Not all C code has a runtime that provides those name. Then you have to specify, somehow, that you don't want those automatically included. I mean, I'm sure there are people who want to buy cars with no engine, as they will install their own, but those will be in a tiny minority. It would make it super-annoying to have ensure you'd remembered to tick the boxes for 'engine' and '4 wheels' for 99.999% of people with normal needs. Since I wrote my post 50 minutes minutes ago, I had to put together a test program. I started off with 'stdio.h'. Then it need to use malloc (compiler reported an error) and I needed stdlib.h. I needed to zero that memory (need string.h for 'memset' after another compiler error). Then I wanted to time it; now I needed time.h (another compiler error, but here I had to guess it was time.h and not sys/time.h which also exists). It is quite exasperating. I can't even just use a header 'stdall.h' which contains all the rest, since there was a likelihood I'd have to post the test programs for others to try out, and you can't use private headers. Maybe paste a list of all 30 includes? That wouldn't be appreciated either!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-04 13:31 +0200 |
| Message-ID | <vsofu3$3b14s$1@dont-email.me> |
| In reply to | #391930 |
On 03/04/2025 17:52, bart wrote:
> On 03/04/2025 16:26, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 03/04/2025 14:44, Michael S wrote:
>>
>>>> Overhead is a smaller concern. Name clashes are bigger concern.
>>>
>>> Examples? Somebody would be foolhardy to use names like 'printf' or
>>> 'exit' for their own, unrelated functions. (Compilers will anyway warn
>>> about that.)
>>
>> I've written my own printf and exit implementations in the
>> past. Not all C code has a runtime that provides those name.
>
> Then you have to specify, somehow, that you don't want those
> automatically included.
>
It is not unusual in embedded systems to provide your own versions of
standard library functions. For example, I have regularly implemented
my own "exit" as something like :
_Noreturn void exit(int status) {
(void) status;
while (true) ;
}
I do that because in my embedded systems, the program never ends - but
the C startup code typically calls exit() after main() returns. This
pulls in exit() from the library, which pulls in everything for handling
at_exit() functions, which pulls in malloc(), and so on - for small
microcontrollers, you can sometimes end up with a significant fraction
of your flash used by library code you never want to use.
Similarly, sometimes you might want to replace standard library IO
functions with something appropriate for the small devices.
This is all undefined behaviour in the C standards (mostly UB because it
is not discussed or defined), but the way linkers work and the way most
C standard libraries are arranged means it works fine.
However, it's a bit more questionable if you are making your own
functions with names that coincide with standard library function names
but have different signatures.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-03 11:31 -0700 |
| Message-ID | <85y0whjdw3.fsf@nosuchdomain.example.com> |
| In reply to | #391908 |
bart <bc@freeuk.com> writes:
[...]
> I understand C23 mode will be enabled by a compiler option (-std=c23);
> the same method could have been used to enable all std headers, and
> for that to be the default.
The standard says exactly nothing about compiler options. "-std=c23"
is a convention used by *some* compilers (gcc and other compilers
designed to be compatible with it).
> Hello World then becomes this one-liner:
>
> int main() {puts("Hello, World!");}
A compiler could provide such an option as a non-conforming extension
with no change in the standard. I'm not aware that any compiler
has done so, or that there's been any demand for it. One reason
for the lack of demand might be that any code that depends on it
is not portable. (Older versions of MS Visual Studio create a
"stdafx.h" header, but newer versions appear to have dropped that.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-03 20:51 +0200 |
| Message-ID | <vsmlc4$1c39t$1@dont-email.me> |
| In reply to | #391938 |
On 03/04/2025 20:31, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> I understand C23 mode will be enabled by a compiler option (-std=c23);
>> the same method could have been used to enable all std headers, and
>> for that to be the default.
>
> The standard says exactly nothing about compiler options. "-std=c23"
> is a convention used by *some* compilers (gcc and other compilers
> designed to be compatible with it).
>
>> Hello World then becomes this one-liner:
>>
>> int main() {puts("Hello, World!");}
>
> A compiler could provide such an option as a non-conforming extension
> with no change in the standard. I'm not aware that any compiler
> has done so, or that there's been any demand for it. One reason
> for the lack of demand might be that any code that depends on it
> is not portable. (Older versions of MS Visual Studio create a
> "stdafx.h" header, but newer versions appear to have dropped that.)
>
gcc provides such an option :
gcc -include stdio.h hello_world.c
If someone really wanted to, they could easily make a shell script, bash
alias, Windows bat file, or whatever, as a wrapper for gcc with a whole
bunch of "-include" options for all the standard headers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-03 12:29 -0700 |
| Message-ID | <85ldshjb72.fsf@nosuchdomain.example.com> |
| In reply to | #391941 |
David Brown <david.brown@hesbynett.no> writes:
> On 03/04/2025 20:31, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> I understand C23 mode will be enabled by a compiler option (-std=c23);
>>> the same method could have been used to enable all std headers, and
>>> for that to be the default.
>> The standard says exactly nothing about compiler options.
>> "-std=c23"
>> is a convention used by *some* compilers (gcc and other compilers
>> designed to be compatible with it).
>>
>>> Hello World then becomes this one-liner:
>>>
>>> int main() {puts("Hello, World!");}
>> A compiler could provide such an option as a non-conforming
>> extension
>> with no change in the standard. I'm not aware that any compiler
>> has done so, or that there's been any demand for it. One reason
>> for the lack of demand might be that any code that depends on it
>> is not portable. (Older versions of MS Visual Studio create a
>> "stdafx.h" header, but newer versions appear to have dropped that.)
>>
>
> gcc provides such an option :
>
> gcc -include stdio.h hello_world.c
>
> If someone really wanted to, they could easily make a shell script,
> bash alias, Windows bat file, or whatever, as a wrapper for gcc with a
> whole bunch of "-include" options for all the standard headers.
I wouldn't call that "such an option". The kind of option being
discussed is one that would implicitly include *all* the standard
headers.
Sure, you could use it in a wrapper script, but it would be just
as easy to write a wrapper script that generates and compiles a
source file that includes all the standard headers and the source
file and then compiles that (with a #line directive so diagnostic
messages refer to the original source file).
My point is that, as far as I'm aware, nobody has implemented
"implicitly include all the standard headers", either as a compiler
option or as a wrapper script. I'm sure somebody has (I could do
it in a few minutes), but it's just not something that programmers
appear to want.
Of course part of the motivation for *not* wanting this is that
it results in non-portable code, and if it were standardized that
wouldn't be an issue.
And if it were standardized, <assert.h> would raise some issues,
since NDEBUG needs to be defined or not defined before including it.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-04-14 01:46 -0700 |
| Message-ID | <86ecxv9lkx.fsf@linuxsc.com> |
| In reply to | #391945 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: [considering ways of importing all headers defined as part of the standard library] > My point is that, as far as I'm aware, nobody has implemented > "implicitly include all the standard headers", either as a compiler > option or as a wrapper script. I'm sure somebody has (I could do > it in a few minutes), but it's just not something that programmers > appear to want. > > Of course part of the motivation for *not* wanting this is that > it results in non-portable code, and if it were standardized that > wouldn't be an issue. > > And if it were standardized, <assert.h> would raise some issues, > since NDEBUG needs to be defined or not defined before including it. Not really a problem, since if a different choice for NDEBUG were desired then it could be #define'd or #undef'ed, as appropriate, followed by another #include <assert.h>. That said, it's hard to imagine many people wanting such a thing. It's a very rare translation unit that needs or even wants access to symbols defined in every header in the standard library. And it flies in the face of the common practice of #include'ing only those headers that are actually needed in each translation unit.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-03 11:19 -0700 |
| Message-ID | <855xjlkszr.fsf@nosuchdomain.example.com> |
| In reply to | #391899 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> It is bold, perhaps, but there are certainly good reasons. As far as
> I can see we have some keywords that have dropped their
> underscore-capital form:
>
> alignas
> alignof
> bool
> static_assert
> thread_local
The underscore-capital forms still exist as alternate spellings.
Dropping _Bool et al would have broken existing code.
> And we have some new ones :
>
> constexpr
> false
> nullptr
> true
> typeof
> typeof_unequal
That last one is "typeof_unqual".
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-03 20:54 +0200 |
| Message-ID | <vsmlh7$1c39t$2@dont-email.me> |
| In reply to | #391936 |
On 03/04/2025 20:19, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> It is bold, perhaps, but there are certainly good reasons. As far as >> I can see we have some keywords that have dropped their >> underscore-capital form: >> >> alignas >> alignof >> bool >> static_assert >> thread_local > > The underscore-capital forms still exist as alternate spellings. > Dropping _Bool et al would have broken existing code. > Yes. But they are listed as alternate spellings, rather than keywords. I don't think it makes any difference, other than that if they were called "keywords" then they would need to be mentioned more in the standards. >> And we have some new ones : >> >> constexpr >> false >> nullptr >> true >> typeof >> typeof_unequal > > That last one is "typeof_unqual". > That makes much more sense :-)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-04-02 16:16 +0000 |
| Message-ID | <vpdHP.1828825$TBhc.94105@fx16.iad> |
| In reply to | #391841 |
Muttley@DastardlyHQ.org writes: >On Wed, 2 Apr 2025 16:59:45 +0200 >David Brown <david.brown@hesbynett.no> wibbled: >>On 02/04/2025 16:05, Muttley@DastardlyHQ.org wrote: ist first. > >>18. "unreachable()" is now standard. > >Googled it - don't see the point. That's a defect in your understanding, not a defect in the standard. I've found the gcc equivelent useful often in standalone applications (OS, Hypervisor, standalone utilities, etc).
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2025-04-03 08:45 +0000 |
| Message-ID | <vslhrm$7uv3$1@dont-email.me> |
| In reply to | #391846 |
On Wed, 02 Apr 2025 16:16:27 GMT scott@slp53.sl.home (Scott Lurndal) wibbled: >Muttley@DastardlyHQ.org writes: >>On Wed, 2 Apr 2025 16:59:45 +0200 >>David Brown <david.brown@hesbynett.no> wibbled: >>>On 02/04/2025 16:05, Muttley@DastardlyHQ.org wrote: >ist first. >> >>>18. "unreachable()" is now standard. >> >>Googled it - don't see the point. > >That's a defect in your understanding, not a defect in the standard. > >I've found the gcc equivelent useful often in standalone >applications (OS, Hypervisor, standalone utilities, etc). Enlighten me then.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-03 11:41 +0200 |
| Message-ID | <vsll4b$8mfb$3@dont-email.me> |
| In reply to | #391894 |
On 03/04/2025 10:45, Muttley@DastardlyHQ.org wrote:
> On Wed, 02 Apr 2025 16:16:27 GMT
> scott@slp53.sl.home (Scott Lurndal) wibbled:
>> Muttley@DastardlyHQ.org writes:
>>> On Wed, 2 Apr 2025 16:59:45 +0200
>>> David Brown <david.brown@hesbynett.no> wibbled:
>>>> On 02/04/2025 16:05, Muttley@DastardlyHQ.org wrote:
>> ist first.
>>>
>>>> 18. "unreachable()" is now standard.
>>>
>>> Googled it - don't see the point.
>>
>> That's a defect in your understanding, not a defect in the standard.
>>
>> I've found the gcc equivelent useful often in standalone
>> applications (OS, Hypervisor, standalone utilities, etc).
>
> Enlighten me then.
>
I can't tell you what Scott uses it for, but I have used gcc's
__builtin_unreachable() a fair number of times in my coding. I use it
to inform both the compiler and human readers that a path is unreachable:
switch (x) {
case 1 : ...
case 2 : ...
case 3 : ...
default : __builtin_unreachable();
}
I can also use it to inform the compiler about data :
if ((x < 0) || (x > 10)) __builtin_unreachable();
// x must be 1 .. 10
Mostly I have it wrapped in macros that let me conveniently have
run-time checking during testing or debugging, and extra efficiency in
the code when I am confident it is bug-free.
Good use of __builtin_unreachable() can result in smaller and faster
code, and possibly improved static error checking. It is related to the
C++23 "assume" attribute (which is also available as a gcc extension in
any C and C++ version).
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2025-04-03 11:07 +0000 |
| Message-ID | <vslq6b$ginf$1@dont-email.me> |
| In reply to | #391902 |
On Thu, 3 Apr 2025 11:41:31 +0200
David Brown <david.brown@hesbynett.no> wibbled:
>On 03/04/2025 10:45, Muttley@DastardlyHQ.org wrote:
>> On Wed, 02 Apr 2025 16:16:27 GMT
>> scott@slp53.sl.home (Scott Lurndal) wibbled:
>>> Muttley@DastardlyHQ.org writes:
>>>> On Wed, 2 Apr 2025 16:59:45 +0200
>>>> David Brown <david.brown@hesbynett.no> wibbled:
>>>>> On 02/04/2025 16:05, Muttley@DastardlyHQ.org wrote:
>>> ist first.
>>>>
>>>>> 18. "unreachable()" is now standard.
>>>>
>>>> Googled it - don't see the point.
>>>
>>> That's a defect in your understanding, not a defect in the standard.
>>>
>>> I've found the gcc equivelent useful often in standalone
>>> applications (OS, Hypervisor, standalone utilities, etc).
>>
>> Enlighten me then.
>>
>
>I can't tell you what Scott uses it for, but I have used gcc's
>__builtin_unreachable() a fair number of times in my coding. I use it
>to inform both the compiler and human readers that a path is unreachable:
What for? The compiler doesn't care and a human reader would probably
prefer a meaningful comment if its not obvious. If you're worried about the
code accidently going there use an assert.
> switch (x) {
> case 1 : ...
> case 2 : ...
> case 3 : ...
> default : __builtin_unreachable();
> }
>
>I can also use it to inform the compiler about data :
>
> if ((x < 0) || (x > 10)) __builtin_unreachable();
> // x must be 1 .. 10
And that'll do what? You want the compiler to compile in a hidden value check?
>Good use of __builtin_unreachable() can result in smaller and faster
>code, and possibly improved static error checking. It is related to the
Sorry, don't see how. If you think a piece of code is unreachable then don't
put it in in the first place!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-03 15:58 +0200 |
| Message-ID | <vsm45d$ncfh$4@dont-email.me> |
| In reply to | #391905 |
On 03/04/2025 13:07, Muttley@DastardlyHQ.org wrote:
> On Thu, 3 Apr 2025 11:41:31 +0200
> David Brown <david.brown@hesbynett.no> wibbled:
>> On 03/04/2025 10:45, Muttley@DastardlyHQ.org wrote:
>>> On Wed, 02 Apr 2025 16:16:27 GMT
>>> scott@slp53.sl.home (Scott Lurndal) wibbled:
>>>> Muttley@DastardlyHQ.org writes:
>>>>> On Wed, 2 Apr 2025 16:59:45 +0200
>>>>> David Brown <david.brown@hesbynett.no> wibbled:
>>>>>> On 02/04/2025 16:05, Muttley@DastardlyHQ.org wrote:
>>>> ist first.
>>>>>
>>>>>> 18. "unreachable()" is now standard.
>>>>>
>>>>> Googled it - don't see the point.
>>>>
>>>> That's a defect in your understanding, not a defect in the standard.
>>>>
>>>> I've found the gcc equivelent useful often in standalone
>>>> applications (OS, Hypervisor, standalone utilities, etc).
>>>
>>> Enlighten me then.
>>>
>>
>> I can't tell you what Scott uses it for, but I have used gcc's
>> __builtin_unreachable() a fair number of times in my coding. I use it
>> to inform both the compiler and human readers that a path is unreachable:
>
> What for? The compiler doesn't care and a human reader would probably
> prefer a meaningful comment if its not obvious. If you're worried about the
> code accidently going there use an assert.
The compiler /does/ care - as I said, it can generate better code and
sometimes do better static error checking.
Human readers prefer clear code to comments. Comments get out of sync -
code does not.
>
>> switch (x) {
>> case 1 : ...
>> case 2 : ...
>> case 3 : ...
>> default : __builtin_unreachable();
>> }
>>
>> I can also use it to inform the compiler about data :
>>
>> if ((x < 0) || (x > 10)) __builtin_unreachable();
>> // x must be 1 .. 10
>
> And that'll do what? You want the compiler to compile in a hidden value check?
>
No, I want the compiler to be able to take advantage of the information
that I have, that it could not otherwise infer from the code.
>> Good use of __builtin_unreachable() can result in smaller and faster
>> code, and possibly improved static error checking. It is related to the
>
> Sorry, don't see how. If you think a piece of code is unreachable then don't
> put it in in the first place!
>
Ignorance is curable - wilful ignorance is much more stubborn. But I
will try.
Let me give you an example, paraphrased from the C23 standards:
#include <stddef.h>
enum Colours { red, green, blue };
unsigned int colour_to_hex(enum Colours c) {
switch (c) {
case red : return 0xff'00'00;
case green : return 0x00'ff'00;
case blue : return 0x00'00'ff;
}
unreachable();
}
With "unreachable()", "gcc -std=c23 -O2 -Wall" gives :
colour_to_hex:
mov edi, edi
mov eax, DWORD PTR CSWTCH.1[0+rdi*4]
ret
Without it, it gives :
colour_to_hex:
cmp edi, 2
ja .L1
mov edi, edi
mov eax, DWORD PTR CSWTCH.1[0+rdi*4]
.L1:
ret
That is noticeably bigger and slower code. gcc also gives a warning
"control reaches end of non-void function".
Neither "// This should never be reached" nor "assert(false);" is a
suitable alternative.
Try it for yourself.
<https://godbolt.org/z/8EG11MW4o>
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2025-04-04 09:40 +0000 |
| Message-ID | <vso9fa$34vau$1@dont-email.me> |
| In reply to | #391922 |
On Thu, 3 Apr 2025 15:58:05 +0200
David Brown <david.brown@hesbynett.no> wibbled:
>Human readers prefer clear code to comments. Comments get out of sync -
>code does not.
Thats not a reason for not using comments. Its very easy to understand your
own code that you've just written - not so much for someone else or for you
years down the line.
>Ignorance is curable - wilful ignorance is much more stubborn. But I
>will try.
Guffaw! You should do standup.
>Let me give you an example, paraphrased from the C23 standards:
>
>
> #include <stddef.h>
>
> enum Colours { red, green, blue };
>
> unsigned int colour_to_hex(enum Colours c) {
> switch (c) {
> case red : return 0xff'00'00;
> case green : return 0x00'ff'00;
> case blue : return 0x00'00'ff;
> }
> unreachable();
> }
>
>
>With "unreachable()", "gcc -std=c23 -O2 -Wall" gives :
>
> colour_to_hex:
> mov edi, edi
> mov eax, DWORD PTR CSWTCH.1[0+rdi*4]
> ret
>
>Without it, it gives :
>
> colour_to_hex:
> cmp edi, 2
> ja .L1
> mov edi, edi
> mov eax, DWORD PTR CSWTCH.1[0+rdi*4]
> .L1:
> ret
Except its not unreachable is it? There's nothing in C to prevent you
calling that function with a value other than defined in the enum so what
happens if there's a bug and it hits unreachable? Oh thats right , its
"undefined" ie , a crash or hidden bug with bugger all info.
>Neither "// This should never be reached" nor "assert(false);" is a
>suitable alternative.
In your opinion. I would never use that example above, its just asking for
trouble down the line.
Also FWIW, putting seperators in the hex values makes it less readable to me
not more.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-04 13:39 +0200 |
| Message-ID | <vsogcq$3b14s$2@dont-email.me> |
| In reply to | #391977 |
On 04/04/2025 11:40, Muttley@DastardlyHQ.org wrote:
> On Thu, 3 Apr 2025 15:58:05 +0200
> David Brown <david.brown@hesbynett.no> wibbled:
>> Human readers prefer clear code to comments. Comments get out of sync -
>> code does not.
>
> Thats not a reason for not using comments.
It is a reason for never using a comment when you can express the same
thing in code.
> Its very easy to understand your
> own code that you've just written - not so much for someone else or for you
> years down the line.
If that's your problem, write better code - not more comments.
Comments should say /why/ you are doing something, not /what/ you are doing.
>
>> Ignorance is curable - wilful ignorance is much more stubborn. But I
>> will try.
>
> Guffaw! You should do standup.
>
>> Let me give you an example, paraphrased from the C23 standards:
>>
>>
>> #include <stddef.h>
>>
>> enum Colours { red, green, blue };
>>
>> unsigned int colour_to_hex(enum Colours c) {
>> switch (c) {
>> case red : return 0xff'00'00;
>> case green : return 0x00'ff'00;
>> case blue : return 0x00'00'ff;
>> }
>> unreachable();
>> }
>>
>>
>> With "unreachable()", "gcc -std=c23 -O2 -Wall" gives :
>>
>> colour_to_hex:
>> mov edi, edi
>> mov eax, DWORD PTR CSWTCH.1[0+rdi*4]
>> ret
>>
>> Without it, it gives :
>>
>> colour_to_hex:
>> cmp edi, 2
>> ja .L1
>> mov edi, edi
>> mov eax, DWORD PTR CSWTCH.1[0+rdi*4]
>> .L1:
>> ret
>
> Except its not unreachable is it?
It /is/ unreachable. That's why I wrote it.
> There's nothing in C to prevent you
> calling that function with a value other than defined in the enum so what
> happens if there's a bug and it hits unreachable?
There's nothing in the English language preventing me from calling you a
"very stable genius" - but I can assure you that it is not going to happen.
> Oh thats right , its
> "undefined" ie , a crash or hidden bug with bugger all info.
Welcome to the world of software development. If I specify a function
as working for input values "red", "green", and "blue", and you choose
to misuse it, that is /your/ fault, not mine. I write the code to work
with valid inputs and give no promises about what will happen with any
other input.
>
>> Neither "// This should never be reached" nor "assert(false);" is a
>> suitable alternative.
>
> In your opinion. I would never use that example above, its just asking for
> trouble down the line.
>
> Also FWIW, putting seperators in the hex values makes it less readable to me
> not more.
>
Again, that's /your/ problem.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2025-04-04 14:10 +0000 |
| Message-ID | <vsop83$3k0rp$1@dont-email.me> |
| In reply to | #391988 |
On Fri, 4 Apr 2025 13:39:06 +0200
David Brown <david.brown@hesbynett.no> wibbled:
>On 04/04/2025 11:40, Muttley@DastardlyHQ.org wrote:
>> On Thu, 3 Apr 2025 15:58:05 +0200
>> David Brown <david.brown@hesbynett.no> wibbled:
>>> Human readers prefer clear code to comments. Comments get out of sync -
>>> code does not.
>>
>> Thats not a reason for not using comments.
>
>It is a reason for never using a comment when you can express the same
>thing in code.
>
>If that's your problem, write better code - not more comments.
Ah, the typical arrogant programmer who thinks their code is so well written
that anyone can understand it and comments arn't required. Glad I don't have
to work on anything you've written.
>
>Comments should say /why/ you are doing something, not /what/ you are doing.
Rubbish. A lot of the time what is being done is just as obtuse as why.
>> Except its not unreachable is it?
>
>It /is/ unreachable. That's why I wrote it.
Really?
int main()
{
colour_to_hex(10);
return 0;
}
You have no idea how someone might try and use that function in the future.
Just assuming they'll always pass parameters within limits is not just
cretinous, its dangerous.
>> There's nothing in C to prevent you
>> calling that function with a value other than defined in the enum so what
>> happens if there's a bug and it hits unreachable?
>
>There's nothing in the English language preventing me from calling you a
>"very stable genius" - but I can assure you that it is not going to happen.
Poor analogy.
>> Oh thats right , its
>> "undefined" ie , a crash or hidden bug with bugger all info.
>
>Welcome to the world of software development. If I specify a function
>as working for input values "red", "green", and "blue", and you choose
>to misuse it, that is /your/ fault, not mine. I write the code to work
>with valid inputs and give no promises about what will happen with any
>other input.
Its your fault if it dies in a heap with no info or worse returns but does
some random shit. Any well written API function should do at least basic
sanity checking on its inputs and return a fail or assert unless its very low
level and speed is the priority eg strlen().
But then you're arrogant, so no surprise really.
>> Also FWIW, putting seperators in the hex values makes it less readable to me
>> not more.
>>
>
>Again, that's /your/ problem.
See above.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-04 17:12 +0200 |
| Message-ID | <vsostb$3nn12$1@dont-email.me> |
| In reply to | #391995 |
On 04/04/2025 16:10, Muttley@DastardlyHQ.org wrote:
> On Fri, 4 Apr 2025 13:39:06 +0200
> David Brown <david.brown@hesbynett.no> wibbled:
>> On 04/04/2025 11:40, Muttley@DastardlyHQ.org wrote:
>>> On Thu, 3 Apr 2025 15:58:05 +0200
>>> David Brown <david.brown@hesbynett.no> wibbled:
>>>> Human readers prefer clear code to comments. Comments get out of sync -
>>>> code does not.
>>>
>>> Thats not a reason for not using comments.
>>
>> It is a reason for never using a comment when you can express the same
>> thing in code.
>>
>> If that's your problem, write better code - not more comments.
>
> Ah, the typical arrogant programmer who thinks their code is so well written
> that anyone can understand it and comments arn't required. Glad I don't have
> to work on anything you've written.
Arrogance would be judging my code without having seen it. Writing code
that is clear and does not require comments to say what it does is not
arrogance - it is good coding.
>
>>
>> Comments should say /why/ you are doing something, not /what/ you are doing.
>
> Rubbish. A lot of the time what is being done is just as obtuse as why.
That can /occasionally/ be the case. But if it happens a lot of the
time, you are writing poor code. It's time to refactor or rename.
>
>>> Except its not unreachable is it?
>>
>> It /is/ unreachable. That's why I wrote it.
>
> Really?
>
> int main()
> {
> colour_to_hex(10);
> return 0;
> }
UB. It's /your/ fault.
Most of my code is written on the assumption that the people using it
are not incompetent morons. They may make mistakes in their coding, but
not like that. The code in question is unreachable because the kind of
person who could write a call like that would not be working with my code.
There are situations where you want to make your code handle as wide a
range of inputs as possible, and provide error returns to help catch
mistakes. Typically that is for boundary or interface code - such as
libraries written for other people to use.
For internal code within TU's or parts of a project, such things are
just a waste of effort. They can make it significantly harder to design
the code, since you have to figure out what behaviour is appropriate for
invalid input - what should a function called "colour_to_hex" do when
presented with an input that is not a colour? Sometimes they are
impossible to implement - how do you check the precondition "this is a
valid pointer" ? They limit your functionality and future expansion -
if I have specified that inputs other than "red", "green" or "blue" give
the result 0x00'00'00, then I can't add "purple" to the list of colours.
There are all sorts of reasons why it is a good idea for functions to
have pre-conditions, and for letting calls to the function without
satisfying those pre-conditions be undefined behaviour.
>
> You have no idea how someone might try and use that function in the future.
Yes, I do.
> Just assuming they'll always pass parameters within limits is not just
> cretinous, its dangerous.
Nope. It is how software development works. If you don't understand
about function specifications, you might want to read up on some basic
computer science.
>
>>> There's nothing in C to prevent you
>>> calling that function with a value other than defined in the enum so what
>>> happens if there's a bug and it hits unreachable?
>>
>> There's nothing in the English language preventing me from calling you a
>> "very stable genius" - but I can assure you that it is not going to happen.
>
> Poor analogy.
>
>>> Oh thats right , its
>>> "undefined" ie , a crash or hidden bug with bugger all info.
>>
>> Welcome to the world of software development. If I specify a function
>> as working for input values "red", "green", and "blue", and you choose
>> to misuse it, that is /your/ fault, not mine. I write the code to work
>> with valid inputs and give no promises about what will happen with any
>> other input.
>
> Its your fault if it dies in a heap with no info or worse returns but does
> some random shit.
If the caller fails to satisfy the pre-conditions of the function,
that's the caller's fault. If the function fails to satisfy the
post-conditions when called with correct pre-conditions, that's the
function's fault. That's the contract, and that's the basis of all
programming.
> Any well written API function should do at least basic
> sanity checking on its inputs and return a fail or assert unless its very low
> level and speed is the priority eg strlen().
>
At clear boundaries of development responsibility - such as the public
functions of a library - then it is often nice to add some extra
checking and error feedback to help users of the library find their bugs.
> But then you're arrogant, so no surprise really.
>
>>> Also FWIW, putting seperators in the hex values makes it less readable to me
>>> not more.
>>>
>>
>> Again, that's /your/ problem.
>
> See above.
>
[toc] | [prev] | [next] | [standalone]
Page 16 of 23 — ← Prev page 1 … 14 15 [16] 17 18 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web