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 20 of 23 — ← Prev page 1 … 18 19 [20] 21 22 23 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-08 23:34 +0100 |
| Message-ID | <vt488v$35hh3$1@dont-email.me> |
| In reply to | #392222 |
On 08/04/2025 22:46, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
>> Clearly, they're not quite as fully supported as short, int etc; they
>> are usually just aliases. But that needn't stop them being shown on
>> such a chart.
>
> Apparently the author of the chart chose to include types that are
> defined by the core language, not by the library.
So here you're finally admitteding they are a different rank.
> I think that was a
> perfectly valid choice. Adding all the types specified in the library
> would make the chart far too big and not much more informative.
So there is a place for 'extended integer types', '_Bitint',
'_Decimal128' and 'long double _Complex', which people could spend years
coding in C and never use, but not for the equivalents of these everyday
types:
i8 i16 i32 i64
u8 u16 u32 u64
which are the core integer types of languages like C#, D, Go, Rust, Zig,
Java (signed only), Nim and Odin.
To me it is astounding that such fundamental machine types (and C is one
of the those closest to hardware) should be omitted from such a diagram.
But clearly you have a different view even after insisting they are an
fully integrated part of the language.
> If you don't like it, make your own chart.
Actually I can't quite see the purpose of this chart, why it has to be
so complicated (even with bits missing) or who it is for.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-08 17:33 -0700 |
| Message-ID | <87r022qimb.fsf@nosuchdomain.example.com> |
| In reply to | #392223 |
bart <bc@freeuk.com> writes:
> On 08/04/2025 22:46, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>
>>> Clearly, they're not quite as fully supported as short, int etc; they
>>> are usually just aliases. But that needn't stop them being shown on
>>> such a chart.
>> Apparently the author of the chart chose to include types that are
>> defined by the core language, not by the library.
>
> So here you're finally admitteding they are a different rank.
I'm not "finally admitting" anything. I don't know or care what you
mean by "rank" (it happens to be a technical term in the standard, but
that's clearly not what you meant).
[SNIP]
> Actually I can't quite see the purpose of this chart, why it has to be
> so complicated (even with bits missing) or who it is for.
So you're wasting time arguing about something you don't even care
about. Consider not doing that anymore.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-04-08 22:47 -0400 |
| Message-ID | <vt4n3d$3e8hi$1@dont-email.me> |
| In reply to | #392223 |
bart <bc@freeuk.com> writes: > On 08/04/2025 22:46, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: ...>> Apparently the author of the chart chose to include types that are >> defined by the core language, not by the library. > > So here you're finally admitteding they are a different rank. The core language and the library are equal in rank, both being different parts of any implementation of C. > Actually I can't quite see the purpose of this chart, why it has to be > so complicated (even with bits missing) or who it is for. Every category shown on that chart has rules that are apply only to types in that category. The chart is for people who have not yet memorized the relationships shown, and who need to understand the rules that apply to each category. That clearly doesn't apply to you, since understanding the rules would make it more difficult for you to complain about them.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-04-08 21:36 -0700 |
| Message-ID | <86ecy2c5o4.fsf@linuxsc.com> |
| In reply to | #392230 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > bart <bc@freeuk.com> writes: > >> On 08/04/2025 22:46, Keith Thompson wrote: >> >>> bart <bc@freeuk.com> writes: > > ...>> Apparently the author of the chart chose to include types > ...>> that are > >>> defined by the core language, not by the library. >> >> So here you're finally admitteding they are a different rank. > > The core language and the library are equal in rank, both being > different parts of any implementation of C. This statement isn't exactly right. Some parts of the standard library are available only in hosted implementations, and not in freestanding implementations.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-08 23:12 -0700 |
| Message-ID | <87mscprhhe.fsf@nosuchdomain.example.com> |
| In reply to | #392232 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> bart <bc@freeuk.com> writes:
>>> On 08/04/2025 22:46, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>> ...>> Apparently the author of the chart chose to include types
>> ...>> that are
>>
>>>> defined by the core language, not by the library.
>>>
>>> So here you're finally admitteding they are a different rank.
>>
>> The core language and the library are equal in rank, both being
>> different parts of any implementation of C.
>
> This statement isn't exactly right. Some parts of the standard
> library are available only in hosted implementations, and not in
> freestanding implementations.
True. Also, freestanding implementations must support <stddef.h>
and <stdint.h>, among several other headers.
--
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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-04-09 10:55 +0300 |
| Message-ID | <20250409105549.000037dd@yahoo.com> |
| In reply to | #392237 |
On Tue, 08 Apr 2025 23:12:13 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > >> bart <bc@freeuk.com> writes: > >>> On 08/04/2025 22:46, Keith Thompson wrote: > >>>> bart <bc@freeuk.com> writes: > >> ...>> Apparently the author of the chart chose to include types > >> ...>> that are > >> > >>>> defined by the core language, not by the library. > >>> > >>> So here you're finally admitteding they are a different rank. > >> > >> The core language and the library are equal in rank, both being > >> different parts of any implementation of C. > > > > This statement isn't exactly right. Some parts of the standard > > library are available only in hosted implementations, and not in > > freestanding implementations. > > True. Also, freestanding implementations must support <stddef.h> > and <stdint.h>, among several other headers. > May be in some formal sense headers and library routines that are mandatory for freestanding implementations belong to the same rank as core language. But in practice there exists an obvious difference. In the first case, name clashes are avoidable (sometimes with toothless threat that they can happen in the future) and in the second case they are unavoidable.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-04-09 13:52 -0700 |
| Message-ID | <86semhawhs.fsf@linuxsc.com> |
| In reply to | #392238 |
Michael S <already5chosen@yahoo.com> writes: > On Tue, 08 Apr 2025 23:12:13 -0700 > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >>> >>>> bart <bc@freeuk.com> writes: >>>> >>>>> On 08/04/2025 22:46, Keith Thompson wrote: >>>>> >>>>>> bart <bc@freeuk.com> writes: >>>> >>>> ...>> Apparently the author of the chart chose to include types >>>> ...>> that are >>>> >>>>>> defined by the core language, not by the library. >>>>> >>>>> So here you're finally admitteding they are a different rank. >>>> >>>> The core language and the library are equal in rank, both being >>>> different parts of any implementation of C. >>> >>> This statement isn't exactly right. Some parts of the standard >>> library are available only in hosted implementations, and not in >>> freestanding implementations. >> >> True. Also, freestanding implementations must support <stddef.h> >> and <stdint.h>, among several other headers. > > May be in some formal sense headers and library routines that are > mandatory for freestanding implementations belong to the same rank as > core language. But in practice there exists an obvious difference. In > the first case, name clashes are avoidable (sometimes with toothless > threat that they can happen in the future) and in the second case they > are unavoidable. It's hard for me to make sense sense of this comment. The only library routines that are required in standard C are those documented as part of a section for one of the standard headers. For freestanding implementations in particular, there are only two names (va_copy and va_end) that might correspond to library functions, and if they do then the names are reserved for that purpose. Do you mean to suggest that user code defining either va_copy or va_end as a symbol with external linkage is unavoidable? Any user code that does so could be summarily rejected by the implementation. It's hard to imagine anyone writing user code wanting to define either of those names as a symbol with external linkage.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-04-10 11:50 +0300 |
| Message-ID | <20250410115004.00005276@yahoo.com> |
| In reply to | #392289 |
On Wed, 09 Apr 2025 13:52:15 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > > On Tue, 08 Apr 2025 23:12:13 -0700 > > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > > > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> > >>> James Kuyper <jameskuyper@alumni.caltech.edu> writes: > >>> > >>>> bart <bc@freeuk.com> writes: > >>>> > >>>>> On 08/04/2025 22:46, Keith Thompson wrote: > >>>>> > >>>>>> bart <bc@freeuk.com> writes: > >>>> > >>>> ...>> Apparently the author of the chart chose to include types > >>>> ...>> that are > >>>> > >>>>>> defined by the core language, not by the library. > >>>>> > >>>>> So here you're finally admitteding they are a different rank. > >>>> > >>>> The core language and the library are equal in rank, both being > >>>> different parts of any implementation of C. > >>> > >>> This statement isn't exactly right. Some parts of the standard > >>> library are available only in hosted implementations, and not in > >>> freestanding implementations. > >> > >> True. Also, freestanding implementations must support <stddef.h> > >> and <stdint.h>, among several other headers. > > > > May be in some formal sense headers and library routines that are > > mandatory for freestanding implementations belong to the same rank > > as core language. But in practice there exists an obvious > > difference. In the first case, name clashes are avoidable > > (sometimes with toothless threat that they can happen in the > > future) and in the second case they are unavoidable. > > It's hard for me to make sense sense of this comment. The only > library routines that are required in standard C are those > documented as part of a section for one of the standard headers. > For freestanding implementations in particular, there are only > two names (va_copy and va_end) that might correspond to library > functions, and if they do then the names are reserved for that > purpose. Do you mean to suggest that user code defining either > va_copy or va_end as a symbol with external linkage is > unavoidable? Any user code that does so could be summarily > rejected by the implementation. It's hard to imagine anyone > writing user code wanting to define either of those names as a > symbol with external linkage. I merely wanted to say that it is pretty easy to write a legal, if not necessarily sensible, code that uses variable named 'memcpy' and function named 'size_t'. OTOH, you can't name you variable 'break' or 'continue'. Or even 'bool', if you happen to use C23 compiler.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-04-11 12:27 -0400 |
| Message-ID | <vtbfuf$1tc7o$4@dont-email.me> |
| In reply to | #392308 |
On 4/10/25 04:50, Michael S wrote: ... > I merely wanted to say that it is pretty easy to write a legal, if not > necessarily sensible, code that uses variable named 'memcpy' and > function named 'size_t'. OTOH, you can't name you variable 'break' or > 'continue'. Or even 'bool', if you happen to use C23 compiler. Yes, the rules for reserved identifiers are different for the keywords that are part of the language syntax, than for the identifiers that identify parts of the standard library. Lots of other things are different between them, too. However, they are still both parts of a conforming implementation of C, one covered by clause 6, and the other by clause 7. Also, note that all identifiers from the standard library that have external linkage are reserved for use as identifiers with external linkage. memcpy has external linkage, so you cannot define such a variable with external linkage. size_t is a typedef, which has no linkage.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-04-14 01:24 -0700 |
| Message-ID | <86ikn79mlq.fsf@linuxsc.com> |
| In reply to | #392308 |
Michael S <already5chosen@yahoo.com> writes: > On Wed, 09 Apr 2025 13:52:15 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: [...distinction between hosted implementions and freestanding implementations...] >>> May be in some formal sense headers and library routines that are >>> mandatory for freestanding implementations belong to the same rank >>> as core language. But in practice there exists an obvious >>> difference. In the first case, name clashes are avoidable >>> (sometimes with toothless threat that they can happen in the >>> future) and in the second case they are unavoidable. >> >> It's hard for me to make sense sense of this comment. The only >> library routines that are required in standard C are those >> documented as part of a section for one of the standard headers. >> For freestanding implementations in particular, there are only >> two names (va_copy and va_end) that might correspond to library >> functions, and if they do then the names are reserved for that >> purpose. Do you mean to suggest that user code defining either >> va_copy or va_end as a symbol with external linkage is >> unavoidable? Any user code that does so could be summarily >> rejected by the implementation. It's hard to imagine anyone >> writing user code wanting to define either of those names as a >> symbol with external linkage. > > I merely wanted to say that it is pretty easy to write a legal, if > not necessarily sensible, code that uses variable named 'memcpy' > and function named 'size_t'. OTOH, you can't name you variable > 'break' or 'continue'. Or even 'bool', if you happen to use C23 > compiler. I sort of agree with you (even if in practice it isn't hard to avoid using identifiers like memcpy or size_t). I was confused because this problem doesn't have much to do with whether an implementation is freestanding or not. There are different kinds of identifiers, and the different kinds have different properties about where they may or may not be used. Do you really have a problem avoiding identifiers defined in this or that library header, either for all headers or just those headers required for freestanding implementations?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-04-14 12:55 +0300 |
| Message-ID | <20250414125529.00000673@yahoo.com> |
| In reply to | #392493 |
On Mon, 14 Apr 2025 01:24:49 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > about where they may or may not be used. Do you really have a > problem avoiding identifiers defined in this or that library > header, either for all headers or just those headers required for > freestanding implementations? I don't know. In order to know I'd have to include all standard headers into all of my C files But I would guess that for headers required for freestanding implementations I would have no problems. But that's me. People with less experience or with lesser tendency to recollect unimportant things (most likely at cost of reduced reliability of the memory store for more important things) can have different experience.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-05-06 06:56 -0700 |
| Message-ID | <86a57p3kro.fsf@linuxsc.com> |
| In reply to | #392498 |
Michael S <already5chosen@yahoo.com> writes: > On Mon, 14 Apr 2025 01:24:49 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> about where they may or may not be used. Do you really have a >> problem avoiding identifiers defined in this or that library >> header, either for all headers or just those headers required for >> freestanding implementations? > > I don't know. In order to know I'd have to include all > standard headers into all of my C files Let me ask the question differently. Have you ever run into an actual problem due to inadvertent collision with a reserved identifier? > But I would guess that for headers required for freestanding > implementations I would have no problems. There are a few freestanding-required headers that I use often enough that for practical purposes they can be considered as always having been #include'd. Those headers are <limits.h>, <stdarg.h>, and <stddef.h>. For headers more generally, <stdio.h>, <stdlib.h>, and <string.h> are the most prevalent; there are cases where these headers have not been #include'd, but those cases are the exception rather than the rule. All other headers I #include only on an as-needed basis, although the threshold is higher for some than for others. A good example is <errno.h>. I try to limit those .c files where <errno.h> has been #include'd, because of the rule about preprocessor symbols starting with E (which I treat as ruling out any macro starting with the letter E, even though the rule in the C standard might be somewhat different). For comparison, I'm okay with the rule that function names that start str[a-z], mem[a-z], or wcs[a-s] should be avoided everywhere (because of <stdlib.h> and <string.h>), and similarly for function names that start either is[a-z] or to[a-z] (because of <ctype.h>). A good resource for finding symbols to avoid is the section on Future library directions, which offers a nicely compact summary of the most significant reserved names.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-06 13:25 -0700 |
| Message-ID | <87bjs5fpvi.fsf@nosuchdomain.example.com> |
| In reply to | #393208 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Michael S <already5chosen@yahoo.com> writes:
>> On Mon, 14 Apr 2025 01:24:49 -0700
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> about where they may or may not be used. Do you really have a
>>> problem avoiding identifiers defined in this or that library
>>> header, either for all headers or just those headers required for
>>> freestanding implementations?
>>
>> I don't know. In order to know I'd have to include all
>> standard headers into all of my C files
>
> Let me ask the question differently. Have you ever run into an
> actual problem due to inadvertent collision with a reserved
> identifier?
I'm not Michael, but I was once mildly inconvienced because I
defined a logging function called log(). The solution was trivial:
I changed the name.
[...]
--
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-05-08 08:37 -0700 |
| Message-ID | <867c2r15bc.fsf@linuxsc.com> |
| In reply to | #393217 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Mon, 14 Apr 2025 01:24:49 -0700 >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> about where they may or may not be used. Do you really have a >>>> problem avoiding identifiers defined in this or that library >>>> header, either for all headers or just those headers required for >>>> freestanding implementations? >>> >>> I don't know. In order to know I'd have to include all >>> standard headers into all of my C files >> >> Let me ask the question differently. Have you ever run into an >> actual problem due to inadvertent collision with a reserved >> identifier? > > I'm not Michael, but I was once mildly inconvienced because I > defined a logging function called log(). The solution was trivial: > I changed the name. Yes, I expect I have run into similar situations. What I was wondering about were problems where either the existence of the problem or what to do to fix it needed more than a minimal effort.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-05-08 15:48 +0000 |
| Message-ID | <Xm4TP.29894$JRnc.17616@fx37.iad> |
| In reply to | #393255 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> Michael S <already5chosen@yahoo.com> writes: >>> >>>> On Mon, 14 Apr 2025 01:24:49 -0700 >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>> >>>>> about where they may or may not be used. Do you really have a >>>>> problem avoiding identifiers defined in this or that library >>>>> header, either for all headers or just those headers required for >>>>> freestanding implementations? >>>> >>>> I don't know. In order to know I'd have to include all >>>> standard headers into all of my C files >>> >>> Let me ask the question differently. Have you ever run into an >>> actual problem due to inadvertent collision with a reserved >>> identifier? >> >> I'm not Michael, but I was once mildly inconvienced because I >> defined a logging function called log(). The solution was trivial: >> I changed the name. > >Yes, I expect I have run into similar situations. What I was >wondering about were problems where either the existence of >the problem or what to do to fix it needed more than a minimal >effort. I recall running into issues using variables named 'index' when porting code to SVR4 when the BSD compatibility layer was present. https://man.freebsd.org/cgi/man.cgi?query=index&sektion=3
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-05-08 16:32 +0000 |
| Message-ID | <20250508092354.556@kylheku.com> |
| In reply to | #393256 |
On 2025-05-08, Scott Lurndal <scott@slp53.sl.home> wrote: > I recall running into issues using variables named 'index' > when porting code to SVR4 when the BSD compatibility layer > was present. I've also run into issues with clashes with BSD-specific functions on those systems. It's because the BSD people refuse to understand how feature selection macros are supposed to work. In BSD toolchains, if you don't specify any -D_WHATEVER=BLAH feature selection macro, then all identifiers are visible. When when features are specified, they *restrict* visibility. When you specify -D_FOO and -D_BAR, you get the *intersection* of FOO and BAR. That includes compiler dialect selection options. Under BSDs, if you specify, say, "-ansi" on your command line, you are not only getting a certain dialect from the compiler, but the BSD header files like <stdio.h> will hide POSIX functions like fdopen, even if you have a POSIX macro like -D_POSIX_SOURCE. The intersection of ANSI and POSIX does not contain fdopen. So what ends up happening on BSDs is that you end up revealing more identifiers than you need, which exposes clashes. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-05-08 22:53 -0700 |
| Message-ID | <86tt5uz5w9.fsf@linuxsc.com> |
| In reply to | #393256 |
scott@slp53.sl.home (Scott Lurndal) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>>> Michael S <already5chosen@yahoo.com> writes: >>>> >>>>> On Mon, 14 Apr 2025 01:24:49 -0700 >>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>>> >>>>>> about where they may or may not be used. Do you really have a >>>>>> problem avoiding identifiers defined in this or that library >>>>>> header, either for all headers or just those headers required >>>>>> for freestanding implementations? >>>>> >>>>> I don't know. In order to know I'd have to include all >>>>> standard headers into all of my C files >>>> >>>> Let me ask the question differently. Have you ever run into an >>>> actual problem due to inadvertent collision with a reserved >>>> identifier? >>> >>> I'm not Michael, but I was once mildly inconvienced because I >>> defined a logging function called log(). The solution was >>> trivial: I changed the name. >> >> Yes, I expect I have run into similar situations. What I was >> wondering about were problems where either the existence of the >> problem or what to do to fix it needed more than a minimal >> effort. > > I recall running into issues using variables named 'index' > when porting code to SVR4 when the BSD compatibility layer > was present. > > https://man.freebsd.org/cgi/man.cgi?query=index&sektion=3 I understand how that might be annoying. Did you have any trouble either discovering what the problem was or fixing it once you did, or both? I presume there was no difficulty in knowing that there /was/ a problem; is that not the case?
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-05-08 14:09 +0000 |
| Message-ID | <vvidv5$7r6u$1@paganini.bofh.team> |
| In reply to | #393208 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Michael S <already5chosen@yahoo.com> writes:
>
>> On Mon, 14 Apr 2025 01:24:49 -0700
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> about where they may or may not be used. Do you really have a
>>> problem avoiding identifiers defined in this or that library
>>> header, either for all headers or just those headers required for
>>> freestanding implementations?
>>
>> I don't know. In order to know I'd have to include all
>> standard headers into all of my C files
>
> Let me ask the question differently. Have you ever run into an
> actual problem due to inadvertent collision with a reserved
> identifier?
Not in my own code. But I remember an old piece of code whose
author apparently thought that 'inline' is a perfect name for
input line. Few days ago I had trouble compiling with gcc-15
code which declares its own 'bool' type. The code is supposed to
compile using a wide range of compilers, so I am still looking
for "best" solution.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-05-08 16:52 +0200 |
| Message-ID | <vvigfv$1rirc$1@dont-email.me> |
| In reply to | #393252 |
On 08/05/2025 16:09, Waldek Hebisch wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Mon, 14 Apr 2025 01:24:49 -0700 >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> about where they may or may not be used. Do you really have a >>>> problem avoiding identifiers defined in this or that library >>>> header, either for all headers or just those headers required for >>>> freestanding implementations? >>> >>> I don't know. In order to know I'd have to include all >>> standard headers into all of my C files >> >> Let me ask the question differently. Have you ever run into an >> actual problem due to inadvertent collision with a reserved >> identifier? > > Not in my own code. But I remember an old piece of code whose > author apparently thought that 'inline' is a perfect name for > input line. Few days ago I had trouble compiling with gcc-15 > code which declares its own 'bool' type. The code is supposed to > compile using a wide range of compilers, so I am still looking > for "best" solution. > gcc changed the default standard to "gnu23" in gcc15, from "gnu17" in earlier versions. Their policy is that unless you specify the standard explicitly, you get the latest C standard that is well-supported by gcc, along with the common gcc extensions. (New ISO C standards supersede older ones - thus "C" means "C23" at the moment.) And in C23, "bool", "true" and "false" are now keywords. The boolean type was renamed "bool" with "_Bool" being an alias for compatibility. C23 has more backwards incompatible changes than usual for C standards since C99. (Personally, I am happy to see such changes - people have had a generation to get used to C booleans - but I fully understand that does not apply to everyone or all code.) The "best" solution, IMHO, is that you should never use a C compiler for serious work without specifying the standard you are using. (And if the C compiler doesn't let you choose the standard, consider whether it is actually a suitable tool for serious work.) If you decide that you want C23, with or without gcc extensions, you will need to fix that ancient code to remove or rename its home-made "bool" type. If you want to keep the code unchanged, pick an appropriate older C standard. (You will also want to do that if you want to be able to compile the code with older gcc versions or other compilers that don't yet support C23.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-05-08 08:49 -0700 |
| Message-ID | <8634df14rd.fsf@linuxsc.com> |
| In reply to | #393252 |
antispam@fricas.org (Waldek Hebisch) writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Mon, 14 Apr 2025 01:24:49 -0700
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> about where they may or may not be used. Do you really have a
>>>> problem avoiding identifiers defined in this or that library
>>>> header, either for all headers or just those headers required for
>>>> freestanding implementations?
>>>
>>> I don't know. In order to know I'd have to include all
>>> standard headers into all of my C files
>>
>> Let me ask the question differently. Have you ever run into an
>> actual problem due to inadvertent collision with a reserved
>> identifier?
>
> Not in my own code. But I remember an old piece of code whose
> author apparently thought that 'inline' is a perfect name for
> input line.
Yeah. That falls into a different category, because 'inline' is a
keyword rather than being defined in a standard header. In any case
the problem is essentially impossible to miss, and straightforward
to fix.
> Few days ago I had trouble compiling with gcc-15
> code which declares its own 'bool' type. The code is supposed to
> compile using a wide range of compilers, so I am still looking
> for "best" solution.
When I had to deal with a similar problem in the past, my
approach was something along these lines (obviously more
cases can be added if needed to deal with unusual compilers
or compilation options):
#if defined bool
#undef bool
#endif
#if !defined __STDC_VERSION__ || __STDC_VERSION__ < 199901L
typedef unsigned char bool;
#elif __STDC_VERSION__ < 201112L
typedef _Bool bool;
#elif __STDC_VERSION__ < 201710L
typedef _Bool bool;
#elif __STDC_VERSION__ < 202300L
typedef _Bool bool;
#else
/* 'bool' is keyword in C23+ ... */
#endif
[toc] | [prev] | [next] | [standalone]
Page 20 of 23 — ← Prev page 1 … 18 19 [20] 21 22 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web