Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #161260 > unrolled thread
| Started by | James Harris <james.harris.1@gmail.com> |
|---|---|
| First post | 2021-06-06 13:16 +0100 |
| Last post | 2021-06-17 19:30 +0200 |
| Articles | 20 on this page of 391 — 31 participants |
Back to article view | Back to comp.lang.c
Why does C allow structs to have a tag? James Harris <james.harris.1@gmail.com> - 2021-06-06 13:16 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-06 15:27 +0200
Re: Why does C allow structs to have a tag? Thiago Adams <thiago.adams@gmail.com> - 2021-06-07 06:00 -0700
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-07 18:06 +0200
Re: Why does C allow structs to have a tag? Öö Tiib <ootiib@hot.ee> - 2021-06-06 06:34 -0700
Re: Why does C allow structs to have a tag? James Harris <james.harris.1@gmail.com> - 2021-06-06 16:33 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-06 14:59 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-06 15:05 +0000
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-06-06 18:58 +0200
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-06 21:12 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-06 21:02 +0100
Re: Why does C allow structs to have a tag? Richard Harnden <richard.nospam@gmail.com> - 2021-06-06 21:25 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 15:13 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-06 23:55 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 17:02 -0700
Re: Why does C allow structs to have a tag? James Harris <james.harris.1@gmail.com> - 2021-06-07 18:42 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-07 19:39 +0100
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-06-07 17:15 +0200
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-07 12:03 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-07 20:55 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-07 22:17 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-07 21:54 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-07 13:22 -0700
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-06-07 13:36 -0700
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-07 08:52 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-07 11:06 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-07 13:25 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-07 13:00 +0100
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-06-07 07:25 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-07 16:31 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-07 16:15 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-07 17:53 +0100
Re: Why does C allow structs to have a tag? James Harris <james.harris.1@gmail.com> - 2021-06-07 19:02 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-07 22:26 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-08 00:19 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-07 17:06 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-08 11:13 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-08 11:43 -0700
Re: Why does C allow structs to have a tag? James Harris <james.harris.1@gmail.com> - 2021-06-07 18:54 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-07 19:57 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 15:10 -0700
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-06 14:51 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-06 16:05 +0100
Re: Why does C allow structs to have a tag? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-06 14:20 -0400
Re: Why does C allow structs to have a tag? Richard Damon <Richard@Damon-Family.org> - 2021-06-06 15:03 -0400
Re: Why does C allow structs to have a tag? James Harris <james.harris.1@gmail.com> - 2021-06-07 18:38 +0100
Re: Why does C allow structs to have a tag? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-06-08 08:06 -0600
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-06-08 07:45 -0700
Re: Why does C allow structs to have a tag? Guillaume <message@bottle.org> - 2021-06-08 17:09 +0200
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-08 16:00 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-08 17:23 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-08 18:59 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-09 00:22 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-08 16:53 -0700
Re: Why does C allow structs to have a tag? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-09 11:40 -0400
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-09 17:36 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-09 17:48 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-09 20:19 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-09 21:28 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-09 23:47 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-10 11:14 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-10 12:38 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-10 15:30 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-10 15:18 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-10 16:55 +0200
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-06-10 17:23 +0200
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-10 20:47 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-10 17:19 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-11 09:52 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-11 11:25 +0200
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-11 12:00 -0700
Re: Why does C allow structs to have a tag? Guillaume <message@bottle.org> - 2021-06-11 21:14 +0200
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-11 19:46 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-11 15:28 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-11 15:06 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-11 15:08 -0700
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-12 00:32 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-11 22:32 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-11 15:17 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-11 23:29 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-11 23:21 +0000
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-06-12 00:39 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-12 01:11 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-12 00:51 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-12 11:08 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-12 16:12 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-12 18:36 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-12 13:06 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-12 12:42 -0700
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-12 14:13 +0200
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-10 15:16 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-10 16:45 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-10 16:56 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-10 19:32 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-09 22:37 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-09 15:12 -0700
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-09 23:18 +0000
Re: Why does C allow structs to have a tag? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-06-08 09:25 -0600
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-08 16:13 +0000
Re: Why does C allow structs to have a tag? Richard Damon <Richard@Damon-Family.org> - 2021-06-08 21:43 -0400
Re: Why does C allow structs to have a tag? John Bode <jfbode1029@gmail.com> - 2021-06-08 15:03 -0500
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-24 10:33 -0700
Re: Why does C allow structs to have a tag? Öö Tiib <ootiib@hot.ee> - 2021-06-24 13:45 -0700
Re: Why does C allow structs to have a tag? John Bode <jfbode1029@gmail.com> - 2021-07-01 17:57 -0500
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-11 00:26 -0700
Re: Why does C allow structs to have a tag? John Bode <jfbode1029@gmail.com> - 2021-07-26 09:49 -0500
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-27 15:47 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-27 10:55 -0700
Re: Why does C allow structs to have a tag? Guillaume <message@bottle.org> - 2021-07-27 23:48 +0200
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-27 22:12 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-28 00:38 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-27 18:30 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-28 13:02 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-28 07:19 -0700
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-28 14:06 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-28 15:44 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-28 15:21 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-28 17:49 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-28 17:21 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-28 23:41 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-28 16:07 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-29 02:23 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-28 19:20 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-29 11:05 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-29 08:12 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-29 16:34 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-29 17:10 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-29 10:29 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-29 10:28 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-29 19:07 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-29 11:16 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-29 19:41 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-29 12:43 -0700
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-30 15:06 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-30 16:31 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-07-30 19:49 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-30 20:03 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-07-30 23:16 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 01:51 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-07-31 13:42 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 14:56 +0100
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-07-31 19:33 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 19:17 +0100
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-07-31 21:32 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 23:10 +0100
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-08-01 00:43 +0200
Re: Why does C allow structs to have a tag? Richard Damon <Richard@Damon-Family.org> - 2021-07-31 15:54 -0700
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-04 13:36 +0200
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-04 13:32 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-04 14:24 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-04 16:08 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-04 16:32 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-04 16:33 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-04 18:40 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-04 19:31 +0100
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-07 10:03 -0400
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-07 17:11 +0100
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-08 08:51 -0400
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-08 15:41 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-08-08 17:12 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-08 20:25 +0100
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-08 20:21 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-08 20:38 +0100
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-08 14:00 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-08 22:16 +0100
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-08 22:17 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-08 22:32 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-08 23:13 +0100
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-09 01:46 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-09 10:54 +0100
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-09 03:59 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-09 13:55 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-09 16:08 +0200
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-09 07:53 -0700
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-09 08:28 -0700
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-09 08:19 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-09 16:51 +0100
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-09 16:47 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-09 17:09 +0100
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-08 15:30 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-09 00:33 +0100
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-08 20:03 -0400
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-09 01:29 -0700
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-09 15:05 -0400
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-09 23:48 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-09 16:45 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-10 01:33 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-09 17:52 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-10 11:17 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 11:22 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-10 20:05 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 13:49 -0700
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-10 03:03 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-10 16:27 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 11:17 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-10 20:23 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 14:00 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-10 22:54 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 15:32 -0700
Re: Why does C allow structs to have a tag? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-08-09 17:53 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-09 18:27 -0700
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-10 01:55 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-10 12:19 +0100
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-10 02:04 -0700
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-10 09:42 -0700
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-11 17:19 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 20:04 +0100
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-11 20:19 +0000
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-11 16:51 -0400
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 21:33 +0000
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-11 19:10 -0400
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-12 16:08 +0000
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-08 19:56 +0000
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-10 14:35 -0700
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 21:41 +0000
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-10 15:08 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-10 23:22 +0100
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-10 20:15 -0400
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-11 08:34 +0000
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-11 11:23 +0100
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-11 03:46 -0700
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-11 14:29 +0100
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-11 07:26 -0700
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-01 15:04 -0700
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-11 03:55 -0700
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 13:55 +0000
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-11 07:07 -0700
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-01 13:44 -0700
Re: Why does C allow structs to have a tag? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-10-01 22:40 -0700
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 01:37 -0700
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-11 14:29 -0400
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 18:54 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 20:10 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 20:04 +0000
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-11 17:04 -0400
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 11:09 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 13:52 +0000
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-11 08:01 -0700
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 15:06 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 16:47 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 16:14 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 18:27 +0100
Re: Why does C allow structs to have a tag? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-08-11 11:01 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 19:45 +0100
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-11 15:55 -0400
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 22:10 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-11 22:47 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 23:00 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-12 10:29 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-12 12:10 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-12 16:28 +0200
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-12 08:03 -0700
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-12 15:52 +0000
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-12 17:55 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-12 16:59 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-12 19:44 +0200
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-12 19:02 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-12 20:22 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-12 11:10 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-12 23:17 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-12 16:52 -0700
Re: Why does C allow structs to have a tag? Richard Damon <Richard@Damon-Family.org> - 2021-08-12 22:22 -0400
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-12 19:51 -0700
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-01 13:49 -0700
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-12 16:52 +0000
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-12 18:45 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-12 22:17 +0100
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-11 21:09 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 23:13 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 23:30 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-12 10:39 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-12 12:26 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-12 16:44 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-12 17:20 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-12 20:00 +0200
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-12 00:44 +0000
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-11 10:39 -0700
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 17:52 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-11 11:41 -0700
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-08 16:00 -0400
Re: Why does C allow structs to have a tag? Ike Naar <ike@rie.sdf.org> - 2021-08-09 05:46 +0000
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-09 01:38 -0700
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-09 01:57 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-09 10:55 +0100
Re: Why does C allow structs to have a tag? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-04 11:48 -0400
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-04 19:34 +0200
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-07-31 19:18 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 22:35 +0100
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-07-31 23:51 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-01 01:46 +0100
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-07-30 17:20 +0200
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 11:16 -0700
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-07-30 20:24 +0200
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 14:17 -0700
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-30 14:55 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-30 16:13 +0100
Re: Why does C allow structs to have a tag? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-07-30 09:08 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-30 18:18 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-30 17:38 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 11:17 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-30 20:33 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-30 20:10 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-30 21:50 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 14:49 -0700
Re: Why does C allow structs to have a tag? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-30 14:39 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 14:44 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 00:08 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 16:31 -0700
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-07-31 19:57 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 11:01 -0700
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-07-30 23:28 +0200
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 15:19 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 11:12 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-30 20:26 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-30 20:08 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-30 22:10 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 15:34 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 00:13 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 16:36 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 02:23 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 21:14 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 11:27 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-31 15:29 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-31 15:48 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-01 00:14 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-31 16:25 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-01 00:52 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-01 00:29 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-31 16:50 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-01 01:16 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-31 18:01 -0700
Re: Why does C allow structs to have a tag? gazelle@shell.xmission.com (Kenny McCormack) - 2021-08-01 01:38 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-01 11:41 +0100
Re: Why does C allow structs to have a tag? gazelle@shell.xmission.com (Kenny McCormack) - 2021-08-01 19:14 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-01 11:54 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-01 16:34 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-01 14:58 -0700
Re: Why does C allow structs to have a tag? Manfred <noname@invalid.add> - 2021-08-01 19:27 +0200
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 14:43 -0700
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-07-30 23:33 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 02:11 +0100
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-07-31 20:33 +0000
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-31 02:14 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 21:23 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 11:39 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-31 12:58 -0700
Re: Why does C allow structs to have a tag? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-07-31 21:21 +0000
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-30 14:54 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 10:47 -0700
Re: Why does C allow structs to have a tag? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-30 14:16 -0700
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-30 14:51 +0000
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-07-30 20:22 +0200
Re: Why does C allow structs to have a tag? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-30 14:07 -0700
Re: Why does C allow structs to have a tag? John Dill <jadill33@gmail.com> - 2021-07-29 06:09 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-29 14:26 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-29 13:51 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-29 16:18 +0100
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-09-30 05:39 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-27 17:14 -0700
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-28 02:01 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-27 19:07 -0700
Re: Why does C allow structs to have a tag? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-27 12:32 -0700
Re: Why does C allow structs to have a tag? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-27 12:41 -0700
Re: Why does C allow structs to have a tag? John Bode <jfbode1029@gmail.com> - 2021-07-30 09:02 -0500
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-30 15:19 +0100
Re: Why does C allow structs to have a tag? John Bode <jfbode1029@gmail.com> - 2021-07-30 10:19 -0500
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-30 16:34 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-30 15:58 +0000
Re: Why does C allow structs to have a tag? Lowell Gilbert <lgusenet@be-well.ilk.org> - 2021-07-30 11:28 -0400
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-09-06 05:20 -0700
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-09-06 05:09 -0700
Re: Why does C allow structs to have a tag? Siri Cruise <chine.bleu@yahoo.com> - 2021-06-11 12:33 -0700
Re: Why does C allow structs to have a tag? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-06-16 19:39 -0700
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-06-17 11:50 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-17 12:02 +0100
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-06-17 17:05 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-17 13:49 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-17 13:39 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-17 15:05 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-17 14:34 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-17 18:35 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-17 18:14 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-17 11:29 +0100
Re: Why does C allow structs to have a tag? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-06-17 08:22 -0700
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-17 16:22 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-17 17:57 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-17 17:53 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-17 21:27 +0100
Re: Why does C allow structs to have a tag? Öö Tiib <ootiib@hot.ee> - 2021-06-17 17:58 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-18 11:25 +0100
Re: Why does C allow structs to have a tag? Guillaume <message@bottle.org> - 2021-06-17 19:30 +0200
Page 6 of 20 — ← Prev page 1 … 4 5 [6] 7 8 … 20 Next page →
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2021-06-08 15:03 -0500 |
| Message-ID | <s9oidl$te9$1@dont-email.me> |
| In reply to | #161260 |
On 6/6/21 7:16 AM, James Harris wrote:
> Does C, as a language, need to allow its structs to have tags?
>
You can ask the same question of enum and union types - the answer
in all three cases is "yes".
> AIUI a fragment such as "struct A {....};" reserves no storage but
> declares a template which can be used later, e.g. to declare a variable
> as in
>
> struct A var;
>
> to declare a parameter as in
>
> void f(struct A parm) {....}
>
> to effect a cast as in
>
> (struct A *) p
>
> etc but in all such cases struct A is being used as a type.
And this is why tags exist. That's how you refer to the specific
struct/union/enum type after its definition.
> And there is
> a more general feature for that in typedef.
>
To reiterate a point I make a lot - typedef on its own creates leaky
abstractions. If I need to know that I have to use the `.` or `->`
operator on something, I'd rather have it declared as `struct A foo;` or
`struct B *ptr;` instead of a type name that doesn't convey struct-ness
at all. Same reason I don't like it when people hide pointers behind
typedefs - I once spent half a day chasing my tail because somebody
created a typedef name for a pointer type and used that as a template
parameter for a vector in C++, such that when I was using an iterator
I needed to write
(*it)->do_something();
However, since the typedef name didn't indicate pointer-ness *at all*, I
wound up writing
it->do_something();
and g++ vomited up hundreds of incomprehensible error messages that
basically boiled down to "you need to use a * here, dummy".
Either create an API that completely abstracts out the struct-ness of
the type (such that you don't have to explicitly use the `.` or `->`
operators), or don't bother with a typedef.
> So could C's struct tags be omitted from the language? If not, what does
> a struct tag add? Is it something to do with forward declarations or
> syntactic consistency with union tags, etc?
>
>
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-06-24 10:33 -0700 |
| Message-ID | <867dijb22a.fsf@linuxsc.com> |
| In reply to | #161333 |
John Bode <jfbode1029@gmail.com> writes: [...] > To reiterate a point I make a lot - typedef on its own creates leaky > abstractions. If I need to know that I have to use the `.` or `->` > operator on something, I'd rather have it declared as `struct A foo;` or > `struct B *ptr;` instead of a type name that doesn't convey struct-ness > at all. Same reason I don't like it when people hide pointers behind > typedefs - I once spent half a day chasing my tail because somebody > created a typedef name for a pointer type and used that as a template > parameter for a vector in C++, such that when I was using an iterator > I needed to write > > (*it)->do_something(); > > However, since the typedef name didn't indicate pointer-ness *at all*, I > wound up writing > > it->do_something(); > > and g++ vomited up hundreds of incomprehensible error messages that > basically boiled down to "you need to use a * here, dummy". Sounds to me like the culprit is C++, not typedefs.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-06-24 13:45 -0700 |
| Message-ID | <2c251905-2ee0-44f0-bac6-2233d23bfcb1n@googlegroups.com> |
| In reply to | #161483 |
On Thursday, 24 June 2021 at 20:33:12 UTC+3, Tim Rentsch wrote: > John Bode <jfbod...@gmail.com> writes: > > [...] > > > To reiterate a point I make a lot - typedef on its own creates leaky > > abstractions. If I need to know that I have to use the `.` or `->` > > operator on something, I'd rather have it declared as `struct A foo;` or > > `struct B *ptr;` instead of a type name that doesn't convey struct-ness > > at all. Same reason I don't like it when people hide pointers behind > > typedefs - I once spent half a day chasing my tail because somebody > > created a typedef name for a pointer type and used that as a template > > parameter for a vector in C++, such that when I was using an iterator > > I needed to write > > > > (*it)->do_something(); > > > > However, since the typedef name didn't indicate pointer-ness *at all*, I > > wound up writing > > > > it->do_something(); > > > > and g++ vomited up hundreds of incomprehensible error messages that > > basically boiled down to "you need to use a * here, dummy". > > Sounds to me like the culprit is C++, not typedefs. It is good old issue of three star programmers (that both C and C++ share) and on given case it was additionally obfuscated by using typedef of pointer. By most C coding guidelines I've seen it is advised not to typedef pointers that are meant to be dereferenced.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2021-07-01 17:57 -0500 |
| Message-ID | <sblh9g$muc$1@dont-email.me> |
| In reply to | #161483 |
On 6/24/21 12:33 PM, Tim Rentsch wrote: > John Bode <jfbode1029@gmail.com> writes: > > [...] > >> To reiterate a point I make a lot - typedef on its own creates leaky >> abstractions. If I need to know that I have to use the `.` or `->` >> operator on something, I'd rather have it declared as `struct A foo;` or >> `struct B *ptr;` instead of a type name that doesn't convey struct-ness >> at all. Same reason I don't like it when people hide pointers behind >> typedefs - I once spent half a day chasing my tail because somebody >> created a typedef name for a pointer type and used that as a template >> parameter for a vector in C++, such that when I was using an iterator >> I needed to write >> >> (*it)->do_something(); >> >> However, since the typedef name didn't indicate pointer-ness *at all*, I >> wound up writing >> >> it->do_something(); >> >> and g++ vomited up hundreds of incomprehensible error messages that >> basically boiled down to "you need to use a * here, dummy". > > Sounds to me like the culprit is C++, not typedefs. > g++ doesn't handle errors in template parameters very well and generates a *lot* of hard-to-follow error messages for relatively simple mistakes. And at the time I was still relatively inexperienced with C++, which didn't help. But the typedef name (or, more properly, the incomplete and leaky abstraction introduced by that typedef name) was the actual culprit. Again, there was nothing to tell me that I was iterating over a vector of *pointers*, not a vector of instances, which required me to use different syntax. With better error messages I would have figured it out in a few minutes rather than half a day, but it was still time lost to a leaky abstraction. That was an egregious case, but far from the only one. Hiding pointers and struct types behind typedefs without an API to handle pointer and member selection operations for you is unambiguously bad practice, and people need to stop doing it.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-07-11 00:26 -0700 |
| Message-ID | <86a6mt8g69.fsf@linuxsc.com> |
| In reply to | #161576 |
John Bode <jfbode1029@gmail.com> writes: > On 6/24/21 12:33 PM, Tim Rentsch wrote: > >> John Bode <jfbode1029@gmail.com> writes: >> >> [...] >> >>> To reiterate a point I make a lot - typedef on its own creates leaky >>> abstractions. If I need to know that I have to use the `.` or `->` >>> operator on something, I'd rather have it declared as `struct A foo;` or >>> `struct B *ptr;` instead of a type name that doesn't convey struct-ness >>> at all. Same reason I don't like it when people hide pointers behind >>> typedefs - I once spent half a day chasing my tail because somebody >>> created a typedef name for a pointer type and used that as a template >>> parameter for a vector in C++, such that when I was using an iterator >>> I needed to write >>> >>> (*it)->do_something(); >>> >>> However, since the typedef name didn't indicate pointer-ness *at all*, I >>> wound up writing >>> >>> it->do_something(); >>> >>> and g++ vomited up hundreds of incomprehensible error messages that >>> basically boiled down to "you need to use a * here, dummy". >> >> Sounds to me like the culprit is C++, not typedefs. > > g++ doesn't handle errors in template parameters very well and generates > a *lot* of hard-to-follow error messages for relatively simple mistakes. > And at the time I was still relatively inexperienced with C++, which > didn't help. > > But the typedef name (or, more properly, the incomplete and leaky > abstraction introduced by that typedef name) was the actual culprit. > [...] I stand by my earlier claim that the culprit here is C++ rather than typedefs.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2021-07-26 09:49 -0500 |
| Message-ID | <sdmi0u$55d$1@dont-email.me> |
| In reply to | #161867 |
On 7/11/21 2:26 AM, Tim Rentsch wrote: > John Bode <jfbode1029@gmail.com> writes: > >> On 6/24/21 12:33 PM, Tim Rentsch wrote: >> >>> John Bode <jfbode1029@gmail.com> writes: >>> >>> [...] >>> >>>> To reiterate a point I make a lot - typedef on its own creates leaky >>>> abstractions. If I need to know that I have to use the `.` or `->` >>>> operator on something, I'd rather have it declared as `struct A foo;` or >>>> `struct B *ptr;` instead of a type name that doesn't convey struct-ness >>>> at all. Same reason I don't like it when people hide pointers behind >>>> typedefs - I once spent half a day chasing my tail because somebody >>>> created a typedef name for a pointer type and used that as a template >>>> parameter for a vector in C++, such that when I was using an iterator >>>> I needed to write >>>> >>>> (*it)->do_something(); >>>> >>>> However, since the typedef name didn't indicate pointer-ness *at all*, I >>>> wound up writing >>>> >>>> it->do_something(); >>>> >>>> and g++ vomited up hundreds of incomprehensible error messages that >>>> basically boiled down to "you need to use a * here, dummy". >>> >>> Sounds to me like the culprit is C++, not typedefs. >> >> g++ doesn't handle errors in template parameters very well and generates >> a *lot* of hard-to-follow error messages for relatively simple mistakes. >> And at the time I was still relatively inexperienced with C++, which >> didn't help. >> >> But the typedef name (or, more properly, the incomplete and leaky >> abstraction introduced by that typedef name) was the actual culprit. >> [...] > > I stand by my earlier claim that the culprit here is C++ > rather than typedefs. > I honestly don't know how to make it any clearer. I lost time due to using the wrong syntax. I was using the wrong syntax because the information I needed in order to use the right syntax was hidden from me. That's not a function of it being C++, that's a function of the abstraction not being complete. I'm not saying don't use typedef. I'm saying that you shouldn't hide pointer-ness or struct-ness behind a typedef name *unless* you are willing to provide an API that hides corresponding operations on those types as well. The C standard library doesn't hide pointer-ness behind typedef names (e.g. the FILE type). You shouldn't either. If you're going to hide a floating point type behind a typedef name, don't make me have to hunt for the typedef to know which conversion specifier I have to use to print it out - provide an API to format it for me. If you're going to hide a struct or union type behind a typedef name, don't make me hunt down the typedef to know how to access the members - provide an API to do that for me. If you're going to hide an array type behind a typedef name, don't make me hunt down the typedef to know I have to use the [] operator or the size - provide an API to handle that for me. If you're going to create an abstraction for a type, CREATE A FULL ABSTRACTION FOR THAT TYPE or don't bother doing it at all.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-07-27 15:47 +0000 |
| Message-ID | <20210727083246.384@kylheku.com> |
| In reply to | #162051 |
On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
> If you're going to hide a struct or union type behind a typedef name,
> don't make me hunt down the typedef to know how to access the members -
> provide an API to do that for me.
I don't find that reasonable; it's pretty common to make typedef names
for structures just to have a shorthand for declaring them, without
intending to create a fully opaque type with abstracted operations.
typedef struct version {
int major;
int minor;
} version_t;
The typedef is co-located with the struct declaration; your ediutor
should be able to jump to the definition of version_t which is
the above line.
Your remark makes sense for a typedef name for a pointer to such
a structure. That's often intended to be an abstract handle.
> If you're going to hide an array type behind a typedef name, don't
Array typedefs should only ever be used for breaking up declarations.
simplifying declarations, not as an abstract type in an API.
Hiding arrays behind typedef names is a poor idea because the result
"abstraction" still cannot be passed to functions, returned or assigned.
The type still decays into a pointer when used as as parameter type.
typedef int foo_t[42];
void fun(foo_t x) {
// programmer trap:
// sizeof x isn't sizeof (foo_t) here!
foo_t y;
// sizeof y *is* sizeof (foo_t).
}
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-07-27 10:55 -0700 |
| Message-ID | <87h7gfiqu0.fsf@nosuchdomain.example.com> |
| In reply to | #162054 |
Kaz Kylheku <563-365-8930@kylheku.com> writes:
> On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
>> If you're going to hide a struct or union type behind a typedef name,
>> don't make me hunt down the typedef to know how to access the members -
>> provide an API to do that for me.
>
> I don't find that reasonable; it's pretty common to make typedef names
> for structures just to have a shorthand for declaring them, without
> intending to create a fully opaque type with abstracted operations.
>
> typedef struct version {
> int major;
> int minor;
> } version_t;
>
> The typedef is co-located with the struct declaration; your ediutor
> should be able to jump to the definition of version_t which is
> the above line.
I disagree. I prefer to refer to the type as "struct version" and not
bother with the typedef.
I'm not arguing I'm right and you're wrong. It's just my preference
(for which I've given reasons before).
The point is that there are two major styles for defining struct types,
and every C programmer who works with code written by other people will
need to deal with both of them.
If I did use typedefs, I'd probably use the same identifier for the tag
and the typedef name.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Guillaume <message@bottle.org> |
|---|---|
| Date | 2021-07-27 23:48 +0200 |
| Message-ID | <sdpuui$1c0v$1@gioia.aioe.org> |
| In reply to | #162057 |
Le 27/07/2021 à 19:55, Keith Thompson a écrit :
> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>> On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
>>> If you're going to hide a struct or union type behind a typedef name,
>>> don't make me hunt down the typedef to know how to access the members -
>>> provide an API to do that for me.
>>
>> I don't find that reasonable; it's pretty common to make typedef names
>> for structures just to have a shorthand for declaring them, without
>> intending to create a fully opaque type with abstracted operations.
>>
>> typedef struct version {
>> int major;
>> int minor;
>> } version_t;
>>
>> The typedef is co-located with the struct declaration; your ediutor
>> should be able to jump to the definition of version_t which is
>> the above line.
>
> I disagree. I prefer to refer to the type as "struct version" and not
> bother with the typedef.
Okay,then certainly it's a matter of taste, and that can't be discussed.
All I'm seeing though is that your argument could be used for just any
type really. Any typedef "hides" the type. It's made for that. It's an
abstraction. It's the whole point. Are you for typeless languages?
Or, what is it that you specifically have with structs that you wouldn't
mind with other types? Like, why does it bother you not to directly see
that a type is a struct, while the fact it's an int, a double, or an
array would matter to you? In any case, you must know what a given type
is for properly using it.
I don't get it. And others seem not to as well. I guess we will never
get it, and that's fine.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-07-27 22:12 +0000 |
| Message-ID | <Tw%LI.6384$XI4.2315@fx09.iad> |
| In reply to | #162063 |
Guillaume <message@bottle.org> writes:
>Le 27/07/2021 à 19:55, Keith Thompson a écrit :
>> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>>> On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
>>>> If you're going to hide a struct or union type behind a typedef name,
>>>> don't make me hunt down the typedef to know how to access the members -
>>>> provide an API to do that for me.
>>>
>>> I don't find that reasonable; it's pretty common to make typedef names
>>> for structures just to have a shorthand for declaring them, without
>>> intending to create a fully opaque type with abstracted operations.
>>>
>>> typedef struct version {
>>> int major;
>>> int minor;
>>> } version_t;
>>>
>>> The typedef is co-located with the struct declaration; your ediutor
>>> should be able to jump to the definition of version_t which is
>>> the above line.
>>
>> I disagree. I prefer to refer to the type as "struct version" and not
>> bother with the typedef.
>
>Okay,then certainly it's a matter of taste, and that can't be discussed.
>
>All I'm seeing though is that your argument could be used for just any
>type really. Any typedef "hides" the type. It's made for that. It's an
>abstraction. It's the whole point. Are you for typeless languages?
>
>Or, what is it that you specifically have with structs that you wouldn't
>mind with other types? Like, why does it bother you not to directly see
>that a type is a struct, while the fact it's an int, a double, or an
>array would matter to you? In any case, you must know what a given type
>is for properly using it.
Consider abstract types such as pid_t or off_t. These allow
the underlying field to change in size (e.g. from unsigned
short to unsigned int) without changing the semantics of
the use of the type. A simple recompile/relink is all that is
necessary to switch to the new definition on a new machine with
different fundamental types.
When you hide a struct behind a typedef, it's not opaque,
as the field names are not generic (there was a time when any
field name could be used with any pointer, but that's long in
the past now).
I generally fall into Keith's camp on this in C, and in C++
I never use typedef to hide a struct (the struct tag is,
in a sense, a typedef in C++).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-28 00:38 +0100 |
| Message-ID | <sdq5e2$e4v$1@dont-email.me> |
| In reply to | #162064 |
On 27/07/2021 23:12, Scott Lurndal wrote:
> Guillaume <message@bottle.org> writes:
>> Le 27/07/2021 à 19:55, Keith Thompson a écrit :
>>> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>>>> On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
>>>>> If you're going to hide a struct or union type behind a typedef name,
>>>>> don't make me hunt down the typedef to know how to access the members -
>>>>> provide an API to do that for me.
>>>>
>>>> I don't find that reasonable; it's pretty common to make typedef names
>>>> for structures just to have a shorthand for declaring them, without
>>>> intending to create a fully opaque type with abstracted operations.
>>>>
>>>> typedef struct version {
>>>> int major;
>>>> int minor;
>>>> } version_t;
>>>>
>>>> The typedef is co-located with the struct declaration; your ediutor
>>>> should be able to jump to the definition of version_t which is
>>>> the above line.
>>>
>>> I disagree. I prefer to refer to the type as "struct version" and not
>>> bother with the typedef.
>>
>> Okay,then certainly it's a matter of taste, and that can't be discussed.
>>
>> All I'm seeing though is that your argument could be used for just any
>> type really. Any typedef "hides" the type. It's made for that. It's an
>> abstraction. It's the whole point. Are you for typeless languages?
>>
>> Or, what is it that you specifically have with structs that you wouldn't
>> mind with other types? Like, why does it bother you not to directly see
>> that a type is a struct, while the fact it's an int, a double, or an
>> array would matter to you? In any case, you must know what a given type
>> is for properly using it.
>
> Consider abstract types such as pid_t or off_t. These allow
> the underlying field to change in size (e.g. from unsigned
> short to unsigned int) without changing the semantics of
> the use of the type. A simple recompile/relink is all that is
> necessary to switch to the new definition on a new machine with
> different fundamental types.
I would rather see specific types, such as i16 i32 i64.
If they need to vary by platform, then provide specific headers for that
platform, instead of ending up with an unmaintainable, unreadable,
fragile mess by trying to have one header for everything.
Some integer types will depend on the target so, fine, use special types
for those (size_t and intptr_t for example). But DON'T have a dedicated
integer typedef for every field of every struct! Declarations like this
are a joke:
struct stat {
dev_t st_dev; /* ID of device containing file */
ino_t st_ino; /* inode number */
mode_t st_mode; /* protection */
nlink_t st_nlink; /* number of hard links */
uid_t st_uid; /* user ID of owner */
gid_t st_gid; /* group ID of owner */
dev_t st_rdev; /* device ID (if special file) */
off_t st_size; /* total size, in bytes */
blksize_t st_blksize; /* blocksize for file system I/O */
blkcnt_t st_blocks; /* number of 512B blocks allocated */
time_t st_atime; /* time of last access */
time_t st_mtime; /* time of last modification */
time_t st_ctime; /* time of last status change */
};
I think there are 13 fields and 10 different types! There will be a
section of header where those 10 typedefs are defined differently per
platform; just use that same mechanism to define specific stat structs
instead.
> When you hide a struct behind a typedef, it's not opaque,
> as the field names are not generic (there was a time when any
> field name could be used with any pointer, but that's long in
> the past now).
>
> I generally fall into Keith's camp on this in C, and in C++
> I never use typedef to hide a struct (the struct tag is,
> in a sense, a typedef in C++).
You don't need to hide it:
typedef struct {...} struct_T;
instead of:
struct T {...};
Use typedef and you can be consistent with all other named user types.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-07-27 18:30 -0700 |
| Message-ID | <87sfzzgr72.fsf@nosuchdomain.example.com> |
| In reply to | #162066 |
Bart <bc@freeuk.com> writes:
> On 27/07/2021 23:12, Scott Lurndal wrote:
[...]
>> Consider abstract types such as pid_t or off_t. These allow
>> the underlying field to change in size (e.g. from unsigned
>> short to unsigned int) without changing the semantics of
>> the use of the type. A simple recompile/relink is all that is
>> necessary to switch to the new definition on a new machine with
>> different fundamental types.
>
> I would rather see specific types, such as i16 i32 i64.
C has those in <stdint.h> (though not by those names).
> If they need to vary by platform, then provide specific headers for
> that platform, instead of ending up with an unmaintainable,
> unreadable, fragile mess by trying to have one header for everything.
The audience for most system headers is the compiler, not the
programmer. I don't need to look at /usr/include/stdint.h to understand
what int32_t means.
> Some integer types will depend on the target so, fine, use special
> types for those (size_t and intptr_t for example). But DON'T have a
> dedicated integer typedef for every field of every struct!
> Declarations like this are a joke:
>
> struct stat {
> dev_t st_dev; /* ID of device containing file */
> ino_t st_ino; /* inode number */
> mode_t st_mode; /* protection */
> nlink_t st_nlink; /* number of hard links */
> uid_t st_uid; /* user ID of owner */
> gid_t st_gid; /* group ID of owner */
> dev_t st_rdev; /* device ID (if special file) */
> off_t st_size; /* total size, in bytes */
> blksize_t st_blksize; /* blocksize for file system I/O */
> blkcnt_t st_blocks; /* number of 512B blocks allocated */
> time_t st_atime; /* time of last access */
> time_t st_mtime; /* time of last modification */
> time_t st_ctime; /* time of last status change */
> };
Would you insist on using the [u]intN_t types for all those members?
And if the requirements for a field vary from one system to another,
what then? Would st_dev and st_ino be the same type on one platform and
different types on another?
> I think there are 13 fields and 10 different types! There will be a
> section of header where those 10 typedefs are defined differently per
> platform; just use that same mechanism to define specific stat structs
> instead.
Are you saying I'd have to use
#include <sys/foostat.h>
on one system and
#include <sys/barstat.h>
on another? I don't think that's really what you meant.
>> When you hide a struct behind a typedef, it's not opaque,
>> as the field names are not generic (there was a time when any
>> field name could be used with any pointer, but that's long in
>> the past now).
>> I generally fall into Keith's camp on this in C, and in C++
>> I never use typedef to hide a struct (the struct tag is,
>> in a sense, a typedef in C++).
>
> You don't need to hide it:
>
> typedef struct {...} struct_T;
>
> instead of:
>
> struct T {...};
>
> Use typedef and you can be consistent with all other named user types.
As you know, that doesn't allow for the very common case of a struct
that contains a pointer to itself. And "struct_T" is (very slightly)
more difficult to type than "struct T".
Most "named user types" are structs. I use a consistent naming scheme
for them. I don't give separate names to pointer or array types, and
most named integer types that I use are defined in standard or system
headers.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-28 13:02 +0100 |
| Message-ID | <sdrh1c$ss$1@dont-email.me> |
| In reply to | #162068 |
On 28/07/2021 02:30, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> I think there are 13 fields and 10 different types! There will be a
>> section of header where those 10 typedefs are defined differently per
>> platform; just use that same mechanism to define specific stat structs
>> instead.
>
> Are you saying I'd have to use
> #include <sys/foostat.h>
> on one system and
> #include <sys/barstat.h>
> on another? I don't think that's really what you meant.
No, you'd use:
#include <sys/stat.h>
If you compile on platform foo, the contents of stat.h will be relevant
to foo; on bar, relevant to bar. You don't have one stat.h containing
declarations for a dozen irrelevant platforms to the one you're on.
If you need to cross-compile for foo or bar on X, then you give the
compiler suitable options as to where to look for system headers. (I
guess the same as happens when you give -m32 or -m64 options.) Or you
just have separate compiler installations.
>> You don't need to hide it:
>>
>> typedef struct {...} struct_T;
>>
>> instead of:
>>
>> struct T {...};
>>
>> Use typedef and you can be consistent with all other named user types.
>
> As you know, that doesn't allow for the very common case of a struct
> that contains a pointer to itself.
I think that's covered with:
typedef struct T {...; struct T*...} struct_T;
> And "struct_T" is (very slightly)
> more difficult to type than "struct T".
That was a suggestion. Other hints can be used. For example I commonly
use Trec, or in the past, rT (eg. rsystemtime).
>
> Most "named user types" are structs.
Apart from off_t, clock_t and friends!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-07-28 07:19 -0700 |
| Message-ID | <87bl6mh65x.fsf@nosuchdomain.example.com> |
| In reply to | #162074 |
Bart <bc@freeuk.com> writes:
> On 28/07/2021 02:30, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> I think there are 13 fields and 10 different types! There will be a
>>> section of header where those 10 typedefs are defined differently per
>>> platform; just use that same mechanism to define specific stat structs
>>> instead.
>> Are you saying I'd have to use
>> #include <sys/foostat.h>
>> on one system and
>> #include <sys/barstat.h>
>> on another? I don't think that's really what you meant.
>
> No, you'd use:
>
> #include <sys/stat.h>
Right, that's what I do now.
> If you compile on platform foo, the contents of stat.h will be
> relevant to foo; on bar, relevant to bar. You don't have one stat.h
> containing declarations for a dozen irrelevant platforms to the one
> you're on.
>
> If you need to cross-compile for foo or bar on X, then you give the
> compiler suitable options as to where to look for system headers. (I
> guess the same as happens when you give -m32 or -m64 options.) Or you
> just have separate compiler installations.
The approach you suggest is perfectly possible and permitted by the
language. Your complaint isn't about C; it's about how implementers
choose to write their headers.
Personally, it wouldn't affect me, since when I use <sys/stat.h> I
usually consult the relevant documentation, not the contents of the
header file.
I suggest that providing a single header makes maintenance easier. If
an implementer chooses to maintain separate "foo" and "bar" versions of
stat.h, they're likely to generate them from a common source anyway.
It's easy enough to use the preprocessor to generate the different
versions.
>>> You don't need to hide it:
>>>
>>> typedef struct {...} struct_T;
>>>
>>> instead of:
>>>
>>> struct T {...};
>>>
>>> Use typedef and you can be consistent with all other named user types.
>> As you know, that doesn't allow for the very common case of a struct
>> that contains a pointer to itself.
>
> I think that's covered with:
>
> typedef struct T {...; struct T*...} struct_T;
Yes, it is, and that's what often done in practice. And if you want to
do it that way, you certainly can. I suggest that just using "struct T"
and dropping the typedef is simpler.
>> And "struct_T" is (very slightly)
>> more difficult to type than "struct T".
>
> That was a suggestion. Other hints can be used. For example I commonly
> use Trec, or in the past, rT (eg. rsystemtime).
Why are "hints" needed? Why use different identifiers for the tag and
the typedef? There are probably some reasons to do that, but *if*
you're going to use typedefs, it's simpler to write:
typedef struct T { ... } T;
>> Most "named user types" are structs.
>
> Apart from off_t, clock_t and friends!
As I wrote, and you snipped (emphasis added):
Most "named user types" are structs. I use a consistent naming
scheme for them. I don't give separate names to pointer or array
types, **and most named integer types that I use are defined in
standard or system headers**.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-07-28 14:06 +0000 |
| Message-ID | <GvdMI.119844$h8.84268@fx47.iad> |
| In reply to | #162068 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Bart <bc@freeuk.com> writes:
>> On 27/07/2021 23:12, Scott Lurndal wrote:
>[...]
>
>> Some integer types will depend on the target so, fine, use special
>> types for those (size_t and intptr_t for example). But DON'T have a
>> dedicated integer typedef for every field of every struct!
>> Declarations like this are a joke:
>>
>> struct stat {
>> dev_t st_dev; /* ID of device containing file */
>> ino_t st_ino; /* inode number */
>> mode_t st_mode; /* protection */
>> nlink_t st_nlink; /* number of hard links */
>> uid_t st_uid; /* user ID of owner */
>> gid_t st_gid; /* group ID of owner */
>> dev_t st_rdev; /* device ID (if special file) */
>> off_t st_size; /* total size, in bytes */
>> blksize_t st_blksize; /* blocksize for file system I/O */
>> blkcnt_t st_blocks; /* number of 512B blocks allocated */
>> time_t st_atime; /* time of last access */
>> time_t st_mtime; /* time of last modification */
>> time_t st_ctime; /* time of last status change */
>> };
>
>Would you insist on using the [u]intN_t types for all those members?
We learned thirty years ago that using sized integer types instead
of abstract types in struct stat (and other application<->OS APIs)
was a very, very, very, very bad idea.
Bart has this bugaboo about having to track down the final definitions
of these abstract types, which is, frankly, ridiculous and short-sighted.
In any case, a simple gcc -E will provide the exact line and exact
source file name for any abstract type defined by the implementation
easily and simply.
$ (cd ~; cc -E a.c | grep ino_t)
typedef unsigned long int __ino_t;
typedef __ino_t ino_t;
__ino_t st_ino;
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-28 15:44 +0100 |
| Message-ID | <sdrqho$qta$1@dont-email.me> |
| In reply to | #162075 |
On 28/07/2021 15:06, Scott Lurndal wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Bart <bc@freeuk.com> writes:
>>> On 27/07/2021 23:12, Scott Lurndal wrote:
>> [...]
>
>>
>>> Some integer types will depend on the target so, fine, use special
>>> types for those (size_t and intptr_t for example). But DON'T have a
>>> dedicated integer typedef for every field of every struct!
>>> Declarations like this are a joke:
>>>
>>> struct stat {
>>> dev_t st_dev; /* ID of device containing file */
>>> ino_t st_ino; /* inode number */
>>> mode_t st_mode; /* protection */
>>> nlink_t st_nlink; /* number of hard links */
>>> uid_t st_uid; /* user ID of owner */
>>> gid_t st_gid; /* group ID of owner */
>>> dev_t st_rdev; /* device ID (if special file) */
>>> off_t st_size; /* total size, in bytes */
>>> blksize_t st_blksize; /* blocksize for file system I/O */
>>> blkcnt_t st_blocks; /* number of 512B blocks allocated */
>>> time_t st_atime; /* time of last access */
>>> time_t st_mtime; /* time of last modification */
>>> time_t st_ctime; /* time of last status change */
>>> };
>>
>> Would you insist on using the [u]intN_t types for all those members?
>
> We learned thirty years ago that using sized integer types instead
> of abstract types in struct stat (and other application<->OS APIs)
> was a very, very, very, very bad idea.
>
> Bart has this bugaboo about having to track down the final definitions
> of these abstract types, which is, frankly, ridiculous and short-sighted.
>
> In any case, a simple gcc -E will provide the exact line and exact
> source file name for any abstract type defined by the implementation
> easily and simply.
>
> $ (cd ~; cc -E a.c | grep ino_t)
> typedef unsigned long int __ino_t;
> typedef __ino_t ino_t;
> __ino_t st_ino;
>
Here's my definition of struct stat as used in stat.h for my Win64 C
compiler:
struct _stat {
unsigned int st_dev;
unsigned short st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
unsigned long st_rdev;
unsigned int st_size;
unsigned long long int st_atime;
unsigned long long int st_mtime;
unsigned long long int st_ctime;
};
This doesn't tell you exactly what short, long etc are, but neither does
you grep example.
But since this is for Windows, that specifies short, int, long, long
long as 16, 32, 32 and 64 bits respectively.
(BTW there are 2 bytes of padding between st_gid and st_rdev fields. You
can determine this by carefully counting, but only becauses the field
sizes are much easier to determine.)
Below are versions from stat.h belonging to Windows SDK. Even though
they are already specific, they still make extensive use of typedefed names!
You can imagine it's rather puzzling figuring out which one I ought to
be using, if I wanted to use some of that functions via a FFI, even
before I need to determine what the types mean.
(I wonder what the purpose of __time32_t is, if this is supposed to be a
32-bit field anyway?)
struct _stat32
{
_dev_t st_dev;
_ino_t st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
_dev_t st_rdev;
_off_t st_size;
__time32_t st_atime;
__time32_t st_mtime;
__time32_t st_ctime;
};
struct _stat32i64
{
_dev_t st_dev;
_ino_t st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
_dev_t st_rdev;
__int64 st_size;
__time32_t st_atime;
__time32_t st_mtime;
__time32_t st_ctime;
};
struct _stat64i32
{
_dev_t st_dev;
_ino_t st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
_dev_t st_rdev;
_off_t st_size;
__time64_t st_atime;
__time64_t st_mtime;
__time64_t st_ctime;
};
struct _stat64
{
_dev_t st_dev;
_ino_t st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
_dev_t st_rdev;
__int64 st_size;
__time64_t st_atime;
__time64_t st_mtime;
__time64_t st_ctime;
};
#define __stat64 _stat64 // For legacy compatibility
#if defined(_CRT_INTERNAL_NONSTDC_NAMES) && _CRT_INTERNAL_NONSTDC_NAMES
&& !defined _CRT_NO_TIME_T
struct stat
{
_dev_t st_dev;
_ino_t st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
_dev_t st_rdev;
_off_t st_size;
time_t st_atime;
time_t st_mtime;
time_t st_ctime;
};
#endif
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-07-28 15:21 +0000 |
| Message-ID | <nCeMI.8803$Dk6.4825@fx20.iad> |
| In reply to | #162077 |
Bart <bc@freeuk.com> writes:
>On 28/07/2021 15:06, Scott Lurndal wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Bart <bc@freeuk.com> writes:
>>>> On 27/07/2021 23:12, Scott Lurndal wrote:
>>> [...]
>>
>>>
>>>> Some integer types will depend on the target so, fine, use special
>>>> types for those (size_t and intptr_t for example). But DON'T have a
>>>> dedicated integer typedef for every field of every struct!
>>>> Declarations like this are a joke:
>>>>
>>>> struct stat {
>>>> dev_t st_dev; /* ID of device containing file */
>>>> ino_t st_ino; /* inode number */
>>>> mode_t st_mode; /* protection */
>>>> nlink_t st_nlink; /* number of hard links */
>>>> uid_t st_uid; /* user ID of owner */
>>>> gid_t st_gid; /* group ID of owner */
>>>> dev_t st_rdev; /* device ID (if special file) */
>>>> off_t st_size; /* total size, in bytes */
>>>> blksize_t st_blksize; /* blocksize for file system I/O */
>>>> blkcnt_t st_blocks; /* number of 512B blocks allocated */
>>>> time_t st_atime; /* time of last access */
>>>> time_t st_mtime; /* time of last modification */
>>>> time_t st_ctime; /* time of last status change */
>>>> };
>>>
>>> Would you insist on using the [u]intN_t types for all those members?
>>
>> We learned thirty years ago that using sized integer types instead
>> of abstract types in struct stat (and other application<->OS APIs)
>> was a very, very, very, very bad idea.
>>
>> Bart has this bugaboo about having to track down the final definitions
>> of these abstract types, which is, frankly, ridiculous and short-sighted.
>>
>> In any case, a simple gcc -E will provide the exact line and exact
>> source file name for any abstract type defined by the implementation
>> easily and simply.
>>
>> $ (cd ~; cc -E a.c | grep ino_t)
>> typedef unsigned long int __ino_t;
>> typedef __ino_t ino_t;
>> __ino_t st_ino;
>>
>
>Here's my definition of struct stat as used in stat.h for my Win64 C
>compiler:
You are willfully ignoring what I wrote.
The point is that _nobody_ cares what the underlying type
of ino_t is.
The point is that we learned the hard way that your solution
isn't future-safe.
The point is that 'struct stat' is data structure defined
by standards that mandate the member data types.
How many customers use your Win64 C compiler for anything,
particularly for production code? How many different computer
architectures does your C compiler support?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-28 17:49 +0100 |
| Message-ID | <sds1rk$pvj$1@dont-email.me> |
| In reply to | #162078 |
On 28/07/2021 16:21, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> Here's my definition of struct stat as used in stat.h for my Win64 C
>> compiler:
>
> You are willfully ignoring what I wrote.
>
> The point is that _nobody_ cares what the underlying type
> of ino_t is.
I do. Or more likely types such as off_t , or off64_t which are also
used in applications. (Wouldn't off_t just be i64?)
> The point is that we learned the hard way that your solution
> isn't future-safe.
It's not my language that is stuck at int = 32 bits, while everything
these days is 64 bits.
> The point is that 'struct stat' is data structure defined
> by standards that mandate the member data types.
What standards? I showed half-a-dozen different versions! Two more below...
> How many customers use your Win64 C compiler for anything,
> particularly for production code? How many different computer
> architectures does your C compiler support?
This is exactly my point. A compiler installation can exist for just one
platform. This goes for Windows compilers such as Pelles C (2 targets),
DMC, lccwin (2 targets), Tcc (2 targets).
The 2 targets in each case are Win32 and Win64. There only really need
to be two targets, in the case of struct stat, because of NOT
future-proofing sufficiently: the needs for file and volume sizes beyond
32-bit capacity were clear 30 years ago.
A product like gcc is huge (like 100,000 development files); having
dedicated definitions for a handful of system header files is
insignificant compared with the dedicated files needed for all its
various targets.
BTW here are two more struct stat definitions to add the mix, this time
from DMC (the one that ONLY needs to support Win32); ghastly isn't it?
Suppose your job is to call one of the myriad *stat() functions from a
non-C language, to find out some info about a file; you'll have your
work cut out. (Actually I don't think I ever bothered trying to call it.)
#if !defined(_STYPES)
#define _ST_FSTYPSZ 16
/* SVR4 stat */
struct stat {
dev_t st_dev;
long st_pad1[3];
ino_t st_ino;
mode_t st_mode;
nlink_t st_nlink;
uid_t st_uid;
gid_t st_gid;
dev_t st_rdev;
long st_pad2[2];
off_t st_size;
long st_pad3;
union
{
time_t st__sec;
timestruc_t st__tim;
} st_atim,
st_mtim,
st_ctim;
long st_blksize;
long st_blocks;
char st_fstype[_ST_FSTYPSZ];
int st_aclcnt;
level_t st_level;
ulong_t st_flags;
lid_t st_cmwlevel;
long st_pad4[4];
};
#define st_atime st_atim.st__sec
#define st_mtime st_mtim.st__sec
#define st_ctime st_ctim.st__sec
#else /* !defined(_STYPES) */
/* SVID 2 stat */
struct stat {
o_dev_t st_dev;
o_ino_t st_ino;
o_mode_t st_mode;
o_nlink_t st_nlink;
o_uid_t st_uid;
o_gid_t st_gid;
o_dev_t st_rdev;
off_t st_size;
time_t st_atime;
time_t st_mtime;
time_t st_ctime;
};
int __cdecl stat(const char *,struct stat *);
int __cdecl fstat(int,struct stat *);
#if !defined(_POSIX_SOURCE)
int __cdecl lstat(const char *, struct stat *);
int __cdecl mknod(const char *, mode_t, dev_t);
#endif
#endif /* !defined(_STYPES) */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-07-28 17:21 +0000 |
| Message-ID | <1mgMI.17475$6j.16299@fx04.iad> |
| In reply to | #162080 |
Bart <bc@freeuk.com> writes:
>On 28/07/2021 16:21, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> Here's my definition of struct stat as used in stat.h for my Win64 C
>>> compiler:
>>
>> You are willfully ignoring what I wrote.
>>
>> The point is that _nobody_ cares what the underlying type
>> of ino_t is.
>
>I do. Or more likely types such as off_t , or off64_t which are also
>used in applications. (Wouldn't off_t just be i64?)
But you are a minority of one. Why should the world cater to
your whims?
(And no, it wouldn't be i64; some implementations may not support
64-bit integers, others may prefer an unsigned definition (although
in this case, posix has specific requirements that off_t be a signed
integer type). All the programmer needs to know that it is a
signed integer type.
>
>> The point is that we learned the hard way that your solution
>> isn't future-safe.
>
>It's not my language that is stuck at int = 32 bits, while everything
>these days is 64 bits.
>
>> The point is that 'struct stat' is data structure defined
>> by standards that mandate the member data types.
>
>What standards? I showed half-a-dozen different versions! Two more below...
>
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html
>
>This is exactly my point. A compiler installation can exist for just one
>platform. This goes for Windows compilers such as Pelles C (2 targets),
>DMC, lccwin (2 targets), Tcc (2 targets).
So what? Programmers generally[*] don't write code for a particular compiler or platform,
they write code to the language specification to solve some problem, which is independent
of any particular compiler implementation. Portability of C code is what
has built the internet as we know it.
And for other languages, the language provides the binding, for
example:
http://www.nongnu.org/posix90/#SEC7
[*] exceptions exist for OS, firmware and to a much lesser extent,
compiler programmers.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-28 23:41 +0100 |
| Message-ID | <sdsme0$2r6$1@dont-email.me> |
| In reply to | #162081 |
On 28/07/2021 18:21, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 28/07/2021 16:21, Scott Lurndal wrote: >>> Bart <bc@freeuk.com> writes: >> >>>> Here's my definition of struct stat as used in stat.h for my Win64 C >>>> compiler: >>> >>> You are willfully ignoring what I wrote. >>> >>> The point is that _nobody_ cares what the underlying type >>> of ino_t is. >> >> I do. Or more likely types such as off_t , or off64_t which are also >> used in applications. (Wouldn't off_t just be i64?) > > But you are a minority of one. Why should the world cater to > your whims? Because it makes sense? These types are long overdue for a clearout. > (And no, it wouldn't be i64; I meant why wouldn't off64_t be just i64. Having off64_t be uint16_t or whatever would be perverse. some implementations may not support > 64-bit integers, others may prefer an unsigned definition (although > in this case, posix has specific requirements that off_t be a signed > integer type). All the programmer needs to know that it is a > signed integer type. I want to call a C function via an FFI from a language that I've devised. The public API says one parameter type is off_t. Which type matches that in my language? I have to choose from i8-i64 and u8-u64. The kind of answer I want is (a) 'It uses i64' etc; or (b) 'It uses i32 or u64 depending on platform'. Not keeping the answer buried for decades under a dozen typedefs, dependent on a dozen conditional macros, dependent on the C compilers used [what C compiler? I might not have one] and hidden in include files 6 levels deep, scattered across multiple directories, to make it as hard as possible to find out. I think the WINAPI also defines far too many different types, but at least they are better documented: https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types You can find all the information needed here, to be able to use these types from a language that is not C. >> >>> The point is that we learned the hard way that your solution >>> isn't future-safe. >> >> It's not my language that is stuck at int = 32 bits, while everything >> these days is 64 bits. >> >>> The point is that 'struct stat' is data structure defined >>> by standards that mandate the member data types. >> >> What standards? I showed half-a-dozen different versions! Two more below... >> > > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html The one that comes with gcc/tdm only defines half a dozen of those (but takes 115 lines to do so!). Others I've seen define 3 or 4. >> >> This is exactly my point. A compiler installation can exist for just one >> platform. This goes for Windows compilers such as Pelles C (2 targets), >> DMC, lccwin (2 targets), Tcc (2 targets). > > So what? Programmers generally[*] don't write code for a particular compiler or platform, > they write code to the language specification to solve some problem, which is independent > of any particular compiler implementation. Portability of C code is what > has built the internet as we know it. > > And for other languages, the language provides the binding, for > example: > > http://www.nongnu.org/posix90/#SEC7 This doesn't do struct stat. But supposing it did, how did /they/ pick up the necessary information? Although they seem to have clocked that 'clock_t' is an integer type, rather than float, something else that C prefers to keep under wraps.
[toc] | [prev] | [next] | [standalone]
Page 6 of 20 — ← Prev page 1 … 4 5 [6] 7 8 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web