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 5 of 20 — ← Prev page 1 … 3 4 [5] 6 7 … 20 Next page →
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-06-11 23:21 +0000 |
| Message-ID | <20210611160729.280@kylheku.com> |
| In reply to | #161390 |
On 2021-06-11, Bart <bc@freeuk.com> wrote:
> On 11/06/2021 23:17, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> How about a table of function pointers which needs to hold pointers to
>>> functions with arbitrary, mixed signatures. (Eg. the return values of
>>> dlsym or GetProcAddress.)
>>
>> I'd implement that as a table of function pointers.
>
> Yeah, maybe. But that lets you call such a pointer without a cast, while
> a void* or intptr_t entry always requires a cast.
That isn't true if the pointers are prototyped; the call would have to
match the type signature by dumb luck, the probability of which you can
reduce to close to zero somehow, one of the ways being this:
void (*fptr)(int, int, int, int, int, int, int, int, int, int, int,
int, int, int, int, int, int, int, int, int, int, int);
It's probably pretty hard to accidentally call a function pointer with
exactly 24 arguments.
Another way would be to define some struct type which is not known
outside of the declaration, such as because it specifies a struct
without a tag:
void (*fptr)(struct { int x; });
There is no way to call this function; it requires an argument of a type
which is not known outside of the declration.
I'm not sure if this is conforming code without diving into ISO C
scripture, but the on-by-default GCC diagnostic that it elicits is
enough to render this unattractive.
> Somebody looking at the code and seeing, say, an array of void(*)(void)
> might also assume the elements are actual void(*)(void) pointers.
To simply dissuade someone from calling the functions, without making
it a compiler error:
// do not directly call function pointers marked with this;
// the pointers must be converted to the matching type.
typedef void donotcall
struct whatever {
void (*fptr[13])(donotcall);
}
And then there is always:
#define donotcall int, int, int // umpteen times
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-06-12 00:39 +0100 |
| Message-ID | <87wnr00y56.fsf@bsb.me.uk> |
| In reply to | #161393 |
Kaz Kylheku <563-365-8930@kylheku.com> writes:
> On 2021-06-11, Bart <bc@freeuk.com> wrote:
>> On 11/06/2021 23:17, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>> How about a table of function pointers which needs to hold pointers to
>>>> functions with arbitrary, mixed signatures. (Eg. the return values of
>>>> dlsym or GetProcAddress.)
>>>
>>> I'd implement that as a table of function pointers.
>>
>> Yeah, maybe. But that lets you call such a pointer without a cast, while
>> a void* or intptr_t entry always requires a cast.
>
> That isn't true if the pointers are prototyped; the call would have to
> match the type signature by dumb luck, the probability of which you can
> reduce to close to zero somehow, one of the ways being this:
>
> void (*fptr)(int, int, int, int, int, int, int, int, int, int, int,
> int, int, int, int, int, int, int, int, int, int, int);
>
> It's probably pretty hard to accidentally call a function pointer with
> exactly 24 arguments.
>
> Another way would be to define some struct type which is not known
> outside of the declaration, such as because it specifies a struct
> without a tag:
>
> void (*fptr)(struct { int x; });
>
> There is no way to call this function; it requires an argument of a type
> which is not known outside of the declration.
>
> I'm not sure if this is conforming code without diving into ISO C
> scripture, but the on-by-default GCC diagnostic that it elicits is
> enough to render this unattractive.
You can avoid the diagnostic at the expense of a struct type that could,
in theory, be completed. I've done this in the past:
typedef struct dont_complete_me dont_call_me_without_a_cast;
typedef void function(dont_call_me_without_a_cast);
(I prefer not to include the pointer in the function type.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-06-12 01:11 +0100 |
| Message-ID | <XYSwI.115529$O2a8.52210@fx02.ams4> |
| In reply to | #161394 |
On 12/06/2021 00:39, Ben Bacarisse wrote:
> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>
>> On 2021-06-11, Bart <bc@freeuk.com> wrote:
>>> On 11/06/2021 23:17, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>
>>>>> How about a table of function pointers which needs to hold pointers to
>>>>> functions with arbitrary, mixed signatures. (Eg. the return values of
>>>>> dlsym or GetProcAddress.)
>>>>
>>>> I'd implement that as a table of function pointers.
>>>
>>> Yeah, maybe. But that lets you call such a pointer without a cast, while
>>> a void* or intptr_t entry always requires a cast.
>>
>> That isn't true if the pointers are prototyped; the call would have to
>> match the type signature by dumb luck, the probability of which you can
>> reduce to close to zero somehow, one of the ways being this:
>>
>> void (*fptr)(int, int, int, int, int, int, int, int, int, int, int,
>> int, int, int, int, int, int, int, int, int, int, int);
>>
>> It's probably pretty hard to accidentally call a function pointer with
>> exactly 24 arguments.
>>
>> Another way would be to define some struct type which is not known
>> outside of the declaration, such as because it specifies a struct
>> without a tag:
>>
>> void (*fptr)(struct { int x; });
Another way is just to do this:
void* functable[]={printf, malloc, fwrite};
and specify the compiler options to be used or not used. Just don't
anyone about it on comp.lang.c.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-06-12 00:51 +0000 |
| Message-ID | <20210611171319.390@kylheku.com> |
| In reply to | #161395 |
On 2021-06-12, Bart <bc@freeuk.com> wrote:
> On 12/06/2021 00:39, Ben Bacarisse wrote:
>> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>>
>>> On 2021-06-11, Bart <bc@freeuk.com> wrote:
>>>> On 11/06/2021 23:17, Keith Thompson wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>>> How about a table of function pointers which needs to hold pointers to
>>>>>> functions with arbitrary, mixed signatures. (Eg. the return values of
>>>>>> dlsym or GetProcAddress.)
>>>>>
>>>>> I'd implement that as a table of function pointers.
>>>>
>>>> Yeah, maybe. But that lets you call such a pointer without a cast, while
>>>> a void* or intptr_t entry always requires a cast.
>>>
>>> That isn't true if the pointers are prototyped; the call would have to
>>> match the type signature by dumb luck, the probability of which you can
>>> reduce to close to zero somehow, one of the ways being this:
>>>
>>> void (*fptr)(int, int, int, int, int, int, int, int, int, int, int,
>>> int, int, int, int, int, int, int, int, int, int, int);
>>>
>>> It's probably pretty hard to accidentally call a function pointer with
>>> exactly 24 arguments.
>>>
>>> Another way would be to define some struct type which is not known
>>> outside of the declaration, such as because it specifies a struct
>>> without a tag:
>>>
>>> void (*fptr)(struct { int x; });
>
> Another way is just to do this:
>
> void* functable[]={printf, malloc, fwrite};
>
> and specify the compiler options to be used
Wow, that went downhill fast!
From:
"But that lets you call such a pointer without a cast"
To:
Let's use compiler options that lets you stick these pointers
into that table without casts.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-06-12 11:08 +0100 |
| Message-ID | <9I%wI.16462$yVI1.8123@fx07.ams4> |
| In reply to | #161396 |
On 12/06/2021 01:51, Kaz Kylheku wrote:
> On 2021-06-12, Bart <bc@freeuk.com> wrote:
>> Another way is just to do this:
>>
>> void* functable[]={printf, malloc, fwrite};
>>
>> and specify the compiler options to be used
>
> Wow, that went downhill fast!
>
> From:
>
> "But that lets you call such a pointer without a cast"
>
> To:
>
> Let's use compiler options that lets you stick these pointers
> into that table without casts.
Huh? I'm taking about not being able to /call/ them. This doesn't work
using my table:
functable[2]();
If you use a table of function pointers:
void(*functable[])(void)={(void(*)(void))printf, NULL, NULL};
This has several problems:
(1) I couldn't for the life of me figure out the type syntax. (I had to
go back two generations in my language to a version with a C target;
then write this declaration: '[]ref proc functable', and look at the
generated C)
(2) Each initialisation element needs the right cast (not sure why those
NULLs don't need it, as I thought they had void* type)
(3) You can now call any element like this: functable[0]().
Alternatively we can go with your idea of using a function pointer type
that cannot be called by accident:
typedef void(*fnptr)(int,int,int,int,int,int);
fnptr functable[]={(fnptr)printf, (fnptr)malloc, (fnptr)fwrite};
Except now gcc complains of casts between incompatible pointer types.
And it has a point. It needs to go through an intermediate type:
fnptr functable[]={(fnptr)(uintptr_t)printf,
(fnptr)(uintptr_t)malloc, (fnptr)(uintptr_t)fwrite};
Sheesh... you don't think this is going around the houses a little for
something that you should just be done with in a couple of seconds?
----------------
This is a bit of generated C code that needs to use such a table of
pointers (here as a table of structs):
--------------------------------------------------
struct osnos_os_getdllprocaddr_rec {
uint8_t * name;
void * addr;
};
void (*osnos_os_getdllprocaddr(int64_t hinst,uint8_t * name))(void) {
static struct osnos_os_getdllprocaddr_rec table[23] = {
{(uint8_t*)"malloc",(void *)(&malloc)},
{(uint8_t*)"realloc",(void *)(&realloc)},
{(uint8_t*)"free",(void *)(&free)},
{(uint8_t*)"printf",(void *)(&printf)},
{(uint8_t*)"puts",(void *)(&puts)},
{(uint8_t*)"fgetc",(void *)(&fgetc)},
{(uint8_t*)"fputc",(void *)(&fputc)},
{(uint8_t*)"getchar",(void *)(&getchar)},
{(uint8_t*)"fopen",(void *)(&fopen)},
{(uint8_t*)"fclose",(void *)(&fclose)},
{(uint8_t*)"fseek",(void *)(&fseek)},
{(uint8_t*)"ftell",(void *)(&ftell)},
{(uint8_t*)"fread",(void *)(&fread)},
{(uint8_t*)"fwrite",(void *)(&fwrite)},
{(uint8_t*)"clock",(void *)(&clock)},
{(uint8_t*)"isalpha",(void *)(&isalpha)},
{(uint8_t*)"tolower",(void *)(&tolower)},
{(uint8_t*)"feof",(void *)(&feof)},
{(uint8_t*)"memset",(void *)(&memset)},
{(uint8_t*)"memcpy",(void *)(&memcpy)},
{(uint8_t*)"ungetc",(void *)(&ungetc)},
{(uint8_t*)"remove",(void *)(&remove)},
{(uint8_t*)"system",(void *)(&system)}
};
int64_t av_1;
int64_t i;
L1 :;
for (i=(int64_t)1;i<=(int64_t)23;i+=(int64_t)1) {
L2 :;
if (!!(mlib_eqstring(table[(i)-1].name,name))) {
return (void (*)(void))(table[(i)-1].addr);
};
L3 :;
}L4 :;
;
return (void (*)(void))(0);
}
--------------------------------------------------
Such a table allows me to write a limited version of an interpreter,
that normally would rely on GetProcAddress or dlsym, as an OS-neutral
version that compiles on either OS.
This is the original source:
global function os_getdllprocaddr(intm hinst,ichar name)ref proc=
record rec=
ichar name
ref void addr
end
static []rec table=(
("malloc", &malloc),
("realloc", &realloc),
("free", &free),
("printf", &printf),
("puts", &puts),
("fgetc", &fgetc),
("fputc", &fputc),
("getchar", &getchar),
("fopen", &fopen),
("fclose", &fclose),
("fseek", &fseek),
("ftell", &ftell),
("fread", &fread),
("fwrite", &fwrite),
("clock", &clock),
("isalpha", &isalpha),
("tolower", &tolower),
("feof", &feof),
("memset", &memset),
("memcpy", &memcpy),
("ungetc", &ungetc),
("remove", &remove),
("system", &system))
for i to table.len do
if eqstring(table[i].name,name) then
return table[i].addr
fi
od
return nil
end
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-06-12 16:12 +0000 |
| Message-ID | <20210612084006.621@kylheku.com> |
| In reply to | #161401 |
On 2021-06-12, Bart <bc@freeuk.com> wrote:
> On 12/06/2021 01:51, Kaz Kylheku wrote:
>> On 2021-06-12, Bart <bc@freeuk.com> wrote:
>
>>> Another way is just to do this:
>>>
>>> void* functable[]={printf, malloc, fwrite};
>>>
>>> and specify the compiler options to be used
>>
>> Wow, that went downhill fast!
>>
>> From:
>>
>> "But that lets you call such a pointer without a cast"
>>
>> To:
>>
>> Let's use compiler options that lets you stick these pointers
>> into that table without casts.
>
> Huh? I'm taking about not being able to /call/ them. This doesn't work
> using my table:
>
> functable[2]();
>
> If you use a table of function pointers:
>
> void(*functable[])(void)={(void(*)(void))printf, NULL, NULL};
>
> This has several problems:
>
> (1) I couldn't for the life of me figure out the type syntax.
Right; that's why there is this comp.lang.c newsgroup where getting
help with that is topical.
You could make a typedef:
typedef void (*any_fun_t)(int, int, int, ..., int);
This exists in precisely one place in the entire program. Then
it's just:
any_fun_t funtab[] = { (any_fun_t) printf, ... };
If there are many functions and/or tables, and have to be
frequently maintained, C99 preprocessing features could be used to
create a variadic initializer macro for this which looks like:
any_fun_t funtab3[] = fun_tab_init(foo, bar, xyzzy);
My main concern here would be this: the table records no type
information about the functions, which have arbitrary signatures.
Thus, if there is any intent to use the table to make calls,
there is no obvious way to do so correctly. Information about the
functions must be in some parallel table or other structure, which has
to track the functions accurately.
You're using a strawman example to make an unclear point.
> (2) Each initialisation element needs the right cast (not sure why those
> NULLs don't need it, as I thought they had void* type)
>
> (3) You can now call any element like this: functable[0]().
>
> Alternatively we can go with your idea of using a function pointer type
> that cannot be called by accident:
>
> typedef void(*fnptr)(int,int,int,int,int,int);
>
> fnptr functable[]={(fnptr)printf, (fnptr)malloc, (fnptr)fwrite};
>
> Except now gcc complains of casts between incompatible pointer types.
> And it has a point.
Now you're evidently just making things up:
$ gcc -Wall -W -pedantic -ansi fptr.c -c
$ gcc -Wall -W -pedantic -std=c99 fptr.c -c # silence
$ cat fptr.c
#include <stdio.h>
void (*fptr)(void) = (void (*)(void)) printf;
$ gcc --version
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
> void (*osnos_os_getdllprocaddr(int64_t hinst,uint8_t * name))(void) {
> static struct osnos_os_getdllprocaddr_rec table[23] = {
> {(uint8_t*)"malloc",(void *)(&malloc)},
> {(uint8_t*)"realloc",(void *)(&realloc)},
> {(uint8_t*)"free",(void *)(&free)},
This is supposed to show how to do it more succinctly with fewer casts?
Why would you not just use "char *", for one thing.
> {(uint8_t*)"printf",(void *)(&printf)},
^ gratuitous operator
^ unnecessary parens
The cast notation and & are both unary operators: they go on the left
side of the operand and consequently associate right to left.
Parentheses are never needed to disambiguate between the same category
of operators; that's not what they are for.
> This is the original source:
>
> global function os_getdllprocaddr(intm hinst,ichar name)ref proc=
> record rec=
> ichar name
> ref void addr
> end
Now *that*'s a low-effort way to write a table of function pointers in C.
Write another language first, then capture the output.
Where is the risk in any of this code that a table entry could be called
directly?
The gaping risk is that something will call the function to look up
a name, and then misuse it by casting it to the wrong type before
calling it.
Obtaining an address from a name with the nicest C code is the least
important aspect of the whole interpreter design situation.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-06-12 18:36 +0100 |
| Message-ID | <Xg6xI.24716$mGJ.14154@fx08.ams4> |
| In reply to | #161407 |
On 12/06/2021 17:12, Kaz Kylheku wrote:
> On 2021-06-12, Bart <bc@freeuk.com> wrote:
>> (1) I couldn't for the life of me figure out the type syntax.
>
> Right; that's why there is this comp.lang.c newsgroup where getting
> help with that is topical.
>
> You could make a typedef:
>
> typedef void (*any_fun_t)(int, int, int, ..., int);
Yes, that's what I did for the second example (well, I copied from yours).
> You're using a strawman example to make an unclear point.
My point (1) is that C type declarations are so crazy, they are not fit
for purpose. I shoudn't need to use external tools or workarounds like
typedefs to write a perfectly simple type that in my everyday language I
just write as '[]ref proc' (array of pointer to function).
(Has it never occurred to anyone here how absolutely bizarre it is to
have that array modifier '[]' /in the middle/ of
'void(*functable[])(void)'?)
>> typedef void(*fnptr)(int,int,int,int,int,int);
>>
>> fnptr functable[]={(fnptr)printf, (fnptr)malloc, (fnptr)fwrite};
>>
>> Except now gcc complains of casts between incompatible pointer types.
>> And it has a point.
>
> Now you're evidently just making things up:
>
> $ gcc -Wall -W -pedantic -ansi fptr.c -c
> $ gcc -Wall -W -pedantic -std=c99 fptr.c -c # silence
> $ cat fptr.c
> #include <stdio.h>
>
> void (*fptr)(void) = (void (*)(void)) printf;
I get this:
C:\c>gcc @w c.c
c.c:5:20: warning: cast between incompatible function types from 'int
(*)(const char * restrict, ..
.)' to 'void (*)(int, int, int, int, int, int)' [-Wcast-function-type]
5 | fnptr functable[]={(fnptr)printf, (fnptr)malloc, (fnptr)fwrite};
| ^
.... + 2 more identical warnings ....
'w' contains a long bunch of options I downloaded from somewhere. The
relevant one is '-Wbad-function-cast'.
But if you decide not to use it, then somebody else will, as I found out
what I used to post links to some of my generated code. Somebody would
always ramp up the warnings as a way to make out that my code was
rubbish. (The same program can generate from 0 lines of warnings, to
28,000 lines.)
However, I can use C compilers' typical laxity to my advantage, by
saying my code needs to be compiled with NO options except any necessary
ones to get the job done (eg. -O3, -m64, -o, and on Linux, -lm and -ldl).
Since apparently /I/ get to choose whether a program is correct or not
by the options I feed a compiler. So here /I/ decide that using void*
for function pointers is correct code. If someone doesn't agree, take it
up with the compiler writers.
>> void (*osnos_os_getdllprocaddr(int64_t hinst,uint8_t * name))(void) {
>> static struct osnos_os_getdllprocaddr_rec table[23] = {
>> {(uint8_t*)"malloc",(void *)(&malloc)},
>> {(uint8_t*)"realloc",(void *)(&realloc)},
>> {(uint8_t*)"free",(void *)(&free)},
>
> This is supposed to show how to do it more succinctly with fewer casts?
>
> Why would you not just use "char *", for one thing.
Because literal strings in the original language have type 'ref u8' (the
nearest C type), and the generated code has to reflect what is in the
original source.
Literal strings in C would normally have type 'ref i8', but the reality
is even weirder: they have type 'ref ?8' where ? is either i or u, but
you can't specify which as ? is compatible with neither.
>> {(uint8_t*)"printf",(void *)(&printf)},
> ^ gratuitous operator
> ^ unnecessary parens
> The cast notation and & are both unary operators: they go on the left
> side of the operand and consequently associate right to left.
>
> Parentheses are never needed to disambiguate between the same category
> of operators; that's not what they are for.
You're nitpicking my C code generator. If I try and minimise the
generation of parentheses, I'm going to get it wrong (as I found out).
But in generated code, superfluous parentheses are harmeless. (You're
seeing here the results of an experiment to use uint8_t int64_t etc
instead of u8 and i64; the visual impact of those is greater.)
>> global function os_getdllprocaddr(intm hinst,ichar name)ref proc=
>> record rec=
>> ichar name
>> ref void addr
>> end
>
> Now *that*'s a low-effort way to write a table of function pointers in C.
> Write another language first, then capture the output.
Huh?
>
> Where is the risk in any of this code that a table entry could be called
> directly?
That's an old function that used 'ref proc' as a way to indicate a
generic function pointer. It may have had something to do with problems
generating C code if I'd used 'ref void'; I don't recall.
The current version uses 'ref void' (void*). I no longer support a C target.
> The gaping risk is that something will call the function to look up
> a name, and then misuse it by casting it to the wrong type before
> calling it.
They can always cast things in both languages.
> Obtaining an address from a name with the nicest C code is the least
> important aspect of the whole interpreter design situation.
Yes, that's the easy bit. The hard bit, calling the functions, in 'C'
usually involves a complicated library called LIBFF, which only works
with gcc or compatible compilers since it uses inline ASM.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-12 13:06 -0700 |
| Message-ID | <87a6nuzw42.fsf@nosuchdomain.example.com> |
| In reply to | #161409 |
Bart <bc@freeuk.com> writes:
[...]
> (Has it never occurred to anyone here how absolutely bizarre it is to
> have that array modifier '[]' /in the middle/ of
> 'void(*functable[])(void)'?)
[...]
It's probably occurred to *everyone* here.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-12 12:42 -0700 |
| Message-ID | <87eed6zx7g.fsf@nosuchdomain.example.com> |
| In reply to | #161401 |
Bart <bc@freeuk.com> writes:
[...]
> Alternatively we can go with your idea of using a function pointer
> type that cannot be called by accident:
>
> typedef void(*fnptr)(int,int,int,int,int,int);
>
> fnptr functable[]={(fnptr)printf, (fnptr)malloc, (fnptr)fwrite};
>
> Except now gcc complains of casts between incompatible pointer
> types.
That gives me a warning only if I enable gcc's "-Wcast-function-type"
option, which is included in "-Wextra". The code is valid (though as
Kaz points out, you have to store some other information to be able to
use the pointers safely).
Compilers are allowed to warn about anything they like.
> And it has a point. It needs to go through an intermediate
> type:
>
> fnptr functable[]={(fnptr)(uintptr_t)printf,
> (fnptr)(uintptr_t)malloc, (fnptr)(uintptr_t)fwrite};
No, you don't need to go through an intermediate type. The original
code is safe and portable. Your version with the intermediate type is
not (it would fail on an implementation where a function pointer can't
be converted to uintptr_t without loss of information). You've made the
code worse for the sake of avoiding a warning.
Your void* approach was actually better than your uintptr_t approach
(but still not 100% portable, but I know you don't care about that).
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-12 14:13 +0200 |
| Message-ID | <sa28ds$f2c$3@dont-email.me> |
| In reply to | #161390 |
On 12/06/2021 00:29, Bart wrote:
> On 11/06/2021 23:17, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> How about a table of function pointers which needs to hold pointers to
>>> functions with arbitrary, mixed signatures. (Eg. the return values of
>>> dlsym or GetProcAddress.)
>>
>> I'd implement that as a table of function pointers.
>
> Yeah, maybe. But that lets you call such a pointer without a cast, while
> a void* or intptr_t entry always requires a cast.
>
> Somebody looking at the code and seeing, say, an array of void(*)(void)
> might also assume the elements are actual void(*)(void) pointers.
So make your own type:
typedef struct {
void (*)(void) pf;
} function_pointer_t;
(Use whatever typedef, struct tags, naming conventions, etc., that you
like.)
That keeps it all clear in the code (you have a specific named type for
the job), and it keeps it safe - any attempt to use values of that type
directly as function pointers or object pointers will fail.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-06-10 15:16 +0000 |
| Message-ID | <20210610081447.278@kylheku.com> |
| In reply to | #161349 |
On 2021-06-10, Bart <bc@freeuk.com> wrote: > On 10/06/2021 10:14, David Brown wrote: >> On 10/06/2021 00:47, Bart wrote: >>> On 09/06/2021 22:28, Kaz Kylheku wrote: >>>> On 2021-06-09, Bart <bc@freeuk.com> wrote: >>> >>>> Possibly, yes. Twenty categories of identifiers might legitimately >>>> belong to a single namespace, or two two namespaces, or three, ... >>>> anywhere up to twenty namespaces. >>> >>> All that can occur as top-level names in an expression (not following >>> "." or other special syntax) are in one namespace, which is most of them. >>> >>> Each also belongs inside a real namespace, one created by a module, >>> record or function. There is no need for artificial namespaces just so I >>> can use A, A and A for different purposes inside the same scope. >>> >>> I would call that an anti-feature. >> >> I would look at the other way round. There is no language reason why, >> say, type names, variables and functions should share the same namespace >> - they are different concepts, for different purposes. > > What would: > > print(A) > > mean when A could exist in half a dozen different namespaces? Print the value of variable A.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-06-10 16:45 +0100 |
| Message-ID | <NsqwI.1758$FfP2.1135@fx32.ams4> |
| In reply to | #161354 |
On 10/06/2021 16:16, Kaz Kylheku wrote: > On 2021-06-10, Bart <bc@freeuk.com> wrote: >> What would: >> >> print(A) >> >> mean when A could exist in half a dozen different namespaces? > > Print the value of variable A. > OK, that is your choice to restrict a language in some ways, and to have it totally unrestricted in others. Presumably the value of A could include a reference to a function? In that case, how does that reference get into the variable, since here: A = F you'd have the same problem: F can only be a variable. But presumably the F in F() /can/ be a function. Which allows you do: F = F() Again, your choice. I like the convenience and flexibility of having everything in one namespace, and you like the idea of /reusing the same identifiers/ for different purposes within each scope. Personally I don't have that much of a problem with thinking up unique names within a scope, as even with case-insensitity and no extra namespaces, there are 6 quadrillion possible names up to 10 letters, or 2 billion even within 6 letters (like the Fortran and Algol I used to use).
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-06-10 16:56 +0000 |
| Message-ID | <20210610093024.441@kylheku.com> |
| In reply to | #161356 |
On 2021-06-10, Bart <bc@freeuk.com> wrote:
> On 10/06/2021 16:16, Kaz Kylheku wrote:
>> On 2021-06-10, Bart <bc@freeuk.com> wrote:
>
>>> What would:
>>>
>>> print(A)
>>>
>>> mean when A could exist in half a dozen different namespaces?
>>
>> Print the value of variable A.
>>
>
> OK, that is your choice to restrict a language in some ways, and to have
> it totally unrestricted in others.
>
> Presumably the value of A could include a reference to a function? In
> that case, how does that reference get into the variable, since here:
>
> A = F
A = function F // insert syntactic sugar
A = &F; // C-like, with syntactic sugar.
The sugared version is already valid C, and C programs already do this,
even though it's not required.
In ANSI Lisp:
(let ((a (function f))
...)
Sugared with #'
(let ((a #'f))
...)
In code that does a lot of manipulation with higher order functions,
all the #' and funcall contributes to noise. ANSI CL has been often
criticized for that.
If you have a separate var/function namespace, then there is an abiguity
in calling. If F is both a variable and a function, how do you know
which one you are calling?
A = call F (args ...)
A = F(arsgs ...)
C has an existing sugar for this which is currently unnecessary, but has
been used in programs anyway, for clarity.
A = (*F)(args);
A = F(args)
Effectively C simulates two namespaces by the fact that if fun is a
function, &fun and fun are the same pointer, and also fun, *fun, **fun,
***fun, ***fun, .... are all the same.
There are some noteworthy situations in C++. In C++, the & operator
*must* be used for lifting a pointer to a static member function:
void (*pfun)(int) = &foo::fun; // cannot just be foo::fun
I can't remmeber what the rationale is; I can't think of a reason why
foo::fun shouldn't just work.
In C++ there is a feature called pointer-to-member for pointing to
non-static member functions. That must use not only explicit address
lifting, but explicit dereferencing. The operator for declaring
the pointer and for taking the address contain a class resolution
part, which indicates the namespace:
void (foo::*pmemb)(int) = &foo::fun;
pmemb must be used with an object because fun is non-static:
(obj.*pmemb)(42); // parens required like (*pfn)(42);
> I like the convenience and flexibility of having everything in one
> namespace, and you like the idea of /reusing the same identifiers/ for
> different purposes within each scope.
No, I don't. The different namespaces are in fact different scopes.
Nothing is reused in one scope; that is a logical impossibilty.
If ever in the same program you use the same identifier for two
different purposes in two differen places, you are supporting the idea
of multiple namespaces.
The only way to cling to a pure single namespace view is to insist that
there is only a global dictionary for all identifiers for the entire
program, so that once i is used somewhere, that name refers only to that
i and cannot be reused.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-06-10 19:32 +0100 |
| Message-ID | <dVswI.37673$TPRa.8509@fx01.ams4> |
| In reply to | #161358 |
On 10/06/2021 17:56, Kaz Kylheku wrote:
> On 2021-06-10, Bart <bc@freeuk.com> wrote:
>> I like the convenience and flexibility of having everything in one
>> namespace, and you like the idea of /reusing the same identifiers/ for
>> different purposes within each scope.
>
> No, I don't. The different namespaces are in fact different scopes.
> Nothing is reused in one scope; that is a logical impossibilty.
Here, A is used for 3 purposes /in the same scope/:
{A:; struct A{}; int A;}
>
> If ever in the same program you use the same identifier for two
> different purposes in two differen places, you are supporting the idea
> of multiple namespaces.
Yes, namespaces created by an enclosing class, function** or module.
To access the public names from one of those from one place, you usually
name a qualifier (the name of the class, function or module), which must
itself exist in namespace visible from that location.
You can't use 'A' for different things at the same location. You either
need a qualifier, or you need to be in a scope where the particular A
you want can be used without a qualifier.
> The only way to cling to a pure single namespace view is to insist that
> there is only a global dictionary for all identifiers for the entire
> program, so that once i is used somewhere, that name refers only to that
> i and cannot be reused.
Nobody is talking about a single global namespace. As I said, each
module has its own namespace: each class has one; each function has one;
and even each program/library can have one.
I'm talking about the ridiculous idea that the collection of unique
identifiers visible as top-level names from any one location in source
code, should be split up into multiple namespaces, which will also allow
you to have multiple versions of any particular name.
(** Functions are not usually considered to be collections of things
like a class. But in my stuff, they can be used like that: you can
access names (not local variables but statics, types, enums etc) inside
a function, from outside.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-06-09 22:37 +0100 |
| Message-ID | <0xawI.5$mGJ.2@fx08.ams4> |
| In reply to | #161341 |
On 09/06/2021 18:48, Kaz Kylheku wrote: > On 2021-06-09, Bart <bc@freeuk.com> wrote: >> On 09/06/2021 16:40, James Kuyper wrote: >>> On 6/8/21 11:09 AM, Guillaume wrote: >>> ... >>>> I think this just has historical reasons for C, but it's kind of weird >>>> indeed. Especially since, not only does it give two ways of defining and >>>> using struct types, but it also implies separate namespaces. (structs >>>> have their own namespace, as well as enums, unions, then typedefs, ...) >>> >>> Almost: struct, union, and enumeration tags all share a single name >>> space. Typedefs shares the "ordinary identifier" name space with the >>> names of objects, functions, macro names and macro parameters (6.2.3). >> >> Labels bizarrely have their own name space too. > > It's the same in Common Lisp. > > > (block foo (let ((foo 3)) (return-from foo foo))) > 3 > > The block named foo isn't shadowed by the variable foo. Why would it be; > it's a completely different kind of thing. > > In C, labels are visible function wide, whereas lexical scope follows > blocks. So that alone calls for a separate namespace. It calls for different scoping rules. Labels are assigned to the outermost block of a function. That's if you wanted similar behaviour with labels always having function-wide scope. Non-label identifiers either are not allowed to shadow label names, or are. Alternatively, label names follow exactly the same rules as other identifiers in a function, with label names inside blocks able to shadow each other. This is how it works with Algol68 that also has block scopes. I've never implemented block scopes in a language of mine (only in C), and there the rules are very simple: a function has exactly one scope, and there is one namespace.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-09 15:12 -0700 |
| Message-ID | <87mtryofgu.fsf@nosuchdomain.example.com> |
| In reply to | #161344 |
Bart <bc@freeuk.com> writes:
> On 09/06/2021 18:48, Kaz Kylheku wrote:
[...]
>> In C, labels are visible function wide, whereas lexical scope follows
>> blocks. So that alone calls for a separate namespace.
>
> It calls for different scoping rules. Labels are assigned to the
> outermost block of a function.
>
> That's if you wanted similar behaviour with labels always having
> function-wide scope.
[...]
Label names have function scope, not block scope. They're the only
kind of identifier that has function scope.
I suppose they could have been described as being scoped to the
outermost block of the function (since goto statements and labeled
statements can only appear within that block), but then you'd still
have to describe the special rule that a label name is visible
before the labeled statement that creates it.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-06-09 23:18 +0000 |
| Message-ID | <20210609161050.826@kylheku.com> |
| In reply to | #161344 |
On 2021-06-09, Bart <bc@freeuk.com> wrote:
> On 09/06/2021 18:48, Kaz Kylheku wrote:
>> On 2021-06-09, Bart <bc@freeuk.com> wrote:
>>> On 09/06/2021 16:40, James Kuyper wrote:
>>>> On 6/8/21 11:09 AM, Guillaume wrote:
>>>> ...
>>>>> I think this just has historical reasons for C, but it's kind of weird
>>>>> indeed. Especially since, not only does it give two ways of defining and
>>>>> using struct types, but it also implies separate namespaces. (structs
>>>>> have their own namespace, as well as enums, unions, then typedefs, ...)
>>>>
>>>> Almost: struct, union, and enumeration tags all share a single name
>>>> space. Typedefs shares the "ordinary identifier" name space with the
>>>> names of objects, functions, macro names and macro parameters (6.2.3).
>>>
>>> Labels bizarrely have their own name space too.
>>
>> It's the same in Common Lisp.
>>
>> > (block foo (let ((foo 3)) (return-from foo foo)))
>> 3
>>
>> The block named foo isn't shadowed by the variable foo. Why would it be;
>> it's a completely different kind of thing.
>>
>> In C, labels are visible function wide, whereas lexical scope follows
>> blocks. So that alone calls for a separate namespace.
>
> It calls for different scoping rules. Labels are assigned to the
> outermost block of a function.
Unfortunately, then if they are in the same namespace, then what
it means that identifiers are not added to the scope in lexical order.
{ int x; // 0
{ int x; // 1
x: ; } } // 3
The level 1 x shadows level 0 x, but then the level 3 x is shadowed by
both of them; effectively it doesn't exist.
When x: is seen, the compiler grabs the function-level lexical
environment, and slides x into there, rather than the current
environment.
It's a workable design, to be sure, and programmers can learn the
rules. Though nobody cares about this and it will never happen.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2021-06-08 09:25 -0600 |
| Message-ID | <1bv96otm33.fsf@pfeifferfamily.net> |
| In reply to | #161325 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Tuesday, 8 June 2021 at 15:06:45 UTC+1, Joe Pfeiffer wrote: >> James Harris <james.h...@gmail.com> writes: >> >> > Does C, as a language, need to allow its structs to have tags? >> <snip example> >> > etc but in all such cases struct A is being used as a type. And there >> > is a more general feature for that in typedef. >> > >> > So could C's struct tags be omitted from the language? If not, what >> > does a struct tag add? Is it something to do with forward declarations >> > or syntactic consistency with union tags, etc? >> structs (with tags) predate typedefs. I expect you're right that they >> are no longer necessary, but they cause no harm that I know of and >> removing them now would break lots of code written by people who don't >> like typedefs. >> > You need a tag when a struct contains a pointer to its own kind. Which is quite > common for graph nodes. > In other situations, you have the option - either typedef the struct or use the > "struct mytag" syntax. This isn't really desireable. Programming languages > shouldn't provide two ways to do essentially the same thing. It just > leads to gratuitious inconsistencies, sometimes even incompatibilities. Ah, you are correct. Though if we were eliminating struct tags, we could modify typedefs so they could have what amounts to a forward reference (as we can with tagged structs).
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-06-08 16:13 +0000 |
| Message-ID | <20210608090039.219@kylheku.com> |
| In reply to | #161327 |
On 2021-06-08, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Tuesday, 8 June 2021 at 15:06:45 UTC+1, Joe Pfeiffer wrote:
>>> James Harris <james.h...@gmail.com> writes:
>>>
>>> > Does C, as a language, need to allow its structs to have tags?
>>> <snip example>
>>> > etc but in all such cases struct A is being used as a type. And there
>>> > is a more general feature for that in typedef.
>>> >
>>> > So could C's struct tags be omitted from the language? If not, what
>>> > does a struct tag add? Is it something to do with forward declarations
>>> > or syntactic consistency with union tags, etc?
>>> structs (with tags) predate typedefs. I expect you're right that they
>>> are no longer necessary, but they cause no harm that I know of and
>>> removing them now would break lots of code written by people who don't
>>> like typedefs.
>>>
>> You need a tag when a struct contains a pointer to its own kind. Which is quite
>> common for graph nodes.
>> In other situations, you have the option - either typedef the struct or use the
>> "struct mytag" syntax. This isn't really desireable. Programming languages
>> shouldn't provide two ways to do essentially the same thing. It just
>> leads to gratuitious inconsistencies, sometimes even incompatibilities.
>
> Ah, you are correct. Though if we were eliminating struct tags, we
> could modify typedefs so they could have what amounts to a forward
> reference (as we can with tagged structs).
You don't want to eliminate struct tags, because a struct type should
know what its name is. It's just a matter of forwarding that
information to the ordinary namespace.
struct foo; // effectively a forward declaration
// foo is now in the regular identifier namespace as if introduced
// by typedef. It refers to an incomplete type.
struct bar {
foo *pfoo;
};
struct foo {
bar *pbar;
struct xyzzy { // xyzzy introduced into surrounding name space
int plop;
} x;
};
// foo now refers to a complete type
xyzzy *px; // xyzzy known here
When "struct xyzzy" is introduced in the middle of a struct, the
declared identifier x is entered into that struct as a member, and the
typedef name "xyzzy" is introduced into the closest enclosing ordinary
lexical scope or file scope.
Note that this is different from C++, in which xyzzy would be
foo::xyzzy. Anyone who has ever prepared a C API header with nested
structures for C++ use would have run into this.
In other regards, it resembles the C++ solution.
("struct foo" doesn't introduce a typedef name in C++. It introduces a
class name, which has a baggage around it. Class names have linkage and
are subject to the one definition rule and such.)
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-06-08 21:43 -0400 |
| Message-ID | <V0VvI.18376$J21.7547@fx40.iad> |
| In reply to | #161325 |
On 6/8/21 10:45 AM, Malcolm McLean wrote:
> On Tuesday, 8 June 2021 at 15:06:45 UTC+1, Joe Pfeiffer wrote:
>> James Harris <james.h...@gmail.com> writes:
>>
>>> Does C, as a language, need to allow its structs to have tags?
>> <snip example>
>>> etc but in all such cases struct A is being used as a type. And there
>>> is a more general feature for that in typedef.
>>>
>>> So could C's struct tags be omitted from the language? If not, what
>>> does a struct tag add? Is it something to do with forward declarations
>>> or syntactic consistency with union tags, etc?
>> structs (with tags) predate typedefs. I expect you're right that they
>> are no longer necessary, but they cause no harm that I know of and
>> removing them now would break lots of code written by people who don't
>> like typedefs.
>>
> You need a tag when a struct contains a pointer to its own kind. Which is quite
> common for graph nodes.
> In other situations, you have the option - either typedef the struct or use the
> "struct mytag" syntax. This isn't really desireable. Programming languages
> shouldn't provide two ways to do essentially the same thing. It just
> leads to gratuitious inconsistencies, sometimes even incompatibilities.
>
Actually, you can do:
typedef struct Foo Foo;
struct Foo {
Foo* nextFoo;
};
and not need to use the struct foo in the structure, just in the typedef
and the actual struct definition.
As has been mentioned, the tag namespace existed before typedefs were
created. C could have defined that the struct put its tag into the
normal namespace, but then before typedefs were created it complicates
the parser, as then it needs to look up the name to see if it is a type
or not. Before the typedef, all type names began with a reserved identifier.
When typedefs were invented, there was probably already existing code
that did things like struct foo foo; which would have become an error if
the tag suddenly got promoted to the base namespace.
C++ could do it as they chose to do it early before there was existing
C++ code that did it.
[toc] | [prev] | [next] | [standalone]
Page 5 of 20 — ← Prev page 1 … 3 4 [5] 6 7 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web