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 4 of 20 — ← Prev page 1 2 3 [4] 5 6 … 20 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-10 11:14 +0200 |
| Message-ID | <s9sl65$tsq$1@dont-email.me> |
| In reply to | #161346 |
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. There is no advantage to them sharing the same namespace. Separate namespaces for different types of identifiers makes sense. (And it does not /force/ people to abuse them to write confusing code.) Of course hierarchical namespaces based on modules, classes, etc., is also a good thing - it is one of the major advantages of C++ over C when dealing with larger code bases. The namespacing choices in C were based primarily on having a direct mapping from identifiers in the language to identifiers in the generated assembly. And after that, like most aspects of C things were not changed unless there was overwhelming reason to change them. If you want a tool to give warnings that re-using the same name is a poor idea, that's fine - but there are endless choices of names that are allowed in pretty much any language that are confusing. I don't read Lisp, but I'm happy to believe Kaz sees "list (list list)" as clear. I am less happy to believe you find "int all, al1, a1l, a11;" as clear - yet those names are fine in your language and almost any other language.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-06-10 12:38 +0100 |
| Message-ID | <qRmwI.20038$gpy1.17527@fx11.ams4> |
| In reply to | #161348 |
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?
I can see how it would be terribly attractive to people to have
different namespaces for types, functions, and even arrays, structs,
pointers and *keywords* because they might be distinguished by syntax
and/or context.
Personally I view it all as crazy (plenty of wacko ideas like this on
reddit).
Being theoretically possible doesn't mean it is a good idea. Whatever
arcane algorithms a compiler has to apply to sort out the mess, the
reader of the code has to do the same.
> There is no
> advantage to them sharing the same namespace.
Yes there is. But I'm not going to convince you.
> Separate namespaces for
> different types of identifiers makes sense.
No there isn't.
Remember my print(A) example? See my dynamic language example at the end
where 10 different categories of A in the same scope (but they need
different names) are printed. All exist in the same namespace.
What would it look like when there are multiple namespaces?
> If you want a tool to give warnings that re-using the same name is a
> poor idea, that's fine - but there are endless choices of names that are
> allowed in pretty much any language that are confusing. I don't read
> Lisp, but I'm happy to believe Kaz sees "list (list list)" as clear. I
> am less happy to believe you find "int all, al1, a1l, a11;" as clear -
> yet those names are fine in your language and almost any other language.
These aren't fine in mine because they clash:
int all, alL, aLl, aLL, All, AlL, ALl, ALL
Meanwhile C allows:
int all, all, all, all;
====================================================================
proc d={}
proc fn(i)=
type a = int32
type b = record(var x)
type c = struct(int32 x)
e::
importdll msvcrt=clang proc f end
const g=100
enum (h)
static var j=20
var k:=30
println =A
println =B, tab, B.$, (new(b).basetype)
println =C, tab, C.$, (new(c).basetype)
println =D
println =E
println =F
println =G, tab, G.$
println =H, tab, H.$
println =I, tab, I.$
println =J, tab, J.$
println =K, tab, K.$
end
fn(10)
------------------------------
The X.$ construct gives info about the symbol itself, when print doesn't
display that anyway. The output is:
A= int32
B= b <type:"b"> record
C= c <type:"c"> struct
D= <proc:"d">
E= <label:"e">
F= <dllproc:"f">
G= 100 <const:"g">
H= 1 <enum:"h">
I= 10 <param:"i">
J= 20 <static:"j">
K= 30 <frame:"k">
Not included because I can't print them are named operators like 'abs',
but they are all in the one namespace too.
However I do use alternate namespaces in certain very limited cases:
println 3 million
million := 777
'million' is a 1000000x scaling factor in the first context, but can
otherwise be a normal identifier.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-10 15:30 +0200 |
| Message-ID | <s9t457$53d$1@dont-email.me> |
| In reply to | #161349 |
On 10/06/2021 13:38, Bart 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? That would depend on how "print" is defined. For most possible kind of identifiers, printing makes no sense - you don't "print" a label, a function, or a type. You only print things with values, and those would be in the same namespace. > > I can see how it would be terribly attractive to people to have > different namespaces for types, functions, and even arrays, structs, > pointers and *keywords* because they might be distinguished by syntax > and/or context. Different namespaces make sense for things that can't be used in the same way or in the same kind of context. In a C-like language, arrays, structs, and scalers are all objects with values that can be used similarly - so you'd have them in the same namespace. A type definition (struct declaration, typedef, etc.) is totally different. So is a function (but not a function pointer or the address of a function). So they could happily be in different namespaces. In a functional programming language, functions can be treated as objects so they might be in the same namespace. No one (but you) is suggesting having different namespaces for things that may be used in the same way. > > Personally I view it all as crazy (plenty of wacko ideas like this on > reddit). Having listened to your ideas about programming languages over the years, your misconceptions and misunderstandings about C, and your attempts to take language design and coding styles back to the 1970's, you'll forgive me if I don't place any weight on what you think is "crazy" or "wacko". (I'm quite happy for you to describe things that way, I just don't assume it is an opinion I or anyone else would share.) I've seen some outstandingly bad ideas from your languages and coding style, and some excellent ideas - enough variation to know that I don't trust your judgement here. > > Being theoretically possible doesn't mean it is a good idea. Whatever > arcane algorithms a compiler has to apply to sort out the mess, the > reader of the code has to do the same. > "Arcane algorithms" ? The compiler - and the programmer - needs to be able to parse the code enough to tell if an identifier is a type, a function or a variable (or something else). The compiler keeps track by having three hashmaps for the symbol tables instead of one. That really is not rocket science. >> There is no >> advantage to them sharing the same namespace. > > Yes there is. But I'm not going to convince you. Try it. Start from "You see an identifier in the code, and you know from the context and grammar of the language that it is a type." Explain what advantages there are to the programmer that this is in the same namespace as function names and object names. > >> Separate namespaces for >> different types of identifiers makes sense. > > No there isn't. > > Remember my print(A) example? See my dynamic language example at the end > where 10 different categories of A in the same scope (but they need > different names) are printed. All exist in the same namespace. > > What would it look like when there are multiple namespaces? Your "print(A)" example? You mean, when you said "what would print(A) mean" ? Was that supposed to be an example of something relevant? If you have a language for which it makes sense to "print" a function or a type, then in such a language you would view both functions and types as things with a value, and you'd then want them in the same namespace. If it doesn't make sense (and usually it doesn't), then different namespaces are fine. The only time separate namespaces can be a disadvantage is if you might want to use items from the different namespaces in the same context, /and/ it is likely that there would be a conflict of names, /and/ there is no other convenient way to resolve the ambiguity. If you expect "print(A)", given a type, to print the type's name, then you could say the "print" function takes an object, not a type - and in the rare cases where you want to print a type's name, you write "print(typename(A))". Problem solved (if there ever was a problem). > >> If you want a tool to give warnings that re-using the same name is a >> poor idea, that's fine - but there are endless choices of names that are >> allowed in pretty much any language that are confusing. I don't read >> Lisp, but I'm happy to believe Kaz sees "list (list list)" as clear. I >> am less happy to believe you find "int all, al1, a1l, a11;" as clear - >> yet those names are fine in your language and almost any other language. > > These aren't fine in mine because they clash: > > int all, alL, aLl, aLL, All, AlL, ALl, ALL But you still allow "int all, al1, a1l, a11;" as four different identifiers that are easily confused. Stop trying to wiggle out of it by bringing up straw men. > > Meanwhile C allows: > > int all, all, all, all; It does indeed - but that is the same as just "int all;". It is not declaring or defining multiple objects - you are again bringing up straw men. Face it. Your language allows confusing code and identifiers, just like /every/ other programming language. Your language does not /force/ people to use confusing identifiers - nor do any other languages (baring the intentionally esoteric ones). There may be minor differences in detail regarding what different languages allow or do not allow, but the principle is the same.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-06-10 15:18 +0100 |
| Message-ID | <EapwI.31173$TPRa.30348@fx01.ams4> |
| In reply to | #161351 |
On 10/06/2021 14:30, David Brown wrote:
> On 10/06/2021 13:38, Bart wrote:
> That would depend on how "print" is defined. For most possible kind of
> identifiers, printing makes no sense - you don't "print" a label, a
> function, or a type. You only print things with values, and those would
> be in the same namespace.
> If you have a language for which it makes sense to "print" a function
You mean like C:
#include <stdio.h>
#include <stdint.h>
void fn(void){}
int main(void){
printf("%p\n",(void*)(intptr_t)fn);
}
In any case, a function name without () is considered a value.
or
> a type, then in such a language you would view both functions and types
> as things with a value, and you'd then want them in the same namespace.
> If it doesn't make sense (and usually it doesn't), then different
> namespaces are fine.
>
> The only time separate namespaces can be a disadvantage is if you might
> want to use items from the different namespaces in the same context,
> /and/ it is likely that there would be a conflict of names, /and/ there
> is no other convenient way to resolve the ambiguity. If you expect
> "print(A)", given a type, to print the type's name, then you could say
> the "print" function takes an object, not a type - and in the rare cases
> where you want to print a type's name, you write "print(typename(A))".
So you need special syntax - 'typename', which cannot be a regular
function - to disambiguate. A kind of Hungarian notation.
> Problem solved (if there ever was a problem).
The problem doesn't exist yet. It will do if you introduce these namespaces.
>>
>>> If you want a tool to give warnings that re-using the same name is a
>>> poor idea, that's fine - but there are endless choices of names that are
>>> allowed in pretty much any language that are confusing. I don't read
>>> Lisp, but I'm happy to believe Kaz sees "list (list list)" as clear. I
>>> am less happy to believe you find "int all, al1, a1l, a11;" as clear -
>>> yet those names are fine in your language and almost any other language.
>>
>> These aren't fine in mine because they clash:
>>
>> int all, alL, aLl, aLL, All, AlL, ALl, ALL
>
> But you still allow "int all, al1, a1l, a11;" as four different
> identifiers that are easily confused. Stop trying to wiggle out of it
> by bringing up straw men.
>
>>
>> Meanwhile C allows:
>>
>> int all, all, all, all;
>
> It does indeed - but that is the same as just "int all;". It is not
> declaring or defining multiple objects - you are again bringing up straw
> men.
>
> Face it. Your language allows confusing code and identifiers, just like
> /every/ other programming language.
For every 6-letter variable name, C allows 64 distinct variations in the
same scope, or 192 across the 3 namespaces, by using case differences.
I allow exactly one. So while I can't eliminate all misguided
identifiers, I can do something about an awful lot of them.
With a longer name like LabelOffsetTable, C allows nearly 192K
variations (64K variables etc, 64K tags, 64K labels) ...
... per block (labels are limited to 64K across a function).
I still allow exactly one.
I really don't understand the preoccupation of some people with reusing
the same identifier over and over again:
* abc is not enough, you need 8 variations via case differences
* 8 is not enough, you need 24 across variable, tag and label namespaces
* 24 is still not enough, you additionally need function and type namespaces
* 40 is STILL not enough, you need to resuse the same ones (or 32 of
them) inside every {} block!
*That* is not crazy?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-10 16:55 +0200 |
| Message-ID | <s9t95k$9m2$1@dont-email.me> |
| In reply to | #161352 |
On 10/06/2021 16:18, Bart wrote:
> On 10/06/2021 14:30, David Brown wrote:
>> On 10/06/2021 13:38, Bart wrote:
>
>> That would depend on how "print" is defined. For most possible kind of
>> identifiers, printing makes no sense - you don't "print" a label, a
>> function, or a type. You only print things with values, and those would
>> be in the same namespace.
>
>> If you have a language for which it makes sense to "print" a function
>
> You mean like C:
>
> #include <stdio.h>
> #include <stdint.h>
>
> void fn(void){}
>
> int main(void){
> printf("%p\n",(void*)(intptr_t)fn);
> }
That is not "printing" a function. It is taking the /address/ of a
function - something entirely different (the address of your house is
not the same thing as your house). Then you are casting it to a pointer
(in a way that is not actually defined by the C standards - but let's
skip that for now). All in all, you are printing an object that refers
to a function, you are not printing the function.
>
> In any case, a function name without () is considered a value.
In C, it is considered the address of the function.
This means that in C, you could not make functions and objects have
separate namespaces. But that's fine - no one is suggesting changing C.
In a hypothetical new language, you could easily have the function name
referring to the function, not its address, and it could be in a
separate namespace. "Printing" the function would not make sense. If
you really wanted to show its address (rarely a useful thing to do), you
could write "print(function_address(foo))", or something like that.
>
>
> or
>> a type, then in such a language you would view both functions and types
>> as things with a value, and you'd then want them in the same namespace.
>> If it doesn't make sense (and usually it doesn't), then different
>> namespaces are fine.
>>
>> The only time separate namespaces can be a disadvantage is if you might
>> want to use items from the different namespaces in the same context,
>> /and/ it is likely that there would be a conflict of names, /and/ there
>> is no other convenient way to resolve the ambiguity. If you expect
>> "print(A)", given a type, to print the type's name, then you could say
>> the "print" function takes an object, not a type - and in the rare cases
>> where you want to print a type's name, you write "print(typename(A))".
>
> So you need special syntax - 'typename', which cannot be a regular
> function - to disambiguate. A kind of Hungarian notation.
>
No, it would be a function which takes a type and returns its name. I
see nothing special about that (even though you can't write such
functions in C.) It would be silly to create a new modern language that
does not have at least that level of introspection.
And no, it is not a "kind of Hungarian notation" - that comment makes no
sense to anyone who knows what "Hungarian notation" means.
>> Problem solved (if there ever was a problem).
>
> The problem doesn't exist yet. It will do if you introduce these
> namespaces.
>
No, it would not.
<snip>
Look, we know you don't like people to use a variety of names - you'd
really be happier if we stuck to an old Fortran-era convention of
all-caps identifiers of no more than 6 letters. We know you don't like
structured programming. You don't like macros, you don't like types,
you don't like generic programming, you don't like object oriented
programming, you don't like strong typing, you don't like anything
popularised since the ZX Spectrum was at its peak.
Basically, you want a cross between assembly and BASIC.
That's okay - you make whatever language suits you. Just don't expect
anyone else to think you've got the perfect language, or that you can
judge what features of a language would be practical or useful to others.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-06-10 17:23 +0200 |
| Message-ID | <s9tapn$ra2$1@gioia.aioe.org> |
| In reply to | #161353 |
On 6/10/2021 4:55 PM, David Brown wrote: > No, it would be a function which takes a type and returns its name. I > see nothing special about that (even though you can't write such > functions in C.) It would be silly to create a new modern language that > does not have at least that level of introspection. I'm going to make a note about this, although extrapolated from context. I don't think it would be silly. I mean, introspection is well known, and quite popular in /some/ kind of programming, but IMO it is not a "must have" feature that would be silly to miss. Nor makes a language modern per se - it is rather a feature that comes cheap with interpreted and JIT languages, which have gotten popular because of their perception of being easy to use.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-10 20:47 +0200 |
| Message-ID | <s9tmob$e75$1@dont-email.me> |
| In reply to | #161355 |
On 10/06/2021 17:23, Manfred wrote: > On 6/10/2021 4:55 PM, David Brown wrote: >> No, it would be a function which takes a type and returns its name. I >> see nothing special about that (even though you can't write such >> functions in C.) It would be silly to create a new modern language that >> does not have at least that level of introspection. > > I'm going to make a note about this, although extrapolated from context. > > I don't think it would be silly. > I mean, introspection is well known, and quite popular in /some/ kind of > programming, but IMO it is not a "must have" feature that would be silly > to miss. > Nor makes a language modern per se - it is rather a feature that comes > cheap with interpreted and JIT languages, which have gotten popular > because of their perception of being easy to use. A basic level of introspection is free (in the sense of no cost to the programmer or to the run-time speed or size - clearly it takes time for the tool implementer) in a language - compiled, interpreted, JIT, or whatever. C has very limited support - things like sizeof, __func__, __LINE__. C++ has more, though the RTTI is run-time rather than compile-time. Things like the names of types, details of structures (something that has been under discussion in a thread here recently), and names of enumerator constants would all be very simple to have in a language and would be useful for programmers. Yes, I would say it would be silly to make a new language without such features. But there are older languages that have them - Ada being an example where you have quite a lot of introspection through attributes.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-06-10 17:19 +0100 |
| Message-ID | <cYqwI.32883$co68.31746@fx03.ams4> |
| In reply to | #161353 |
On 10/06/2021 15:55, David Brown wrote: > On 10/06/2021 16:18, Bart wrote: >> On 10/06/2021 14:30, David Brown wrote: >>> On 10/06/2021 13:38, Bart wrote: > In a hypothetical new language, you could easily have the function name > referring to the function, not its address, and it could be in a > separate namespace. "Printing" the function would not make sense. If > you really wanted to show its address (rarely a useful thing to do), you > could write "print(function_address(foo))", or something like that. When I print a function in my latest language, it shows its name. I can do that even with an indirect reference from a variable (a 'function pointer' in C). However, I presume you mean (see my response to Kaz) that: F In an expression is not a function but a variable F() Here is a function Which allows you to do: F = F() I don't know you'd set (variable) F up to be a pointer to (function) F. To me it sounds like a nightmare language. >>> The only time separate namespaces can be a disadvantage is if you might >>> want to use items from the different namespaces in the same context, >>> /and/ it is likely that there would be a conflict of names, /and/ there >>> is no other convenient way to resolve the ambiguity. If you expect >>> "print(A)", given a type, to print the type's name, then you could say >>> the "print" function takes an object, not a type - and in the rare cases >>> where you want to print a type's name, you write "print(typename(A))". >> >> So you need special syntax - 'typename', which cannot be a regular >> function - to disambiguate. A kind of Hungarian notation. > > No, it would be a function which takes a type and returns its name. That's not going to work. Don't forget there is more than one namespace. A by itself is a /variable/. The /type/ A is in a separate namespace and cannot be refered to directly without special syntax or context. I assumes 'typename' was that special syntax or context where its argument was looked up in the type namespace. Now, A might be a variable that /refers to/ a named type that exists in that special namespace, in which case the problem, like F above, shifts to how you'd get the type A into the variable A. > I > see nothing special about that (even though you can't write such > functions in C.) It would be silly to create a new modern language that > does not have at least that level of introspection. I demonstrated that level of introspection in the example from my language. It's got nothing to do with extra namespaces. However in my example, you can't use F for both a function and a variable name in the same scope, and you can't use A for both a type and a variable name in the same scope. That sounds entirely sensible to me. Namespaces as you propose are just a can of worms. > Look, we know you don't like people to use a variety of names - you'd > really be happier if we stuck to an old Fortran-era convention of > all-caps identifiers of no more than 6 letters. No limit on length and not all-caps. You just don't need identifiers that differ only in case. > We know you don't like > structured programming. Where did you get that idea? > You don't like macros No. > you don't like types Not gratuitous ones that makes my life harder. > you don't like generic programming I get generic programming with my dynamic language. Doing it in static languages makes those languages difficult and inefficient (eg. C++ and Rust). > you don't like object oriented > programming I can take it or leave it. I've part implemented OOP features in dynamic code, and sometimes use them. But elsehwhere people go overboard with it. , you don't like strong typing, you don't like anything > popularised since the ZX Spectrum was at its peak. > > Basically, you want a cross between assembly and BASIC. Rubbish. My two languages lie on this line: ASM--C--M-----Q------------Python > That's okay - you make whatever language suits you. Just don't expect > anyone else to think you've got the perfect language, or that you can > judge what features of a language would be practical or useful to others. At least I have created languages, implemented them, and successfully used them to write commercial software. Some characteristics of mine: * Case-insensitive (like Fortran and Ada and the Algols) * Algol68-style block syntax (like Algol68 and Ada and Lua) * 1-based and N-based arrays (like Ada, Pascal, modern Fortran) * No silly separate namespaces (like most languages) * No textual macro system (like most languages) So, none of this is unique to what I'm doing. It's just not fashionable. I wouldn't like to use one of yours where you'd tie yourself up in knots with elaborate type systems and namespaces.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-06-11 09:52 +0100 |
| Message-ID | <UvFwI.63057$TPRa.40408@fx01.ams4> |
| In reply to | #161353 |
On 10/06/2021 15:55, David Brown wrote:
> On 10/06/2021 16:18, Bart wrote:
>> On 10/06/2021 14:30, David Brown wrote:
>>> On 10/06/2021 13:38, Bart wrote:
>>
>>> That would depend on how "print" is defined. For most possible kind of
>>> identifiers, printing makes no sense - you don't "print" a label, a
>>> function, or a type. You only print things with values, and those would
>>> be in the same namespace.
>>
>>> If you have a language for which it makes sense to "print" a function
>>
>> You mean like C:
>>
>> #include <stdio.h>
>> #include <stdint.h>
>>
>> void fn(void){}
>>
>> int main(void){
>> printf("%p\n",(void*)(intptr_t)fn);
>> }
>
> That is not "printing" a function. It is taking the /address/ of a
> function - something entirely different (the address of your house is
> not the same thing as your house). Then you are casting it to a pointer
> (in a way that is not actually defined by the C standards - but let's
> skip that for now).
What's wrong with it? How would /you/ turn a function pointer into a
void* type?
> All in all, you are printing an object that refers
> to a function, you are not printing the function.
Because 'printing the function' means what instead? If I try 'printing
an array':
char A[] = {0x48,0x83,0xec,0x08,0x48,0x83,0xc4,0x08,0xc3};
printf("%p\n",A);
I just get its address too.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-11 11:25 +0200 |
| Message-ID | <s9va74$6of$1@dont-email.me> |
| In reply to | #161377 |
On 11/06/2021 10:52, Bart wrote:
> On 10/06/2021 15:55, David Brown wrote:
>> On 10/06/2021 16:18, Bart wrote:
>>> On 10/06/2021 14:30, David Brown wrote:
>>>> On 10/06/2021 13:38, Bart wrote:
>>>
>>>> That would depend on how "print" is defined. For most possible kind of
>>>> identifiers, printing makes no sense - you don't "print" a label, a
>>>> function, or a type. You only print things with values, and those
>>>> would
>>>> be in the same namespace.
>>>
>>>> If you have a language for which it makes sense to "print" a function
>>>
>>> You mean like C:
>>>
>>> #include <stdio.h>
>>> #include <stdint.h>
>>>
>>> void fn(void){}
>>>
>>> int main(void){
>>> printf("%p\n",(void*)(intptr_t)fn);
>>> }
>>
>> That is not "printing" a function. It is taking the /address/ of a
>> function - something entirely different (the address of your house is
>> not the same thing as your house). Then you are casting it to a pointer
>> (in a way that is not actually defined by the C standards - but let's
>> skip that for now).
>
> What's wrong with it? How would /you/ turn a function pointer into a
> void* type?
Generally, I wouldn't. There simply isn't much use of inspecting a
function pointer, other than perhaps curiosity.
In my line of work, it can occasionally be useful to know exactly where
a function is. Maybe I want to check if the function is in ram or
flash, perhaps during testing and debugging. There I know /exactly/ the
details of the target, the implementation, the particular compiler, etc.
And I know that on that particular implementation, it is fine to cast
the function pointer to (uintptr_t) or (uint32_t), and use the value.
(Who uses "intptr_t" ? A /signed/ pointer?)
The conversions you used are allowed, but they are implementation dependent.
(I believe we have been through this before - you wanted to store your
function pointers as "void *" instead of something a little better such
as "void (*)(void)". There is no need to redo that here.)
>
>> All in all, you are printing an object that refers
>> to a function, you are not printing the function.
>
> Because 'printing the function' means what instead?
That is precisely my point - it does not have a meaning. It /might/
make sense to print the address, but printing the name is likely to be
more useful. Perhaps printing the assembly listing, or the RTL
intermediate code, or the source code would be more useful. Perhaps the
size. Perhaps all these. In C, with casts (or a very lenient
compiler), you get the address - that does not mean you are "printing
the function". You are printing the /address/ of the function.
> If I try 'printing
> an array':
>
> char A[] = {0x48,0x83,0xec,0x08,0x48,0x83,0xc4,0x08,0xc3};
> printf("%p\n",A);
>
> I just get its address too.
Yes, that's the way C works. But you are not printing the array - C
does not have built-in (or standard library) support to do that.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-11 12:00 -0700 |
| Message-ID | <87wnr0z0o8.fsf@nosuchdomain.example.com> |
| In reply to | #161377 |
Bart <bc@freeuk.com> writes:
[...]
> What's wrong with it? How would /you/ turn a function pointer into a
> void* type?
Most likely I wouldn't.
If I actually needed to convert a function pointer to void*, I'd
use a cast. I'd be aware that the C standard doesn't define the
behavior of such a conversion, and that it might not work or might
be rejected by a conforming C compiler on some implementations.
For example, a function pointer might be bigger than a void*, so
the conversion would lose information. I'd probably also reread
the section of the standard that discusses pointer conversions.
I can imagine wanting to do such a conversion in non-portable code
(most likely temporary throwaway code), and a cast is likely to do
what I want for the system I'm using at the moment. Sometimes that's
good enough.
If I wanted to examine the representation of a function ponter in
a completely portable manner, I'd copy it to an array of unsigned
char of the appropriate size.
Or perhaps I'd store the address of a function pointer object in
a void* object, which might qualify as "turning it into" a void*,
but probably isn't what you meant.
But before doing any of that, I'd carefully consider *why* I want
to turn a function pointer into a void* (or why somebody else wants
me to) and what I want to do with the result, and work to define
the actual requirement precisely.
--
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 | Guillaume <message@bottle.org> |
|---|---|
| Date | 2021-06-11 21:14 +0200 |
| Message-ID | <sa0cmu$1n17$1@gioia.aioe.org> |
| In reply to | #161381 |
Le 11/06/2021 à 21:00, Keith Thompson a écrit : > Bart <bc@freeuk.com> writes: > [...] >> What's wrong with it? How would /you/ turn a function pointer into a >> void* type? > > Most likely I wouldn't. According to C99, a pointer to a function is compatible with a pointer to a function of a different type. Compatibility with a pointer to any other object is not defined indeed. That can suggest, for instance, that pointers to functions may have a different size than others pointers, making a conversion impossible on some platforms. Now in the "J.5 Common extensions" section, you can find "J.5.7 Function pointer casts". It's of course completely implementation-specific, but as defined in the "common extensions" section, is very likely to be found on a large range of platforms. So if you want your code to be 100% portable, it's obviously to be avoided, but assuming this in your code is still likely to be portable on a pretty large range of systems. Your call. Now even when this is allowed, it's still a slippery feature. Assigning any pointer to a void * or conversely essentially bypasses any type checking (except for the qualifiers).
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-06-11 19:46 +0000 |
| Message-ID | <20210611124436.183@kylheku.com> |
| In reply to | #161382 |
On 2021-06-11, Guillaume <message@bottle.org> wrote: > Le 11/06/2021 à 21:00, Keith Thompson a écrit : >> Bart <bc@freeuk.com> writes: >> [...] >>> What's wrong with it? How would /you/ turn a function pointer into a >>> void* type? >> >> Most likely I wouldn't. > > According to C99, a pointer to a function is compatible with a pointer > to a function of a different type. Compatibility with a pointer to any > other object is not defined indeed. That can suggest, for instance, that > pointers to functions may have a different size than others pointers, > making a conversion impossible on some platforms. Those platforms wouldn't have a GetProcAddress or dlopen function, which means they are either specialized DSPs running very specialized, single-purpose firmware, very tiny microcontrollers also running very specialized firmware, or else museum machines.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-11 15:28 -0700 |
| Message-ID | <87im2kyr14.fsf@nosuchdomain.example.com> |
| In reply to | #161384 |
Kaz Kylheku <563-365-8930@kylheku.com> writes:
> On 2021-06-11, Guillaume <message@bottle.org> wrote:
>> Le 11/06/2021 à 21:00, Keith Thompson a écrit :
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> What's wrong with it? How would /you/ turn a function pointer into a
>>>> void* type?
>>>
>>> Most likely I wouldn't.
>>
>> According to C99, a pointer to a function is compatible with a pointer
>> to a function of a different type. Compatibility with a pointer to any
>> other object is not defined indeed. That can suggest, for instance, that
>> pointers to functions may have a different size than others pointers,
>> making a conversion impossible on some platforms.
>
> Those platforms wouldn't have a GetProcAddress or dlopen function,
> which means they are either specialized DSPs running very specialized,
> single-purpose firmware, very tiny microcontrollers also running
> very specialized firmware, or else museum machines.
dlopen (defined by POSIX, not by C) return a void* that's a handle to a
dynamic library. You can pass that handle, along with a pointer to a
string to dlsym() to get the address of an object or function.
POSIX requires that a void* value *returned by dlsym()* can be converted
to the appropriate function pointer type and used to call the function.
As far as I can tell, it imposes no such requirement for pointer
conversions in general (I think that might be a relatively recent change
in POSIX). An implementation where, for example, function pointers are
bigger than void* could still support dlsym() with some special case
code. (It's very likely that there are no actual implementations that
need to do this.)
I'm less familiar with GetProcAddress (a Windows thing), but it returns
a result of type FARPROC, which apparently is actually defined as a
function pointer type. There are probably no Windows implementations
where function pointers are bigger than object pointers, but
GetProcAddress isn't what prevents 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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-11 15:06 -0700 |
| Message-ID | <87sg1oys2z.fsf@nosuchdomain.example.com> |
| In reply to | #161382 |
Guillaume <message@bottle.org> writes:
> Le 11/06/2021 à 21:00, Keith Thompson a écrit :
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> What's wrong with it? How would /you/ turn a function pointer into a
>>> void* type?
>> Most likely I wouldn't.
>
> According to C99, a pointer to a function is compatible with a pointer
> to a function of a different type. Compatibility with a pointer to any
> other object is not defined indeed. That can suggest, for instance,
> that pointers to functions may have a different size than others
> pointers, making a conversion impossible on some platforms.
Quibble: the standard uses the word "compatible" in a very narrow sense.
Different function pointer types are not compatible in that sense. What
the standard does say is that you can convert from one pointer type to
another and back again and get the original value (or at least
something that compares equal to 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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-11 15:08 -0700 |
| Message-ID | <87r1h8yrz5.fsf@nosuchdomain.example.com> |
| In reply to | #161382 |
Guillaume <message@bottle.org> writes:
> Le 11/06/2021 à 21:00, Keith Thompson a écrit :
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> What's wrong with it? How would /you/ turn a function pointer into a
>>> void* type?
>> Most likely I wouldn't.
>
> According to C99, a pointer to a function is compatible with a pointer
> to a function of a different type. Compatibility with a pointer to any
> other object is not defined indeed. That can suggest, for instance,
> that pointers to functions may have a different size than others
> pointers, making a conversion impossible on some platforms.
Quibble: the standard uses the word "compatible" in a very narrow sense.
Different function pointer types are not compatible in that sense. What
the standard does say is that you can convert from one pointer type to
another and back again and get the original value (or at least
something that compares equal to 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-12 00:32 +0200 |
| Message-ID | <sa0oa1$8oe$1@dont-email.me> |
| In reply to | #161382 |
On 11/06/2021 21:14, Guillaume wrote: > Le 11/06/2021 à 21:00, Keith Thompson a écrit : >> Bart <bc@freeuk.com> writes: >> [...] >>> What's wrong with it? How would /you/ turn a function pointer into a >>> void* type? >> >> Most likely I wouldn't. > > According to C99, a pointer to a function is compatible with a pointer > to a function of a different type. Compatibility with a pointer to any > other object is not defined indeed. That can suggest, for instance, that > pointers to functions may have a different size than others pointers, > making a conversion impossible on some platforms. Conversion between function pointers and object pointers is not defined explicitly. But conversions between function pointers and integer types, and between object pointers and integer types, are implementation-defined. This means that you /can/ convert between a function pointer and an object pointer (like void*) if you go via an integer type. It is all implementation-defined, and may lead to traps, invalid values, lost data (i.e., you can't necessarily reverse the sequence and get the same pointer back), etc. And yes, different sizes for different kinds of pointers is indeed allowed in C - and does indeed exist in some implementations. > > Now in the "J.5 Common extensions" section, you can find "J.5.7 Function > pointer casts". It's of course completely implementation-specific, but > as defined in the "common extensions" section, is very likely to be > found on a large range of platforms. So if you want your code to be 100% > portable, it's obviously to be avoided, but assuming this in your code > is still likely to be portable on a pretty large range of systems. Your > call. > > Now even when this is allowed, it's still a slippery feature. Assigning > any pointer to a void * or conversely essentially bypasses any type > checking (except for the qualifiers). > >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-06-11 22:32 +0100 |
| Message-ID | <SDQwI.44742$v0S3.2038@fx12.ams4> |
| In reply to | #161381 |
On 11/06/2021 20:00, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [...] >> What's wrong with it? How would /you/ turn a function pointer into a >> void* type? > > Most likely I wouldn't. > > If I actually needed to convert a function pointer to void*, I'd > use a cast. I'd be aware that the C standard doesn't define the > behavior of such a conversion, and that it might not work or might > be rejected by a conforming C compiler on some implementations. > For example, a function pointer might be bigger than a void*, so > the conversion would lose information. I'd probably also reread > the section of the standard that discusses pointer conversions. > I can imagine wanting to do such a conversion in non-portable code > (most likely temporary throwaway code), and a cast is likely to do > what I want for the system I'm using at the moment. Sometimes that's > good enough. > > If I wanted to examine the representation of a function ponter in > a completely portable manner, Not everyone needs to write 100% portable code. They might have some targets in mind that they've used for years, and are likely to continue using them for years to come. At the minute I'be surprised if any contemporary /computer/ (not some device that by some miracle someone has adapted a C compiler for), doesn't use 64-bit functions and 64-bit object pointers, or 32-bit equivalents. I'd copy it to an array of unsigned > char of the appropriate size. > > Or perhaps I'd store the address of a function pointer object in > a void* object, which might qualify as "turning it into" a void*, > but probably isn't what you meant. > > But before doing any of that, I'd carefully consider *why* I want > to turn a function pointer into a void* (or why somebody else wants > me to) 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.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-11 15:17 -0700 |
| Message-ID | <87mtrwyrk7.fsf@nosuchdomain.example.com> |
| In reply to | #161385 |
Bart <bc@freeuk.com> writes:
> On 11/06/2021 20:00, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> What's wrong with it? How would /you/ turn a function pointer into a
>>> void* type?
>> Most likely I wouldn't.
>> If I actually needed to convert a function pointer to void*, I'd
>> use a cast. I'd be aware that the C standard doesn't define the
>> behavior of such a conversion, and that it might not work or might
>> be rejected by a conforming C compiler on some implementations.
>> For example, a function pointer might be bigger than a void*, so
>> the conversion would lose information. I'd probably also reread
>> the section of the standard that discusses pointer conversions.
>> I can imagine wanting to do such a conversion in non-portable code
>> (most likely temporary throwaway code), and a cast is likely to do
>> what I want for the system I'm using at the moment. Sometimes that's
>> good enough.
>> If I wanted to examine the representation of a function ponter in
>> a completely portable manner,
>
> Not everyone needs to write 100% portable code. They might have some
> targets in mind that they've used for years, and are likely to
> continue using them for years to come.
Yes, I've repeatedly acknowledged that.
> At the minute I'be surprised if any contemporary /computer/ (not some
> device that by some miracle someone has adapted a C compiler for),
> doesn't use 64-bit functions and 64-bit object pointers, or 32-bit
> equivalents.
So would I. I still prefer to write portable code when practical.
> I'd copy it to an array of unsigned
>> char of the appropriate size.
>> Or perhaps I'd store the address of a function pointer object in
>> a void* object, which might qualify as "turning it into" a void*,
>> but probably isn't what you meant.
>> But before doing any of that, I'd carefully consider *why* I want
>> to turn a function pointer into a void* (or why somebody else wants
>> me to)
>
> 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. The standard
guarantees that you can safely convert any pointer-to-function to any
pointer-to-function type and back again. It makes no such guarantee for
converting function pointers to void*.
Now if you decide to use void*, I won't tell you not to. I might not
even tell you it's not 100% portable unless you ask.
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-06-11 23:29 +0100 |
| Message-ID | <7tRwI.23036$73h1.4209@fx10.ams4> |
| In reply to | #161388 |
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.
[toc] | [prev] | [next] | [standalone]
Page 4 of 20 — ← Prev page 1 2 3 [4] 5 6 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web