Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #393426 > unrolled thread
| Started by | "Paul Edwards" <mutazilah@gmail.com> |
|---|---|
| First post | 2025-05-20 16:06 +1000 |
| Last post | 2025-05-24 22:10 -0700 |
| Articles | 20 on this page of 343 — 23 participants |
Back to article view | Back to comp.lang.c
encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-20 16:06 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-20 07:27 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-20 19:33 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 00:10 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 10:23 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 03:37 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 20:00 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 06:49 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-22 07:02 +0000
Re: encapsulating directory operations Jakob Bohm <egenagwemdimtapsar@jbohm.dk> - 2025-08-17 21:04 +0200
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-08-18 00:30 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-08-19 18:09 -0400
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-21 19:51 -0400
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 05:04 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-22 14:13 -0400
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 22:46 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-22 19:07 -0400
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-22 23:15 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 09:26 +1000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 00:44 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-24 02:26 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-22 20:10 -0400
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 02:08 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-23 19:29 -0400
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-24 00:08 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-31 08:20 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-31 21:42 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-01 07:58 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-01 07:43 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-02 09:35 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-02 15:24 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-06-02 19:14 -0400
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-02 23:54 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-03 01:02 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-03 19:41 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-03 18:25 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-06 10:29 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-06 14:10 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-06 19:10 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-06 17:24 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-06 19:26 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-07 04:04 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-07 06:24 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-07 19:58 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-07 18:31 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-08 02:43 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-07 21:22 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-08 03:56 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-07 23:57 +0200
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 10:06 +0200
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-08 08:55 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 17:02 +0200
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-08 15:08 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 17:18 +0200
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-09 09:20 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 12:58 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-08 16:55 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-08 17:45 +0000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-10 03:21 -0700
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 22:07 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-09 07:13 +0800
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-09 10:21 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 13:01 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-08 22:52 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 17:06 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-09 00:28 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 22:05 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-09 06:51 +0800
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-09 07:59 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 13:04 +0200
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-06-07 23:12 +0200
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 17:11 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-08 16:58 +0000
Re: encapsulating directory operations "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-08 11:48 -0700
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 22:09 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-09 14:01 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 17:24 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-09 15:53 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 19:45 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-09 18:33 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 20:39 +0200
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-10 07:21 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-10 13:19 +0000
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-10 14:46 +0000
Re: encapsulating directory operations "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-10 12:08 -0700
Re: encapsulating directory operations antispam@fricas.org (Waldek Hebisch) - 2025-06-10 20:22 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-06-09 19:22 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-09 18:59 -0700
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-10 09:51 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-03 00:37 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-10 14:07 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-10 14:36 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-10 16:40 +0200
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-10 16:52 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-10 23:33 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-11 07:07 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-11 05:34 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-11 13:41 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-11 17:33 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-12 01:33 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 02:18 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 10:33 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-20 19:45 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-20 13:42 +0200
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 13:55 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 15:05 +0100
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-05-20 14:09 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 00:15 +1000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 00:48 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 16:02 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 01:28 +1000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-23 05:43 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-23 14:27 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-23 22:32 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-24 06:54 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-28 05:41 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-28 14:10 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-11 20:15 -0700
Re: encapsulating directory operations Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2025-05-26 15:19 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-27 16:23 +0200
Re: encapsulating directory operations Michael S <already5chosen@yahoo.com> - 2025-05-27 18:10 +0300
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-27 19:24 +0200
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-27 16:16 -0700
Re: encapsulating directory operations Michael S <already5chosen@yahoo.com> - 2025-05-28 16:04 +0300
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-28 22:54 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-29 10:21 +0200
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-06 17:16 -0700
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-06 17:26 -0700
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-27 16:18 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-20 19:36 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-20 14:23 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-20 23:47 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 15:37 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 01:11 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 16:43 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 07:15 +1000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 22:50 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 01:11 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-20 22:40 -0400
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 05:50 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-21 10:06 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 09:27 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-20 18:19 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 17:43 +0100
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 17:14 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 18:20 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-20 17:51 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 19:50 +0100
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 19:34 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-21 10:09 +0200
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 16:51 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-20 16:58 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 18:09 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-20 17:48 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 19:34 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 07:51 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 05:31 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 20:08 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 11:28 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-21 17:00 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 16:37 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-21 16:03 +0000
Re: encapsulating directory operations Michael S <already5chosen@yahoo.com> - 2025-05-21 20:21 +0300
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-22 06:37 -0400
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-22 17:53 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-21 10:27 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 20:46 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-21 16:46 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 07:41 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 15:02 -0700
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 01:05 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 19:23 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-29 07:21 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-29 15:06 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-30 18:41 +1000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 08:09 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 00:12 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 10:25 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 01:03 +0000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-06 17:58 -0800
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 13:53 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 00:12 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 14:41 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 08:38 +1000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 09:09 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 16:22 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-21 00:18 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 10:31 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 01:02 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 16:18 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 09:57 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 22:41 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 20:41 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-21 11:06 -0700
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-21 11:22 -0700
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-21 20:58 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 07:10 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-22 15:32 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 09:16 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-22 18:38 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 08:12 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-25 15:34 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 09:01 +1000
Re: encapsulating directory operations gazelle@shell.xmission.com (Kenny McCormack) - 2025-05-25 23:25 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 02:28 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-22 21:27 -0700
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-23 07:08 +0200
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-22 22:20 -0700
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-23 07:43 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 07:54 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-25 15:29 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 08:40 +1000
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-26 03:29 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 11:46 +1000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-26 09:43 -0400
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-26 17:16 +0000
Re: encapsulating directory operations vallor <vallor@cultnix.org> - 2025-05-26 04:05 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 08:31 +1000
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-26 03:37 +0200
Re: encapsulating directory operations Richard Harnden <richard.harnden@gmail.invalid> - 2025-05-23 16:09 +0100
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-23 17:50 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-23 16:57 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-23 18:00 +0100
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 17:22 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-23 11:10 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 20:27 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-23 21:35 +0100
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 21:10 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-23 23:13 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-23 22:22 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-24 06:46 +0100
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-29 07:27 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 09:39 +0100
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-29 09:37 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-29 06:11 -0400
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 13:41 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-29 15:08 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 17:36 +0100
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-29 17:18 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 18:51 +0100
Re: encapsulating directory operations "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-29 14:31 -0700
Re: encapsulating directory operations "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-29 14:29 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 13:38 +0100
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-29 12:55 -0400
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 18:48 +0100
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-30 03:10 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-30 11:20 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 11:54 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-30 16:02 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 16:26 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-30 17:42 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 17:39 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-07-01 10:09 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-30 18:04 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-29 21:24 +0200
Re: encapsulating directory operations Michael S <already5chosen@yahoo.com> - 2025-05-29 23:24 +0300
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 21:27 +0100
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-29 13:45 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 22:09 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-29 21:19 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 22:40 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-30 18:18 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-30 22:10 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-04 19:23 +1000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-04 13:05 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 00:00 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-06-04 17:30 +0200
Re: encapsulating directory operations Josef Möllers <josef@invalid.invalid> - 2025-06-04 20:48 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-04 21:09 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-06-05 08:18 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 04:58 +1000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-04 19:19 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 05:24 +1000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-04 21:30 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-04 22:38 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 19:31 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-06-05 08:32 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 19:28 +1000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 20:25 +1000
Re: encapsulating directory operations antispam@fricas.org (Waldek Hebisch) - 2025-06-06 03:26 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-04 23:22 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-04 23:48 +0000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-10 07:18 -0700
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-29 14:50 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 00:05 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-30 17:37 +0200
Re: encapsulating directory operations Richard Harnden <richard.nospam@gmail.invalid> - 2025-05-30 17:25 +0100
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 17:39 +0100
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 17:32 +0100
Re: encapsulating directory operations antispam@fricas.org (Waldek Hebisch) - 2025-05-30 02:46 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-30 03:42 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-30 07:34 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-23 21:10 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 21:31 +0000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-23 22:05 -0700
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-24 01:27 -0700
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-10 08:52 -0700
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-10 13:35 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-10 21:34 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-10 15:09 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-11 01:16 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-10 19:11 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-11 15:23 +0000
Re: encapsulating directory operations "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-11 11:57 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-11 15:32 +0000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 04:39 -0800
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 08:44 +1000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 08:06 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-22 18:24 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 02:19 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-21 19:31 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 07:45 +1000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-21 13:59 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 07:52 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-23 01:18 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 09:48 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-26 00:15 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 11:50 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-29 07:26 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-30 18:47 +1000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-21 02:21 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 22:49 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 20:44 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 12:06 +0100
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-21 11:15 -0700
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-21 21:02 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-21 19:49 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 19:38 +1000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-20 22:26 -0400
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 03:32 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 19:50 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 00:03 +0000
Re: encapsulating directory operations Jakob Bohm <egenagwemdimtapsar@jbohm.dk> - 2025-05-22 02:20 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 02:53 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-21 22:14 -0700
Re: encapsulating directory operations Jakob Bohm <egenagwemdimtapsar@jbohm.dk> - 2025-08-17 22:34 +0200
Re: encapsulating directory operations antispam@fricas.org (Waldek Hebisch) - 2025-05-21 21:19 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-23 01:17 +0000
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-21 04:35 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 19:45 +1000
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-21 17:07 +0200
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-22 20:34 +0200
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-24 22:10 -0700
Page 15 of 18 — ← Prev page 1 … 13 14 [15] 16 17 18 Next page →
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-06-04 23:22 +0000 |
| Message-ID | <101qkeo$13glj$9@dont-email.me> |
| In reply to | #393705 |
On Wed, 4 Jun 2025 19:23:42 +1000, Paul Edwards wrote: > "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message > news:101dac8$mkpm$3@dont-email.me... >> >> Mainframes are supposed to be all about COBOL code, aren't they? Or so >> we keep being told. > > That would make the IBM COBOL compiler the most important compiler in > the world, not the most important C compiler in the world. We heard that 20-30 years ago. IBM’s declining fortunes over all that time clearly indicate otherwise: batch-oriented mainframes are simply not a growth market. All that COBOL code is going out of use, one way or another: if the companies reliant on it don’t retire it, they are more likely to go out of business anyway. It’s just free-market competition in action. Most of the remaining COBOL code nowadays is compiled with ... wait for it ... GNU COBOL. And the GNU compiler suite is, I believe, written in C++ at its core these days (used to be C).
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-06-04 23:48 +0000 |
| Message-ID | <8X40Q.28346$Yx54.24444@fx40.iad> |
| In reply to | #393717 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: >On Wed, 4 Jun 2025 19:23:42 +1000, Paul Edwards wrote: > >Most of the remaining COBOL code nowadays is compiled with ... wait for >it ... GNU COBOL. And the GNU compiler suite is, I believe, written in C++ >at its core these days (used to be C). I suspect your rather baseless assertion would be a surprise to Micro Focus.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-06-10 07:18 -0700 |
| Message-ID | <86frg7r86t.fsf@linuxsc.com> |
| In reply to | #393655 |
scott@slp53.sl.home (Scott Lurndal) writes: [...] > And all the existing C compilers in the entire planet support > the C90 dialect[*], if so instructed. Where is the problem? It is common to use the word "dialect" when talking about different editions of the C standard, but actually it isn't right. The word "dialect" comes from linguistics, and it has a particular meaning that does not apply in this case. My understanding of the terminology used in linguistics is that C90, C99, C11, and so forth, should be referred to as "varieties" of the C language, in much the same way that American English and British English and Indian English are all different varieties (rather than dialects) of English.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-29 14:50 -0700 |
| Message-ID | <87o6vbdr3e.fsf@nosuchdomain.example.com> |
| In reply to | #393653 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 29/05/2025 21:45, Keith Thompson wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> On 29/05/2025 20:24, David Brown wrote:
>> [...]
>>>> That's one of the reasons I like C99 and C11, and look forward to
>>>> C23. Once implemented, they don't change either.
>>>> I agree with all your are arguments on this,
>>>
>>> So far so good. :-)
>>>
>>>> except for one - I can't understand why you think C90 is different
>>>> from later C standards in this regard.
>>>
>>> I realise that my reply is going to sound glib, but I can't help that.
>>>
>>> I *don't* think C90 is different. I think C90 is exactly the
>>> same. It's the later standards that are different. Different from C90.
>> I'd like to understand the point you're trying to make.
>
> I'll do what I can to help out; I'm really not trying to be obscure.
>
>> Being different is a transitive relationship. C90 is different
>> "from later C standards". You say that C90 is "exactly the same"
>> -- as what? As itself?
>
> Yes. And nothing else has that quality of being C90.
>
>> C99 is also exactly the same as itself.
>
> Yes, but it's different from C99.
I hope that was a typo. If you really meant that C99 is different from
C99, I suggest that requires a bit more explanation.
>> If the difference is that you personally like C90 and dislike C99
>> and later editions, that's fine. De gustibus non est disputandem
>> (never argue with a guy named Gus).
>
> Look, Gus, if that's what you want to call yourself...well, okay, I
> can't in all honesty deny that de gustibus is part of it, but it's
> more to do with bit rot.
>
> Software houses need C90 for the same reason the government needs IBM
> 1311s (unless they've finished migrating off them now), cassette
> players, WW2 crypto keys, and the boot passwords for those early 1990s
> PCs lurking in the cellar.
>
> I shudder to think how much C90 code is out there, but it has to be
> /at least/ in the region of 10^9 LOC, much of it in the military
> arena, medical applications, and particularly the world of
> comms. Letting C90 compilers fall off the radar (e.g. by society
> forgetting how to program in it) really could be a stupendously bad
> idea, for all the reasons that people overlook when they shrug and say
> `I expect it'll all turn out fine'.
Right, there's a lot of existing C90 code out there, and we need
both C90 compilers and programmers who are familiar with C90
to maintain it. The alternative of updating it to conform to a
later C standard is often impractical (and the update would also
require programmers who know C90). I don't recall anyone suggesting
otherwise. ISO has decreed that each edition "cancels and replaces"
the previous edition, but none of us are obligated to accept that.
If I were starting a new project in C, I would not consider
using C90. At this point, I'd probably use C11 (perhaps with
compiler-specific extensions depending on the details of the
project).
Obviously C90, C99, and C11 are all different from each other.
You seem to be suggesting that C90 is special in some way that C99
and C11 are not. If that's an accurate summary of your opinion,
can you explain it? And if it isn't, just what are we talking about?
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-30 00:05 +0100 |
| Message-ID | <101ap7i$3mu1$1@dont-email.me> |
| In reply to | #393660 |
On 29/05/2025 22:50, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: >> On 29/05/2025 21:45, Keith Thompson wrote: >>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>> On 29/05/2025 20:24, David Brown wrote: >>> [...] >>>>> That's one of the reasons I like C99 and C11, and look forward to >>>>> C23. Once implemented, they don't change either. >>>>> I agree with all your are arguments on this, >>>> >>>> So far so good. :-) >>>> >>>>> except for one - I can't understand why you think C90 is different >>>>> from later C standards in this regard. >>>> >>>> I realise that my reply is going to sound glib, but I can't help that. >>>> >>>> I *don't* think C90 is different. I think C90 is exactly the >>>> same. It's the later standards that are different. Different from C90. >>> I'd like to understand the point you're trying to make. >> >> I'll do what I can to help out; I'm really not trying to be obscure. >> >>> Being different is a transitive relationship. C90 is different >>> "from later C standards". You say that C90 is "exactly the same" >>> -- as what? As itself? >> >> Yes. And nothing else has that quality of being C90. >> >>> C99 is also exactly the same as itself. >> >> Yes, but it's different from C99. > > I hope that was a typo. If you really meant that C99 is different from > C99, I suggest that requires a bit more explanation. Typo, of course. (9 is next to 0.) Alas, my typo-free days are over. <snip> > Obviously C90, C99, and C11 are all different from each other. > You seem to be suggesting that C90 is special in some way that C99 > and C11 are not. Yes. Nothing magical, of course. But C90 was there first and is (fairly literally) universal as no other dialect is. It would be a mistake to lose that. > If that's an accurate summary of your opinion, > can you explain it? Not sure I can be any clearer than I already have been, which seems to have been about as clear as mud. Ah well. > And if it isn't, just what are we talking about? Maybe I'm just being grumpy out loud instead of muttering dark imprecations into my coffee mug. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-05-30 17:37 +0200 |
| Message-ID | <101cjbh$i2b3$1@dont-email.me> |
| In reply to | #393662 |
On 30/05/2025 01:05, Richard Heathfield wrote: > On 29/05/2025 22:50, Keith Thompson wrote: >> Richard Heathfield <rjh@cpax.org.uk> writes: >>> On 29/05/2025 21:45, Keith Thompson wrote: >>>> C99 is also exactly the same as itself. >>> >>> Yes, but it's different from C99. >> >> I hope that was a typo. If you really meant that C99 is different from >> C99, I suggest that requires a bit more explanation. > > Typo, of course. (9 is next to 0.) Alas, my typo-free days are over. > You are, I believe, older than me. At what age can I expect my typo-free days to start? :-)
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2025-05-30 17:25 +0100 |
| Message-ID | <101cm58$ij24$1@dont-email.me> |
| In reply to | #393677 |
On 30/05/2025 16:37, David Brown wrote: > On 30/05/2025 01:05, Richard Heathfield wrote: >> >> Typo, of course. (9 is next to 0.) Alas, my typo-free days are over. >> > > You are, I believe, older than me. At what age can I expect my typo- > free days to start? Typo free days to /end/
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-30 17:39 +0100 |
| Message-ID | <101cn0d$ikgf$3@dont-email.me> |
| In reply to | #393679 |
On 30/05/2025 17:25, Richard Harnden wrote: > On 30/05/2025 16:37, David Brown wrote: >> On 30/05/2025 01:05, Richard Heathfield wrote: >>> >>> Typo, of course. (9 is next to 0.) Alas, my typo-free days are >>> over. >>> >> >> You are, I believe, older than me. At what age can I expect my >> typo- free days to start? > > Typo free days to /end/ No, I think he was right the first time. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-30 17:32 +0100 |
| Message-ID | <101cmj7$ikgf$1@dont-email.me> |
| In reply to | #393677 |
On 30/05/2025 16:37, David Brown wrote: > On 30/05/2025 01:05, Richard Heathfield wrote: >> On 29/05/2025 22:50, Keith Thompson wrote: >>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>> On 29/05/2025 21:45, Keith Thompson wrote: > >>>>> C99 is also exactly the same as itself. >>>> >>>> Yes, but it's different from C99. >>> >>> I hope that was a typo. If you really meant that C99 is >>> different from >>> C99, I suggest that requires a bit more explanation. >> >> Typo, of course. (9 is next to 0.) Alas, my typo-free days are >> over. >> > > You are, I believe, older than me. At what age can I expect my > typo-free days to start? > > :-) I came up with a few answers to that, but you'll be glad to hear that I decided you didn't deserve any of them. ;-) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-05-30 02:46 +0000 |
| Message-ID | <101b66m$2g6n0$1@paganini.bofh.team> |
| In reply to | #393653 |
Richard Heathfield <rjh@cpax.org.uk> wrote:
>
> Software houses need C90 for the same reason the government needs
> IBM 1311s (unless they've finished migrating off them now),
> cassette players, WW2 crypto keys, and the boot passwords for
> those early 1990s PCs lurking in the cellar.
>
> I shudder to think how much C90 code is out there, but it has to
> be /at least/ in the region of 10^9 LOC, much of it in the
> military arena, medical applications, and particularly the world
> of comms. Letting C90 compilers fall off the radar (e.g. by
> society forgetting how to program in it) really could be a
> stupendously bad idea, for all the reasons that people overlook
> when they shrug and say `I expect it'll all turn out fine'.
Clearly there is a lot of old code there. I am not sure why
you think that C90 is very special here. I mean, goverment
loves standards and for goverment project may mandate use
of "standard" language, which could mean C90 in relevant
period. However, business had tendency to use whatever their
compilers supported, which frequently meant using vendor
extentions. Due to extentions, I suspect that there is very
little pure C90 code. Even if C90 was mandated it is not
clear if C90 was really deliverd. More precisely, when you
look at small snippets of C code there is good chance that
they will be valid regardless of version of C that you use.
However in large codebase one can expect some constructs that
are not valid C90. Even for code born as pure C90, there is
notrivial chance that maintanence introduced constructs
from later C standards.
AFAICS C99 and C11 did not introduced major incompatibilities
with C90. OTOH some vendor extentions to C90 were
standarized in C99 and C11. So, it is reasonable to suspect
that amount of say C99 code is significantly larger
than C90 code. Or may be better to say that deviation of
C code from C99 is probably smaller than deviation from C90.
Concerning new code it makes sense to avoid constructs that
are made illegal in later standard, that is write to the
latter of later standard even if you use only constructs
available in C90. And concerning constructs not in C90,
I find ability to mix declarations and statements important
to readability. So any code that I write now is unlikely
to be valid C90 for this (technically trivial) reason.
For computational code multidimensional arrays are
useful. In general purpose code sizes of arrays are
typically only known at runtime, so it is natural to
use variable modified types. Other people may find useful
some other features of C99 or later standards, so there
is incentive to go beyond C90.
There is also historic aspect. C90 is part of history and
I fully support preserving it (specification and actual
programs) as historic artifacts. But I also think that
C90 should be retired from practical use, that is code
should be modernized to comply with later standards.
If code needs to be very portable, than C90 compatibility
makes sense, but for most code it it better to take
advantage of newer features.
BTW: In the past I used to point out to students that some
features that they use in their programs are not C90 but
say C99. But now I do not think that it is worth to
bother students with information about C90.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-05-30 03:42 +0000 |
| Message-ID | <20250529203642.525@kylheku.com> |
| In reply to | #393663 |
On 2025-05-30, Waldek Hebisch <antispam@fricas.org> wrote: > Concerning new code it makes sense to avoid constructs that > are made illegal in later standard, that is write to the > latter of later standard even if you use only constructs > available in C90. Speaking of which, I like to avoid declarations mixed with statements. GCC supports that with a diagnostic: -Werror=declaration-after-statement. However, the wording of the diagnostic, when it goes off, is poor: it says something like "C90 doesn't allow mixed declarations and statements". Aaaargh! I said, error out for declarations after statements. I didn't say I'm writing in C90. Look, in the same function, I initialized an automatic aggregate with a non-constant, which is also not in C90! -- 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 | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-30 07:34 +0000 |
| Message-ID | <101bn1t$cc5u$5@dont-email.me> |
| In reply to | #393653 |
On Thu, 29 May 2025 22:09:54 +0100, Richard Heathfield wrote: > I shudder to think how much C90 code is out there, but it has to be /at > least/ in the region of 10^9 LOC, much of it in the military arena, > medical applications, and particularly the world of comms. The military and aerospace were/are using Ada a lot. That’s why the 🇺🇸 DoD sponsored its creation, after all. And guess what: that is a language that is still alive and well and being maintained today. Because that is a language that was designed to be more robust against stupid errors than C could ever be.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-05-23 21:10 +0000 |
| Message-ID | <1v5YP.4$8%X2.2@fx08.iad> |
| In reply to | #393573 |
Kaz Kylheku <643-408-1753@kylheku.com> writes:
>On 2025-05-23, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Richard Harnden <richard.harnden@gmail.invalid> writes:
>>> On 22/05/2025 23:32, Keith Thompson wrote:
>>>> "Paul Edwards" <mutazilah@gmail.com> writes:
>>>>> [...]
>>>> In one of your library's headers:
>>>> extern const char ESCAPE;
>>>> In the corresponding *.c file:
>>>> const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
>>>> Change the name if you prefer.
>>>
>>> Wouldn't that be a reserved identifier?
>>
>> Yes, it would. Good catch.
>>
>> (Identifiers starting with E followed by either a digit or an uppercase
>> letter are reserved; they could be defined as macros in <errno.h>.)
>
>But C99 introduced, for instance "double round(double);".
>
>If you had programs which used that as a file scope identifier
>where <float.h> was included, or an external name, you had a clash.
>
>It wasn't previously announced that common mathematical words are
>reserved, or that identifiers starting with "r" are reserved.
>
>Basically, the concept of reserved spaces is not worth a damn, because
>ISO C doesn't actually confine itself to them when naming new entities,
>and so no matter what name you choose, you could have a clash in the
>future.
>
>There is no way to estimate whether some specific name starting with E
>is more or less likely to experience a clash than any other hame;
>i.e. we cannot say with certainty that ESCAPE is more likely to
>clash than MY_ESCAPE.
>
>Ironically, one way to protect yourself, at least as a solo developer
>working on a greenfield projecg with no third party cruft, is to use
>short identifiers like extern const char ES. Because no standard or
>major API is going to use short names. Everyone uses long-ish names
>because it's insane to do otherwise. And that gives YOU the room
>to do the insane thing. :)
Along with a couple dozen other new floating point functions. All
of which are defined in <math.h>. The only potential conflict in
code written prior to C99 would be applications that include <math.h>
and defined their own 'round' function.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-05-23 21:31 +0000 |
| Message-ID | <20250523142024.453@kylheku.com> |
| In reply to | #393575 |
On 2025-05-23, Scott Lurndal <scott@slp53.sl.home> wrote:
> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>On 2025-05-23, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> Richard Harnden <richard.harnden@gmail.invalid> writes:
>>>> On 22/05/2025 23:32, Keith Thompson wrote:
>>>>> "Paul Edwards" <mutazilah@gmail.com> writes:
>>>>>> [...]
>>>>> In one of your library's headers:
>>>>> extern const char ESCAPE;
>>>>> In the corresponding *.c file:
>>>>> const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
>>>>> Change the name if you prefer.
>>>>
>>>> Wouldn't that be a reserved identifier?
>>>
>>> Yes, it would. Good catch.
>>>
>>> (Identifiers starting with E followed by either a digit or an uppercase
>>> letter are reserved; they could be defined as macros in <errno.h>.)
>>
>>But C99 introduced, for instance "double round(double);".
>>
>>If you had programs which used that as a file scope identifier
>>where <float.h> was included, or an external name, you had a clash.
>>
[ ...]
> Along with a couple dozen other new floating point functions. All
> of which are defined in <math.h>. The only potential conflict in
> code written prior to C99 would be applications that include <math.h>
> and defined their own 'round' function.
1. What are the odds that a program which defines its own round function
might also include <math.h>?
2. round is not only something declared in a header, but a name with
external linkage which may have only one definition. If you're able
to define round as an external name in your program, that's not due
to a requirement coming from ISO C.
3. Even if you're able to override the platform's external names in
your program, you will not get away with that in a large project
with third party dependencies. As soon as something wants to
call the C99 round functon or the POSIX stat function,
your clashing external definition for round or stat becomes
a problem. You can really only gat away with "external name
squatting" in solo projects with no dependencies, or projects of a
similar nature and scope.
--
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-23 22:05 -0700 |
| Message-ID | <864ixavbs4.fsf@linuxsc.com> |
| In reply to | #393572 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Richard Harnden <richard.harnden@gmail.invalid> writes:
>
>> On 22/05/2025 23:32, Keith Thompson wrote:
>>
>>> "Paul Edwards" <mutazilah@gmail.com> writes:
>>>
>>>> [...]
>>>
>>> In one of your library's headers:
>>> extern const char ESCAPE;
>>> In the corresponding *.c file:
>>> const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
>>> Change the name if you prefer.
>>
>> Wouldn't that be a reserved identifier?
>
> Yes, it would. Good catch.
>
> (Identifiers starting with E followed by either a digit or an uppercase
> letter are reserved; they could be defined as macros in <errno.h>.)
They are reserved only as macros, and only if <errno.h> has
been #include'd.
For this particular use, it's easy to make the definition work,
simply by adding
#undef ESCAPE
before the declaration in the header file, and before the
definition in the source file (assuming of course that if
there are any #include <errno.h> they precede the #undef's).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-24 01:27 -0700 |
| Message-ID | <87plfys9a5.fsf@nosuchdomain.example.com> |
| In reply to | #393582 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Richard Harnden <richard.harnden@gmail.invalid> writes:
>>> On 22/05/2025 23:32, Keith Thompson wrote:
[...]
>>>> In one of your library's headers:
>>>> extern const char ESCAPE;
>>>> In the corresponding *.c file:
>>>> const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
>>>> Change the name if you prefer.
>>>
>>> Wouldn't that be a reserved identifier?
>>
>> Yes, it would. Good catch.
>>
>> (Identifiers starting with E followed by either a digit or an uppercase
>> letter are reserved; they could be defined as macros in <errno.h>.)
>
> They are reserved only as macros, and only if <errno.h> has
> been #include'd.
>
> For this particular use, it's easy to make the definition work,
> simply by adding
>
> #undef ESCAPE
>
> before the declaration in the header file, and before the
> definition in the source file (assuming of course that if
> there are any #include <errno.h> they precede the #undef's).
It would be even easier to pick a different name.
If I had a time machine and sufficient influence, I might make all
the errno macros start with something more distinct, like E_ or ERR.
But I don't.
--
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-06-10 08:52 -0700 |
| Message-ID | <86bjqvr3u5.fsf@linuxsc.com> |
| In reply to | #393587 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Richard Harnden <richard.harnden@gmail.invalid> writes:
>>>
>>>> On 22/05/2025 23:32, Keith Thompson wrote:
>
> [...]
>
>>>>> In one of your library's headers:
>>>>> extern const char ESCAPE;
>>>>> In the corresponding *.c file:
>>>>> const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
>>>>> Change the name if you prefer.
>>>>
>>>> Wouldn't that be a reserved identifier?
>>>
>>> Yes, it would. Good catch.
>>>
>>> (Identifiers starting with E followed by either a digit or an
>>> uppercase letter are reserved; they could be defined as macros
>>> in <errno.h>.)
>>
>> They are reserved only as macros, and only if <errno.h> has
>> been #include'd.
>>
>> For this particular use, it's easy to make the definition work,
>> simply by adding
>>
>> #undef ESCAPE
>>
>> before the declaration in the header file, and before the
>> definition in the source file (assuming of course that if
>> there are any #include <errno.h> they precede the #undef's).
>
> It would be even easier to pick a different name.
The point of my comment was to help explain the rules about what
macro names are reserved and under what circumstances, not to
suggest a way to avoid conflicts.
A better way to avoid conflicts with E* macros is to take functions
where errno is needed, as for example signal(), and not call them
directly but rather wrap each one in a function, with the wrapping
functions put in (one or more) separate translation unit(s). Those
translation units, and only those translation units, are the ones
where a #include <errno.h> is done. Some details are needed to keep
the separation complete, but I think those aren't too hard to work
out, so if someone has trouble please ask. This way most of the
program can use names beginning with E that might otherwise be
reserved, without any fear of conflicts. There is a bit of source
code overhead, but that is paid only once, across all projects that
use this approach. Also there are some other benefits, related to
libraries used that are not part of ISO C, such as Posix, which
again should be readily apparent to anyone used to working in large
projects that use such libraries.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-06-10 13:35 -0700 |
| Message-ID | <878qlzibco.fsf@nosuchdomain.example.com> |
| In reply to | #393793 |
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:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Richard Harnden <richard.harnden@gmail.invalid> writes:
>>>>> On 22/05/2025 23:32, Keith Thompson wrote:
>> [...]
>>
>>>>>> In one of your library's headers:
>>>>>> extern const char ESCAPE;
>>>>>> In the corresponding *.c file:
>>>>>> const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
>>>>>> Change the name if you prefer.
>>>>>
>>>>> Wouldn't that be a reserved identifier?
>>>>
>>>> Yes, it would. Good catch.
>>>>
>>>> (Identifiers starting with E followed by either a digit or an
>>>> uppercase letter are reserved; they could be defined as macros
>>>> in <errno.h>.)
>>>
>>> They are reserved only as macros, and only if <errno.h> has
>>> been #include'd.
>>>
>>> For this particular use, it's easy to make the definition work,
>>> simply by adding
>>>
>>> #undef ESCAPE
>>>
>>> before the declaration in the header file, and before the
>>> definition in the source file (assuming of course that if
>>> there are any #include <errno.h> they precede the #undef's).
>>
>> It would be even easier to pick a different name.
>
> The point of my comment was to help explain the rules about what
> macro names are reserved and under what circumstances, not to
> suggest a way to avoid conflicts.
And the point of my comment was to suggest a way to avoid conflicts.
> A better way to avoid conflicts with E* macros is to take functions
> where errno is needed, as for example signal(), and not call them
> directly but rather wrap each one in a function, with the wrapping
> functions put in (one or more) separate translation unit(s). Those
> translation units, and only those translation units, are the ones
> where a #include <errno.h> is done. Some details are needed to keep
> the separation complete, but I think those aren't too hard to work
> out, so if someone has trouble please ask. This way most of the
> program can use names beginning with E that might otherwise be
> reserved, without any fear of conflicts. There is a bit of source
> code overhead, but that is paid only once, across all projects that
> use this approach. Also there are some other benefits, related to
> libraries used that are not part of ISO C, such as Posix, which
> again should be readily apparent to anyone used to working in large
> projects that use such libraries.
That doesn't strike me as better. You're suggesting a substantial
reorganization to avoid some simple name conflicts (identifiers
starting with 'E'). I find it much easier -- and yes, better --
to avoid defining identifiers starting with 'E'. (Actually only
identifiers starting with 'E' followed by either a digit or an
uppercase letter are reserved. It's simpler to avoid all identifiers
starting with 'E', but you can safely use something like "Escape"
if you like.)
If there are other reasons for such an organization, that's fine.
(My personal policy is to assume a more expansive set of reserved
identifiers, because it means I only have to remember a simpler
set of rules. For example, I find it easier to avoid defining any
identifiers starting with '_' than to account for the rules for which
_* identifiers are reserved for which purposes in which contexts.
Of course I'll look up and apply the actual rules when I need to.)
I find the reservation of potential errno macro names annoying.
Using and reserving identifiers starting with "E_", for example,
would have been less intrusive. But we're stuck with 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 | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-06-10 21:34 +0000 |
| Message-ID | <20250610142356.296@kylheku.com> |
| In reply to | #393797 |
On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > I find the reservation of potential errno macro names annoying. If the standard contained /no/ statements about what a given header file may reserve, then /any/ identifier whatsoever would be a potential clash. The errno reservation is kind of good because implementors often extend the set of errno constants. POSIX has a lot more of them than ISO C, and there are some vendor-specific ones. Anyway, you can safely ignore the reservation theatre, and just deal with clashes that happen, when they happen. (If you're lucky, that could just be never). Anyway, ISO C, POSIX and vendors have historically introduced new identifiers in spaces that were not previously declared as reserved. If you're ever hit by that, you will feel like a completel sucker if you've religiously adhered to namespaces from your end. -- 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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-06-10 15:09 -0700 |
| Message-ID | <874iwni6zb.fsf@nosuchdomain.example.com> |
| In reply to | #393798 |
Kaz Kylheku <643-408-1753@kylheku.com> writes:
> On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> I find the reservation of potential errno macro names annoying.
>
> If the standard contained /no/ statements about what a given header
> file may reserve, then /any/ identifier whatsoever would be a potential
> clash.
>
> The errno reservation is kind of good because implementors often extend
> the set of errno constants. POSIX has a lot more of them than ISO C, and
> there are some vendor-specific ones.
>
> Anyway, you can safely ignore the reservation theatre, and just
> deal with clashes that happen, when they happen. (If you're lucky,
> that could just be never).
You can do that, but a new clash could happen when your code is
compiled on a system that defines an errno macro that you haven't
seen before.
> Anyway, ISO C, POSIX and vendors have historically introduced new
> identifiers in spaces that were not previously declared as reserved.
> If you're ever hit by that, you will feel like a completel sucker if
> you've religiously adhered to namespaces from your end.
Yes, that can happen, but no, I won't feel like a complete sucker.
If I define my own strfoo() function and a new edition of the standard
defines strfoo() in <string.h>, the clash is my fault,and I could have
avoided it by defining str_foo().
Nothing can prevent all possible name clashes, but I like to follow the
rules in the standard that let me prevent some of them.
--
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]
Page 15 of 18 — ← Prev page 1 … 13 14 [15] 16 17 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web