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 15 of 20 — ← Prev page 1 … 13 14 [15] 16 17 … 20 Next page →
| From | Ike Naar <ike@rie.sdf.org> |
|---|---|
| Date | 2021-08-09 05:46 +0000 |
| Message-ID | <slrnsh1g90.c0p.ike@rie.sdf.org> |
| In reply to | #162248 |
On 2021-08-08, Bart <bc@freeuk.com> wrote:
> On 08/08/2021 13:51, DFS wrote:
>> 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.
It might depend on whether the output stream is buffered or not.
I'd expect output to the console to be unbuffered.
What happens if you change it to fully buffered, adding
setvbuf(stdout, NULL, _IOFBF, 0);
at the start of the program?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2021-08-09 01:38 -0700 |
| Message-ID | <45070459-0768-4e68-8ea7-0f115c2180e4n@googlegroups.com> |
| In reply to | #162264 |
On Monday, August 9, 2021 at 8:46:20 AM UTC+3, Ike Naar wrote:
> On 2021-08-08, Bart <b...@freeuk.com> wrote:
> > On 08/08/2021 13:51, DFS wrote:
> >> 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.
> It might depend on whether the output stream is buffered or not.
> I'd expect output to the console to be unbuffered.
> What happens if you change it to fully buffered, adding
>
> setvbuf(stdout, NULL, _IOFBF, 0);
>
> at the start of the program?
Such addition changes nothing.
But setvbuf(stdout, NULL, _IOFBF, 512); cuts the run time from 6 sec down to 170-300 msec.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2021-08-09 01:57 -0700 |
| Message-ID | <e9378781-ac20-434a-84cc-e6a4c3f26953n@googlegroups.com> |
| In reply to | #162266 |
On Monday, August 9, 2021 at 11:38:43 AM UTC+3, Michael S wrote:
> On Monday, August 9, 2021 at 8:46:20 AM UTC+3, Ike Naar wrote:
> > On 2021-08-08, Bart <b...@freeuk.com> wrote:
> > > On 08/08/2021 13:51, DFS wrote:
> > >> 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.
> > It might depend on whether the output stream is buffered or not.
> > I'd expect output to the console to be unbuffered.
> > What happens if you change it to fully buffered, adding
> >
> > setvbuf(stdout, NULL, _IOFBF, 0);
> >
> > at the start of the program?
> Such addition changes nothing.
> But setvbuf(stdout, NULL, _IOFBF, 512); cuts the run time from 6 sec down to 170-300 msec.
BTW, by setting setvbuf(stdout, NULL, _IONBF, 0); I was able to reproduce a "slow" behaviour with Microsoft's dev tools.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-09 10:55 +0100 |
| Message-ID | <sequ22$55f$2@dont-email.me> |
| In reply to | #162264 |
On 09/08/2021 06:46, Ike Naar wrote:
> On 2021-08-08, Bart <bc@freeuk.com> wrote:
>> On 08/08/2021 13:51, DFS wrote:
>>> 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.
>
> It might depend on whether the output stream is buffered or not.
> I'd expect output to the console to be unbuffered.
> What happens if you change it to fully buffered, adding
>
> setvbuf(stdout, NULL, _IOFBF, 0);
>
> at the start of the program?
>
No, only if I use 512 instead of 0 as posted elsewhere.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-08-04 11:48 -0400 |
| Message-ID | <5c69db6a-2415-1277-51d2-735aaafaf626@alumni.caltech.edu> |
| In reply to | #162226 |
On 8/4/21 10:08 AM, David Brown wrote: > 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: ... > 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 think it made sense, and still makes sense, to create multi-function modules if the multiple functions are so closely related to each other that they are guaranteed (or nearly so) to all be used by any program that uses any one of them. For instance, fopen() could be bundled together with fclose().
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-08-04 19:34 +0200 |
| Message-ID | <seej3k$4jj$1@dont-email.me> |
| In reply to | #162229 |
On 04/08/2021 17:48, James Kuyper wrote: > On 8/4/21 10:08 AM, David Brown wrote: >> 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: > ... >> 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 think it made sense, and still makes sense, to create multi-function > modules if the multiple functions are so closely related to each other > that they are guaranteed (or nearly so) to all be used by any program > that uses any one of them. For instance, fopen() could be bundled > together with fclose(). > Agreed.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2021-07-31 19:18 +0000 |
| Message-ID | <se47ms$df3$1@z-news.wcss.wroc.pl> |
| In reply to | #162163 |
Bart <bc@freeuk.com> 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.
David presented too rosy picture (more below). But your tests
ignore how things are supposed to work, so only say something
about you, not about size of statically linked libraries.
> My brief experiments seem to show:
>
> * If you link in biglib.o, it will include everything from biglib,
> whether or not used from outside
That is traditional behaviour of linkers, no surprize here.
> * 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
Again no suprize.
> But my experiments only covered a .a file made from a single .o file.
Yes, that big mistake. Traditional .a library is supposed to have
.o file per function, then you linker includes only function that
you include directly or indirectly.
> 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,
Yes. A lot of folks dislkied idea of splitting library into thousends
of small .c files in order to get separate .o files. Reasonably modern
version of gcc support '-ffunction-sections' option, which means
that each function will be a separate "unit" for linker (otherwise
whole .o file would be a unit). You need to compile all files
going into library using this option. When linking program
you need to use '--gc-sections' option. Both options together
work and may give desired result.
But there are traps. Probably biggest trap is OO code. In such
code typically each object has table of methods. If you use
object linker normally will pull table of methods and consequently
will pull _all_ methods for given object, even if you use
only one (possibly trivial) method. Each method will pull
object that they use. If you have inhertance chain and use
most specialized object linker will amist surely pull whole
inhertance chain. So in OO library with say 100 classes and
5000 methods as little as 10 methods may easily pull majority
of the library. Another trap is that function that you need
may have extra functionality that you do not need but which
will pull other things as dependencies. Notable example is
that function my detect errors. Even if you usage never leads
to errors such function will pull error handling support (for
example 'printf' to print error message). I have limited
knowledge about Windows API, but it is resonable to suspect
that that using just few functions could pull quite a lot
of code.
> 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?)
Here you completely messed up things: static linking does not
require position-independent code. In fact, one modtivation
for static linking is that position-dependent code is few
percent faster, so with static linking you can squese some
extra performance when it metters.
Concerning function size and relocations: that is contained
in .o file (apropriate tables are build by assembler).
I find it curious that somebody boasts about writing an
assembler, but apparently does not know what should go
into .o file...
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-31 22:35 +0100 |
| Message-ID | <se4fnl$ujs$1@dont-email.me> |
| In reply to | #162166 |
On 31/07/2021 20:18, antispam@math.uni.wroc.pl wrote: > Bart <bc@freeuk.com> wrote: >> I don't think this is right. > > David presented too rosy picture (more below). But your tests > ignore how things are supposed to work, so only say something > about you, not about size of statically linked libraries. > >> My brief experiments seem to show: >> >> * If you link in biglib.o, it will include everything from biglib, >> whether or not used from outside > > That is traditional behaviour of linkers, no surprize here. > >> * 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 > > Again no suprize. > >> But my experiments only covered a .a file made from a single .o file. > > Yes, that big mistake. Traditional .a library is supposed to have > .o file per function, then you linker includes only function that > you include directly or indirectly. > >> 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, > > Yes. A lot of folks dislkied idea of splitting library into thousends > of small .c files in order to get separate .o files. Because it's plainly crazy. > Reasonably modern > version of gcc support '-ffunction-sections' option, which means > that each function will be a separate "unit" for linker (otherwise > whole .o file would be a unit). You need to compile all files > going into library using this option. When linking program > you need to use '--gc-sections' option. Both options together > work and may give desired result. So presumably that wasn't done with that libraylib_static.a library that I used? See, you don't have control over the libraries that other people distribute. > But there are traps. Probably biggest trap is OO code. In such > code typically each object has table of methods. If you use > object linker normally will pull table of methods and consequently > will pull _all_ methods for given object, even if you use > only one (possibly trivial) method. Each method will pull > object that they use. If you have inhertance chain and use > most specialized object linker will amist surely pull whole > inhertance chain. So in OO library with say 100 classes and > 5000 methods as little as 10 methods may easily pull majority > of the library. Another trap is that function that you need > may have extra functionality that you do not need but which > will pull other things as dependencies. Notable example is > that function my detect errors. Even if you usage never leads > to errors such function will pull error handling support (for > example 'printf' to print error message). I have limited > knowledge about Windows API, but it is resonable to suspect > that that using just few functions could pull quite a lot > of code. > >> 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?) > > Here you completely messed up things: static linking does not > require position-independent code. Hmm, yes it does, at least on x64 architecture. A CALL to another function normally uses a relative offset. You can't just extract functions and move them about without invalidating those offsets. And doing that requires being able to precisely track what is code and what is data (even in executable memory). Another factor is being able to extract global variables, which are usually accessed by absolute addresses. Put them somewhere else, and now you /need/ relocation data to fix up all the references. (DLL files will have that info, but are intended for moving the entirely library, not individual blocks of functions or data.) In fact, one modtivation > for static linking is that position-dependent code is few > percent faster, so with static linking you can squese some > extra performance when it metters. > > Concerning function size and relocations: that is contained > in .o file (apropriate tables are build by assembler). > I find it curious that somebody boasts about writing an > assembler, but apparently does not know what should go > into .o file... This is nonsense, at least for COFF files. Tell me whereabouts function sizes are stored in that file format. It can only infer the sizes by analysing the start addresses of all the functions, and then it might be stuck on the last one, or where data is intermingled. That is too haphazard an approach to use reliably. David Brown creates applications for small devices so he has to pull out all the stops, use all possible options to keep things compact. But my desktop PC already has nearly 40,000 DLL files, totalling 25GB, belong to the system or to installed programs. If static linking of third party libraries was such a great idea, then I would hardly ever see DLL files! Archive files have lots of problems: * Each library must issue them for multiple languages/compilers/formats (raylib provides seprate versions for tcc and gcc, plus .dll that works with anything) * Each language implementation must come with 1000s of archive files for misc libraries * Any updates (breaking changes is a separate topic) means generating multiple new versions, and updating every language installation that bundles .a files * Whether a smaller executable is actually achieved depends on how the library vendor built the library * If most of a library is used anyway, then multiple applications using the same library will duplicate it on disk and in memory DLLs solve a lot of those: * The vendor provides one file that works with any compiler and any language * No need to bundle with every compiler * Only one copy of the library on any one machine * Updates can benefit applications without recompiling or reinstalling
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2021-07-31 23:51 +0000 |
| Message-ID | <se4nm2$rnl$1@z-news.wcss.wroc.pl> |
| In reply to | #162172 |
Bart <bc@freeuk.com> wrote:
> On 31/07/2021 20:18, antispam@math.uni.wroc.pl wrote:
> > Bart <bc@freeuk.com> wrote:
>
> > Reasonably modern
> > version of gcc support '-ffunction-sections' option, which means
> > that each function will be a separate "unit" for linker (otherwise
> > whole .o file would be a unit). You need to compile all files
> > going into library using this option. When linking program
> > you need to use '--gc-sections' option. Both options together
> > work and may give desired result.
>
> So presumably that wasn't done with that libraylib_static.a library that
> I used?
Possibly. As I wrote, there are traps and even if you use
proper compiler and linker options the result may be disappointing.
> See, you don't have control over the libraries that other people distribute.
>
>
> > But there are traps. Probably biggest trap is OO code. In such
> > code typically each object has table of methods. If you use
> > object linker normally will pull table of methods and consequently
> > will pull _all_ methods for given object, even if you use
> > only one (possibly trivial) method. Each method will pull
> > object that they use. If you have inhertance chain and use
> > most specialized object linker will amist surely pull whole
> > inhertance chain. So in OO library with say 100 classes and
> > 5000 methods as little as 10 methods may easily pull majority
> > of the library. Another trap is that function that you need
> > may have extra functionality that you do not need but which
> > will pull other things as dependencies. Notable example is
> > that function my detect errors. Even if you usage never leads
> > to errors such function will pull error handling support (for
> > example 'printf' to print error message). I have limited
> > knowledge about Windows API, but it is resonable to suspect
> > that that using just few functions could pull quite a lot
> > of code.
> >
> >> 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?)
> >
> > Here you completely messed up things: static linking does not
> > require position-independent code.
>
> Hmm, yes it does, at least on x64 architecture.
>
> A CALL to another function normally uses a relative offset. You can't
> just extract functions and move them about without invalidating those
> offsets. And doing that requires being able to precisely track what is
> code and what is data (even in executable memory).
Do you know what position-independent code means? And what static
linking means? With static linking relative positions of various
parts of executable are fixed at link time. Frequently also
absolute positions are fixed at link time, but for example DOS
exe format contained relocation info so absolute positions were
fixed only at load time. And yes, after static linking linking
you can not move code around, unless (like DOS) you keep
relocation tables. During link you use relocation tables, so
linker moves sections around and adjusts addresses using
relocation tables.
FYI, position-idependent code is different: after link you
get a blob which uses only relative addresses inside blob.
If for some reason relative addressing is inadeqater (say
machine does not support PC-relative addressing mode),
then position-idependent code uses extra register containing
its location in memory. So for internal references you can
put the blob anywhere in address space and it will work the
same. There is trouble with external references. External
references are all replaced by indirect references via a
table. This table is filled by dynamic linker, based on
_dynamic_ relocation tables. Table of external references
is usually much smaller than code, so gain with
position-idependent independent code is that you can keep
one copy of executable part in memory and use it for
many programs (variables and table of external references
are separate in each program). You need position-idependent
code when you want shared libraries or dynamic linking
without upleasent restrictions. Main point here is that
for sane sharing you do not want to touch executable
part of library, so you can not do relocations on load.
With static linking addresses are fixed, either after
link proper or after applying relocations (which
modifies code). Since addresses are fixed there
is no need for position-idependent code.
> Another factor is being able to extract global variables, which are
> usually accessed by absolute addresses. Put them somewhere else, and now
> you /need/ relocation data to fix up all the references.
With static linking addresses are known when whole linking process
is finished (logically on DOS linking process is finshed only
after load). In particular after linking proces you no longer can
"Put them somewhere else". Relative addresses of global variables
can not change after link proper, on Linux also absolute addresses
can not change after link.
> (DLL files will have that info, but are intended for moving the entirely
> library, not individual blocks of functions or data.)
Yes, Windows i386 DLL-s used static linking with relocation info
for adjusting start address of library at load time. And relocation
was applied to the whole library. This is very unlike what ELF
on Linux is doing: Linux shared libraries need position-independent
code, unlike i386 Windows DLL-s. IIUC also 64-bit Windows DLL
work like Linux ones and need position-independent code.
>
> In fact, one modtivation
> > for static linking is that position-dependent code is few
> > percent faster, so with static linking you can squese some
> > extra performance when it metters.
> >
> > Concerning function size and relocations: that is contained
> > in .o file (apropriate tables are build by assembler).
> > I find it curious that somebody boasts about writing an
> > assembler, but apparently does not know what should go
> > into .o file...
>
> This is nonsense, at least for COFF files. Tell me whereabouts function
> sizes are stored in that file format. It can only infer the sizes by
> analysing the start addresses of all the functions, and then it might be
> stuck on the last one, or where data is intermingled.
I do not understand your fixation on function size. Linker works
with sections and relocates sections as a whole. If you want
functions than use '-ffunction-sections', then section size
will be the same as function size. Concerning COFF, I do not
know if it supports multiple sections in single .o (or .obj if
you prefer) file. If not, then we are back to splitting files
so that single .o file contains exactly one function. I would
hope that Windows COFF (there are a lot of variants of COFF,
but you probably only care about Windows) adapted to modern
trends, but I had no reason to check this.
Bottom lines is that linker works on section, which in primitive
systems may be limited to whole .o file. Each section contains
table of exported addresses, imported ones and table of needed
relocations. Linker moves _sections_ (that is why without
'-ffunction-sections' (explicit or possibly as default for some
target) linker can not eliminate part of section, this is all
-or-nothing business.
> That is too
> haphazard an approach to use reliably.
Well, for reliable results one do not use random binary libraries
from Internet. One either fetches sources and compiles them
with needed options or at least inspects binaries (objdump -h
will tell you which sections are in a library). For example,
when I created file containing 3 functions and compiled it
using '-ffunction-sections' I get from objedump:
....
3 .text.f_id 00000003 0000000000000000 0000000000000000 00000040 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
4 .text.f_a1 00000003 0000000000000000 0000000000000000 00000043 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
5 .text.f_a2 00000003 0000000000000000 0000000000000000 00000046 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
....
so there are 3 sections, 1 for each function. When I omit
'-ffunction-sections' I get
0 .text 00000009 0000000000000000 0000000000000000 00000040 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
....
that is single code section.
> David Brown creates applications for small devices so he has to pull out
> all the stops, use all possible options to keep things compact.
>
> But my desktop PC already has nearly 40,000 DLL files, totalling 25GB,
> belong to the system or to installed programs.
>
> If static linking of third party libraries was such a great idea, then I
> would hardly ever see DLL files!
I do not advocate using static linking, but in some (rare) situations
it can be helpful. Cretainly not a normal approach on desktop system.
>
> Archive files have lots of problems:
>
> * Each library must issue them for multiple languages/compilers/formats
> (raylib provides seprate versions for tcc and gcc, plus .dll that works
> with anything)
That is independent issue having little to do with static versus
dynamic. If you "standarize" on "one true toolchain" than you
can use single format. OTOH, AFAIK you can install alternative
DLL loaders in Windows, so if you wish you can have as many
dll formats as you wish.
> * Each language implementation must come with 1000s of archive files for
> misc libraries
Convince your vendors to use single standard format. Drop vendors
that do not agree.
> * Any updates (breaking changes is a separate topic) means generating
> multiple new versions, and updating every language installation that
> bundles .a files
Any change requires proper management. Again, choose your vendors...
> * Whether a smaller executable is actually achieved depends on how the
> library vendor built the library
I hope that we agreed that small size of static executable is not
_excluded_, but size usually prefers dynamic linking.
> * If most of a library is used anyway, then multiple applications using
> the same library will duplicate it on disk and in memory
Ditto.
> DLLs solve a lot of those:
>
> * The vendor provides one file that works with any compiler and any language
If that is true, than fine. However, what about situations where
"the same" library (but is subtly diffrent versions) is bundled
with several packages. Or lowely Windows Update decided to install
"new improved" version of some library.
> * No need to bundle with every compiler
But if you distribute binary you need to bundle non-standard
libraries.
> * Only one copy of the library on any one machine
Yes.
> * Updates can benefit applications without recompiling or reinstalling
Well, experience seem to indicate otherwise: "fixed" versions of
library functions may cause breakage. Better shared library
systems make sure that after incompatible change program still
uses old version of a function.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-01 01:46 +0100 |
| Message-ID | <se4qss$akg$1@dont-email.me> |
| In reply to | #162182 |
On 01/08/2021 00:51, antispam@math.uni.wroc.pl wrote: > Bart <bc@freeuk.com> wrote: >> A CALL to another function normally uses a relative offset. You can't >> just extract functions and move them about without invalidating those >> offsets. And doing that requires being able to precisely track what is >> code and what is data (even in executable memory). > > Do you know what position-independent code means? I know what I mean by it. Which is the ability to relocate a contiguous block of code at any address, and internal references /within/ the code still work. But not to move parts of it separately. (I think this was discussed on comp.lang.misc recently.) > And what static > linking means? In the current context, whether an external library's code is incorporated into the executable you're building. Otherwise it's accessed as a shared library with fixups done when the program is loaded for execution. >> (DLL files will have that info, but are intended for moving the entirely >> library, not individual blocks of functions or data.) > > Yes, Windows i386 DLL-s used static linking with relocation info > for adjusting start address of library at load time. And relocation > was applied to the whole library. This is very unlike what ELF > on Linux is doing: Linux shared libraries need position-independent > code, unlike i386 Windows DLL-s. IIUC also 64-bit Windows DLL > work like Linux ones and need position-independent code. Actually there is no such restriction on 64-bit DLLs. The only requirement is that absolute addresses within the code are part of the relocation table. (At least, /I/ don't bother with PIC, it's all mixed, and the DLL files I write seem to work.) >> This is nonsense, at least for COFF files. Tell me whereabouts function >> sizes are stored in that file format. It can only infer the sizes by >> analysing the start addresses of all the functions, and then it might be >> stuck on the last one, or where data is intermingled. > > I do not understand your fixation on function size. Linker works > with sections and relocates sections as a whole. If you want > functions than use '-ffunction-sections', then section size > will be the same as function size. So one section per function, really? I remember linkers on mainframes being massive programs taking most of the resources, and taking forever. When I created my own linkers (I just called them loaders), they were much, much simpler, and worked instantly. They just incorporated every module submitted. This worked well even with 64KB memory. But probably because /I/ wrote all the libraries so they weren't bloated! (It did manage overlays though.) Now I've eliminated most aspects of 'linking' completely. I don't use object files nor these ".a" or ".lib" files, which to me seem so old-fashioned. > Concerning COFF, I do not > know if it supports multiple sections in single .o (or .obj if > you prefer) file. I think they use 16-bit fields for section numbers, so maybe 32K or 64K sections. Whether supported by tools is another matter. > If not, then we are back to splitting files > so that single .o file contains exactly one function. I would > hope that Windows COFF (there are a lot of variants of COFF, > but you probably only care about Windows) adapted to modern > trends, but I had no reason to check this. > Bottom lines is that linker works on section, which in primitive > systems may be limited to whole .o file. (Whenever I sometimes generate .obj, it actually represents an entire program. So rather than one function per .o instead one one module, it's one program per .o! My aims are the opposite.) >> David Brown creates applications for small devices so he has to pull out >> all the stops, use all possible options to keep things compact. >> >> But my desktop PC already has nearly 40,000 DLL files, totalling 25GB, >> belong to the system or to installed programs. >> >> If static linking of third party libraries was such a great idea, then I >> would hardly ever see DLL files! > > I do not advocate using static linking, but in some (rare) situations > it can be helpful. Cretainly not a normal approach on desktop system. >> >> Archive files have lots of problems: >> >> * Each library must issue them for multiple languages/compilers/formats >> (raylib provides seprate versions for tcc and gcc, plus .dll that works >> with anything) > > That is independent issue having little to do with static versus > dynamic. If you "standarize" on "one true toolchain" than you > can use single format. OTOH, AFAIK you can install alternative > DLL loaders in Windows, so if you wish you can have as many > dll formats as you wish. For quite a while I wondered why compilers still /bothered/ with .a and .lib files, when many can now link directly with .dll. (I think someone once suggested that functions in dll files could be individually extracted, but for the reasons being discussed, that is not practical. Why they'd want that is another question.)
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-07-30 17:20 +0200 |
| Message-ID | <se15br$1pog$1@gioia.aioe.org> |
| In reply to | #162102 |
On 7/29/2021 8:41 PM, Bart wrote:
> On 29/07/2021 19:16, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 29/07/2021 18:28, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> This program:
>>>>>
>>>>> #include <stdio.h>
>>>>> int main(void) {printf("%zu\n",sizeof(void*));}
>>>>>
>>>>> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
>>>
>>>> The problem is with the old C library. The version of gcc is
>>>> irrelevant.
>>>> Windows 7 is obsolete. If you're stuck using it for some reason,
>>>> that's
>>>> a valid reason to avoid "%zu". "it doesn't work on Windows" is not.
>>>
>>> Looks like Windows 10 is obsolete too:
>>>
>>> c:\c>ver
>>> Microsoft Windows [Version 10.0.14393]
>>>
>>> c:\c>type c.c
>>> #include <stdio.h>
>>>
>>> int main(void) {
>>> printf("%zu\n", sizeof(void*));
>>> }
>>>
>>> c:\c>gcc c.c
>>>
>>> c:\c>a
>>> zu
>>
>> No, it looks like you're using an obsolete C library implementation on
>> Windows 10.
>
> You said 'Windows 7 is obsolete'.
>
> Anyway, how can the C library be obsolete if it comes /with/ Windows 10?
> Even if I could, installing a different library wouldn't be much help,
> since then I'd have programs that worked fine on my Windows, but on no
> one else's unless they jumped through the same hoops.
This is a Windows problem, not gcc. As far as I can tell printf comes
with the famous msvcrt.dll, which comes with Windows, BUT also comes
with msvcrXXX.dll as an official redistributable of Visual Studio, that
Microsoft allows to distribute with applications developed with that.
Microsoft gives guidelines for installers about how to deploy these
components, but the result, obviously, is that different Windows boxes
have different C runtimes depending on which packages have been installed.
As a curiosity, you may try this:
#include <Windows.h>
#include <stdio.h>
typedef int (*__cdecl PrintfT)(const char * _Format, ...);
int main(void)
{
if (HMODULE msvcrtLib = LoadLibrary("msvcrt.dll"))
{
PrintfT msvcrtPrintf = (PrintfT)GetProcAddress(msvcrtLib, "printf");
msvcrtPrintf("msvcrtPrintf %zu\n", sizeof(void*));
FreeLibrary(msvcrtLib);
}
printf("printf %zu\n", sizeof(void*));
}
As usual, Microsoft C implementation has always been "peculiar".
Moreover, if you use gcc under Windows (I don't) you are actually using
cygwin's port of gcc *and* some libc implementation, which is /not/
supported by the gcc team.
>
> Just for the sake of %zu which can be trivially replaced with %d and a
> (int) cast (or %lld and (long long) if expecting some big objects), it
> is not worth the headache of extra dependencies.
Yes, if you use gcc under Windows you are actually importing a chain of
dependencies that you don't want to bother with - That's the reason I
only use gcc on Linux.
>
>> I'm able to compile and run your program on Windows 10,
>> and it prints 8 or 4 depending on which implementation I use.
>>
>> You could probably get some help with that if you asked (and provided
>> some information).
>
> Does Tiny C work too?
>
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-07-30 11:16 -0700 |
| Message-ID | <874kcbekgs.fsf@nosuchdomain.example.com> |
| In reply to | #162115 |
Manfred <noname@add.invalid> writes:
[...]
> Yes, if you use gcc under Windows you are actually importing a chain
> of dependencies that you don't want to bother with - That's the reason
> I only use gcc on Linux.
[...]
Cygwin is one way to use gcc under Windows, but it's not the only one.
There are other implementations on Windows that include gcc but are not
connected to Cygwin. See for example mingw-w64 (which seems to have
some relationship to Cygwin, but I'm not clear on the details).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-07-30 20:24 +0200 |
| Message-ID | <se1g4e$1635$2@gioia.aioe.org> |
| In reply to | #162127 |
On 7/30/2021 8:16 PM, Keith Thompson wrote: > Manfred <noname@add.invalid> writes: > [...] >> Yes, if you use gcc under Windows you are actually importing a chain >> of dependencies that you don't want to bother with - That's the reason >> I only use gcc on Linux. > [...] > > Cygwin is one way to use gcc under Windows, but it's not the only one. > There are other implementations on Windows that include gcc but are not > connected to Cygwin. See for example mingw-w64 (which seems to have > some relationship to Cygwin, but I'm not clear on the details). > Still I believe that none of them is officially supported by the gcc team.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-07-30 14:17 -0700 |
| Message-ID | <87r1ffcxij.fsf@nosuchdomain.example.com> |
| In reply to | #162130 |
Manfred <noname@add.invalid> writes:
> On 7/30/2021 8:16 PM, Keith Thompson wrote:
>> Manfred <noname@add.invalid> writes:
>> [...]
>>> Yes, if you use gcc under Windows you are actually importing a chain
>>> of dependencies that you don't want to bother with - That's the reason
>>> I only use gcc on Linux.
>> [...]
>> Cygwin is one way to use gcc under Windows, but it's not the only
>> one.
>> There are other implementations on Windows that include gcc but are not
>> connected to Cygwin. See for example mingw-w64 (which seems to have
>> some relationship to Cygwin, but I'm not clear on the details).
>
> Still I believe that none of them is officially supported by the gcc team.
Right, gcc and glibc are separate projects, both under the GNU umbrella.
I'm unsure of the relationship between newlib and GNU (a quick look at
its README and MAINTAINERS files was a bit confusing), but that doesn't
really matter for most purposes.
Of course the whole point of gcc is for it to be usable as a compiler.
If some change in gcc caused it not to work with glibc, that would be a
bug that would presumably be addressed with a high priority, and vice
versa. (A similar bug that affects gcc working together with a
Microsoft-specific runtime library might be given a lower priority.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-07-30 14:55 +0000 |
| Message-ID | <20210730075445.167@kylheku.com> |
| In reply to | #162094 |
On 2021-07-29, Bart <bc@freeuk.com> wrote:
> It's Windows 7. gcc is version 9.2.0.
> This program:
>
> #include <stdio.h>
> int main(void) {printf("%zu\n",sizeof(void*));}
>
> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
The above has no meaning. "gcc" is not the name of any software that
provides a printf function.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-30 16:13 +0100 |
| Message-ID | <se14v7$gb6$1@dont-email.me> |
| In reply to | #162111 |
On 30/07/2021 15:55, Kaz Kylheku wrote:
> On 2021-07-29, Bart <bc@freeuk.com> wrote:
>> It's Windows 7. gcc is version 9.2.0.
>
>> This program:
>>
>> #include <stdio.h>
>> int main(void) {printf("%zu\n",sizeof(void*));}
>>
>> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
>
> The above has no meaning. "gcc" is not the name of any software that
> provides a printf function.
>
OK. But gcc and tcc are products that you expect to make the necessary
arrangements for ensuring they your program can call a C standard
function called "printf".
Which they do, because it generally works. But whatever it is they end
up linking into your program, doesn't support "zu".
I use msvcrt.dll for my compiler's library (sometimes, ucrtbase.dll).
Which library do gcc and tcc use?
I don't know. However, if I peek inside an executable for hello.c
created with tcc, it apparently imports msvcrt.dll, same as mine does.
gcc does the same. But if I try Clang, there is no import library (or no
relevant one). So whatever it uses might be statically linked in.
Same with MSVC (CL), but that is unsurprising, since Clang, despite
being a massive 1600MB installation with LLVM, apparently relies on MS
tools to do the linking, so may use the same library.
But this is all getting away from the point you're trying to make, which
is that gcc has no hand at all it in providing a 'printf' function for
my C programs.
You're wrong.
Further, if I try and compile this program:
extern int printf(long long,...);
int main(void) {
printf((long long)"Hello, World!\n");
}
gcc complains that my printf conflicts with the built-in printf; so it
knows perfectly well what it is. It will even tell me if I get the
format codes wrong!
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-07-30 09:08 -0700 |
| Message-ID | <cd904d15-015e-41ec-b894-15fcd04ea8b7n@googlegroups.com> |
| In reply to | #162113 |
On Friday, July 30, 2021 at 11:13:55 AM UTC-4, Bart wrote:
> On 30/07/2021 15:55, Kaz Kylheku wrote:
> > On 2021-07-29, Bart <b...@freeuk.com> wrote:
> >> It's Windows 7. gcc is version 9.2.0.
> >
> >> This program:
> >>
> >> #include <stdio.h>
> >> int main(void) {printf("%zu\n",sizeof(void*));}
> >>
> >> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
> >
> > The above has no meaning. "gcc" is not the name of any software that
> > provides a printf function.
> >
> OK. But gcc and tcc are products that you expect to make the necessary
> arrangements for ensuring they your program can call a C standard
> function called "printf".
No, I don't, because I read the documentation. I expect gcc to use
whichever library it's connected to, whether or not that library constitutes
a conforming implementation of the C standard library. In order to get a
fully conforming implementation of C, you need to connect it to a library
that is a fully conforming and gcc-compatible implementation of the C
standard library. Such a library is provided by the Ubuntu distribution of
Linux that I'm using on my desktop, and automatically connected to my
copy of gcc, but that is apparently not the case of the Windows system
you're using. Since Keith has no problem with this on his Windows 10
machine, it's not merely Windows 10 that's the issue - it's how your
particular copy of Windows was installed that's the problem.
> Which they do, because it generally works. But whatever it is they end
> up linking into your program, doesn't support "zu".
>
> I use msvcrt.dll for my compiler's library (sometimes, ucrtbase.dll).
> Which library do gcc and tcc use?
That depends upon how they're installed. As you have repeatedly
demonstrated in the past, you have no clear understanding of how
you've installed such things.
> But this is all getting away from the point you're trying to make, which
> is that gcc has no hand at all it in providing a 'printf' function for
> my C programs.
>
> You're wrong.
It makes no promise to provide any such function.
If you buy hot dog buns from a bakery, do you complain about the fact
that they don't have any hot dogs in them? If someone sells hot dog
buns without hot dogs, and someone else sells hot dogs without buns,
it's your responsibility, if you want to take advantage of those choices,
to put them together yourself. If you don't want that responsibility, get
your hot dog with a bun from someone who actually sells such things.
Many sources provide fully conforming C compilers bundled together
with compatible fully conforming standard libraries. You just aren't
using one of them.
> int main(void) {
> printf((long long)"Hello, World!\n");
> }
>
> gcc complains that my printf conflicts with the built-in printf; so it
> knows perfectly well what it is. It will even tell me if I get the
> format codes wrong!
It's not the "built-in" printf(), it's the printf() that's provided by
whichever library gcc is currently configured to use - which is not
provided by gcc, and which gcc makes no promises about.
Yes, it does provide compile-time checking of printf/scanf family
format specifiers. That checking occurs before linking, and is based
upon the assumption that the library your connecting to is a fully
conforming implementation of the C standard library. As a result,
the format specifier checking can actually produce incorrect results,
if the printf() function provided by that library accepts different
format specifiers than what's required of the C standard library
printf() function.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-07-30 18:18 +0100 |
| Message-ID | <se1c9a$5f7$1@dont-email.me> |
| In reply to | #162120 |
On 30/07/2021 17:08, james...@alumni.caltech.edu wrote:
> On Friday, July 30, 2021 at 11:13:55 AM UTC-4, Bart wrote:
>> On 30/07/2021 15:55, Kaz Kylheku wrote:
>>> On 2021-07-29, Bart <b...@freeuk.com> wrote:
>>>> It's Windows 7. gcc is version 9.2.0.
>>>
>>>> This program:
>>>>
>>>> #include <stdio.h>
>>>> int main(void) {printf("%zu\n",sizeof(void*));}
>>>>
>>>> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
>>>
>>> The above has no meaning. "gcc" is not the name of any software that
>>> provides a printf function.
>>>
>> OK. But gcc and tcc are products that you expect to make the necessary
>> arrangements for ensuring they your program can call a C standard
>> function called "printf".
>
> No, I don't, because I read the documentation.
Are you serious? Just gcc.info is 1000 pages of options.
Someone who has been using:
tcc prog.c
effectively, and now wants to try gcc, expects to type the equivalent:
gcc prog.c
except for options like -O3 to get faster code.
> I expect gcc to use
> whichever library it's connected to, whether or not that library constitutes
> a conforming implementation of the C standard library. In order to get a
> fully conforming implementation of C, you need to connect it to a library
> that is a fully conforming and gcc-compatible implementation of the C
> standard library. Such a library is provided by the Ubuntu distribution of
> Linux that I'm using on my desktop, and automatically connected to my
> copy of gcc, but that is apparently not the case of the Windows system
> you're using. Since Keith has no problem with this on his Windows 10
> machine, it's not merely Windows 10 that's the issue - it's how your
> particular copy of Windows was installed that's the problem.
I don't even know what gcc bundle Keith might have. Also he doesn't have
tcc so he cannot say what that does or doesn't do.
However, if I delve into my gcc installation, there are 1277 lib*.a
files, of which 14 have "crt" in their names (shared between 32- and
64-bit versions).
If I try the -lucrt or -lucrtbase option with gcc, then "zu" works. With
-lmsvcrt then "zu" doesn't work.
So now I know how to get gcc on Windows to use "zu". Except that may not
be helpful, if it depends on the installer of gcc including the mingw64
runtime libraries, if these lib*.a files are dependent on that being an
installed component.
Plus it probably still won't work on tcc, as it can't find -lucrt, and
it can't directly link libucrt.a.
Plus it still won't work my bcc and I can't see a way of turning
libucrt.a into a DLL that can export its C functions.
So, in all, it's much safer not use "zu". Remember that all we're doing
is printing a number, which is either u32 or u64.
>> Which they do, because it generally works. But whatever it is they end
>> up linking into your program, doesn't support "zu".
>>
>> I use msvcrt.dll for my compiler's library (sometimes, ucrtbase.dll).
>> Which library do gcc and tcc use?
>
> That depends upon how they're installed. As you have repeatedly
> demonstrated in the past, you have no clear understanding of how
> you've installed such things.
Utter nonsense. I just use the supplied installers. On the gcc/tdm
install program, you select the components needed, and most start off
already ticked.
On simpler compilers, there may be no options at all. (Mine is just a
bare .exe file, ready-to-go.)
>> But this is all getting away from the point you're trying to make, which
>> is that gcc has no hand at all it in providing a 'printf' function for
>> my C programs.
>>
>> You're wrong.
>
> It makes no promise to provide any such function.
My compiler will produce an executable where printf is an imported
function. To succeed, it will need, at compile-time, the name of a DLL
where the symbol can be located (but msvcrt.dll is searched automatically).
Even with the EXE generated, because of dynamic linking, it will further
need the DLL available at runtime.
In practice, printf will always be available because msvcrt.dll is a
part of Windows, which cannot easily be deleted.
>
> If you buy hot dog buns from a bakery, do you complain about the fact
> that they don't have any hot dogs in them? If someone sells hot dog
> buns without hot dogs, and someone else sells hot dogs without buns,
> it's your responsibility, if you want to take advantage of those choices,
> to put them together yourself. If you don't want that responsibility, get
> your hot dog with a bun from someone who actually sells such things.
> Many sources provide fully conforming C compilers bundled together
> with compatible fully conforming standard libraries. You just aren't
> using one of them.
I've been writing compilers for 40 years. Especially within the last 10,
where I have also strived to make them smaller, simpler, faster, more
self-contained and more effortless to install and use than the
mainstream ones.
So you can't really get on your pulpit and tell people they don't
understand their Compiler (namely 'gcc'), as there is more than one, and
anything amiss is therefore their fault as they haven't read through
10,000 pages of docs.
They can all be different. gcc apparently comes with this practice of
separating out all the various components, which you and Keith and now
KK like to beat people over the head with whenever sometimes makes some
assumption about what a compiler is. YOU can't make assumptions either.
Some are a lot more friendly than your gcc and more informal.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-07-30 17:38 +0000 |
| Message-ID | <ZNWMI.97171$Vv6.46033@fx45.iad> |
| In reply to | #162121 |
Bart <bc@freeuk.com> writes: >On 30/07/2021 17:08, james...@alumni.caltech.edu wrote: >> No, I don't, because I read the documentation. > >Are you serious? Just gcc.info is 1000 pages of options. RTFM. And, much as I dislike the GNU info utility UI, the data is well organized and fairly complete. >I don't even know what gcc bundle Keith might have. Also he doesn't have >tcc so he cannot say what that does or doesn't do. I believe he mentioned using cygwin gcc, which comes with glibc.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-07-30 11:17 -0700 |
| Message-ID | <87zgu3d5ur.fsf@nosuchdomain.example.com> |
| In reply to | #162122 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Bart <bc@freeuk.com> writes:
>>On 30/07/2021 17:08, james...@alumni.caltech.edu wrote:
>
>>> No, I don't, because I read the documentation.
>>
>>Are you serious? Just gcc.info is 1000 pages of options.
>
> RTFM. And, much as I dislike the GNU info utility UI, the
> data is well organized and fairly complete.
>
>
>>I don't even know what gcc bundle Keith might have. Also he doesn't have
>>tcc so he cannot say what that does or doesn't do.
>
> I believe he mentioned using cygwin gcc, which comes with glibc.
Cygwin gcc uses newlib, not glibc.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 15 of 20 — ← Prev page 1 … 13 14 [15] 16 17 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web