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 7 of 20 — ← Prev page 1 … 5 6 [7] 8 9 … 20 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-07-28 16:07 -0700 |
| Message-ID | <87zgu6f367.fsf@nosuchdomain.example.com> |
| In reply to | #162082 |
Bart <bc@freeuk.com> writes:
> On 28/07/2021 18:21, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
[...]
> I want to call a C function via an FFI from a language that I've
> devised. The public API says one parameter type is off_t.
>
> Which type matches that in my language? I have to choose from i8-i64
> and u8-u64.
>
> The kind of answer I want is (a) 'It uses i64' etc; or (b) 'It uses
> i32 or u64 depending on platform'.
POSIX says that off_t is a signed integer type.
Is there some reason that compiling and running this program on the
target system doesn't solve your problem?
#include <stdio.h>
#include <limits.h>
int main(void) {
printf("off_t is %c%zu\n",
(off_t)-1 < (off_t)0 ? 'i' : 'u',
CHAR_BIT * sizeof (off_t));
}
> Not keeping the answer buried for decades under a dozen typedefs,
> dependent on a dozen conditional macros, dependent on the C compilers
> used [what C compiler? I might not have one] and hidden in include
> files 6 levels deep, scattered across multiple directories, to make it
> as hard as possible to find out.
Yeah, you don't need to do any of that.
[...]
>>> This is exactly my point. A compiler installation can exist for just one
>>> platform. This goes for Windows compilers such as Pelles C (2 targets),
>>> DMC, lccwin (2 targets), Tcc (2 targets).
>> So what? Programmers generally[*] don't write code for a
>> particular compiler or platform,
>> they write code to the language specification to solve some problem, which is independent
>> of any particular compiler implementation. Portability of C code is what
>> has built the internet as we know it.
>> And for other languages, the language provides the binding, for
>> example:
>> http://www.nongnu.org/posix90/#SEC7
>
> This doesn't do struct stat. But supposing it did, how did /they/ pick
> up the necessary information? Although they seem to have clocked that
> 'clock_t' is an integer type, rather than float, something else that C
> prefers to keep under wraps.
POSIX says that clock_t can be either integer or floating-point. You
can use a method similar to what I wrote above to find out what it is in
a particular implementation (without reading the header files).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-29 02:23 +0100 |
| Message-ID | <sdsvto$jqt$1@dont-email.me> |
| In reply to | #162083 |
On 29/07/2021 00:07, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 28/07/2021 18:21, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>
> [...]
>
>> I want to call a C function via an FFI from a language that I've
>> devised. The public API says one parameter type is off_t.
>>
>> Which type matches that in my language? I have to choose from i8-i64
>> and u8-u64.
>>
>> The kind of answer I want is (a) 'It uses i64' etc; or (b) 'It uses
>> i32 or u64 depending on platform'.
>
> POSIX says that off_t is a signed integer type.
>
> Is there some reason that compiling and running this program on the
> target system doesn't solve your problem?
>
> #include <stdio.h>
> #include <limits.h>
> int main(void) {
> printf("off_t is %c%zu\n",
> (off_t)-1 < (off_t)0 ? 'i' : 'u',
> CHAR_BIT * sizeof (off_t));
> }
Sure, I can do that (after fixing the code with the right includes and
avoiding %zu). But that's the trial and error approach.
In the end I might end up with a list of such types for my platform, and
what concrete types they actually are.
But, why doesn't such a list already exist anyway? It's not as though my
platform is a rare, obscure one out of hundreds; it's Windows on x64.
The other two I might be interested in are Linux on x64 and on arm64.
>>> http://www.nongnu.org/posix90/#SEC7
>>
>> This doesn't do struct stat. But supposing it did, how did /they/ pick
>> up the necessary information? Although they seem to have clocked that
>> 'clock_t' is an integer type, rather than float, something else that C
>> prefers to keep under wraps.
>
> POSIX says that clock_t can be either integer or floating-point. You
> can use a method similar to what I wrote above to find out what it is in
> a particular implementation (without reading the header files).
Actually I don't know what type Fortran is trying to represent; it might
not be clock_t; the info at that link is incomplete, and rather poor.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-07-28 19:20 -0700 |
| Message-ID | <87v94tg8sw.fsf@nosuchdomain.example.com> |
| In reply to | #162084 |
Bart <bc@freeuk.com> writes:
> On 29/07/2021 00:07, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 28/07/2021 18:21, Scott Lurndal wrote:
>>>> Bart <bc@freeuk.com> writes:
>> [...]
>>
>>> I want to call a C function via an FFI from a language that I've
>>> devised. The public API says one parameter type is off_t.
>>>
>>> Which type matches that in my language? I have to choose from i8-i64
>>> and u8-u64.
>>>
>>> The kind of answer I want is (a) 'It uses i64' etc; or (b) 'It uses
>>> i32 or u64 depending on platform'.
>> POSIX says that off_t is a signed integer type.
>> Is there some reason that compiling and running this program on the
>> target system doesn't solve your problem?
>> #include <stdio.h>
>> #include <limits.h>
>> int main(void) {
>> printf("off_t is %c%zu\n",
>> (off_t)-1 < (off_t)0 ? 'i' : 'u',
>> CHAR_BIT * sizeof (off_t));
>> }
>
> Sure, I can do that (after fixing the code with the right includes and
> avoiding %zu). But that's the trial and error approach.
%zu is the correct format specifier. I'm not even going to ask why
you'd want to avoid it.
Yes, I probably should have used `#include <sys/types.h>`.
No, it's not trial and error. Write the program once, compile and run
it on each platform of interest. Expand the program as needed to show
the characteristcs of all the types you're interested in. Tweak the
output any way you like to suit your purposes. Make it generate source
code in your personal language if you like.
> In the end I might end up with a list of such types for my platform,
> and what concrete types they actually are.
>
> But, why doesn't such a list already exist anyway? It's not as though
> my platform is a rare, obscure one out of hundreds; it's Windows on
> x64. The other two I might be interested in are Linux on x64 and on
> arm64.
Such a list might exist somewhere. If it doesn't, or if it's hard to
find, it's probably because not many people are interested in it.
And I've just shown you how you can generate such a list yourself, by
writing a C program that generates it.
[snip]
(I didn't look at the Fortran stuff.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-29 11:05 +0100 |
| Message-ID | <sdtugu$an9$1@dont-email.me> |
| In reply to | #162085 |
On 29/07/2021 03:20, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 29/07/2021 00:07, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 28/07/2021 18:21, Scott Lurndal wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>
>>>> I want to call a C function via an FFI from a language that I've
>>>> devised. The public API says one parameter type is off_t.
>>>>
>>>> Which type matches that in my language? I have to choose from i8-i64
>>>> and u8-u64.
>>>>
>>>> The kind of answer I want is (a) 'It uses i64' etc; or (b) 'It uses
>>>> i32 or u64 depending on platform'.
>>> POSIX says that off_t is a signed integer type.
>>> Is there some reason that compiling and running this program on the
>>> target system doesn't solve your problem?
>>> #include <stdio.h>
>>> #include <limits.h>
>>> int main(void) {
>>> printf("off_t is %c%zu\n",
>>> (off_t)-1 < (off_t)0 ? 'i' : 'u',
>>> CHAR_BIT * sizeof (off_t));
>>> }
>>
>> Sure, I can do that (after fixing the code with the right includes and
>> avoiding %zu). But that's the trial and error approach.
>
> %zu is the correct format specifier. I'm not even going to ask why
> you'd want to avoid it.
I'll tell you anyway: it doesn't work on Windows.
> Yes, I probably should have used `#include <sys/types.h>`.
>
> No, it's not trial and error. Write the program once, compile and run
> it on each platform of interest. Expand the program as needed to show
> the characteristcs of all the types you're interested in. Tweak the
> output any way you like to suit your purposes. Make it generate source
> code in your personal language if you like.
This is stuff I've had to do years ago. More recently, I could
semi-translate C APIs (although normally I'd exclude system headers), by
using a special option on my C compiler, which will generate a
particular rendering, as often APIs bristle with compile-specific code.
It doesn't attempt most of the macros that are normally used, which in
general contain expressions in C syntax which is not trivially convertible.
Generating FFI bindings of C APIs is a big job. Most people who have to
do similar things are not going to be writing their own C parsers or
whatever; they might have to use more heavyweight solutions, or simply
do a huge amount of work.
The off_t and other types are examples of where how C is typically
written makes it harder than necessary. Instead of using a plain type,
or even using one layer of typedefs, it uses several.
(For gcc/tdm, off_t is defined inside _mingw_off_t.h (it has its own
header!). This defines also _off_t and off32_t as 'long'; _off64_t and
off64_t; and off_t itself as either off64_t or off32_t
One clock_t type used 6 layers of typedefs and macros; what the hell
happended there? This is why I'm saying this stuff should be overhauled.
Obviously no one wants to mess with it, so they add their own
abstractions. Then someone else does the same... Eventually someone
whats to printf such a value!)
-----------------------------------------------
_mingw_off_t.h
-----------------------------------------------
#ifndef _OFF_T_DEFINED
#define _OFF_T_DEFINED
#ifndef _OFF_T_
#define _OFF_T_
typedef long _off_t;
#if !defined(NO_OLDNAMES) || defined(_POSIX)
typedef long off32_t;
#endif
#endif
#ifndef _OFF64_T_DEFINED
#define _OFF64_T_DEFINED
__MINGW_EXTENSION typedef long long _off64_t;
#if !defined(NO_OLDNAMES) || defined(_POSIX)
__MINGW_EXTENSION typedef long long off64_t;
#endif
#endif /*_OFF64_T_DEFINED */
#ifndef _FILE_OFFSET_BITS_SET_OFFT
#define _FILE_OFFSET_BITS_SET_OFFT
#if !defined(NO_OLDNAMES) || defined(_POSIX)
#if (defined(_FILE_OFFSET_BITS) && (_FILE_OFFSET_BITS == 64))
typedef off64_t off_t;
#else
typedef off32_t off_t;
#endif /* #if !defined(NO_OLDNAMES) || defined(_POSIX) */
#endif /* (defined(_FILE_OFFSET_BITS) && (_FILE_OFFSET_BITS == 64)) */
#endif /* _FILE_OFFSET_BITS_SET_OFFT */
#endif /* _OFF_T_DEFINED */
-----------------------------------------------
All to define a type which is i32 or i64; wonderful isn't it?
Let's face it, if you had to write some functions or data types that
expressed a file offset, you'd just use int64_t and be done with it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-07-29 08:12 -0700 |
| Message-ID | <87mtq5f92k.fsf@nosuchdomain.example.com> |
| In reply to | #162087 |
Bart <bc@freeuk.com> writes:
> On 29/07/2021 03:20, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
[...]
>>> Sure, I can do that (after fixing the code with the right includes and
>>> avoiding %zu). But that's the trial and error approach.
>> %zu is the correct format specifier. I'm not even going to ask why
>> you'd want to avoid it.
>
> I'll tell you anyway: it doesn't work on Windows.
Yes, it does. I don't know why it wouldn't work for you. Are you using
some obsolete version of Windows or of its C implementation?
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-29 16:34 +0100 |
| Message-ID | <sduhq4$3ll$1@dont-email.me> |
| In reply to | #162092 |
On 29/07/2021 16:12, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 29/07/2021 03:20, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
> [...]
>>>> Sure, I can do that (after fixing the code with the right includes and
>>>> avoiding %zu). But that's the trial and error approach.
>>> %zu is the correct format specifier. I'm not even going to ask why
>>> you'd want to avoid it.
>>
>> I'll tell you anyway: it doesn't work on Windows.
>
> Yes, it does. I don't know why it wouldn't work for you. Are you using
> some obsolete version of Windows or of its C implementation?
It's Windows 7. gcc is version 9.2.0.
This program:
#include <stdio.h>
int main(void) {printf("%zu\n",sizeof(void*));}
displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
It shows the correct value with lccwin, DMC, clang and CL (MS' compiler).
Since I predominantly use the first 3 compilers, I don't find zu useful.
Actually until I did this test, I couldn't remember which supported it
and which didn't. I like code that works on anything, so prefer to use a
format supported on any compiler.
Maybe there is a way of persuading gcc to use better libraries, but I've
no idea how, and anyway like to run it like this:
gcc prog.c
If this a program that will only be used with bcc, then there I can use
"%?", which is replaced with the correct format, I believe "%llu" here,
and get the right answer as well. That would have been a more useful
extension than another bizarre and very specific format.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-07-29 17:10 +0000 |
| Message-ID | <MhBMI.30408$bR5.466@fx44.iad> |
| In reply to | #162094 |
Bart <bc@freeuk.com> writes:
>On 29/07/2021 16:12, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 29/07/2021 03:20, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>> [...]
>>>>> Sure, I can do that (after fixing the code with the right includes and
>>>>> avoiding %zu). But that's the trial and error approach.
>>>> %zu is the correct format specifier. I'm not even going to ask why
>>>> you'd want to avoid it.
>>>
>>> I'll tell you anyway: it doesn't work on Windows.
>>
>> Yes, it does. I don't know why it wouldn't work for you. Are you using
>> some obsolete version of Windows or of its C implementation?
>
>It's Windows 7. gcc is version 9.2.0.
>
>This program:
>
> #include <stdio.h>
> int main(void) {printf("%zu\n",sizeof(void*));}
It has _always_ worked properly with GCC. You're clearly
either doing something incorrect if your assertion is accurate.
$ cc -o /tmp/b /tmp/b.c
$ /tmp/b
8
$ cat /tmp/b.c
#include <stdio.h>
int main(void) {printf("%zu\n",sizeof(void*));}
$ cc --version
gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-07-29 10:29 -0700 |
| Message-ID | <87eebhf2pe.fsf@nosuchdomain.example.com> |
| In reply to | #162097 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Bart <bc@freeuk.com> writes:
>>On 29/07/2021 16:12, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 29/07/2021 03:20, Keith Thompson wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>>>> Sure, I can do that (after fixing the code with the right includes and
>>>>>> avoiding %zu). But that's the trial and error approach.
>>>>> %zu is the correct format specifier. I'm not even going to ask why
>>>>> you'd want to avoid it.
>>>>
>>>> I'll tell you anyway: it doesn't work on Windows.
>>>
>>> Yes, it does. I don't know why it wouldn't work for you. Are you using
>>> some obsolete version of Windows or of its C implementation?
>>
>>It's Windows 7. gcc is version 9.2.0.
>>
>>This program:
>>
>> #include <stdio.h>
>> int main(void) {printf("%zu\n",sizeof(void*));}
>
> It has _always_ worked properly with GCC. You're clearly
> either doing something incorrect if your assertion is accurate.
[...]
gcc doesn't implement printf. The C library does. Bart is using an
obsolete version of Microsoft's C library.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-07-29 10:28 -0700 |
| Message-ID | <87im0tf2rn.fsf@nosuchdomain.example.com> |
| In reply to | #162094 |
Bart <bc@freeuk.com> writes:
> On 29/07/2021 16:12, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 29/07/2021 03:20, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>> [...]
>>>>> Sure, I can do that (after fixing the code with the right includes and
>>>>> avoiding %zu). But that's the trial and error approach.
>>>> %zu is the correct format specifier. I'm not even going to ask why
>>>> you'd want to avoid it.
>>>
>>> I'll tell you anyway: it doesn't work on Windows.
>> Yes, it does. I don't know why it wouldn't work for you. Are you
>> using
>> some obsolete version of Windows or of its C implementation?
>
> It's Windows 7. gcc is version 9.2.0.
>
> This program:
>
> #include <stdio.h>
> int main(void) {printf("%zu\n",sizeof(void*));}
>
> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
>
> It shows the correct value with lccwin, DMC, clang and CL (MS' compiler).
>
> Since I predominantly use the first 3 compilers, I don't find zu useful.
>
> Actually until I did this test, I couldn't remember which supported it
> and which didn't. I like code that works on anything, so prefer to use
> a format supported on any compiler.
>
> Maybe there is a way of persuading gcc to use better libraries, but
> I've no idea how, and anyway like to run it like this:
>
> gcc prog.c
>
> If this a program that will only be used with bcc, then there I can
> use "%?", which is replaced with the correct format, I believe "%llu"
> here, and get the right answer as well. That would have been a more
> useful extension than another bizarre and very specific format.
The problem is with the old C library. The version of gcc is
irrelevant.
Windows 7 is obsolete. If you're stuck using it for some reason, that's
a valid reason to avoid "%zu". "it doesn't work on Windows" is not.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-29 19:07 +0100 |
| Message-ID | <sduqoh$np9$1@dont-email.me> |
| In reply to | #162098 |
On 29/07/2021 18:28, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> This program:
>>
>> #include <stdio.h>
>> int main(void) {printf("%zu\n",sizeof(void*));}
>>
>> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
> The problem is with the old C library. The version of gcc is
> irrelevant.
>
> Windows 7 is obsolete. If you're stuck using it for some reason, that's
> a valid reason to avoid "%zu". "it doesn't work on Windows" is not.
Looks like Windows 10 is obsolete too:
c:\c>ver
Microsoft Windows [Version 10.0.14393]
c:\c>type c.c
#include <stdio.h>
int main(void) {
printf("%zu\n", sizeof(void*));
}
c:\c>gcc c.c
c:\c>a
zu
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-07-29 11:16 -0700 |
| Message-ID | <87a6m5f0j9.fsf@nosuchdomain.example.com> |
| In reply to | #162100 |
Bart <bc@freeuk.com> writes:
> On 29/07/2021 18:28, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> This program:
>>>
>>> #include <stdio.h>
>>> int main(void) {printf("%zu\n",sizeof(void*));}
>>>
>>> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
>
>> The problem is with the old C library. The version of gcc is
>> irrelevant.
>> Windows 7 is obsolete. If you're stuck using it for some reason,
>> that's
>> a valid reason to avoid "%zu". "it doesn't work on Windows" is not.
>
> Looks like Windows 10 is obsolete too:
>
> c:\c>ver
> Microsoft Windows [Version 10.0.14393]
>
> c:\c>type c.c
> #include <stdio.h>
>
> int main(void) {
> printf("%zu\n", sizeof(void*));
> }
>
> c:\c>gcc c.c
>
> c:\c>a
> zu
No, it looks like you're using an obsolete C library implementation on
Windows 10. I'm able to compile and run your program on Windows 10,
and it prints 8 or 4 depending on which implementation I use.
You could probably get some help with that if you asked (and provided
some information).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-29 19:41 +0100 |
| Message-ID | <sdusob$h8b$1@dont-email.me> |
| In reply to | #162101 |
On 29/07/2021 19:16, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 29/07/2021 18:28, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> This program:
>>>>
>>>> #include <stdio.h>
>>>> int main(void) {printf("%zu\n",sizeof(void*));}
>>>>
>>>> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
>>
>>> The problem is with the old C library. The version of gcc is
>>> irrelevant.
>>> Windows 7 is obsolete. If you're stuck using it for some reason,
>>> that's
>>> a valid reason to avoid "%zu". "it doesn't work on Windows" is not.
>>
>> Looks like Windows 10 is obsolete too:
>>
>> c:\c>ver
>> Microsoft Windows [Version 10.0.14393]
>>
>> c:\c>type c.c
>> #include <stdio.h>
>>
>> int main(void) {
>> printf("%zu\n", sizeof(void*));
>> }
>>
>> c:\c>gcc c.c
>>
>> c:\c>a
>> zu
>
> No, it looks like you're using an obsolete C library implementation on
> Windows 10.
You said 'Windows 7 is obsolete'.
Anyway, how can the C library be obsolete if it comes /with/ Windows 10?
Even if I could, installing a different library wouldn't be much help,
since then I'd have programs that worked fine on my Windows, but on no
one else's unless they jumped through the same hoops.
Just for the sake of %zu which can be trivially replaced with %d and a
(int) cast (or %lld and (long long) if expecting some big objects), it
is not worth the headache of extra dependencies.
> I'm able to compile and run your program on Windows 10,
> and it prints 8 or 4 depending on which implementation I use.
>
> You could probably get some help with that if you asked (and provided
> some information).
Does Tiny C work too?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-07-29 12:43 -0700 |
| Message-ID | <875ywsgb2d.fsf@nosuchdomain.example.com> |
| In reply to | #162102 |
Bart <bc@freeuk.com> writes:
> On 29/07/2021 19:16, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 29/07/2021 18:28, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> This program:
>>>>>
>>>>> #include <stdio.h>
>>>>> int main(void) {printf("%zu\n",sizeof(void*));}
>>>>>
>>>>> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
>>>
>>>> The problem is with the old C library. The version of gcc is
>>>> irrelevant.
>>>> Windows 7 is obsolete. If you're stuck using it for some reason,
>>>> that's
>>>> a valid reason to avoid "%zu". "it doesn't work on Windows" is not.
>>>
>>> Looks like Windows 10 is obsolete too:
>>>
>>> c:\c>ver
>>> Microsoft Windows [Version 10.0.14393]
>>>
>>> c:\c>type c.c
>>> #include <stdio.h>
>>>
>>> int main(void) {
>>> printf("%zu\n", sizeof(void*));
>>> }
>>>
>>> c:\c>gcc c.c
>>>
>>> c:\c>a
>>> zu
>> No, it looks like you're using an obsolete C library implementation
>> on
>> Windows 10.
>
> You said 'Windows 7 is obsolete'.
I did, and it is.
> Anyway, how can the C library be obsolete if it comes /with/ Windows
> 10? Even if I could, installing a different library wouldn't be much
> help, since then I'd have programs that worked fine on my Windows, but
> on no one else's unless they jumped through the same hoops.
I don't know enough about it to answer that. I use Visual Studio for
work and Cygwin for personal use. I don't have a gcc-based
implementation outside Cygwin. Microsoft's online documentation says
"%zu" works.
I know that Microsoft was very slow to support C99 (which is where %zu
was introduced), but they've made considerable progress more recently.
> Just for the sake of %zu which can be trivially replaced with %d and a
> (int) cast (or %lld and (long long) if expecting some big objects), it
> is not worth the headache of extra dependencies.
On the systems and implementions I currently use, there are no extra
dependencies; "%zu" just works, and I don't seem to have an
implementation where it doesn't. For my own purposes, I have no reason
to avoid "%zu". Obviously your situation is different, and there are
several workarounds you can use.
I don't know what C library implementation you're using or how it was
installed, other than your statement that it came with Windows 10.
If you're not bothered by its lack of support for "%zu", I don't see
anything more to discuss.
>> I'm able to compile and run your program on Windows 10,
>> and it prints 8 or 4 depending on which implementation I use.
>> You could probably get some help with that if you asked (and
>> provided
>> some information).
>
> Does Tiny C work too?
I don't have Tiny C on either Windows 10 system I have access to, but I
presume it would use the same library that gcc uses, so I'd expect it to
work. (tcc, like gcc, is a compiler, not a complete implementation.
You have a habit of glossing over that.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-07-30 15:06 +0000 |
| Message-ID | <20210730075628.870@kylheku.com> |
| In reply to | #162102 |
On 2021-07-29, Bart <bc@freeuk.com> wrote: > Anyway, how can the C library be obsolete if it comes /with/ Windows 10? Windows 10 does not come with a C library. Windows 10 comes with an undocumented internal component called MSVCRT.DLL (or something similar) which is in the system folder. This is used by some utilities that come with Windows. If you create executable programs which link or load this and call into it, you're misusing Windows in an undocumented way, like sticking a fork in a toaster whose user manual describes only bread being stuck into the toaster. A few misguided free software developers came up with the idea that that doing this is a good way to port GNU programs to Windows, because the GPL has a "system library exception". So that is to say, a GPL-ed program being linked to Microsoft's redistributable Visual C run-time would be a GPL violation because that run-time is not a system library, but just another proprietary third-party library with a GPL-incompatible license. Some have additionally defended this idiotic choice because it produces single .EXE programs that are small. That's like saying, "look at the weight and space we can save if we don't put heat sinks on these power transistors; who cares if we are outside of the documented safe operating area!" -- 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-07-30 16:31 +0100 |
| Message-ID | <se160r$o5c$1@dont-email.me> |
| In reply to | #162112 |
On 30/07/2021 16:06, Kaz Kylheku wrote: > On 2021-07-29, Bart <bc@freeuk.com> wrote: >> Anyway, how can the C library be obsolete if it comes /with/ Windows 10? > > Windows 10 does not come with a C library. > > Windows 10 comes with an undocumented internal component called > MSVCRT.DLL (or something similar) which is in the system folder. > > This is used by some utilities that come with Windows. > > If you create executable programs which link or load this and call into > it, you're misusing Windows in an undocumented way, like sticking a fork > in a toaster whose user manual describes only bread being stuck into > the toaster. Yet gcc on Windows (or my TDM version of it) does the same. As does Tiny C. So would any application built with those compilers. Including tcc.exe itself. And gcc.exe itself. (I don't have time to look at various other applications.) So my attitude is, so what?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-07-30 19:49 +0200 |
| Message-ID | <se1e2f$ht1$1@dont-email.me> |
| In reply to | #162117 |
On 30/07/2021 17:31, Bart wrote: > On 30/07/2021 16:06, Kaz Kylheku wrote: >> On 2021-07-29, Bart <bc@freeuk.com> wrote: >>> Anyway, how can the C library be obsolete if it comes /with/ Windows 10? >> >> Windows 10 does not come with a C library. >> >> Windows 10 comes with an undocumented internal component called >> MSVCRT.DLL (or something similar) which is in the system folder. >> >> This is used by some utilities that come with Windows. >> >> If you create executable programs which link or load this and call into >> it, you're misusing Windows in an undocumented way, like sticking a fork >> in a toaster whose user manual describes only bread being stuck into >> the toaster. > > Yet gcc on Windows (or my TDM version of it) does the same. As does Tiny > C. So would any application built with those compilers. > > Including tcc.exe itself. > > And gcc.exe itself. > That matches precisely with what Kaz wrote. Using MSVCRT.DLL as your "system C library" is a lazy, undocumented way to make your C programs work, and being able to boast (pointlessly) about generating small executables. The DLL is slow, outdated, and not intended for such uses - it is designed for runtime versions of functions used in combination with MS's own development tools, not anyone else's tools. It has outdated versions of some functions (it never claimed to support C99, but is primarily for C++). It is not licensed for distribution or use except with executables generated by MSVC - and it is not and has never been a standard part of Windows. You can usually expect a copy of some version of the DLL to be on most Windows systems, since it is commonly distributed with many programs for Windows, though you can only guess at which version of the DLL you might have. Anyone can take the source code for gcc and build a package containing a gcc.exe compiler, with a setup to link to MSVCRT.DLL or a decent C library. That does not make it in any way a compiler from the GNU gcc developers - it's just some person or group using the freedom of the GPL'ed code to make a package that they think some people will find useful. If you find it useful, great. But please don't call it "gcc on Windows" as though it had even the remotest legitimacy as an "official" gcc port for Windows. > (I don't have time to look at various other applications.) > > So my attitude is, so what? > If that's your attitude, that's fine - it's up to you. Many other C programmers - most, perhaps - have joined this century and are using C99 at least. If you are happy with a setup, toolchain and OS for which you can't use C99, that's fine. Don't expect anyone else to have much consideration for your limited arrangements, however.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-30 20:03 +0100 |
| Message-ID | <se1iev$hu3$1@dont-email.me> |
| In reply to | #162124 |
On 30/07/2021 18:49, David Brown wrote:
> On 30/07/2021 17:31, Bart wrote:
>> On 30/07/2021 16:06, Kaz Kylheku wrote:
>>> On 2021-07-29, Bart <bc@freeuk.com> wrote:
>>>> Anyway, how can the C library be obsolete if it comes /with/ Windows 10?
>>>
>>> Windows 10 does not come with a C library.
>>>
>>> Windows 10 comes with an undocumented internal component called
>>> MSVCRT.DLL (or something similar) which is in the system folder.
>>>
>>> This is used by some utilities that come with Windows.
>>>
>>> If you create executable programs which link or load this and call into
>>> it, you're misusing Windows in an undocumented way, like sticking a fork
>>> in a toaster whose user manual describes only bread being stuck into
>>> the toaster.
>>
>> Yet gcc on Windows (or my TDM version of it) does the same. As does Tiny
>> C. So would any application built with those compilers.
>>
>> Including tcc.exe itself.
>>
>> And gcc.exe itself.
>>
>
> That matches precisely with what Kaz wrote. Using MSVCRT.DLL as your
> "system C library" is a lazy, undocumented way to make your C programs
> work, and being able to boast (pointlessly) about generating small
> executables.
Hmm, the hello.exe executable generated by gcc (after you specify
-ohello.exe!) is about 330KB.
And this still imports msvcrt.dll. So small executables aren't the
reason gcc does it. (tcc produces a 2KB executable.)
You also don't seem to understand the point of DLLs: they are SHARED
libraries. They are supposed to save space; it is not just disk space,
but process space. What's the point of 100 active programs all running
their own private copies of the C runtime?
Plus, system DLLs (as I consider msvcrt.dll) are usually not practical
to statically link, because only DLLS are available (eg. kernel32.dll).
How big would a program be if it incorporated half the Windows API as
statically linked code?
The GTK libraries on Windows numbered 28 different DLLs (I don't know
how many MB in total). So what is special about using another DLL called
msvcrt.dll?
You just want to pour more scorn on the efforts of amateur compiler writers.
> Anyone can take the source code for gcc
No. It is a product that consists of about 100,000 files, of which about
half are source files. It is HUGE. It would be a miracle just to get it
to build using the automatic means provided, let alone understand the
ins and outs of it enough to figure out how it deals with system libraries.
When gcc compiles hello.c, it eventually invokes a linker with FIFTY
different options.
That is a totally different world from what I do. My product doesn't
even HAVE a linker! (Because it doesn't need it; an obsolete concept in
my view.)
>> So my attitude is, so what?
>>
>
> If that's your attitude, that's fine - it's up to you.
Because even your beloved gcc does it. And every program that a mingw
gcc builds on Windows, will depend on it too, even when linked with
-lucrt. So why on earth should I worry about whether /I/ use it?
>
> Many other C programmers - most, perhaps - have joined this century and
> are using C99 at least. If you are happy with a setup, toolchain and OS
> for which you can't use C99, that's fine. Don't expect anyone else to
> have much consideration for your limited arrangements, however.
All this fuss about "%zu" which is incredibly naff anyway. If using my
bcc compiler, I can just write:
printf("%?", sizeof(T));
which would work with ANY C library.
If using my private language, it's even simpler:
print T.bytes
So, I should put myself out for a 'format specifier' of the kind that
should have been done away with last century. How about /you/ lot
joining the 21st century!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-07-30 23:16 +0200 |
| Message-ID | <se1q6l$5ou$1@dont-email.me> |
| In reply to | #162131 |
On 30/07/2021 21:03, Bart wrote:
> On 30/07/2021 18:49, David Brown wrote:
>> On 30/07/2021 17:31, Bart wrote:
>>> On 30/07/2021 16:06, Kaz Kylheku wrote:
>>>> On 2021-07-29, Bart <bc@freeuk.com> wrote:
>>>>> Anyway, how can the C library be obsolete if it comes /with/
>>>>> Windows 10?
>>>>
>>>> Windows 10 does not come with a C library.
>>>>
>>>> Windows 10 comes with an undocumented internal component called
>>>> MSVCRT.DLL (or something similar) which is in the system folder.
>>>>
>>>> This is used by some utilities that come with Windows.
>>>>
>>>> If you create executable programs which link or load this and call into
>>>> it, you're misusing Windows in an undocumented way, like sticking a
>>>> fork
>>>> in a toaster whose user manual describes only bread being stuck into
>>>> the toaster.
>>>
>>> Yet gcc on Windows (or my TDM version of it) does the same. As does Tiny
>>> C. So would any application built with those compilers.
>>>
>>> Including tcc.exe itself.
>>>
>>> And gcc.exe itself.
>>>
>>
>> That matches precisely with what Kaz wrote. Using MSVCRT.DLL as your
>> "system C library" is a lazy, undocumented way to make your C programs
>> work, and being able to boast (pointlessly) about generating small
>> executables.
>
> Hmm, the hello.exe executable generated by gcc (after you specify
> -ohello.exe!) is about 330KB.
>
> And this still imports msvcrt.dll. So small executables aren't the
> reason gcc does it. (tcc produces a 2KB executable.)
>
> You also don't seem to understand the point of DLLs: they are SHARED
> libraries. They are supposed to save space; it is not just disk space,
> but process space. What's the point of 100 active programs all running
> their own private copies of the C runtime?
>
I /do/ understand the point of DLL's. The possibility of sharing space
is just one aspect - and it is totally underused on Windows, since
pretty much every program installs its own copies of the DLL's it needs
(with the exception of the /real/ system DLL's) due to a lack of any
centralised repository and a total chaos of DLL versioning on Windows.
(On Linux, and other *nix, DLL equivalents work well as shared
libraries.) There are other reasons for having DLL's, such as breaking
big programs into more manageable pieces, or re-using code for different
programs.
Most of the standard C library functions are fairly trivial in size -
many are wrappers around system calls (which are, of course, in system
libraries, not the C library). For many, the overhead of calling
external DLL functions greatly outweighs the size or the time taken by
the function itself - you want functions like strcat, memcpy, etc., to
be inlined in many cases, or at least implemented by a static library
rather than a DLL. Statically linking your C library is going to be of
insignificant size cost for most programs, but will often be of speed
benefit.
> Plus, system DLLs (as I consider msvcrt.dll) are usually not practical
> to statically link, because only DLLS are available (eg. kernel32.dll).
>
Regardless of how you consider things, "msvcrt.dll" is not a system DLL.
And any decent C standard library will be available for static linking.
(/Real/ system libraries, such as kernel32.dll, are a different matter.)
> How big would a program be if it incorporated half the Windows API as
> statically linked code?
>
For someone who claims to have developed their own languages, compilers,
linkers and other tools for decades, you are remarkably ignorant of how
toolchains work. Or you are trolling, as some people have suggested.
Perhaps you have just written in haste, without thinking - everyone
makes mistakes and occasionally writes something stupid.
> The GTK libraries on Windows numbered 28 different DLLs (I don't know
> how many MB in total). So what is special about using another DLL called
> msvcrt.dll?
>
> You just want to pour more scorn on the efforts of amateur compiler
> writers.
>
Given that there are other free C runtime libraries, I don't see any
good reason for using it when you simply want C coding, without a
specific need for compatibility with (older) MS tools. It is quite
possible that MSVCRT.DLL was the best choice in the past - it is not
now. I can't say I have looked into this in too much detail, since it
is not an issue that is at all relevant to me or my work. But I could
point out that at least two people here have shown the use of gcc with C
libraries that are quite happy with C99 printf. One - Keith - said he
had no trouble when using Cygwin. Someone else - I forget who - said
they could just use the "-lucrt" switch to get a working library. It
does not seem to be too difficult.
>> Anyone can take the source code for gcc
>
> No. It is a product that consists of about 100,000 files, of which about
> half are source files. It is HUGE. It would be a miracle just to get it
> to build using the automatic means provided, let alone understand the
> ins and outs of it enough to figure out how it deals with system libraries.
>
I've compiled it a good many times over the years (first with version
2.95 for the m68k target and a Windows NT 4 host, IIRC), for
cross-compiling.
But let me rephrase. Anyone competent and interested in compiling gcc,
can take the source code and compile it and package it in whatever way
they like. It does require a willingness to read the information
available, follow suggestions and instructions from others, and
generally do your best to get a working result. Those whose main aim is
to whine and cry, complain about the size, and generally try to find
excuses to say how terrible it all is, will probably find it hard to get
a working toolchain.
> When gcc compiles hello.c, it eventually invokes a linker with FIFTY
> different options.
>
So what?
I generally involve the /compiler/ with fifty different options - but
that is because I want these options and features while others might
not. I use build tools, and can write these options in a makefile. And
I /really/ don't care how many options are passed behind the scenes for
different parts of the toolchain - it is behind the scenes!
> That is a totally different world from what I do. My product doesn't
> even HAVE a linker! (Because it doesn't need it; an obsolete concept in
> my view.)
>
Yes, but your tools are useless for anyone but you. gcc (and binutils
for the linker, assuming that's the linker you are using) are designed
to be used by vast numbers of people for vast numbers of different
purposes in vast numbers of different circumstances.
Do you also complain about the size of supermarkets, or the number of
restaurants in your town, just because you are happy with a cheese
sandwich for dinner every night?
>
>>> So my attitude is, so what?
>>>
>>
>> If that's your attitude, that's fine - it's up to you.
>
> Because even your beloved gcc does it. And every program that a mingw
> gcc builds on Windows, will depend on it too, even when linked with
> -lucrt. So why on earth should I worry about whether /I/ use it?
>
>
>>
>> Many other C programmers - most, perhaps - have joined this century and
>> are using C99 at least. If you are happy with a setup, toolchain and OS
>> for which you can't use C99, that's fine. Don't expect anyone else to
>> have much consideration for your limited arrangements, however.
>
> All this fuss about "%zu" which is incredibly naff anyway. If using my
> bcc compiler, I can just write:
>
> printf("%?", sizeof(T));
>
> which would work with ANY C library.
>
> If using my private language, it's even simpler:
>
> print T.bytes
>
> So, I should put myself out for a 'format specifier' of the kind that
> should have been done away with last century. How about /you/ lot
> joining the 21st century!
>
Look, no one gives a ***** about your private little toy language. No
one cares. It is useless for anything real. Even if it was the
greatest invention since sliced bread, no one would use it because it is
the product of one angry little man whose prime motivation is a bizarre
and obsessive hatred of C (and C++) and tools for those languages. This
is comp.lang.c, where we use and discuss C. If any of us here want to
use a different language just to make it slightly simpler to print a
number, we all know of many /real/ languages to use. (And many of us
/do/ use other languages which are better than C for particular tasks.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-31 01:51 +0100 |
| Message-ID | <se26q0$dg5$1@dont-email.me> |
| In reply to | #162139 |
On 30/07/2021 22:16, David Brown wrote: > On 30/07/2021 21:03, Bart wrote: >> Plus, system DLLs (as I consider msvcrt.dll) are usually not practical >> to statically link, because only DLLS are available (eg. kernel32.dll). >> > > Regardless of how you consider things, "msvcrt.dll" is not a system DLL. > And any decent C standard library will be available for static linking. > (/Real/ system libraries, such as kernel32.dll, are a different matter.) I first started using msvcrt.dll or equivalent in mid-90s. I didn't use it from C. To me it was just another library that came with Windows, with a smaller and much simpler API. It was also documented as part of the SDK IIRC. I was hardly even aware then that it was to do with C; as such a library, it could be used from any language, and itself didn't need to be implemented in C (the binary clearly wasn't C!). >> How big would a program be if it incorporated half the Windows API as >> statically linked code? >> > > For someone who claims to have developed their own languages, compilers, > linkers and other tools for decades, you are remarkably ignorant of how > toolchains work. Why, what's wrong with my question? It is perfectly reasonable. I might consider bundling RAYLIB with an application for example, by statically linking (it's some 3MB I think). But not libraries which are guaranteed to come with the OS. (Some exceptions such as OpenGL where the OS one may lag behind.) > Or you are trolling, as some people have suggested. > Perhaps you have just written in haste, without thinking - everyone > makes mistakes and occasionally writes something stupid. OK, now I'm curious; what's the thing that is stupid? Having an opinion different from yours? >> You just want to pour more scorn on the efforts of amateur compiler >> writers. >> > > Given that there are other free C runtime libraries, I don't see any > good reason for using it when you simply want C coding, I don't like dependencies. I like that there is just my program, and the OS. Some third party libraries may necessarily have to be sourced, but MSVCRT.DLL works perfectly well for the vast majority of my needs. (From my private language, I only use about 20 C functions anyway, out of about 1400 in MSVCRT.DLL. It wouldn't be that hard to eliminate it (I did without it for years).) without a > specific need for compatibility with (older) MS tools. It is quite > possible that MSVCRT.DLL was the best choice in the past - it is not > now. I can't say I have looked into this in too much detail, since it > is not an issue that is at all relevant to me or my work. But I could > point out that at least two people here have shown the use of gcc with C > libraries that are quite happy with C99 printf. One - Keith - said he > had no trouble when using Cygwin. I use Windows. (Imagine someone said they had no problem running my Windows program under Wine; but Wine isn't Linux) > Someone else - I forget who - said > they could just use the "-lucrt" switch to get a working library. That was me. But it's not a solution (assuming there was a problem in the first place) as I need to have C code run under bcc and tcc. Especially tcc, since I have an upcoming project that may need a C backend (and for some challenging C code), and using any other compiler would be like hitting a brick wall. > But let me rephrase. Anyone competent and interested in compiling gcc, > can take the source code and compile it and package it in whatever way > they like. Not interested. Life is too short. My entire compiler builds in 0.2 seconds, but might generate code 50% slower than gcc. That will do me. >> That is a totally different world from what I do. My product doesn't >> even HAVE a linker! (Because it doesn't need it; an obsolete concept in >> my view.) >> > > Yes, but your tools are useless for anyone but you. Sure. But they are also proof of concept. Want a blazing fast C compiler? I've done it! (Tcc got there first and better, but I'm not far behind.) Do away with object files? I've done it! Do away with a linker? I've done it! Do away with makefiles? I've done it! Write a whole-program compiler? I've done it! (But not with C - yet.) A 4-million-line-per second assembler? I've done it! So it can all show what is possible. Of little interest in this group obviously and especially to you because you don't understand that some of us are interested in developing efficient, minimalist, human-scale tools, and which might be an inspiration to others. > gcc (and binutils > for the linker, assuming that's the linker you are using) are designed > to be used by vast numbers of people for vast numbers of different > purposes in vast numbers of different circumstances. > > Do you also complain about the size of supermarkets, or the number of > restaurants in your town, just because you are happy with a cheese > sandwich for dinner every night? I would like to cook my own recipes without getting involved in industrial-scale food production. There's a need for that, obviously, but I'm simply not interested. > Look, no one gives a ***** about your private little toy language. No > one cares. It is useless for anything real. I would let that go. But actually, I worked in a commercial environment for 20 years and used exclusively my private languages. They /were/ useful, and were used for a product that was generating, then, perhaps $1m a year of business. So I'm not going to be shouted down by you. Even if it was the > greatest invention since sliced bread, no one would use it because it is > the product of one angry little man whose prime motivation is a bizarre > and obsessive hatred of C (and C++) and tools for those languages. This entire subthread is a perfect example of what I hate about it: all this fuss about a stupid "%zu" format code just to print out a number. Whose idea was that? And how about /properly/ fixing 'print'? > This > is comp.lang.c, where we use and discuss C. I knew it was a mistake coming back to this newsgroup. You know, because of the massive negative reaction in this group (everthing I did was wrong, all my C code was rubbish, I knew nothing about the language, etc etc) a year ago I burnt most of my bridges with C, got rid of my C backends; actually you guys put me off the language a lot more than the language itself. That was a mistake. A C target is genuinely useful to have. And you people don't actually own the language. Neither do you write any of the tools, mostly (some exceptions like JN). And, you can't actually tell people what they can or can't do (go and program in WSL; no thanks!). So I'm resurrecting that C target in a novel, experimental project. I won't make the mistake of posting code here for you to shoot down. And I will use whatever compilers I like with the libraries I want and on the OSes that I choose.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-07-31 13:42 +0200 |
| Message-ID | <se3cvq$mpf$1@dont-email.me> |
| In reply to | #162154 |
On 31/07/2021 02:51, Bart wrote: > On 30/07/2021 22:16, David Brown wrote: >> On 30/07/2021 21:03, Bart wrote: > >>> How big would a program be if it incorporated half the Windows API as >>> statically linked code? >>> >> >> For someone who claims to have developed their own languages, compilers, >> linkers and other tools for decades, you are remarkably ignorant of how >> toolchains work. > > Why, what's wrong with my question? It is perfectly reasonable. > > I might consider bundling RAYLIB with an application for example, by > statically linking (it's some 3MB I think). But not libraries which are > guaranteed to come with the OS. > > (Some exceptions such as OpenGL where the OS one may lag behind.) > >> Or you are trolling, as some people have suggested. >> Perhaps you have just written in haste, without thinking - everyone >> makes mistakes and occasionally writes something stupid. > > OK, now I'm curious; what's the thing that is stupid? Having an opinion > different from yours? > When you use statically linked libraries, you only link in the functions you actually /use/. So it doesn't matter if the static library supports a hundred thousand WinAPI functions and weighs in at 100 MB - if you use a hundred functions, the library will give you an extra 100 KB in your binary. Using a static library for the WinAPI or the C standard library is only going to give you a big binary if you use a very large number of functions from the library - in which case your binary is already very big. > >>> You just want to pour more scorn on the efforts of amateur compiler >>> writers. >>> >> >> Given that there are other free C runtime libraries, I don't see any >> good reason for using it when you simply want C coding, > > I don't like dependencies. I like that there is just my program, and the > OS. Some third party libraries may necessarily have to be sourced, but > MSVCRT.DLL works perfectly well for the vast majority of my needs. I understand not wanting dependencies, and preferring a stand-alone program. That is another good reason to ditch MSVCRT.DLL, which is a completely unnecessary dependency, and statically link a C library. > > (From my private language, I only use about 20 C functions anyway, out > of about 1400 in MSVCRT.DLL. > > It wouldn't be that hard to eliminate it (I did without it for years).) > > without a >> specific need for compatibility with (older) MS tools. It is quite >> possible that MSVCRT.DLL was the best choice in the past - it is not >> now. I can't say I have looked into this in too much detail, since it >> is not an issue that is at all relevant to me or my work. But I could >> point out that at least two people here have shown the use of gcc with C >> libraries that are quite happy with C99 printf. One - Keith - said he >> had no trouble when using Cygwin. > > I use Windows. (Imagine someone said they had no problem running my > Windows program under Wine; but Wine isn't Linux) I see "runs fine with Wine" as a reasonable solution to porting Windows programs to run on Linux - just as Cygwin is a reasonable solution to porting POSIX programs to Windows. It's not native, but it works well for many purposes. > >> Someone else - I forget who - said >> they could just use the "-lucrt" switch to get a working library. > > That was me. But it's not a solution (assuming there was a problem in > the first place) as I need to have C code run under bcc and tcc. It is a solution for when you want to use a C compiler, rather than a compiler for a limited subset of C. If you want C, you need a real compiler and a real library. If you are happy with just part of C (and often that is sufficient), you can use a limited tool like bcc or tcc, and a limited library like MSVCRT.DLL, if you like. Just don't complain when you use such tools and they don't handle some valid C code. > Especially tcc, since I have an upcoming project that may need a C > backend (and for some challenging C code), and using any other compiler > would be like hitting a brick wall. > >> But let me rephrase. Anyone competent and interested in compiling gcc, >> can take the source code and compile it and package it in whatever way >> they like. > > Not interested. Life is too short. My entire compiler builds in 0.2 > seconds, but might generate code 50% slower than gcc. That will do me. > > >>> That is a totally different world from what I do. My product doesn't >>> even HAVE a linker! (Because it doesn't need it; an obsolete concept in >>> my view.) >>> >> >> Yes, but your tools are useless for anyone but you. > > Sure. But they are also proof of concept. Want a blazing fast C > compiler? I've done it! (Tcc got there first and better, but I'm not far > behind.) Why should anyone care about how fast something runs if it does not do the job? If these niche tools are good enough for your particular needs, fine - use them and enjoy them. There is a place in this world for Formula 1 cars that are lighter, smaller, and much faster than normal cars - but only a fool would think they are /better/ than the car you drive every day. > > Do away with object files? I've done it! Do away with a linker? I've > done it! Do away with makefiles? I've done it! Write a whole-program > compiler? I've done it! (But not with C - yet.) A 4-million-line-per > second assembler? I've done it! I have always been impressed by the fact that you have written a compiler at all. Your obsession with speed and size, however, is less impressive. > > So it can all show what is possible. Of little interest in this group > obviously and especially to you because you don't understand that some > of us are interested in developing efficient, minimalist, human-scale > tools, and which might be an inspiration to others. > I can appreciate people making hobby tools. > >> gcc (and binutils >> for the linker, assuming that's the linker you are using) are designed >> to be used by vast numbers of people for vast numbers of different >> purposes in vast numbers of different circumstances. >> >> Do you also complain about the size of supermarkets, or the number of >> restaurants in your town, just because you are happy with a cheese >> sandwich for dinner every night? > > I would like to cook my own recipes without getting involved in > industrial-scale food production. There's a need for that, obviously, > but I'm simply not interested. > >> Look, no one gives a ***** about your private little toy language. No >> one cares. It is useless for anything real. > > I would let that go. But actually, I worked in a commercial environment > for 20 years and used exclusively my private languages. > > They /were/ useful, and were used for a product that was generating, > then, perhaps $1m a year of business. So I'm not going to be shouted > down by you. > I have seen the mistakes made by customers getting software written with "one-man" tools. It can sound like a good idea at the time, but leaves the customer with unmaintainable code. /Sometimes/ it can be a reasonable choice, especially when the system is highly person-specific in the first place and using a language known by others would not help. And it used to be more common long ago, in the "cowboy days" of software development. > > Even if it was the >> greatest invention since sliced bread, no one would use it because it is >> the product of one angry little man whose prime motivation is a bizarre >> and obsessive hatred of C (and C++) and tools for those languages. > > This entire subthread is a perfect example of what I hate about it: all > this fuss about a stupid "%zu" format code just to print out a number. > Just use a C toolchain and the C language, as it is defined - it's not hard. It's only people who haven't joined this century that have problems. > Whose idea was that? And how about /properly/ fixing 'print'? > If we were discussing how a programming language could handle tasks in a different way from the C way, that would come up. No one is in any doubt that a programming language designed today would be somewhat different from one designed 50 years ago. But this is about how to write code in C. > > >> This >> is comp.lang.c, where we use and discuss C. > > I knew it was a mistake coming back to this newsgroup. > > You know, because of the massive negative reaction in this group > (everthing I did was wrong, all my C code was rubbish, I knew nothing > about the language, etc etc) a year ago I burnt most of my bridges with > C, got rid of my C backends; actually you guys put me off the language a > lot more than the language itself. > > That was a mistake. A C target is genuinely useful to have. And you > people don't actually own the language. Neither do you write any of the > tools, mostly (some exceptions like JN). > > And, you can't actually tell people what they can or can't do (go and > program in WSL; no thanks!). > > So I'm resurrecting that C target in a novel, experimental project. I > won't make the mistake of posting code here for you to shoot down. And I > will use whatever compilers I like with the libraries I want and on the > OSes that I choose. > People here have tried to /help/ you. You have never appreciated that.
[toc] | [prev] | [next] | [standalone]
Page 7 of 20 — ← Prev page 1 … 5 6 [7] 8 9 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web