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 18 of 20 — ← Prev page 1 … 16 17 [18] 19 20 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-31 02:11 +0100 |
| Message-ID | <se27vq$jbr$1@dont-email.me> |
| In reply to | #162152 |
On 31/07/2021 00:33, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
>>
>> Further, if I try and compile this program:
>>
>> extern int printf(long long,...);
>>
>> int main(void) {
>> printf((long long)"Hello, World!\n");
>> }
>>
>> gcc complains that my printf conflicts with the built-in printf; so it
>> knows perfectly well what it is. It will even tell me if I get the
>> format codes wrong!
>
> You should know how things work (and 'long long' is sign that
> you prefer to complain instead of taking advantage of capabilites
> of gcc). As a little ilustration that printf is independent from
> gcc you can try the following (on Linux, see remarks below about
> Windows).
>
> You need two files, first called 'printf.c' second 'ts2a.c'.
>
> ---------------------<printf.c start>----------------------
>
> extern int printf(const char *f, ...);
>
> extern int putchar(int c);
> #include <stdarg.h>
> #include <string.h>
> int
> printf(const char *f, ...) {
> if (!strcmp(f, "%zu\n")) {
> va_list ap;
> va_start(ap, f);
> size_t val = va_arg(ap, size_t);
> va_end(ap);
> if ((val < 10) && (val >= 0)) {
> putchar('0'+val);
> putchar('\n');
> return 2;
> }
> }
> return 0;
> }
>
> ---------------------<printf.c end>------------------------
>
> ---------------------<ts2a.c start>------------------------
> extern int printf(const char *f, ...);
>
> int main(void) {
> printf("%zu\n", sizeof(void*));
> }
>
> ---------------------<ts2a.c end>--------------------------
>
> First compile printf.c:
>
> gcc -Wall -O -c printf.c
>
> Then compile test program:
>
> gcc -Wall -O ts2a.c printf.o -o ts2a
>
> Resulting program uses 'printf' defined in 'printf.c'. Of course,
> this is silly implementation handling only single format string,
> but using the similar principle one can create full version.
> More elegant solution would put new printf (and variations of
> printf) in a new library (say 'libmyc'). Linking with 'libmyc'
> would give you better version of selected standard function
> and allow use of other functions from system library. You can
> do equivalent of this on Windows. Sorry, I will not give you
> details, I did such things on (more precisly for) Windows
> in the past but it you who apparently cares about Windows,
> so it is for you to do the homework.
>
Sorry, I don't know what your example is supposed to show.
As it is, your printf is close enough to the real printf for gcc not to
complain. Although when I compile ts2a.c (c.c below) with gcc -Wall, it
warns about the unknown "z" in the "%zu" specifier:
C:\c>gcc -c -Wall c.c
c.c: In function 'main':
c.c:4:14: warning: unknown conversion type character 'z' in format
[-Wformat=]
4 | printf("%zu\n", sizeof(void*));
| ^
c.c:4:12: warning: too many arguments for format [-Wformat-extra-args]
4 | printf("%zu\n", sizeof(void*));
| ^~~~~~~
Try something a little more radical like compiling this program:
int printf(int);
I get:
C:\c>gcc c.c
c.c:1:5: warning: conflicting types for built-in function 'printf';
expected 'int(const char *, ...)
' [-Wbuiltin-declaration-mismatch]
1 | int printf(int);
| ^~~~~~
c.c:1:1: note: 'printf' is declared in header '<stdio.h>'
+++ |+#include <stdio.h>
1 | int printf(int);
I don't even need extra warning options. A project I'm working on now
may need to away with standard headers and define functions such as
printf as:
extern i32 printf(u64, ...);
So it will need special options to shut gcc up.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2021-07-31 20:33 +0000 |
| Message-ID | <se4c28$hda$1@z-news.wcss.wroc.pl> |
| In reply to | #162155 |
Bart <bc@freeuk.com> wrote:
> On 31/07/2021 00:33, antispam@math.uni.wroc.pl wrote:
> > Bart <bc@freeuk.com> wrote:
> >>
> >> Further, if I try and compile this program:
> >>
> >> extern int printf(long long,...);
> >>
> >> int main(void) {
> >> printf((long long)"Hello, World!\n");
> >> }
> >>
> >> gcc complains that my printf conflicts with the built-in printf; so it
> >> knows perfectly well what it is. It will even tell me if I get the
> >> format codes wrong!
> >
> > You should know how things work (and 'long long' is sign that
> > you prefer to complain instead of taking advantage of capabilites
> > of gcc). As a little ilustration that printf is independent from
> > gcc you can try the following (on Linux, see remarks below about
> > Windows).
> >
> > You need two files, first called 'printf.c' second 'ts2a.c'.
> >
> > ---------------------<printf.c start>----------------------
> >
> > extern int printf(const char *f, ...);
> >
> > extern int putchar(int c);
> > #include <stdarg.h>
> > #include <string.h>
> > int
> > printf(const char *f, ...) {
> > if (!strcmp(f, "%zu\n")) {
> > va_list ap;
> > va_start(ap, f);
> > size_t val = va_arg(ap, size_t);
> > va_end(ap);
> > if ((val < 10) && (val >= 0)) {
> > putchar('0'+val);
> > putchar('\n');
> > return 2;
> > }
> > }
> > return 0;
> > }
> >
> > ---------------------<printf.c end>------------------------
> >
> > ---------------------<ts2a.c start>------------------------
> > extern int printf(const char *f, ...);
> >
> > int main(void) {
> > printf("%zu\n", sizeof(void*));
> > }
> >
> > ---------------------<ts2a.c end>--------------------------
> >
> > First compile printf.c:
> >
> > gcc -Wall -O -c printf.c
> >
> > Then compile test program:
> >
> > gcc -Wall -O ts2a.c printf.o -o ts2a
> >
> > Resulting program uses 'printf' defined in 'printf.c'. Of course,
> > this is silly implementation handling only single format string,
> > but using the similar principle one can create full version.
> > More elegant solution would put new printf (and variations of
> > printf) in a new library (say 'libmyc'). Linking with 'libmyc'
> > would give you better version of selected standard function
> > and allow use of other functions from system library. You can
> > do equivalent of this on Windows. Sorry, I will not give you
> > details, I did such things on (more precisly for) Windows
> > in the past but it you who apparently cares about Windows,
> > so it is for you to do the homework.
> >
>
> Sorry, I don't know what your example is supposed to show.
It clearly shows that printf is independent and that you can
easily replace it by your own. It shows advantage of having
a linker: you have control of what gets into your executable.
It shows that there is no excuse of sort "Windows does not
support it": if you want you can easily support it just
by implementing printf family, but reusing rest of msvcrt.
> As it is, your printf is close enough to the real printf for gcc not to
> complain. Although when I compile ts2a.c (c.c below) with gcc -Wall, it
> warns about the unknown "z" in the "%zu" specifier:
>
> C:\c>gcc -c -Wall c.c
> c.c: In function 'main':
> c.c:4:14: warning: unknown conversion type character 'z' in format
> [-Wformat=]
> 4 | printf("%zu\n", sizeof(void*));
> | ^
> c.c:4:12: warning: too many arguments for format [-Wformat-extra-args]
> 4 | printf("%zu\n", sizeof(void*));
> | ^~~~~~~
>
> Try something a little more radical like compiling this program:
>
> int printf(int);
Fact that printf is independent of compiler does not mean that
you should replace it by random garbage. In particular, it
make sense to use name 'printf' only when it is compatible
with requirements of C standard.
> I get:
>
> C:\c>gcc c.c
> c.c:1:5: warning: conflicting types for built-in function 'printf';
> expected 'int(const char *, ...)
> ' [-Wbuiltin-declaration-mismatch]
> 1 | int printf(int);
> | ^~~~~~
> c.c:1:1: note: 'printf' is declared in header '<stdio.h>'
> +++ |+#include <stdio.h>
> 1 | int printf(int);
>
>
> I don't even need extra warning options. A project I'm working on now
> may need to away with standard headers and define functions such as
> printf as:
>
> extern i32 printf(u64, ...);
Once you do "#include <stdio.h>" compiler may assume than printf
is standard compliant. I leave to others checking if such prototype
is legal, but regardless of legality using such prototype is
asking for trouble. But you want troubles, without troubles you
would have nothing to complain about...
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-07-31 02:14 +0000 |
| Message-ID | <20210730191145.720@kylheku.com> |
| In reply to | #162113 |
On 2021-07-30, Bart <bc@freeuk.com> wrote:
> On 30/07/2021 15:55, Kaz Kylheku wrote:
>> On 2021-07-29, Bart <bc@freeuk.com> wrote:
>>> It's Windows 7. gcc is version 9.2.0.
>>
>>> This program:
>>>
>>> #include <stdio.h>
>>> int main(void) {printf("%zu\n",sizeof(void*));}
>>>
>>> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
>>
>> The above has no meaning. "gcc" is not the name of any software that
>> provides a printf function.
>>
>
> OK. But gcc and tcc are products that you expect to make the necessary
> arrangements for ensuring they your program can call a C standard
> function called "printf".
Umm, no. For instance, GCC is used for compiling various embedded
code bases that do not have a printf. (One example being the Linux
kernel, which has printk.)
GCC has diagnostic features to help find problems statically
in calls to printf-like functions.
Using GCC extensiosn, you can easily arrange this for your own
functions.
> Which they do, because it generally works. But whatever it is they end
> up linking into your program, doesn't support "zu".
>
> I use msvcrt.dll for my compiler's library (sometimes, ucrtbase.dll).
> Which library do gcc and tcc use?
There is somnething called "libgcc" associated with GCC. This is
run-time support for compiled code. For instance, numeric routines
for operations that the compiler doesn't want to emit in-line.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-07-30 21:23 -0700 |
| Message-ID | <87o8ajaz76.fsf@nosuchdomain.example.com> |
| In reply to | #162157 |
Kaz Kylheku <563-365-8930@kylheku.com> writes:
> On 2021-07-30, Bart <bc@freeuk.com> wrote:
>> On 30/07/2021 15:55, Kaz Kylheku wrote:
[...]
>> Which they do, because it generally works. But whatever it is they end
>> up linking into your program, doesn't support "zu".
>>
>> I use msvcrt.dll for my compiler's library (sometimes, ucrtbase.dll).
>> Which library do gcc and tcc use?
>
> There is somnething called "libgcc" associated with GCC. This is
> run-time support for compiled code. For instance, numeric routines
> for operations that the compiler doesn't want to emit in-line.
And to be clear (for Bart's possible benefit), msvcrt.dll is an outdated
C library implementation that provides things like printf, while libgcc
is a more limited library that provides features that are more tightly
tied to the compiler than to the library implementation, such as
<stdbool.h>, <stdarg.h>, and low-level startup and shutdown code.
gcc and tcc will of course use other libraries as well in most cases,
depending on how the implementation is configured.
--
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-31 11:39 +0100 |
| Message-ID | <se398v$vju$1@dont-email.me> |
| In reply to | #162157 |
On 31/07/2021 03:14, Kaz Kylheku wrote:
> On 2021-07-30, Bart <bc@freeuk.com> wrote:
>> On 30/07/2021 15:55, Kaz Kylheku wrote:
>>> On 2021-07-29, Bart <bc@freeuk.com> wrote:
>>>> It's Windows 7. gcc is version 9.2.0.
>>>
>>>> This program:
>>>>
>>>> #include <stdio.h>
>>>> int main(void) {printf("%zu\n",sizeof(void*));}
>>>>
>>>> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
>>>
>>> The above has no meaning. "gcc" is not the name of any software that
>>> provides a printf function.
>>>
>>
>> OK. But gcc and tcc are products that you expect to make the necessary
>> arrangements for ensuring they your program can call a C standard
>> function called "printf".
>
> Umm, no. For instance, GCC is used for compiling various embedded
> code bases that do not have a printf. (One example being the Linux
> kernel, which has printk.)
And?
If I look at K&R2 page 6, they show the hello-world example that uses
printf(), and suggest it is built using:
cc hello.c
This seems to magically work, in exactly the same way that:
gcc hello.c
does on Windows. They even both create an executable starting with "a"
(a.out vs a.exe).
Are you going to accuse Kernighan and Ritchie about making unwarranted
assumptions about what a compiler is and isn't?
> GCC is used for compiling various embedded
> code bases that do not have a printf. (One example being the Linux
> kernel, which has printk.)
I think I was coding for nearly 20 years before I first used printf in C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-07-31 12:58 -0700 |
| Message-ID | <87fsvub6gz.fsf@nosuchdomain.example.com> |
| In reply to | #162161 |
Bart <bc@freeuk.com> writes:
> On 31/07/2021 03:14, Kaz Kylheku wrote:
>> On 2021-07-30, Bart <bc@freeuk.com> wrote:
>>> On 30/07/2021 15:55, Kaz Kylheku wrote:
>>>> On 2021-07-29, Bart <bc@freeuk.com> wrote:
>>>>> It's Windows 7. gcc is version 9.2.0.
>>>>
>>>>> This program:
>>>>>
>>>>> #include <stdio.h>
>>>>> int main(void) {printf("%zu\n",sizeof(void*));}
>>>>>
>>>>> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
>>>>
>>>> The above has no meaning. "gcc" is not the name of any software that
>>>> provides a printf function.
>>>
>>> OK. But gcc and tcc are products that you expect to make the necessary
>>> arrangements for ensuring they your program can call a C standard
>>> function called "printf".
>> Umm, no. For instance, GCC is used for compiling various embedded
>> code bases that do not have a printf. (One example being the Linux
>> kernel, which has printk.)
>
> And?
>
> If I look at K&R2 page 6, they show the hello-world example that uses
> printf(), and suggest it is built using:
>
> cc hello.c
>
> This seems to magically work, in exactly the same way that:
>
> gcc hello.c
>
> does on Windows. They even both create an executable starting with "a"
> (a.out vs a.exe).
>
> Are you going to accuse Kernighan and Ritchie about making unwarranted
> assumptions about what a compiler is and isn't?
No, I'm not.
"cc" is as driver program that might invoke several different programs,
including a preprocessor, a compiler, an assembler, and a linker. It
was perfectly reasonable for K&R not to get into those details in the
"Getting Started" section.
The book isn't about teaching people how implementations work. It's
about teaching people to program in C. Details about how the tools work
are appropriately glossed over.
Someone learning to use a C implementation for an embedded target system
that doesn't support printf will need some resource other than K&R.
Kernighan and Ritchie did not repeatedly and stubbornly refuse to
acknowledge, when directly asked, that a compiler is just one component
of a C implementation. That was someone else.
>> GCC is used for compiling various embedded
>> code bases that do not have a printf. (One example being the Linux
>> kernel, which has printk.)
>
> I think I was coding for nearly 20 years before I first used printf in C.
Interesting. A more common time span for that is about 5 minutes.
I'm not saying there's anything wrong with your approach, but you are an
extreme outlier, and you cannot expect everyone to cater to your very
specific needs.
--
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 | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2021-07-31 21:21 +0000 |
| Message-ID | <se4et5$6ho$1@dont-email.me> |
| In reply to | #162169 |
On Sat, 31 Jul 2021 12:58:52 -0700, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: [snip] >> Are you going to accuse Kernighan and Ritchie about making unwarranted >> assumptions about what a compiler is and isn't? > > No, I'm not. > > "cc" is as driver program that might invoke several different programs, > including a preprocessor, a compiler, an assembler, and a linker. It > was perfectly reasonable for K&R not to get into those details in the > "Getting Started" section. > > The book isn't about teaching people how implementations work. It's > about teaching people to program in C. Details about how the tools work > are appropriately glossed over. In "A Tour through the UNIX C Compiler" (D.M. Ritchie, Bell Laboratories, reprinted in "Unix Programmer's Manual Volume 2 (c) 1979, 1983), Dennis Ritchie makes it clear that said compiler's input was the output of a separate C-language preprocessor, and that the compiler's ultimate output was textual assembly language compatible with the Unix Assembler. This situation is also described in "A Tour Through the Portable C Compiler" (S.C. Johnson, Bell Laboratories, reprinted in the same "Unix Programmer's Manual Volume 2), in a little more detail. "The compiler consists of two passes, /pass1/ and /pass2/, that together turn C source code into assembler code for the target machine. The two passes are preceded by a preprocessor, that handles the #define and #include statements, and related features (e.g. #ifdef, etc.). It is a nearly machine independent program and will not be further discussed here. The output of the preprocessor is a text file that is read as the standard input of the first pass. ... The second pass produces, as standard output, the desired assembler language source code." It is worthy to note that, in "A Tour through the UNIX C Compiler", Dennis Ritchie indicates that "C was originally a one-pass compiler" that they divided into two programs because of memory constraints. This explains some of the early C language requirements, such as "declaration before use", etc. [snip] -- Lew Pitcher "In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-07-30 14:54 +0000 |
| Message-ID | <20210730075144.772@kylheku.com> |
| In reply to | #162092 |
On 2021-07-29, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Bart <bc@freeuk.com> writes: >> On 29/07/2021 03:20, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: > [...] >>>> Sure, I can do that (after fixing the code with the right includes and >>>> avoiding %zu). But that's the trial and error approach. >>> %zu is the correct format specifier. I'm not even going to ask why >>> you'd want to avoid it. >> >> I'll tell you anyway: it doesn't work on Windows. > > Yes, it does. I don't know why it wouldn't work for you. Are you using > some obsolete version of Windows or of its C implementation? There is no "its C implementation" in regard to Windows. C programs for Windows carry their own C run-times. (Some misguided developers think that an undocumented component called MSVCRT.DLL in the system folder provides parts of the Library clause of a C implementation for use by Windows applications; they are simply wrong.) -- 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-30 10:47 -0700 |
| Message-ID | <87h7gbels9.fsf@nosuchdomain.example.com> |
| In reply to | #162110 |
Kaz Kylheku <563-365-8930@kylheku.com> writes:
> On 2021-07-29, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 29/07/2021 03:20, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>> [...]
>>>>> Sure, I can do that (after fixing the code with the right includes and
>>>>> avoiding %zu). But that's the trial and error approach.
>>>> %zu is the correct format specifier. I'm not even going to ask why
>>>> you'd want to avoid it.
>>>
>>> I'll tell you anyway: it doesn't work on Windows.
>>
>> Yes, it does. I don't know why it wouldn't work for you. Are you using
>> some obsolete version of Windows or of its C implementation?
>
> There is no "its C implementation" in regard to Windows. C programs for
> Windows carry their own C run-times.
>
> (Some misguided developers think that an undocumented component called
> MSVCRT.DLL in the system folder provides parts of the Library clause of
> a C implementation for use by Windows applications; they are simply wrong.)
Apparently MSVCRT.DLL is an old C runtime library that's still shipped
with Windows for backward compatibility. It (probably) was the
recommended C library implementation for use by Windows applications as
of about 20 years ago.
https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MSVCP*.DLL_and_CRTDLL.DLL
--
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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-07-30 14:16 -0700 |
| Message-ID | <se1q7p$1kf3$1@gioia.aioe.org> |
| In reply to | #162123 |
On 7/30/2021 10:47 AM, Keith Thompson wrote: > Kaz Kylheku <563-365-8930@kylheku.com> writes: >> On 2021-07-29, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>> Bart <bc@freeuk.com> writes: >>>> On 29/07/2021 03:20, Keith Thompson wrote: >>>>> Bart <bc@freeuk.com> writes: >>> [...] >>>>>> Sure, I can do that (after fixing the code with the right includes and >>>>>> avoiding %zu). But that's the trial and error approach. >>>>> %zu is the correct format specifier. I'm not even going to ask why >>>>> you'd want to avoid it. >>>> >>>> I'll tell you anyway: it doesn't work on Windows. >>> >>> Yes, it does. I don't know why it wouldn't work for you. Are you using >>> some obsolete version of Windows or of its C implementation? >> >> There is no "its C implementation" in regard to Windows. C programs for >> Windows carry their own C run-times. >> >> (Some misguided developers think that an undocumented component called >> MSVCRT.DLL in the system folder provides parts of the Library clause of >> a C implementation for use by Windows applications; they are simply wrong.) > > Apparently MSVCRT.DLL is an old C runtime library that's still shipped > with Windows for backward compatibility. It (probably) was the > recommended C library implementation for use by Windows applications as > of about 20 years ago. > > https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MSVCP*.DLL_and_CRTDLL.DLL > Iirc, they have a lot of legacy code from Dinkumwarein in there: https://www.dinkumware.com/
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-07-30 14:51 +0000 |
| Message-ID | <20210730074338.301@kylheku.com> |
| In reply to | #162087 |
On 2021-07-29, Bart <bc@freeuk.com> wrote: > I'll tell you anyway: [%zu] doesn't work on Windows. That has no meaning. "Windows" is not a C implementation. %zu works on Windows if you find a C implementation for Windows with a run-time library whose printf supports it. I see that Microsoft is documenting "z". Find the MSDN documentation page called "Format specification syntax: printf and wprintf functions" and search within it for "Size Prefixes for printf and wprintf Format-Type Specifiers". https://docs.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=msvc-160 Also supported in Cygwin and probably other run-times like MinGW-W64. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-07-30 20:22 +0200 |
| Message-ID | <se1g1e$1635$1@gioia.aioe.org> |
| In reply to | #162087 |
On 7/29/2021 12:05 PM, Bart wrote:
> On 29/07/2021 03:20, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 29/07/2021 00:07, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> On 28/07/2021 18:21, Scott Lurndal wrote:
>>>>>> Bart <bc@freeuk.com> writes:
>>>> [...]
>>>>
>>>>> 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'.
>>>> POSIX says that off_t is a signed integer type.
>>>> Is there some reason that compiling and running this program on the
>>>> target system doesn't solve your problem?
>>>> #include <stdio.h>
>>>> #include <limits.h>
>>>> int main(void) {
>>>> printf("off_t is %c%zu\n",
>>>> (off_t)-1 < (off_t)0 ? 'i' : 'u',
>>>> CHAR_BIT * sizeof (off_t));
>>>> }
>>>
>>> Sure, I can do that (after fixing the code with the right includes and
>>> avoiding %zu). But that's the trial and error approach.
>>
>> %zu is the correct format specifier. I'm not even going to ask why
>> you'd want to avoid it.
>
> I'll tell you anyway: it doesn't work on Windows.
>
>> Yes, I probably should have used `#include <sys/types.h>`.
>>
>> No, it's not trial and error. Write the program once, compile and run
>> it on each platform of interest. Expand the program as needed to show
>> the characteristcs of all the types you're interested in. Tweak the
>> output any way you like to suit your purposes. Make it generate source
>> code in your personal language if you like.
>
> This is stuff I've had to do years ago. More recently, I could
> semi-translate C APIs (although normally I'd exclude system headers), by
> using a special option on my C compiler, which will generate a
> particular rendering, as often APIs bristle with compile-specific code.
>
> It doesn't attempt most of the macros that are normally used, which in
> general contain expressions in C syntax which is not trivially convertible.
>
> Generating FFI bindings of C APIs is a big job. Most people who have to
> do similar things are not going to be writing their own C parsers or
> whatever; they might have to use more heavyweight solutions, or simply
> do a huge amount of work.
>
C APIs (meaning APIs written in C) are excellent for cross-language
implementations, in fact the Windows API /is/ a C api because that's the
best choice to make it usable by the plethora of languages that
Microsoft markets.
If what you actually mean is having a different language interface with
the C standard library, then I see your point.
Comparing e.g. the C standard library and the Windows API, the former is
next to impossible to use from another language compared to the latter,
due to the difficulties you have explained.
The reason for that is, I think, about the demand for such interoperability.
Microsoft has always had a strong commercial drive to sell multiple
programming languages for their system, so they wrote their API in such
a way that it would be relatively easy to interface with from other
languages. As said, the Windows API /is/ written in C because this
language allows for the necessary specialization of an API, but it has
nothing to do with the C standard library - note that the Windows API is
Kernel32.dll and friends, /not/ msvcrt.dll.
An important aspect of this scenario is that Windows has mostly targeted
only Intel based PCs, that's it; and even nowadays I believe they only
support architectures that can provide a compatible subsystem with that
architecture.
The story about the C standard library is completely different, it is
not an OS api, but instead it can be seen as an abstraction /for the C
language/ of OS services that is required to support many different
architectures.
Back to your point, I think that a language that cares about efficiency
would probably access OS facilities directly, for example: on Windows,
kernel32.dll etc., not msvcrt.dll. On *nix I wouldn't know, but I wonder
if a Fortran implementation actually uses libc.so.
If a language would want to use the C standard library to access OS
services I think it should include a C proxy, a module /written in C/
that exposes the required facilities to the language environment: for
example, in your case about "struct stat" a module that provides the
required conversions between its types to the types of your language.
> The off_t and other types are examples of where how C is typically
> written makes it harder than necessary. Instead of using a plain type,
> or even using one layer of typedefs, it uses several.
>
> (For gcc/tdm, off_t is defined inside _mingw_off_t.h (it has its own
> header!). This defines also _off_t and off32_t as 'long'; _off64_t and
> off64_t; and off_t itself as either off64_t or off32_t
>
> One clock_t type used 6 layers of typedefs and macros; what the hell
> happended there? This is why I'm saying this stuff should be overhauled.
> Obviously no one wants to mess with it, so they add their own
> abstractions. Then someone else does the same... Eventually someone
> whats to printf such a value!)
>
> -----------------------------------------------
> _mingw_off_t.h
> -----------------------------------------------
> #ifndef _OFF_T_DEFINED
> #define _OFF_T_DEFINED
> #ifndef _OFF_T_
> #define _OFF_T_
> typedef long _off_t;
> #if !defined(NO_OLDNAMES) || defined(_POSIX)
> typedef long off32_t;
> #endif
> #endif
>
> #ifndef _OFF64_T_DEFINED
> #define _OFF64_T_DEFINED
> __MINGW_EXTENSION typedef long long _off64_t;
> #if !defined(NO_OLDNAMES) || defined(_POSIX)
> __MINGW_EXTENSION typedef long long off64_t;
> #endif
> #endif /*_OFF64_T_DEFINED */
>
> #ifndef _FILE_OFFSET_BITS_SET_OFFT
> #define _FILE_OFFSET_BITS_SET_OFFT
> #if !defined(NO_OLDNAMES) || defined(_POSIX)
> #if (defined(_FILE_OFFSET_BITS) && (_FILE_OFFSET_BITS == 64))
> typedef off64_t off_t;
> #else
> typedef off32_t off_t;
> #endif /* #if !defined(NO_OLDNAMES) || defined(_POSIX) */
> #endif /* (defined(_FILE_OFFSET_BITS) && (_FILE_OFFSET_BITS == 64)) */
> #endif /* _FILE_OFFSET_BITS_SET_OFFT */
>
> #endif /* _OFF_T_DEFINED */
> -----------------------------------------------
>
> All to define a type which is i32 or i64; wonderful isn't it?
>
> Let's face it, if you had to write some functions or data types that
> expressed a file offset, you'd just use int64_t and be done with it.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-07-30 14:07 -0700 |
| Message-ID | <se1pmh$1eme$1@gioia.aioe.org> |
| In reply to | #162129 |
On 7/30/2021 11:22 AM, Manfred wrote: > On 7/29/2021 12:05 PM, Bart wrote: >> On 29/07/2021 03:20, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >>>> On 29/07/2021 00:07, Keith Thompson wrote: >>>>> Bart <bc@freeuk.com> writes: >>>>>> On 28/07/2021 18:21, Scott Lurndal wrote: >>>>>>> Bart <bc@freeuk.com> writes: [...] > Microsoft has always had a strong commercial drive to sell multiple > programming languages for their system, so they wrote their API in such > a way that it would be relatively easy to interface with from other > languages. As said, the Windows API /is/ written in C because this > language allows for the necessary specialization of an API, but it has > nothing to do with the C standard library - note that the Windows API is > Kernel32.dll and friends, /not/ msvcrt.dll. > An important aspect of this scenario is that Windows has mostly targeted > only Intel based PCs, that's it; and even nowadays I believe they only > support architectures that can provide a compatible subsystem with that [...] Windows on a Dec Alpha was fun!
[toc] | [prev] | [next] | [standalone]
| From | John Dill <jadill33@gmail.com> |
|---|---|
| Date | 2021-07-29 06:09 -0700 |
| Message-ID | <b7491e5f-66f9-427b-a738-87b99980abe5n@googlegroups.com> |
| In reply to | #162085 |
On Wednesday, July 28, 2021 at 10:20:43 PM UTC-4, Keith Thompson wrote:
> Bart <b...@freeuk.com> writes:
> > On 29/07/2021 00:07, Keith Thompson wrote:
> >> Bart <b...@freeuk.com> writes:
> >>> On 28/07/2021 18:21, Scott Lurndal wrote:
> >>>> Bart <b...@freeuk.com> writes:
> >> [...]
> >>
> >>> 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'.
> >> POSIX says that off_t is a signed integer type.
> >> Is there some reason that compiling and running this program on the
> >> target system doesn't solve your problem?
> >> #include <stdio.h>
> >> #include <limits.h>
> >> int main(void) {
> >> printf("off_t is %c%zu\n",
> >> (off_t)-1 < (off_t)0 ? 'i' : 'u',
> >> CHAR_BIT * sizeof (off_t));
> >> }
> >
> > Sure, I can do that (after fixing the code with the right includes and
> > avoiding %zu). But that's the trial and error approach.
> %zu is the correct format specifier. I'm not even going to ask why
> you'd want to avoid it.
>
> Yes, I probably should have used `#include <sys/types.h>`.
>
> No, it's not trial and error. Write the program once, compile and run
> it on each platform of interest. Expand the program as needed to show
> the characteristcs of all the types you're interested in. Tweak the
> output any way you like to suit your purposes. Make it generate source
> code in your personal language if you like.
> > In the end I might end up with a list of such types for my platform,
> > and what concrete types they actually are.
> >
> > But, why doesn't such a list already exist anyway? It's not as though
> > my platform is a rare, obscure one out of hundreds; it's Windows on
> > x64. The other two I might be interested in are Linux on x64 and on
> > arm64.
> Such a list might exist somewhere. If it doesn't, or if it's hard to
> find, it's probably because not many people are interested in it.
>
> And I've just shown you how you can generate such a list yourself, by
> writing a C program that generates it.
>
> [snip]
>
> (I didn't look at the Fortran stuff.)
This is kind of what build systems are for, even though it doesn't suit
Bart's tastes. To find the size of an opaque type, you'd leverage something
similar to ac_check_sizeof from autoconf that basically generates a C
program, runs the program, inspects the stdout, stderr or return code, then
sets a define in a config.h style file based on the result.
Bart could even do his own mini home-grown version of that if he had
the motivation. You just need some kind of scripting language that can
interact with the shell.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-29 14:26 +0100 |
| Message-ID | <sduab9$1le$1@dont-email.me> |
| In reply to | #162089 |
On 29/07/2021 14:09, John Dill wrote:
> On Wednesday, July 28, 2021 at 10:20:43 PM UTC-4, Keith Thompson wrote:
>> Bart <b...@freeuk.com> writes:
>>> On 29/07/2021 00:07, Keith Thompson wrote:
>>>> Bart <b...@freeuk.com> writes:
>>>>> On 28/07/2021 18:21, Scott Lurndal wrote:
>>>>>> Bart <b...@freeuk.com> writes:
>>>> [...]
>>>>
>>>>> 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'.
>>>> POSIX says that off_t is a signed integer type.
>>>> Is there some reason that compiling and running this program on the
>>>> target system doesn't solve your problem?
>>>> #include <stdio.h>
>>>> #include <limits.h>
>>>> int main(void) {
>>>> printf("off_t is %c%zu\n",
>>>> (off_t)-1 < (off_t)0 ? 'i' : 'u',
>>>> CHAR_BIT * sizeof (off_t));
>>>> }
>>>
>>> Sure, I can do that (after fixing the code with the right includes and
>>> avoiding %zu). But that's the trial and error approach.
>> %zu is the correct format specifier. I'm not even going to ask why
>> you'd want to avoid it.
>>
>> Yes, I probably should have used `#include <sys/types.h>`.
>>
>> No, it's not trial and error. Write the program once, compile and run
>> it on each platform of interest. Expand the program as needed to show
>> the characteristcs of all the types you're interested in. Tweak the
>> output any way you like to suit your purposes. Make it generate source
>> code in your personal language if you like.
>>> In the end I might end up with a list of such types for my platform,
>>> and what concrete types they actually are.
>>>
>>> But, why doesn't such a list already exist anyway? It's not as though
>>> my platform is a rare, obscure one out of hundreds; it's Windows on
>>> x64. The other two I might be interested in are Linux on x64 and on
>>> arm64.
>> Such a list might exist somewhere. If it doesn't, or if it's hard to
>> find, it's probably because not many people are interested in it.
>>
>> And I've just shown you how you can generate such a list yourself, by
>> writing a C program that generates it.
>>
>> [snip]
>>
>> (I didn't look at the Fortran stuff.)
>
> This is kind of what build systems are for, even though it doesn't suit
> Bart's tastes. To find the size of an opaque type, you'd leverage something
> similar to ac_check_sizeof from autoconf that basically generates a C
> program, runs the program, inspects the stdout, stderr or return code, then
> sets a define in a config.h style file based on the result.
>
> Bart could even do his own mini home-grown version of that if he had
> the motivation. You just need some kind of scripting language that can
> interact with the shell.
>
People seem to be missing the point. You shouldn't NEED to write
scripts, install a C compiler, write test programs just to find out what
a type is! They shouldn't work as hard as they do to hide these types.
For goodness sake, an offset type is either going to be i32 or i64!
Look at my link to Windows data types, where all the info needed is on
that one web-page.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-07-29 13:51 +0000 |
| Message-ID | <JnyMI.95667$Vv6.47715@fx45.iad> |
| In reply to | #162090 |
Bart <bc@freeuk.com> writes: >On 29/07/2021 14:09, John Dill wrote: >> >> Bart could even do his own mini home-grown version of that if he had >> the motivation. You just need some kind of scripting language that can >> interact with the shell. >> > >People seem to be missing the point. You shouldn't NEED to write >scripts, install a C compiler, write test programs just to find out what >a type is! They shouldn't work as hard as they do to hide these types. No, you're missing the point. 99.9999% of people writing code in the C language don't need to know what the underlying type is. Noting that it (off_t for example) is a signed integer is all they need to know. > >For goodness sake, an offset type is either going to be i32 or i64! No, it's not. C runs on many platforms other than Windows on x86.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-29 16:18 +0100 |
| Message-ID | <sdugt4$ncj$1@dont-email.me> |
| In reply to | #162091 |
On 29/07/2021 14:51, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 29/07/2021 14:09, John Dill wrote: > >>> >>> Bart could even do his own mini home-grown version of that if he had >>> the motivation. You just need some kind of scripting language that can >>> interact with the shell. >>> >> >> People seem to be missing the point. You shouldn't NEED to write >> scripts, install a C compiler, write test programs just to find out what >> a type is! They shouldn't work as hard as they do to hide these types. > > No, you're missing the point. 99.9999% of people writing code > in the C language don't need to know what the underlying type is. Noting > that it (off_t for example) is a signed integer is all they need > to know. > >> >> For goodness sake, an offset type is either going to be i32 or i64! > > No, it's not. C runs on many platforms other than Windows on x86. > You have a small point, but mainly you're just making excuses for some terrible header code that should long have been cleaned up. The _mingw_off_t.h file I posted that makes such a meal of defining off_t, is specifically for Windows on x86. I would also suggest that those languages that would like to use C libraries, the ones that predominantly use integer types based around 8/16/32/64 bits, will not be running on the same 13-bit processors that C likes to support. They are also unlikely to run under a system where a file offset of 16 bits is sufficient (that would be too small even for a 1980s floppy disk). The most useful type these days would be i64. I actually haven't used fstat(), if that's what's it's called, for perhaps 20 years. There are two many myriad combinations of it with the numerous variations of struct stat, off_t and the rest. There are 8 combinations listed here (6 functions plus file length variations, halfway down the page): https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fstat-fstat32-fstat64-fstati64-fstat32i64-fstat64i32?view=msvc-160 Another page lists TWELVE versions of struct stat (6 using char* plus 6 with wchar_t*). This is for basically two platforms (Win32 and Win64), but they will run under the same file system that will have files bigger than 2GB, so you'd expect the same file functions and associated types for both. I would call that messy, and that's without even delving into the headers.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-09-30 05:39 -0700 |
| Message-ID | <86wnmyteyo.fsf@linuxsc.com> |
| In reply to | #162064 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Guillaume <message@bottle.org> writes:
>
>> Le 27/07/2021 a` 19:55, Keith Thompson a @C3{A9}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. [...]
Neither off_t nor pid_t is an abstract type. Both are signed
integer types with defined meanings for the values. In the case
of off_t, the value is how many bytes to go forward or backward.
In the case of pid_t, the value is the identifying number of the
process, with two distinguished values (0 and -1) that mean
something else. Knowing the identifying number of a process is
useful for comparing with things like 'ps' output. Also, even if
the identifying number of a process isn't especially useful by
itself, that the value is a signed integer can be useful for
other uses such as sorting or producing hash values. Such things
would not be available if these types were truly abstract types.
What these type names do provide is some amount of information
hiding, in particular how wide the underlying integer type is.
In most cases code doesn't need to know exactly how wide the
underlying type is. Following the principle (in programming)
that if it isn't really important to know something then it's
better not to know it, information about exactly which integer
types are used is hidden behind a typedef name.
> 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).
Using a typedef name for a struct type similarly provides a
degree of information hiding. If there are 25 "clients" of a
struct type, and only 5 of them actually make use of the type's
"structness" (with . or ->), the other 20 can be written without
regard to whether the type is a struct or it isn't. The
principle of information hiding says doing that has value.
Conversely, not using a typedef name for said struct type forces
every client to be aware of the type being a struct type, whether
they need to know that or not. That's an unfortunate consequence
of a rule prohibiting the use of typedefs for struct types.
> 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++).
In many cases struct types are used as "mostly abstract" types,
with only a few use points needing to make use of member access.
In such cases it's nice to have the option of using a typedef so
that the type name reflects the dominant use case.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-07-27 17:14 -0700 |
| Message-ID | <87wnpbgur1.fsf@nosuchdomain.example.com> |
| 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.
>
> I don't get it. And others seem not to as well. I guess we will never
> get it, and that's fine.
As I said, I've discussed my reasoning here before, but I don't mind
doing so again.
For me, the point is that "struct version" already has a perfectly good
name: "struct version". I see no great value in giving it another name,
such as "version_t", or even "version". It introduces potential
confusion with no particular benefit.
FILE is a great example of an appropriate use of a typedef. It's
required to be an object type, but code that uses it doesn't and
shouldn't care that it's a struct, and shouldn't attempt to refer to its
members, if any. But code that uses struct version needs to know that
it's a struct, and needs to be able to refer to its members.
Typedefs are also a good way to define a name for an integer type where
code that uses it doesn't need to know which underlying type it is.
They can provide information about what the type is used for (size_t,
for example). A struct tag can provide that same information.
Historically, typedefs were a relatively late addition to C.
In pre-typedef C, a type name could never be just an identifier. Type
names (unlike in some languages) were always constructed using syntax
involving some combination of keywords, symbols, and identifiers.
It's possible but not practical to give *all* types names consisting of
a single identifier. I see no great advantage in doing so just for
struct types.
Having said that, if I were working on a C project that had a convention
of using typedefs for struct types, I would follow that convention
without hesitation. If there were inconsistent rules about the
relationship between tag names and typedef names, I might raise that as
a concern and suggest using the same identifier for both. And in
$DAYJOB I work in C++, which doesn't have this issue (defining "struct
foo" creates a type named "foo", and I don't call it "struct foo",
because C++ is a different language with different rules).
Routinely using typedefs for struct types strikes me as a way of
papering over an aspect of the C language that some people dislike.
Since I personally don't dislike it, I don't bother unless there's a
good reason to do so.
--
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 | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-07-28 02:01 +0000 |
| Message-ID | <20210727185644.467@kylheku.com> |
| In reply to | #162057 |
On 2021-07-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> 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).
Right, of course; but all I'm saying is that there exists a certain
coding style with those typedefs, in which the typedefs do *not* signify
"I am an opaque type accessed only by an API".
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
Page 18 of 20 — ← Prev page 1 … 16 17 [18] 19 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web