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 8 of 20 — ← Prev page 1 … 6 7 [8] 9 10 … 20 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-31 14:56 +0100 |
| Message-ID | <se3kpv$977$1@dont-email.me> |
| In reply to | #162162 |
On 31/07/2021 12:42, David Brown wrote: > 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. I don't think this is right. My brief experiments seem to show: * If you link in biglib.o, it will include everything from biglib, whether or not used from outside * If you create biglib.a, and link in biglib.a, it will still include everything in biglib, provided at least one export is used elsewhere But my experiments only covered a .a file made from a single .o file. It could be that it works on a granularity of individual object files. But even then, if A and B each have 1000 functions, and you use one function in A which calls one in B, then 2000 functions will get included, not even only 1000. This is some way from your suggestion that the granularity is at the level of individual files, and presumably individual variables. But I guess this all magically becomes possible with special options, including options that will generate the position-independent code that would be necessary to extract and relocate individual functions. (How does it even work out how big a function is?)
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-07-31 19:33 +0200 |
| Message-ID | <se41h9$kbs$1@gioia.aioe.org> |
| In reply to | #162163 |
On 7/31/2021 3:56 PM, Bart wrote: > On 31/07/2021 12:42, David Brown wrote: >> 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. > > I don't think this is right. No, it is right. My brief experiments seem to show: > > * If you link in biglib.o, it will include everything from biglib, > whether or not used from outside > > * If you create biglib.a, and link in biglib.a, it will still include > everything in biglib, provided at least one export is used elsewhere > > But my experiments only covered a .a file made from a single .o file. That's the difference. You should test it with a final executable (and a decent compiler). (btw I assume you didn't mean .a as a linux library, so what did you mean with .a ?) > > It could be that it works on a granularity of individual object files. > But even then, if A and B each have 1000 functions, and you use one > function in A which calls one in B, then 2000 functions will get > included, not even only 1000. > > This is some way from your suggestion that the granularity is at the > level of individual files, and presumably individual variables. That is how static libraries work with decent compilers, the final executable only gets individual /functions/ (not files, but obviously all of the function dependencies) and individual variables. Note, stress is on /static/ libraries (.lib on Windows and .a on Linux, so no .dll or .so statically linked, in case this were a thing) > > But I guess this all magically becomes possible with special options, > including options that will generate the position-independent code that > would be necessary to extract and relocate individual functions. (How > does it even work out how big a function is?) >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-31 19:17 +0100 |
| Message-ID | <se444k$j48$1@dont-email.me> |
| In reply to | #162164 |
On 31/07/2021 18:33, Manfred wrote: > On 7/31/2021 3:56 PM, Bart wrote: >>> 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. >> >> I don't think this is right. > No, it is right. > > My brief experiments seem to show: >> >> * If you link in biglib.o, it will include everything from biglib, >> whether or not used from outside >> >> * If you create biglib.a, and link in biglib.a, it will still include >> everything in biglib, provided at least one export is used elsewhere >> >> But my experiments only covered a .a file made from a single .o file. > > That's the difference. You should test it with a final executable (and a > decent compiler). (btw I assume you didn't mean .a as a linux library, > so what did you mean with .a ?) I'm using tdm-gcc on Windows, which uses .a files as they are on Linux, created with the 'ar' utility. >> >> It could be that it works on a granularity of individual object files. >> But even then, if A and B each have 1000 functions, and you use one >> function in A which calls one in B, then 2000 functions will get >> included, not even only 1000. >> >> This is some way from your suggestion that the granularity is at the >> level of individual files, and presumably individual variables. > > That is how static libraries work with decent compilers, the final > executable only gets individual /functions/ (not files, but obviously > all of the function dependencies) and individual variables. Note, stress > is on /static/ libraries (.lib on Windows and .a on Linux, so no .dll or > .so statically linked, in case this were a thing) My tests with a 4MB library, libraylib_static.a, showed a program with just one reference to one symbol, resulted in executables from 2.7-3.0MB, where an empty program is 0.3MB (normal with tdm-gcc). If I used the -s option, sizes reduce to 0.02MB (empty) to 0.8-1.0MB (single reference, including one to an exported variable, not a function). So it does seem that it uses granularity of a module at best. It seems odd though that the linker doesn't by default, exclude that symbol info which makes a very significant difference, but doesn't, assuming it was capable, eliminate unused functions. I guess now this is going to be the start of another long subthread about how this is all my fault; I should read all the docs for tdm-gcc so that I know how to tell it to /do its job/, how I should just give up Windows right now, blah blah. But I'm not going there. DB said linkers work a certain way, and I just posted my observations about how they work a different way. This was after being called stupid for suggesting that static linking might result in large executables. (Actually, given how huge some applications already are, it would be scary if that was /after/ all unnecessary functions had been eliminated!)
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-07-31 21:32 +0200 |
| Message-ID | <se48g2$1r3g$1@gioia.aioe.org> |
| In reply to | #162165 |
On 7/31/2021 8:17 PM, Bart wrote: > On 31/07/2021 18:33, Manfred wrote: >> On 7/31/2021 3:56 PM, Bart wrote: > >>>> 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. >>> >>> I don't think this is right. >> No, it is right. >> >> My brief experiments seem to show: >>> >>> * If you link in biglib.o, it will include everything from biglib, >>> whether or not used from outside >>> >>> * If you create biglib.a, and link in biglib.a, it will still include >>> everything in biglib, provided at least one export is used elsewhere >>> >>> But my experiments only covered a .a file made from a single .o file. >> >> That's the difference. You should test it with a final executable (and >> a decent compiler). (btw I assume you didn't mean .a as a linux >> library, so what did you mean with .a ?) > > I'm using tdm-gcc on Windows, which uses .a files as they are on Linux, > created with the 'ar' utility. > > >>> >>> It could be that it works on a granularity of individual object >>> files. But even then, if A and B each have 1000 functions, and you >>> use one function in A which calls one in B, then 2000 functions will >>> get included, not even only 1000. >>> >>> This is some way from your suggestion that the granularity is at the >>> level of individual files, and presumably individual variables. >> >> That is how static libraries work with decent compilers, the final >> executable only gets individual /functions/ (not files, but obviously >> all of the function dependencies) and individual variables. Note, >> stress is on /static/ libraries (.lib on Windows and .a on Linux, so >> no .dll or .so statically linked, in case this were a thing) > > > My tests with a 4MB library, libraylib_static.a, showed a program with > just one reference to one symbol, resulted in executables from > 2.7-3.0MB, where an empty program is 0.3MB (normal with tdm-gcc). > > If I used the -s option, sizes reduce to 0.02MB (empty) to 0.8-1.0MB > (single reference, including one to an exported variable, not a function). > > So it does seem that it uses granularity of a module at best. It seems > odd though that the linker doesn't by default, exclude that symbol info > which makes a very significant difference, but doesn't, assuming it was > capable, eliminate unused functions. It turns out it's not that trivial, after my earlier reply I decided to double check it, and in fact I had to ask google about it: https://stackoverflow.com/questions/6687630/how-to-remove-unused-c-c-symbols-with-gcc-and-ld In short: compile with -fdata-sections -ffunction-sections link with: --gc-sections (i.e. invoke gcc with -Wl,--gc-sections) I verified that these options do get function level granularity. The fact that it requires cooperation between compiler and linker suggests that there are reasons for which this can't be done by default. MSVC does the same if you make a pair of projects (lib + exec) in the IDE, and it sets the applicable options by default for Release builds. > > > I guess now this is going to be the start of another long subthread > about how this is all my fault; I should read all the docs for tdm-gcc > so that I know how to tell it to /do its job/, how I should just give up > Windows right now, blah blah. I won't start any of this - as I said it's not as trivial as it looks, so it's not anyone's fault. > > But I'm not going there. DB said linkers work a certain way, and I just > posted my observations about how they work a different way. This was > after being called stupid for suggesting that static linking might > result in large executables. > > (Actually, given how huge some applications already are, it would be > scary if that was /after/ all unnecessary functions had been eliminated!)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-31 23:10 +0100 |
| Message-ID | <se4hop$el3$1@dont-email.me> |
| In reply to | #162167 |
On 31/07/2021 20:32, Manfred wrote: > On 7/31/2021 8:17 PM, Bart wrote: >> So it does seem that it uses granularity of a module at best. It seems >> odd though that the linker doesn't by default, exclude that symbol >> info which makes a very significant difference, but doesn't, assuming >> it was capable, eliminate unused functions. > > It turns out it's not that trivial, after my earlier reply I decided to > double check it, and in fact I had to ask google about it: > https://stackoverflow.com/questions/6687630/how-to-remove-unused-c-c-symbols-with-gcc-and-ld > > > In short: > compile with -fdata-sections -ffunction-sections > link with: --gc-sections (i.e. invoke gcc with -Wl,--gc-sections) > > I verified that these options do get function level granularity. To clarify, these options need to be applied to the library in question. If it's a third party library, then presumably you have to depend on the people creating the .a or .lib file to use suitable options. (When I tried it on a small library, it more than doubled the size of the size of the file.)
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-08-01 00:43 +0200 |
| Message-ID | <se4jnf$a30$1@gioia.aioe.org> |
| In reply to | #162173 |
On 8/1/2021 12:10 AM, Bart wrote: > On 31/07/2021 20:32, Manfred wrote: >> On 7/31/2021 8:17 PM, Bart wrote: > >>> So it does seem that it uses granularity of a module at best. It >>> seems odd though that the linker doesn't by default, exclude that >>> symbol info which makes a very significant difference, but doesn't, >>> assuming it was capable, eliminate unused functions. >> >> It turns out it's not that trivial, after my earlier reply I decided >> to double check it, and in fact I had to ask google about it: >> https://stackoverflow.com/questions/6687630/how-to-remove-unused-c-c-symbols-with-gcc-and-ld >> >> >> In short: >> compile with -fdata-sections -ffunction-sections >> link with: --gc-sections (i.e. invoke gcc with -Wl,--gc-sections) >> >> I verified that these options do get function level granularity. > > To clarify, these options need to be applied to the library in question. > > If it's a third party library, then presumably you have to depend on the > people creating the .a or .lib file to use suitable options. Yes, as I wrote earlier, this feature requires the cooperation of the compiler with the linker, if the compiler was not instructed to generate the library code accordingly, you are stuck with object module granularity (as per your earlier findings - I didn't check) > > (When I tried it on a small library, it more than doubled the size of > the size of the file.) > >
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-31 15:54 -0700 |
| Message-ID | <ywkNI.41387$ilwe.10076@fx35.iad> |
| In reply to | #162173 |
On 7/31/21 3:10 PM, Bart wrote: > On 31/07/2021 20:32, Manfred wrote: >> On 7/31/2021 8:17 PM, Bart wrote: > >>> So it does seem that it uses granularity of a module at best. It >>> seems odd though that the linker doesn't by default, exclude that >>> symbol info which makes a very significant difference, but doesn't, >>> assuming it was capable, eliminate unused functions. >> >> It turns out it's not that trivial, after my earlier reply I decided >> to double check it, and in fact I had to ask google about it: >> https://stackoverflow.com/questions/6687630/how-to-remove-unused-c-c-symbols-with-gcc-and-ld >> >> >> In short: >> compile with -fdata-sections -ffunction-sections >> link with: --gc-sections (i.e. invoke gcc with -Wl,--gc-sections) >> >> I verified that these options do get function level granularity. > > To clarify, these options need to be applied to the library in question. > > If it's a third party library, then presumably you have to depend on the > people creating the .a or .lib file to use suitable options. > > (When I tried it on a small library, it more than doubled the size of > the size of the file.) > Yes, to generate the information to allow selective linking adds a lot of meta-data to the object files. That is one reason it normally isn't the default for the compiler, as it assumes that most files being compiled don't have a lot of 'unused' code, so there is no need to generate all the extra meta-data to allow partial linking of the files.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-08-04 13:36 +0200 |
| Message-ID | <sedu47$kbp$1@dont-email.me> |
| In reply to | #162177 |
On 01/08/2021 00:54, Richard Damon wrote: > On 7/31/21 3:10 PM, Bart wrote: >> On 31/07/2021 20:32, Manfred wrote: >>> On 7/31/2021 8:17 PM, Bart wrote: >> >>>> So it does seem that it uses granularity of a module at best. It >>>> seems odd though that the linker doesn't by default, exclude that >>>> symbol info which makes a very significant difference, but doesn't, >>>> assuming it was capable, eliminate unused functions. >>> >>> It turns out it's not that trivial, after my earlier reply I decided >>> to double check it, and in fact I had to ask google about it: >>> https://stackoverflow.com/questions/6687630/how-to-remove-unused-c-c-symbols-with-gcc-and-ld >>> >>> >>> In short: >>> compile with -fdata-sections -ffunction-sections >>> link with: --gc-sections (i.e. invoke gcc with -Wl,--gc-sections) >>> >>> I verified that these options do get function level granularity. >> >> To clarify, these options need to be applied to the library in question. >> >> If it's a third party library, then presumably you have to depend on the >> people creating the .a or .lib file to use suitable options. >> >> (When I tried it on a small library, it more than doubled the size of >> the size of the file.) >> > > Yes, to generate the information to allow selective linking adds a lot > of meta-data to the object files. > It adds section names - nothing more. Instead of the code for "foo" being in the ".text", it is in a ".text.foo" section. You have more sections in the object files (and therefore library, if you combine the object files in a static library), but that's all. Object files already have vast numbers of sections for different types of text, debug data, initialisation data, exception information (for C++), etc. > That is one reason it normally isn't the default for the compiler, as it > assumes that most files being compiled don't have a lot of 'unused' > code, so there is no need to generate all the extra meta-data to allow > partial linking of the files. > That, and backwards compatibility. Running your tools without flags generally gives the same basic unoptimised and limited functionality as it always has, so that everything works the same - most features above the absolute ground level need flags.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-08-04 13:32 +0200 |
| Message-ID | <sedtrl$irb$1@dont-email.me> |
| In reply to | #162164 |
On 31/07/2021 19:33, Manfred wrote: > On 7/31/2021 3:56 PM, Bart wrote: >> On 31/07/2021 12:42, David Brown wrote: >>> 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. >> >> I don't think this is right. > No, it is right. > > My brief experiments seem to show: >> >> * If you link in biglib.o, it will include everything from biglib, >> whether or not used from outside >> >> * If you create biglib.a, and link in biglib.a, it will still include >> everything in biglib, provided at least one export is used elsewhere >> >> But my experiments only covered a .a file made from a single .o file. > > That's the difference. You should test it with a final executable (and a > decent compiler). (btw I assume you didn't mean .a as a linux library, > so what did you mean with .a ?) > >> >> It could be that it works on a granularity of individual object files. >> But even then, if A and B each have 1000 functions, and you use one >> function in A which calls one in B, then 2000 functions will get >> included, not even only 1000. >> >> This is some way from your suggestion that the granularity is at the >> level of individual files, and presumably individual variables. > > That is how static libraries work with decent compilers, the final > executable only gets individual /functions/ (not files, but obviously > all of the function dependencies) and individual variables. Note, stress > is on /static/ libraries (.lib on Windows and .a on Linux, so no .dll or > .so statically linked, in case this were a thing) > Traditionally - since before C existed - the granularity level for static libraries has been the file level. If you look at libraries where it is normal to except applications to want to use only a few functions out of many, such as the standard C library, the source code is typically divided into one file per function. You might have several related functions in a single file (such as sin and cos, or all the printf family), for slightly improved efficiency or speed of linking. This is how static libraries have worked with good and bad compilers, and assemblers, and compilers of different languages, since the concept of separate compiler, assembler, librarian and linker programs was invented. Good tools, such as gcc and clang, have features such as flags to put each function in a separate section, allowing more efficient linking of static libraries (and object code files) without having to split the source up into so many small files. This is not unique to C - I first saw it as "smart linking" in Borland Pascal for DOS. For gcc, you do need to use a few compiler flags, which is difficult for people who have flag allergies and curl into a fetal position at the mention of "build systems" or "makefiles". In more modern times - the last decade or so - link-time optimisation has moved into the mainstream for good general-purpose compilers. That not only cuts out code from static libraries that is not used by the application, but can inline and otherwise optimise code across library boundaries. (In the embedded world, such "compile and link everything at once" toolchains have been used since the nineties at least.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-04 14:24 +0100 |
| Message-ID | <see4ea$uop$1@dont-email.me> |
| In reply to | #162222 |
On 04/08/2021 12:32, David Brown wrote: > On 31/07/2021 19:33, Manfred wrote: >> On 7/31/2021 3:56 PM, Bart wrote: >>> On 31/07/2021 12:42, David Brown wrote: >>>> 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. >>> >>> I don't think this is right. >> No, it is right. >> >> My brief experiments seem to show: >>> >>> * If you link in biglib.o, it will include everything from biglib, >>> whether or not used from outside >>> >>> * If you create biglib.a, and link in biglib.a, it will still include >>> everything in biglib, provided at least one export is used elsewhere >>> >>> But my experiments only covered a .a file made from a single .o file. >> >> That's the difference. You should test it with a final executable (and a >> decent compiler). (btw I assume you didn't mean .a as a linux library, >> so what did you mean with .a ?) >> >>> >>> It could be that it works on a granularity of individual object files. >>> But even then, if A and B each have 1000 functions, and you use one >>> function in A which calls one in B, then 2000 functions will get >>> included, not even only 1000. >>> >>> This is some way from your suggestion that the granularity is at the >>> level of individual files, and presumably individual variables. >> >> That is how static libraries work with decent compilers, the final >> executable only gets individual /functions/ (not files, but obviously >> all of the function dependencies) and individual variables. Note, stress >> is on /static/ libraries (.lib on Windows and .a on Linux, so no .dll or >> .so statically linked, in case this were a thing) >> > Traditionally - since before C existed - the granularity level for > static libraries has been the file level. If you look at libraries > where it is normal to except applications to want to use only a few > functions out of many, such as the standard C library, the source code > is typically divided into one file per function. You might have several > related functions in a single file (such as sin and cos, or all the > printf family), for slightly improved efficiency or speed of linking. > > This is how static libraries have worked with good and bad compilers, > and assemblers, and compilers of different languages, since the concept > of separate compiler, assembler, librarian and linker programs was invented. > > Good tools, such as gcc and clang, have features such as flags to put > each function in a separate section, allowing more efficient linking of > static libraries (and object code files) without having to split the > source up into so many small files. This is not unique to C - I first > saw it as "smart linking" in Borland Pascal for DOS. For gcc, you do > need to use a few compiler flags, which is difficult for people who have > flag allergies and curl into a fetal position at the mention of "build > systems" or "makefiles". > > In more modern times - the last decade or so - link-time optimisation > has moved into the mainstream for good general-purpose compilers. That > not only cuts out code from static libraries that is not used by the > application, but can inline and otherwise optimise code across library > boundaries. (In the embedded world, such "compile and link everything > at once" toolchains have been used since the nineties at least.) > On some environments such as Windows, using function-at-a-time linking instead of DLLs is pointless. In the case of common libraries such as the C runtime, the chances are that other applications are already using them and so they are already in memory. In the case of the file called 'gcc.exe' of my tdm/gcc installation, it was presumably built with all those flags you mentioned, yet it STILL imports msvcrt.dll. (And if not, then why not?) If I use that gcc to build an app, and specify -lucrt to make use of libucrt.a (and whether or not I use -ffunction-sections for my app), the resulting executable STILL imports msvcrt.dll, but now ALSO imports: api-ms-win-crt-environment-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll for good measure. > This is not unique to C - I first > saw it as "smart linking" in Borland Pascal for DOS. For all of the eighties, I wrote all my own libraries, which didn't have many unnecessary functions. My language's runtime was 4-8KB, which included maths functions /and/ floating point emulation. The only external software used was in the OS via INT calls or whatever the mechanism was. There were some optional modules, mainly a choice of drivers (for video, printer etc), but once chosen, you needed the whole module. So there was no need for traditional linking, just a means the assemble and fixup the relevant set of modules. The point is that typical language implementations (apart from your Borland), had linker programs that were hopelessly inefficient, presumably even without that smart linking. I think I'd assumed it was because it was linking a function at a time, now you are suggesting that it was module at a time; so what on earth were they up to? > In more modern times - the last decade or so - link-time optimisation > has moved into the mainstream for good general-purpose compilers. That > not only cuts out code from static libraries that is not used by the Some of us have gotten even more modern and eliminated linking completely from the task of building a set of sources into one .exe or or .dll file. Fixing up references to functions imported from external .dll files is trivial (you add a reference to an import table). For libraries that are available as source code /in the right language/ then, using whole-program compilation, there are easy ways to eliminate unused functions, if it is important (for my stuff, it isn't, as my programs are already tiny). The method requires means to specify boundaries around what are considered to be a self-contained libraries, otherwise the analysis needed is harder.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-08-04 16:08 +0200 |
| Message-ID | <see71a$gk4$1@dont-email.me> |
| In reply to | #162225 |
On 04/08/2021 15:24, Bart wrote: > On 04/08/2021 12:32, David Brown wrote: >> On 31/07/2021 19:33, Manfred wrote: >>> On 7/31/2021 3:56 PM, Bart wrote: >>>> On 31/07/2021 12:42, David Brown wrote: >>>>> 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. >>>> >>>> I don't think this is right. >>> No, it is right. >>> >>> My brief experiments seem to show: >>>> >>>> * If you link in biglib.o, it will include everything from biglib, >>>> whether or not used from outside >>>> >>>> * If you create biglib.a, and link in biglib.a, it will still include >>>> everything in biglib, provided at least one export is used elsewhere >>>> >>>> But my experiments only covered a .a file made from a single .o file. >>> >>> That's the difference. You should test it with a final executable (and a >>> decent compiler). (btw I assume you didn't mean .a as a linux library, >>> so what did you mean with .a ?) >>> >>>> >>>> It could be that it works on a granularity of individual object files. >>>> But even then, if A and B each have 1000 functions, and you use one >>>> function in A which calls one in B, then 2000 functions will get >>>> included, not even only 1000. >>>> >>>> This is some way from your suggestion that the granularity is at the >>>> level of individual files, and presumably individual variables. >>> >>> That is how static libraries work with decent compilers, the final >>> executable only gets individual /functions/ (not files, but obviously >>> all of the function dependencies) and individual variables. Note, stress >>> is on /static/ libraries (.lib on Windows and .a on Linux, so no .dll or >>> .so statically linked, in case this were a thing) >>> >> Traditionally - since before C existed - the granularity level for >> static libraries has been the file level. If you look at libraries >> where it is normal to except applications to want to use only a few >> functions out of many, such as the standard C library, the source code >> is typically divided into one file per function. You might have several >> related functions in a single file (such as sin and cos, or all the >> printf family), for slightly improved efficiency or speed of linking. >> >> This is how static libraries have worked with good and bad compilers, >> and assemblers, and compilers of different languages, since the concept >> of separate compiler, assembler, librarian and linker programs was >> invented. >> >> Good tools, such as gcc and clang, have features such as flags to put >> each function in a separate section, allowing more efficient linking of >> static libraries (and object code files) without having to split the >> source up into so many small files. This is not unique to C - I first >> saw it as "smart linking" in Borland Pascal for DOS. For gcc, you do >> need to use a few compiler flags, which is difficult for people who have >> flag allergies and curl into a fetal position at the mention of "build >> systems" or "makefiles". >> >> In more modern times - the last decade or so - link-time optimisation >> has moved into the mainstream for good general-purpose compilers. That >> not only cuts out code from static libraries that is not used by the >> application, but can inline and otherwise optimise code across library >> boundaries. (In the embedded world, such "compile and link everything >> at once" toolchains have been used since the nineties at least.) >> > > On some environments such as Windows, using function-at-a-time linking > instead of DLLs is pointless. It can result in smaller and faster binaries with fewer dependencies. Often that is a good thing. > > In the case of common libraries such as the C runtime, the chances are > that other applications are already using them and so they are already > in memory. I would expect that a fair proportion of the functions in the C standard library are not going to be in use by any program running on a typical computer. But you are right that this is one DLL that might see a good deal of sharing on Windows (where DLL's, other than system ones, are often not shared as each app has their own copy to avoid versioning problems). And for bigger or slower functions at least, the extra overhead for using a DLL function rather than a local statically linked function will be negligible. > > In the case of the file called 'gcc.exe' of my tdm/gcc installation, it > was presumably built with all those flags you mentioned, yet it STILL > imports msvcrt.dll. (And if not, then why not?) > > If I use that gcc to build an app, and specify -lucrt to make use of > libucrt.a (and whether or not I use -ffunction-sections for my app), the > resulting executable STILL imports msvcrt.dll, but now ALSO imports: > > api-ms-win-crt-environment-l1-1-0.dll > api-ms-win-crt-runtime-l1-1-0.dll > > for good measure. > >> This is not unique to C - I first >> saw it as "smart linking" in Borland Pascal for DOS. > > For all of the eighties, I wrote all my own libraries, which didn't have > many unnecessary functions. My language's runtime was 4-8KB, which > included maths functions /and/ floating point emulation. > You can do that, for your own code. (The same applies to my code - unused functions are very rare.) General libraries and languages for use by many people will always have more functions than any given user or program will need. > The only external software used was in the OS via INT calls or whatever > the mechanism was. > > There were some optional modules, mainly a choice of drivers (for video, > printer etc), but once chosen, you needed the whole module. So there was > no need for traditional linking, just a means the assemble and fixup the > relevant set of modules. > > The point is that typical language implementations (apart from your > Borland), had linker programs that were hopelessly inefficient, > presumably even without that smart linking. > > I think I'd assumed it was because it was linking a function at a time, > now you are suggesting that it was module at a time; so what on earth > were they up to? General-purpose linkers worked on one object file at a time, and static libraries are basically just a collection of object files. Borland was in a position to control the language, compiler, linker, object file format, library file format - the whole process. So they were able to make a more efficient system. (I fully agree with you that the whole "compile to assembly, assemble to object file, then link object files" process is inefficient and limited. It is the result of compromises and limitations from a bygone day of more limited host computers, and from trying to make something that will work across a range of tools and languages.) > >> In more modern times - the last decade or so - link-time optimisation >> has moved into the mainstream for good general-purpose compilers. That >> not only cuts out code from static libraries that is not used by the > > Some of us have gotten even more modern and eliminated linking > completely from the task of building a set of sources into one .exe or > or .dll file. If you have more than one source file or static object files or static libraries, you are linking. > > Fixing up references to functions imported from external .dll files is > trivial (you add a reference to an import table). > > For libraries that are available as source code /in the right language/ > then, using whole-program compilation, there are easy ways to eliminate > unused functions, if it is important (for my stuff, it isn't, as my > programs are already tiny). > > The method requires means to specify boundaries around what are > considered to be a self-contained libraries, otherwise the analysis > needed is harder.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-04 16:32 +0100 |
| Message-ID | <seebtt$jrq$1@dont-email.me> |
| In reply to | #162226 |
On 04/08/2021 15:08, David Brown wrote: > On 04/08/2021 15:24, Bart wrote: >> Some of us have gotten even more modern and eliminated linking >> completely from the task of building a set of sources into one .exe or >> or .dll file. > > If you have more than one source file or static object files or static > libraries, you are linking. Not with languages designed for whole-program compilation as mine now are. For references outside the program, then using DLLs, there is no actual 'linking' either (at best, a process which has to search DLLs looking for where functions reside, but that info can also be provided by directives). The physical linking process is defered until execution, and there, for PE format files, it is mainly filling in addresses in tables. On my largest app, this process takes no longer than it does with hello.exe (or at least, can't be measured). With languages like C, it's hard to get around independent compilation of modules, so a linking stage is necessary. But even here, I don't use a traditional linker: I process in-memory .asm files, and fix up symbol references across modules. There are no object files and no discrete linker. (I may soon be simplifying that process further for languages that need separate compilation.) Another area where you really need to use DLLs is with interpreted languages where static linking is meaningless, or would get extremely hairy even if all the info was available at compile-time.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-04 16:33 +0000 |
| Message-ID | <CjzOI.1030$Bg6.61@fx42.iad> |
| In reply to | #162228 |
Bart <bc@freeuk.com> writes: >On 04/08/2021 15:08, David Brown wrote: >> On 04/08/2021 15:24, Bart wrote: > >>> Some of us have gotten even more modern and eliminated linking >>> completely from the task of building a set of sources into one .exe or >>> or .dll file. >> >> If you have more than one source file or static object files or static >> libraries, you are linking. > >Not with languages designed for whole-program compilation as mine now are. I would call that a defect, not a feature. If it takes an hour to recompile after a single change to a single file, it's useless; although I suspect you've never tried to compile a project with millions of lines of code. And in any case, the software development infrastructure that has been developed over the past five decades isn't going to change to cater to your whims.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-04 18:40 +0100 |
| Message-ID | <seejf8$9ti$1@dont-email.me> |
| In reply to | #162230 |
On 04/08/2021 17:33, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 04/08/2021 15:08, David Brown wrote: >>> On 04/08/2021 15:24, Bart wrote: >> >>>> Some of us have gotten even more modern and eliminated linking >>>> completely from the task of building a set of sources into one .exe or >>>> or .dll file. >>> >>> If you have more than one source file or static object files or static >>> libraries, you are linking. >> >> Not with languages designed for whole-program compilation as mine now are. > > I would call that a defect, not a feature. > > If it takes an hour to recompile after a single change to a single file, If it takes a hour to compile, say, 5M lines of code, then your throughput is 1.4Klines/second, which is very poor. My own compiler, unoptimised, works 200-250 times faster than that on a low-end PC, on a language that is also somewhat challenging to compile so needs extra passes. A compiler like tcc, at the speed it works with C, would be 2-3 times as fast. So 5M lines might take well under 10 seconds, or 15 seconds on mine, on my PC. Expect better figures on a high-end PC, even with one core. That's without exploiting opportunities to use multiple cores (although parallelising is harder), or reusing data structures from a prior build. But I don't need to do that, because my projects are typically 99% smaller. > it's useless; although I suspect you've never tried to compile a > project with millions of lines of code. The only difference is the granularity of the compilation unit moves from a module to a program. But the 'program' is defined as being a single executable or library file. An application can be multiple executables and libraries, and can comprise also script code. A properly designed application shouldn't be too monolithic, not when developing. Although nothing stops a built application from being tidily installed as a single file; then it doesn't matter. It can even masquerade as a single .exe. > And in any case, the software development infrastructure that has > been developed over the past five decades isn't going to change > to cater to your whims. The infrastructure has been getting slower, especially with tools based around LLVM. (On one test, Rustc was 80,000 times slower - estimated as I couldn't wait 22 hours - than Tiny C.) Note that many languages are run from source anyway, like most scripting ones. Then, even if some will be compiled on demand, a 10M line application will still mean compiling 10M lines from source. So the same 'problem' (although bytecode compilers might be twice as fast).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-04 19:31 +0100 |
| Message-ID | <seemeq$jb$1@dont-email.me> |
| In reply to | #162236 |
On 04/08/2021 18:40, Bart wrote: > On 04/08/2021 17:33, Scott Lurndal wrote: >> it's useless; although I suspect you've never tried to compile a >> project with millions of lines of code. > But the 'program' is defined as being a single executable or library > file. An application can be multiple executables and libraries, and can > comprise also script code. > > A properly designed application shouldn't be too monolithic, not when > developing. Although nothing stops a built application from being tidily > installed as a single file; then it doesn't matter. It can even > masquerade as a single .exe. I've surveyed the EXE and DLL files on my machine. There are 50,000 in all. The largest are DLL files belonging programs like processor, at up to 170MB. But 99% of them are under 10MB. On this machine, a fast non-optimising compiler can generate binary code at about 2MB/s second. So 99% of these files could be built in under 5 seconds, 95% in under 2 seconds, and 85% in half a second. Even that 170MB would take under 90 seconds, nowhere near an hour. Although it would probably need sufficient resources. Optimised code would take a bit longer, but this is a good starting point. It shows that whole-program compilers can be entirely viable for a large proportion of applications.
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2021-08-07 10:03 -0400 |
| Message-ID | <WowPI.4743$NQ1.1007@fx48.iad> |
| In reply to | #162236 |
On 8/4/2021 1:40 PM, Bart wrote: > A compiler like tcc, at the speed it works with C, would be 2-3 times as > fast. So 5M lines might take well under 10 seconds, or 15 seconds on > mine, on my PC. Expect better figures on a high-end PC, even with one core. I recently installed the WinLibs build of gcc for Windows https://winlibs.com I compiled a 900-line file using tcc 0.9.27 and the winlibs gcc 11.2.0 for Windows. The gcc executable is 6.8x larger, and the printf() parts of the code run like a dog vs tcc. Kind of a bust, as I like snappy code. ------------------------------------------------------------------------------ $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=d:/computer/apps/compilers/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/11.2.0/lto-wrapper.exe OFFLOAD_TARGET_NAMES=nvptx-none Target: x86_64-w64-mingw32 Configured with: ../configure --prefix=/R/winlibs64_stage/inst_gcc-11.2.0/share/gcc --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64 x86_64-posix-seh, built by Brecht Sanders' --with-tune=generic --enable-checking=release --enable-threads=posix --disable-sjlj-exceptions --disable-libunwind-exceptions --disable-serial-configure --disable-bootstrap --enable-host-shared --enable-plugin --disable-default-ssp --disable-rpath --enable-libstdcxx-pch --enable-libstdcxx-time=yes --disable-libstdcxx-debug --disable-version-specific-runtime-libs --with-stabs --disable-symvers --enable-languages=c,c++,fortran,lto,objc,obj-c++,d,jit --disable-gold --disable-nls --disable-stage1-checking --disable-win32-registry --disable-multilib --enable-ld --enable-libquadmath --enable-libada --enable-libssp --enable-libstdcxx --enable-lto --enable-fully-dynamic-string --enable-libgomp --enable-graphite --enable-mingw-wildcard --with-mpc=/d/Prog/winlibs64_stage/custombuilt --with-mpfr=/d/Prog/winlibs64_stage/custombuilt --with-gmp=/d/Prog/winlibs64_stage/custombuilt --with-isl=/d/Prog/winlibs64_stage/custombuilt --enable-install-libiberty --enable-__cxa_atexit --without-included-gettext --with-diagnostics-color=auto --enable-clocale=generic --with-libiconv --with-system-zlib --with-build-sysroot=/R/winlibs64_stage/gcc-11.2.0/build_mingw/mingw-w64 CFLAGS=-I/d/Prog/winlibs64_stage/custombuilt/include/libdl-win32 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.2.0 (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders) ------------------------------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-07 17:11 +0100 |
| Message-ID | <sembba$oul$1@dont-email.me> |
| In reply to | #162245 |
On 07/08/2021 15:03, DFS wrote:
> On 8/4/2021 1:40 PM, Bart wrote:
>
>
>> A compiler like tcc, at the speed it works with C, would be 2-3 times
>> as fast. So 5M lines might take well under 10 seconds, or 15 seconds
>> on mine, on my PC. Expect better figures on a high-end PC, even with
>> one core.
>
>
> I recently installed the WinLibs build of gcc for Windows
>
> https://winlibs.com
>
> I compiled a 900-line file using tcc 0.9.27 and the winlibs gcc 11.2.0
> for Windows.
>
> The gcc executable is 6.8x larger, and the printf() parts of the code
> run like a dog vs tcc. Kind of a bust, as I like snappy code.
Trying compiling with -s option, which omits symbols from the executable.
I'm surprised printf (is that to the screen or directed to a file?) is
slower; that should be little to do with the generated code.
All these big compilers run like dogs, but the generated code is
supposed to be faster.
On my machine, gcc-O3 version 11 compiled one of my 43Kloc programs (an
interpreter) in 22 seconds.
tcc did it in 0.15 seconds; 150 times faster.
But when I ran the result on a test input, the gcc-O3-generated program
took nearly 17 seconds, tcc took 35 seconds, just over twice as long:
Compile-speed Runtime
gcc 1.0 1.0
tcc 146.0 2.1
Bigger=better smaller=better
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2021-08-08 08:51 -0400 |
| Message-ID | <CrQPI.669$bS5.239@fx21.iad> |
| In reply to | #162246 |
On 8/7/2021 12:11 PM, Bart wrote:
> On 07/08/2021 15:03, DFS wrote:
>> On 8/4/2021 1:40 PM, Bart wrote:
>>
>>
>>> A compiler like tcc, at the speed it works with C, would be 2-3 times
>>> as fast. So 5M lines might take well under 10 seconds, or 15 seconds
>>> on mine, on my PC. Expect better figures on a high-end PC, even with
>>> one core.
>>
>>
>> I recently installed the WinLibs build of gcc for Windows
>>
>> https://winlibs.com
>>
>> I compiled a 900-line file using tcc 0.9.27 and the winlibs gcc 11.2.0
>> for Windows.
>>
>> The gcc executable is 6.8x larger, and the printf() parts of the code
>> run like a dog vs tcc. Kind of a bust, as I like snappy code.
>
> Trying compiling with -s option, which omits symbols from the executable.
That cut the size in half. Cool. Now it's only 3x as large as the tcc
.exe.
> I'm surprised printf (is that to the screen or directed to a file?) is
> slower; that should be little to do with the generated code.
It's to the screen. Only thing slightly different than usual is using a
width wildcard:
printf("%-*s ", longword, matchwords[i]);
I replaced it with a hardcoded value but it made no difference.
printf("%-16s ", matchwords[i]);
The gcc-Windows compiled version does printf() at 1/4 the speed of tcc.
> All these big compilers run like dogs, but the generated code is
> supposed to be faster.
Most everything but the printf() is just as fast as tcc, maybe a tad faster.
My mind is still boggled by the speed of some C programs.
On my old i5-750 system this program finds N strlen() matches out of
370K words in 33/1000ths of a second:
for(i=0;i<wordcnt;i++) {
if(strlen(words[i]) == atoi(&str[0])) {
matches++;
}
}
I moved the atoi() call out of the loop and the speed increased by 135%,
to 14/1000ths of a second!
int tlen = atoi(&str[0]);
for(i=0;i<wordcnt;i++) {
if(strlen(words[i]) == tlen) {
matches++;
}
}
Incredible.
> On my machine, gcc-O3 version 11 compiled one of my 43Kloc programs (an
> interpreter) in 22 seconds.
>
> tcc did it in 0.15 seconds; 150 times faster.
>
> But when I ran the result on a test input, the gcc-O3-generated program
> took nearly 17 seconds, tcc took 35 seconds, just over twice as long:
>
>
> Compile-speed Runtime
> gcc 1.0 1.0
> tcc 146.0 2.1
>
> Bigger=better smaller=better
How about the size of the executable?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-08 15:41 +0100 |
| Message-ID | <seoqf4$pj7$1@dont-email.me> |
| In reply to | #162247 |
On 08/08/2021 13:51, DFS wrote:
> On 8/7/2021 12:11 PM, Bart wrote:
>> On 07/08/2021 15:03, DFS wrote:
>>> On 8/4/2021 1:40 PM, Bart wrote:
>>>
>>>
>>>> A compiler like tcc, at the speed it works with C, would be 2-3
>>>> times as fast. So 5M lines might take well under 10 seconds, or 15
>>>> seconds on mine, on my PC. Expect better figures on a high-end PC,
>>>> even with one core.
>>>
>>>
>>> I recently installed the WinLibs build of gcc for Windows
>>>
>>> https://winlibs.com
>>>
>>> I compiled a 900-line file using tcc 0.9.27 and the winlibs gcc
>>> 11.2.0 for Windows.
>>>
>>> The gcc executable is 6.8x larger, and the printf() parts of the code
>>> run like a dog vs tcc. Kind of a bust, as I like snappy code.
>>
>> Trying compiling with -s option, which omits symbols from the executable.
>
> That cut the size in half. Cool. Now it's only 3x as large as the tcc
> .exe.
>
What are the actual sizes? Because tcc compiles hello.c to 2KB, gcc to
47KB, as it contains more built-in stuff (eg. printf in gcc is a wrapper
function around vprintf).
>> I'm surprised printf (is that to the screen or directed to a file?) is
>> slower; that should be little to do with the generated code.
>
> It's to the screen. Only thing slightly different than usual is using a
> width wildcard:
>
> printf("%-*s ", longword, matchwords[i]);
>
> I replaced it with a hardcoded value but it made no difference.
>
> printf("%-16s ", matchwords[i]);
>
>
> The gcc-Windows compiled version does printf() at 1/4 the speed of tcc.
You're right; this program:
#include <stdio.h>
int main(void) {
for (int i=0; i<10000; ++i)
printf("%-16s","1234567890"); // no newlines
}
runs in 3 seconds with tcc. With gcc, 21 seconds, even optimised. I've
never noticed before.
My bcc compiler, which also calls printf in msvcrt, does it in 2.3
seconds for some reason. lccwin is 15 seconds, DM 2.7. MSVC is 2.7 too.
Clang is 21 seconds (which is taking being a gcc clone to extremes).
All very strange. I don't know how much this is important, or how much
text you're printing to the screen, since 500 printfs per second is
still faster than anyone can read it. The problem disappears if you
redirect to a file.
You can try bypassing printf in gcc by using sprintf to a string for a
complete line of output, then using puts() on the string. However you
shouldn't need to do this.
> I moved the atoi() call out of the loop and the speed increased by 135%,
> to 14/1000ths of a second!
>
> int tlen = atoi(&str[0]);
> for(i=0;i<wordcnt;i++) {
> if(strlen(words[i]) == tlen) {
> matches++;
> }
> }
>
>
> Incredible.
Here it might be an idea to calculate strlen() on each word once, and
store the lengths in a table (this could be done while reading the text
file). Then strlen() will be outside the loop too.
>
>
>
>> On my machine, gcc-O3 version 11 compiled one of my 43Kloc programs
>> (an interpreter) in 22 seconds.
>>
>> tcc did it in 0.15 seconds; 150 times faster.
>>
>> But when I ran the result on a test input, the gcc-O3-generated
>> program took nearly 17 seconds, tcc took 35 seconds, just over twice
>> as long:
>>
>>
>> Compile-speed Runtime
>> gcc 1.0 1.0
>> tcc 146.0 2.1
>>
>> Bigger=better smaller=better
>
>
> How about the size of the executable?
About the same, comparing tcc with gcc-O0 (857/853KB). gcc-O3 made a
bigger executable (925KB). The differences are bigger than they appear
since half the size here is embedded string literals.
But still, not significant in this case. (Maybe there is a gcc option to
optimise for size, but I don't know what it is.)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-08-08 17:12 +0000 |
| Message-ID | <20210808094716.771@kylheku.com> |
| In reply to | #162248 |
On 2021-08-08, Bart <bc@freeuk.com> wrote: > My bcc compiler, which also calls printf in msvcrt, does it in 2.3 > seconds for some reason. lccwin is 15 seconds, DM 2.7. MSVC is 2.7 too. > Clang is 21 seconds (which is taking being a gcc clone to extremes). The printf MSVCRT.DLL may be fast, but it's still an undocumented system component. Microsoft could make it disappear tomorrow, or introduce some breaking change. A few FOSS people moaning and groaning isn't going to stop a roll-out of a new version of Windows that breaks or removes MSVCRT.DLL. > All very strange. How is it strange that one printf implementation has different performance characteristics from a completely different printf implementation? > I don't know how much this is important, or how much > text you're printing to the screen, since 500 printfs per second is > still faster than anyone can read it. The problem disappears if you > redirect to a file. Might it be that, similarly to the Cygwin DLL, this library does some "cooking" of its console streams? I know that the Cygwin DLL does. In Cygwin, all input and output on console descriptors passes through a software layer which: - simulates a POSIX TTY device: tcgetattr, tcsetattr, ... - interprets ANSI/VT100 escape sequences, converting them into Console API calls, on both input and output. This means that POSIX code which controls the terminal with termios, and/or which uses hard-coded ANSI escape sequences will work. The MSVCRT.DLL printf will not do anything like this for you. It's pretty necessary for porting some POSIX programs to Windows, though, without the huge hassle of rewriting their TTY related code into Console API calls. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
Page 8 of 20 — ← Prev page 1 … 6 7 [8] 9 10 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web