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 9 of 20 — ← Prev page 1 … 7 8 [9] 10 11 … 20 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-08 20:25 +0100 |
| Message-ID | <sepb2q$lp5$1@dont-email.me> |
| In reply to | #162249 |
On 08/08/2021 18:12, Kaz Kylheku wrote:
> On 2021-08-08, Bart <bc@freeuk.com> wrote:
>> My bcc compiler, which also calls printf in msvcrt, does it in 2.3
>> seconds for some reason. lccwin is 15 seconds, DM 2.7. MSVC is 2.7 too.
>> Clang is 21 seconds (which is taking being a gcc clone to extremes).
>
> The printf MSVCRT.DLL may be fast, but it's still an undocumented system
> component. Microsoft could make it disappear tomorrow, or introduce
> some breaking change.
>
> A few FOSS people moaning and groaning isn't going to stop a roll-out of
> a new version of Windows that breaks or removes MSVCRT.DLL.
>
>> All very strange.
>
> How is it strange that one printf implementation has different
> performance characteristics from a completely different printf
> implementation?
But the difference is vast; what can a printf routine possibly be doing
to result in the 1300% slowdown exhibited here (79 X's printed per line):
#include <stdio.h>
int main(void) {
char str[1000];
for (int i=0; i<2000; ++i) {
printf("XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n");
}
}
bcc/tcc take 1.75 seconds; gcc/clang take 25.5 seconds, which is
ridiculous. Clearly something is seriously amiss; you can't just shrug
it off and put it down somewhat different implementations.
And what gcc/clang are up isn't even something useful like implementing
"%zu" or ANSI escape sequences.
The mystery depends because if you write it like this:
puts("XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX");
Then gcc is as fast as the others. It's not *printf formatting overheads
either, because writing it this way:
sprintf(str,"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX");
puts(str);
is also fast.
I did manage to get gcc fast using printf, by replacing #include
<stdio.h> with this line:
extern int printf(const char*, ...);
Then it directly calls the real printf instead of this version:
__mingw_ovr
__attribute__((__format__ (gnu_printf, 1, 2)))
__MINGW_ATTRIB_NONNULL(1)
int printf (const char *__format, ...)
{
int __retval;
__builtin_va_list __local_argv; __builtin_va_start( __local_argv,
__format );
__retval = __mingw_vfprintf( stdout, __format, __local_argv );
__builtin_va_end( __local_argv );
return __retval;
}
>> I don't know how much this is important, or how much
>> text you're printing to the screen, since 500 printfs per second is
>> still faster than anyone can read it. The problem disappears if you
>> redirect to a file.
>
> Might it be that, similarly to the Cygwin DLL, this library
> does some "cooking" of its console streams?
>
> I know that the Cygwin DLL does.
>
> In Cygwin, all input and output on console descriptors passes through a
> software layer which:
>
> - simulates a POSIX TTY device: tcgetattr, tcsetattr, ...
>
> - interprets ANSI/VT100 escape sequences, converting them into Console
> API calls, on both input and output.
>
> This means that POSIX code which controls the terminal with termios,
> and/or which uses hard-coded ANSI escape sequences will work.
>
> The MSVCRT.DLL printf will not do anything like this for you.
But if it did, it wouldn't slow it down at all, because the fast path
(not inside a control sequence is just as fast). And gcc (not in Cygwin
but normal Windows) doesn't support that anyway.
> It's pretty necessary for porting some POSIX programs to Windows,
> though, without the huge hassle of rewriting their TTY related code into
> Console API calls.
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-08-08 20:21 +0100 |
| Message-ID | <87czqnlp2m.fsf@bsb.me.uk> |
| In reply to | #162248 |
Bart <bc@freeuk.com> writes:
>> 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.
You often post times with no indication of what's being measured. The
compiler probably has little to do with it. What C library is being
used? How is the output handled? On my laptop, compiled with gcc
10.3.0 and linked against libc6 version 2.33, it's almost too fast to
measure:
$ time ./o >/dev/null
real 0m0.007s
user 0m0.004s
sys 0m0.004s
> 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.
Yes, but without knowing what's being measured you may never resolve the
mystery.
> 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.
What problem disappears?
> You can try bypassing printf in gcc by using sprintf to a string for a
> complete line of output, then using puts() on the string. However you
> shouldn't need to do this.
Why do you think the problem (whatever it is) has got anything to do
with gcc if the problem disappears when the output is redirected?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-08 20:38 +0100 |
| Message-ID | <sepbrd$vg4$1@dont-email.me> |
| In reply to | #162250 |
On 08/08/2021 20:21, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>>> 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.
>
> You often post times with no indication of what's being measured.
Huh? The test program is shown above. A tcc-compiled program takes 7
times as long as gcc- or clang-compiled one. On Windows (I know Linux
has super-fast console output).
What I'm measuring is how long between starting the program, and
finishing writing stuff to the screen, because on Windows you can see
all this output scrolling up the screen.
> The
> compiler probably has little to do with it. What C library is being
> used? How is the output handled?
I don't know, but... should anyone really have to delve into the exact
implementation of printf to get it to do its job properly? It should
just work! Which means not working a magnitude slower than it should.
See my other post a few minutes after yours for further investigations.
>> You can try bypassing printf in gcc by using sprintf to a string for a
>> complete line of output, then using puts() on the string. However you
>> shouldn't need to do this.
>
> Why do you think the problem (whatever it is) has got anything to do
> with gcc if the problem disappears when the output is redirected?
The 'problem' is with clang/gcc calling 'printf'. All compilers are told
to use printf, yet only these two compilers end up being slow.
Maybe they end up calling some slow, character-at-a-time routine in the
C library which, for the console, means invoking some of those elaborate
WinAPI routines which have high overheads. And maybe those other
compilers manage to do it a string-at-a-time.
But if that is the case, who's fault is that, and what can one do about
it? Do you think it is likely to involve messing with the options for
these gcc or clang installations?
Because you seem keen to put the blame elsewhere.
What can you tell DFS to make fix this problem when using gcc?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2021-08-08 14:00 -0700 |
| Message-ID | <1cc46091-0596-4b43-b59e-514772da56acn@googlegroups.com> |
| In reply to | #162252 |
On Sunday, 8 August 2021 at 20:38:32 UTC+1, Bart wrote: > > The 'problem' is with clang/gcc calling 'printf'. All compilers are told > to use printf, yet only these two compilers end up being slow. > > Maybe they end up calling some slow, character-at-a-time routine in the > C library which, for the console, means invoking some of those elaborate > WinAPI routines which have high overheads. And maybe those other > compilers manage to do it a string-at-a-time. > > But if that is the case, who's fault is that, and what can one do about > it? Do you think it is likely to involve messing with the options for > these gcc or clang installations? > Why would you need a fast printf? There are a few scenarios I can think of, like web servers that need a very fast throughput. But they are quite specialised. And yes, you can probably get a fast printf for such purposes by messing about with clang/gcc's settings. However if printf either sends characters to a scrolling character-mapped console, or is redirected to a fairly slow backing store, then really there's no point in trying to link in a fast version.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-08 22:16 +0100 |
| Message-ID | <sephit$81s$1@dont-email.me> |
| In reply to | #162255 |
On 08/08/2021 22:00, Malcolm McLean wrote: > On Sunday, 8 August 2021 at 20:38:32 UTC+1, Bart wrote: >> >> The 'problem' is with clang/gcc calling 'printf'. All compilers are told >> to use printf, yet only these two compilers end up being slow. >> >> Maybe they end up calling some slow, character-at-a-time routine in the >> C library which, for the console, means invoking some of those elaborate >> WinAPI routines which have high overheads. And maybe those other >> compilers manage to do it a string-at-a-time. >> >> But if that is the case, who's fault is that, and what can one do about >> it? Do you think it is likely to involve messing with the options for >> these gcc or clang installations? >> > Why would you need a fast printf? There are a few scenarios I can > think of, like web servers that need a very fast throughput. But they are > quite specialised. And yes, you can probably get a fast printf for such > purposes by messing about with clang/gcc's settings. > However if printf either sends characters to a scrolling character-mapped > console, or is redirected to a fairly slow backing store, then really there's > no point in trying to link in a fast version. > Well, DFS reported 3 seconds to display output from a program instead of the 0.25 seconds it ought to have been. That's an annoying and unnecessary wait. The question ought to be, why would you want a slow printf? There's clearly something wrong here, since other programs can display output perfectly well, even when they themselves use printf.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-08-08 22:17 +0100 |
| Message-ID | <877dgvljpf.fsf@bsb.me.uk> |
| In reply to | #162252 |
Bart <bc@freeuk.com> writes:
> On 08/08/2021 20:21, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>>> 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.
>> You often post times with no indication of what's being measured.
>
> Huh? The test program is shown above. A tcc-compiled program takes 7
> times as long as gcc- or clang-compiled one. On Windows (I know Linux
> has super-fast console output).
>
> What I'm measuring is how long between starting the program, and
> finishing writing stuff to the screen, because on Windows you can see
> all this output scrolling up the screen.
You've been in the business for many years. I can't believe you don't
know what I mean.
>> The
>> compiler probably has little to do with it. What C library is being
>> used? How is the output handled?
>
> I don't know, but... should anyone really have to delve into the exact
> implementation of printf to get it to do its job properly? It should
> just work! Which means not working a magnitude slower than it should.
I my machine is three times faster than yours (just to get a simple
number) we are talking about three orders of magnitude. Do you think
that's down to the implementation of printf? You certainly haven't
posted any data to support that.
> See my other post a few minutes after yours for further investigations.
>
>>> You can try bypassing printf in gcc by using sprintf to a string for a
>>> complete line of output, then using puts() on the string. However you
>>> shouldn't need to do this.
>> Why do you think the problem (whatever it is) has got anything to do
>> with gcc if the problem disappears when the output is redirected?
>
> The 'problem' is with clang/gcc calling 'printf'. All compilers are
> told to use printf, yet only these two compilers end up being slow.
I thought you said the problem goes away when the output is redirected?
gcc and clang don't generate code that does not call printf when the
output is redirected.
> But if that is the case, who's fault is that, and what can one do
> about it? Do you think it is likely to involve messing with the
> options for these gcc or clang installations?
>
> Because you seem keen to put the blame elsewhere.
Because I think the blame must be elsewhere, but I'm not going to
install Windows (and all the other stuff one might need) just to find
out.
> What can you tell DFS to make fix this problem when using gcc?
To get 1000-fold increase in speed, ditch Windows. If he or she must
use Windows, find out what's taking the time.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-08 22:32 +0100 |
| Message-ID | <sepii6$k2g$1@dont-email.me> |
| In reply to | #162257 |
On 08/08/2021 22:17, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: >> The 'problem' is with clang/gcc calling 'printf'. All compilers are >> told to use printf, yet only these two compilers end up being slow. > > I thought you said the problem goes away when the output is redirected? > gcc and clang don't generate code that does not call printf when the > output is redirected. I thought I explained what might have been happening: gcc might end up calling a routine in msvcrt that works a character at a time, rather than a string at a time. And the former might be slower when sent to the console so you don't see a problem with file output. It seems that bcc/tcc directly call msvcrt's printf, passing it a whole string. But gcc at least implements printf as a call to __mingw_vfprintf inside some vararg-handing code. I don't know what goes on inside _mingw_vfprintf; as far as I can see, nothing of benefit. >> But if that is the case, who's fault is that, and what can one do >> about it? Do you think it is likely to involve messing with the >> options for these gcc or clang installations? >> >> Because you seem keen to put the blame elsewhere. > > Because I think the blame must be elsewhere, but I'm not going to > install Windows (and all the other stuff one might need) just to find > out. > >> What can you tell DFS to make fix this problem when using gcc? > > To get 1000-fold increase in speed, ditch Windows. If he or she must > use Windows, find out what's taking the time. Where did the 1000-fold increase come from? The slowdown on my last test was about 14 times, in line with what DFS reported. The problem occurs when using gcc/clang (and to lesser extent lccwin). You don't want displaying to a screen being a magnitude slower than necessary.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-08 23:13 +0100 |
| Message-ID | <sepkuh$i0q$1@dont-email.me> |
| In reply to | #162258 |
On 08/08/2021 22:32, Bart wrote:
> On 08/08/2021 22:17, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> The 'problem' is with clang/gcc calling 'printf'. All compilers are
>>> told to use printf, yet only these two compilers end up being slow.
>>
>> I thought you said the problem goes away when the output is redirected?
>> gcc and clang don't generate code that does not call printf when the
>> output is redirected.
>
> I thought I explained what might have been happening: gcc might end up
> calling a routine in msvcrt that works a character at a time, rather
> than a string at a time. And the former might be slower when sent to the
> console so you don't see a problem with file output.
If I tweak my program than prints lines of 79 X's, to print them one
character at a time like this: printf("X"), then, guess what, bcc/tcc
take 25 seconds too!
Further, if I redirect the output to a file, then that is fast as well.
You will probably still want to point the blame at this library, for a
having console output that is not as efficient as it could be, and away
from gcc/clang implementations.
But it is those implementations that make things worse by, somehow,
doing character at a time output at the point where it calls into the
library, so invoking 79 lots of overhead when there could have been just
one.
This explains also why using puts, or sprintf into an intermediate
buffer then puts, doesn't exhibit the slowdown.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-08-09 01:46 +0100 |
| Message-ID | <871r73la1b.fsf@bsb.me.uk> |
| In reply to | #162258 |
Bart <bc@freeuk.com> writes: > On 08/08/2021 22:17, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> The 'problem' is with clang/gcc calling 'printf'. All compilers are >>> told to use printf, yet only these two compilers end up being slow. >> I thought you said the problem goes away when the output is redirected? >> gcc and clang don't generate code that does not call printf when the >> output is redirected. > > I thought I explained what might have been happening: gcc might end up > calling a routine in msvcrt that works a character at a time, rather > than a string at a time. And the former might be slower when sent to > the console so you don't see a problem with file output. gcc is a compiler. It generates code that calls printf or similar. After that, what happens is nothing to do with gcc. >>> What can you tell DFS to make fix this problem when using gcc? >> To get 1000-fold increase in speed, ditch Windows. If he or she must >> use Windows, find out what's taking the time. > > Where did the 1000-fold increase come from? The slowdown on my last > test was about 14 times, in line with what DFS reported. You reported 21s, I measured 0.007s, both using gcc. The difference is almost certainly be due to implementation components other than gcc. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-09 10:54 +0100 |
| Message-ID | <sequ10$55f$1@dont-email.me> |
| In reply to | #162263 |
On 09/08/2021 01:46, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> On 08/08/2021 22:17, Ben Bacarisse wrote: >>> Bart <bc@freeuk.com> writes: >> >>>> The 'problem' is with clang/gcc calling 'printf'. All compilers are >>>> told to use printf, yet only these two compilers end up being slow. >>> I thought you said the problem goes away when the output is redirected? >>> gcc and clang don't generate code that does not call printf when the >>> output is redirected. >> >> I thought I explained what might have been happening: gcc might end up >> calling a routine in msvcrt that works a character at a time, rather >> than a string at a time. And the former might be slower when sent to >> the console so you don't see a problem with file output. > > gcc is a compiler. It generates code that calls printf or similar. Actually, it doesn't. As I said, it calls an inline version of printf in its stdio.h, which ends up calling __mingw_vfprintf. I /can/ get it to call the same printf I do, by using this declaration in place of stdio.h: extern int printf(const char*, ...); The problem is that it - my gcc installation - does something different. > After that, what happens is nothing to do with gcc. You're still trying to play that card. >>>> What can you tell DFS to make fix this problem when using gcc? >>> To get 1000-fold increase in speed, ditch Windows. If he or she must >>> use Windows, find out what's taking the time. >> >> Where did the 1000-fold increase come from? The slowdown on my last >> test was about 14 times, in line with what DFS reported. > > You reported 21s, I measured 0.007s, both using gcc. The upper limit of what can be achieved on my Windows system using i/o via msvcrt.dll seems to be about 1.7 seconds for my test (2000 80-character strings, approx 100K chars per second. It will slow down in every case if I write much shorter strings, or single characters. I can't do much about that. Yet some compilers - sorry compilers plus whatever components they've been bundled with - exhibit that slowness even with long strings. > The difference is > almost certainly be due to implementation components other than gcc. > Sure; I'm using a gcc 'bundle', as nearly everyone will be. But such installations are huge; most people will have to trust whatever components have been included. > You reported 21s, I measured 0.007s, both using gcc. I think that was test was 10000 16-character strings, with no newlines so less impact of scrolling. 7ms means 23M characters per second on a graphical, bit-mapped, scrolling character display. (Or I assume it is graphical; if a text-mode display, then that's not playing the game.) At 23Mcps, I don't know what tricks the terminal driver is doing to achieve that. Maybe it's writing into a virtual screen (a text-mode buffer not bit-mapped), and only updating the display intermittently. Or maybe its better at using whatever hardware acceleration exists. The tricks could probably be done on Windows too (eg. using DirectDraw or whatever). But probably not via the clunky console routines that MS provides. But that is all besides the point, which is this: gcc/clang installations on plain Windows using a normal console window, do something that makes printing via printf even slower than it already is.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2021-08-09 03:59 -0700 |
| Message-ID | <1940b600-39e9-4f6c-b194-b7fa2dcf4c27n@googlegroups.com> |
| In reply to | #162268 |
On Monday, August 9, 2021 at 12:54:51 PM UTC+3, Bart wrote: > On 09/08/2021 01:46, Ben Bacarisse wrote: > > Bart <b...@freeuk.com> writes: > > > >> On 08/08/2021 22:17, Ben Bacarisse wrote: > >>> Bart <b...@freeuk.com> writes: > >> > >>>> The 'problem' is with clang/gcc calling 'printf'. All compilers are > >>>> told to use printf, yet only these two compilers end up being slow. > >>> I thought you said the problem goes away when the output is redirected? > >>> gcc and clang don't generate code that does not call printf when the > >>> output is redirected. > >> > >> I thought I explained what might have been happening: gcc might end up > >> calling a routine in msvcrt that works a character at a time, rather > >> than a string at a time. And the former might be slower when sent to > >> the console so you don't see a problem with file output. > > > > gcc is a compiler. It generates code that calls printf or similar. > Actually, it doesn't. As I said, it calls an inline version of printf in > its stdio.h, which ends up calling __mingw_vfprintf. > > I /can/ get it to call the same printf I do, by using this declaration > in place of stdio.h: > extern int printf(const char*, ...); > The problem is that it - my gcc installation - does something different. > > After that, what happens is nothing to do with gcc. > You're still trying to play that card. > >>>> What can you tell DFS to make fix this problem when using gcc? > >>> To get 1000-fold increase in speed, ditch Windows. If he or she must > >>> use Windows, find out what's taking the time. > >> > >> Where did the 1000-fold increase come from? The slowdown on my last > >> test was about 14 times, in line with what DFS reported. > > > > > You reported 21s, I measured 0.007s, both using gcc. > The upper limit of what can be achieved on my Windows system using i/o > via msvcrt.dll seems to be about 1.7 seconds for my test (2000 > 80-character strings, approx 100K chars per second. > > It will slow down in every case if I write much shorter strings, or > single characters. > > I can't do much about that. Yet some compilers - sorry compilers plus > whatever components they've been bundled with - exhibit that slowness > even with long strings. > > The difference is > > almost certainly be due to implementation components other than gcc. > > > Sure; I'm using a gcc 'bundle', as nearly everyone will be. But such > installations are huge; most people will have to trust whatever > components have been included. > > You reported 21s, I measured 0.007s, both using gcc. > I think that was test was 10000 16-character strings, with no newlines > so less impact of scrolling. 7ms means 23M characters per second on a > graphical, bit-mapped, scrolling character display. > > (Or I assume it is graphical; if a text-mode display, then that's not > playing the game.) > > At 23Mcps, I don't know what tricks the terminal driver is doing to > achieve that. Maybe it's writing into a virtual screen (a text-mode > buffer not bit-mapped), and only updating the display intermittently. Or > maybe its better at using whatever hardware acceleration exists. > I'd guess, it's much simpler. A Linux terminal maintains a big queue, which, in absence of special commands from the user, is polled by rendering thread on consumer end 50 or 60 times per second. You can see a very similar behavior if you run your "slow" exe from terminal (mintty.exe), supplied with msys2. I'd guess, something similar can be achieved with cmd.exe console by using non-default console output mode (see SetConsoleMode()) but I never tried it. In my practice, I typically *want* printf output to be seen on screen ASAP and don't care in a slightest about achieved throughput. So, I strongly prefer "slow" defaults of cmd.exe and quite often find myself fighting against "fast" defaults of mintty by insertion of fflush(). > The tricks could probably be done on Windows too (eg. using DirectDraw > or whatever). But probably not via the clunky console routines that MS > provides. > > But that is all besides the point, which is this: gcc/clang > installations on plain Windows using a normal console window, do > something that makes printing via printf even slower than it already is.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-09 13:55 +0100 |
| Message-ID | <ser8jf$cd2$1@dont-email.me> |
| In reply to | #162270 |
On 09/08/2021 11:59, Michael S wrote:
> On Monday, August 9, 2021 at 12:54:51 PM UTC+3, Bart wrote:
>> At 23Mcps, I don't know what tricks the terminal driver is doing to
>> achieve that. Maybe it's writing into a virtual screen (a text-mode
>> buffer not bit-mapped), and only updating the display intermittently. Or
>> maybe its better at using whatever hardware acceleration exists.
>>
>
> I'd guess, it's much simpler.
> A Linux terminal maintains a big queue, which, in absence of special commands from the user,
> is polled by rendering thread on consumer end 50 or 60 times per second.
> You can see a very similar behavior if you run your "slow" exe from terminal (mintty.exe), supplied with msys2.
>
> I'd guess, something similar can be achieved with cmd.exe console by using non-default console output mode
> (see SetConsoleMode()) but I never tried it.
Let's take this program:
#include <stdio.h>
int main(void) {
for (int i=0; i<1000000; ++i) {
printf("%d\n",i);
}
}
On Windows, using normal-speed printf, it takes 88 seconds to print
those 1 million numbers (about 80Kcps). But all of them get displayed.
(The binary to text conversion, tested using sprintf, is 0.4 seconds of
that.)
How long does the program take on a normal Linux system? Does each of
those one million numbers get displayed? Or is it only the last
screenful at the time that polling for display update gets done.
If not showing every number, and doing one million scroll operations,
then I'd consider that cheating, and would render timings such as 7ms
meaningless.
(My program run with gcc and without setvbuf or other workarounds took 8
minutes, or about 10Kcps, 8 times as slow as it could have been.
This 8x accords with there being about 8 characters output per printf
call, which include crlf (a detail which would make it marginally slower
than Linux anyway).)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-08-09 16:08 +0200 |
| Message-ID | <serct0$c90$1@dont-email.me> |
| In reply to | #162271 |
On 09/08/2021 14:55, Bart wrote:
> On 09/08/2021 11:59, Michael S wrote:
>> On Monday, August 9, 2021 at 12:54:51 PM UTC+3, Bart wrote:
>
>>> At 23Mcps, I don't know what tricks the terminal driver is doing to
>>> achieve that. Maybe it's writing into a virtual screen (a text-mode
>>> buffer not bit-mapped), and only updating the display intermittently. Or
>>> maybe its better at using whatever hardware acceleration exists.
>>>
>>
>> I'd guess, it's much simpler.
>> A Linux terminal maintains a big queue, which, in absence of special
>> commands from the user,
>> is polled by rendering thread on consumer end 50 or 60 times per second.
>> You can see a very similar behavior if you run your "slow" exe from
>> terminal (mintty.exe), supplied with msys2.
>>
>> I'd guess, something similar can be achieved with cmd.exe console by
>> using non-default console output mode
>> (see SetConsoleMode()) but I never tried it.
>
> Let's take this program:
>
> #include <stdio.h>
>
> int main(void) {
> for (int i=0; i<1000000; ++i) {
> printf("%d\n",i);
> }
> }
>
>
> On Windows, using normal-speed printf, it takes 88 seconds to print
> those 1 million numbers (about 80Kcps). But all of them get displayed.
> (The binary to text conversion, tested using sprintf, is 0.4 seconds of
> that.)
>
> How long does the program take on a normal Linux system? Does each of
> those one million numbers get displayed? Or is it only the last
> screenful at the time that polling for display update gets done.
>
> If not showing every number, and doing one million scroll operations,
> then I'd consider that cheating, and would render timings such as 7ms
> meaningless.
>
> (My program run with gcc and without setvbuf or other workarounds took 8
> minutes, or about 10Kcps, 8 times as slow as it could have been.
>
> This 8x accords with there being about 8 characters output per printf
> call, which include crlf (a detail which would make it marginally slower
> than Linux anyway).)
>
I've been mostly staying out of this conversation - I don't have a
Windows system available for any testing. However, I /can/ do some
timings on Linux.
Testing in a terminal window on my desktop (Linux Mint with Mate, so
approximately Gnome 2), it took 2.1 seconds. All million numbers are
there, and I can scroll back through the window buffer to see them.
Running it multiple times did not affect the timing, though the buffer
for the terminal gets bigger as it still holds all the lines. (This is
not typical behaviour on Windows command-prompt windows.)
Running on a Linux virtual console outside of X, it took 117 seconds on
the same system.
Running within a "screen" environment, with a default 1000 line history,
it was 1.85 seconds - it seems likely that the shorter buffer made it
more efficient.
None of that was using any special settings or commands - it's just the
program you gave, compiled with gcc 9 out of the box, no flags.
Piping the output into a file (6.6 million characters), to test the
speed without rendering the text, was about 0.09 seconds.
Timing for "cat" on this file, in a terminal window, was about 1 second.
So was the time taken to run "time ./test | cat".
Make of all that what you will.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2021-08-09 07:53 -0700 |
| Message-ID | <8d16684f-d1da-436e-8778-07e2adf99404n@googlegroups.com> |
| In reply to | #162272 |
On Monday, 9 August 2021 at 15:08:44 UTC+1, David Brown wrote:
> On 09/08/2021 14:55, Bart wrote:
> > On 09/08/2021 11:59, Michael S wrote:
> >> On Monday, August 9, 2021 at 12:54:51 PM UTC+3, Bart wrote:
> >
> >>> At 23Mcps, I don't know what tricks the terminal driver is doing to
> >>> achieve that. Maybe it's writing into a virtual screen (a text-mode
> >>> buffer not bit-mapped), and only updating the display intermittently. Or
> >>> maybe its better at using whatever hardware acceleration exists.
> >>>
> >>
> >> I'd guess, it's much simpler.
> >> A Linux terminal maintains a big queue, which, in absence of special
> >> commands from the user,
> >> is polled by rendering thread on consumer end 50 or 60 times per second.
> >> You can see a very similar behavior if you run your "slow" exe from
> >> terminal (mintty.exe), supplied with msys2.
> >>
> >> I'd guess, something similar can be achieved with cmd.exe console by
> >> using non-default console output mode
> >> (see SetConsoleMode()) but I never tried it.
> >
> > Let's take this program:
> >
> > #include <stdio.h>
> >
> > int main(void) {
> > for (int i=0; i<1000000; ++i) {
> > printf("%d\n",i);
> > }
> > }
> >
> >
> > On Windows, using normal-speed printf, it takes 88 seconds to print
> > those 1 million numbers (about 80Kcps). But all of them get displayed.
> > (The binary to text conversion, tested using sprintf, is 0.4 seconds of
> > that.)
> >
> > How long does the program take on a normal Linux system? Does each of
> > those one million numbers get displayed? Or is it only the last
> > screenful at the time that polling for display update gets done.
> >
> > If not showing every number, and doing one million scroll operations,
> > then I'd consider that cheating, and would render timings such as 7ms
> > meaningless.
> >
> > (My program run with gcc and without setvbuf or other workarounds took 8
> > minutes, or about 10Kcps, 8 times as slow as it could have been.
> >
> > This 8x accords with there being about 8 characters output per printf
> > call, which include crlf (a detail which would make it marginally slower
> > than Linux anyway).)
> >
> I've been mostly staying out of this conversation - I don't have a
> Windows system available for any testing. However, I /can/ do some
> timings on Linux.
>
> Testing in a terminal window on my desktop (Linux Mint with Mate, so
> approximately Gnome 2), it took 2.1 seconds. All million numbers are
> there, and I can scroll back through the window buffer to see them.
> Running it multiple times did not affect the timing, though the buffer
> for the terminal gets bigger as it still holds all the lines. (This is
> not typical behaviour on Windows command-prompt windows.)
>
> Running on a Linux virtual console outside of X, it took 117 seconds on
> the same system.
>
> Running within a "screen" environment, with a default 1000 line history,
> it was 1.85 seconds - it seems likely that the shorter buffer made it
> more efficient.
>
> None of that was using any special settings or commands - it's just the
> program you gave, compiled with gcc 9 out of the box, no flags.
>
> Piping the output into a file (6.6 million characters), to test the
> speed without rendering the text, was about 0.09 seconds.
>
> Timing for "cat" on this file, in a terminal window, was about 1 second.
> So was the time taken to run "time ./test | cat".
>
> Make of all that what you will.
>
On a modern desktop system, parsing a printf format string, applying the
arguments, and creating a sequence of characters to pass to stdout doesn't
take much time. It's what happens after that stage that accounts for the
dufferences, which can be a factor of hundreds of thousands. Scrolling
a bit-mapped display on the CPU on every line write is going to be much
much slower than discarding the characters.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2021-08-09 08:28 -0700 |
| Message-ID | <2da5e769-c64f-4817-82df-92d8c2b78b6fn@googlegroups.com> |
| In reply to | #162273 |
On Monday, August 9, 2021 at 5:54:01 PM UTC+3, Malcolm McLean wrote:
> On Monday, 9 August 2021 at 15:08:44 UTC+1, David Brown wrote:
> > On 09/08/2021 14:55, Bart wrote:
> > > On 09/08/2021 11:59, Michael S wrote:
> > >> On Monday, August 9, 2021 at 12:54:51 PM UTC+3, Bart wrote:
> > >
> > >>> At 23Mcps, I don't know what tricks the terminal driver is doing to
> > >>> achieve that. Maybe it's writing into a virtual screen (a text-mode
> > >>> buffer not bit-mapped), and only updating the display intermittently. Or
> > >>> maybe its better at using whatever hardware acceleration exists.
> > >>>
> > >>
> > >> I'd guess, it's much simpler.
> > >> A Linux terminal maintains a big queue, which, in absence of special
> > >> commands from the user,
> > >> is polled by rendering thread on consumer end 50 or 60 times per second.
> > >> You can see a very similar behavior if you run your "slow" exe from
> > >> terminal (mintty.exe), supplied with msys2.
> > >>
> > >> I'd guess, something similar can be achieved with cmd.exe console by
> > >> using non-default console output mode
> > >> (see SetConsoleMode()) but I never tried it.
> > >
> > > Let's take this program:
> > >
> > > #include <stdio.h>
> > >
> > > int main(void) {
> > > for (int i=0; i<1000000; ++i) {
> > > printf("%d\n",i);
> > > }
> > > }
> > >
> > >
> > > On Windows, using normal-speed printf, it takes 88 seconds to print
> > > those 1 million numbers (about 80Kcps). But all of them get displayed.
> > > (The binary to text conversion, tested using sprintf, is 0.4 seconds of
> > > that.)
> > >
> > > How long does the program take on a normal Linux system? Does each of
> > > those one million numbers get displayed? Or is it only the last
> > > screenful at the time that polling for display update gets done.
> > >
> > > If not showing every number, and doing one million scroll operations,
> > > then I'd consider that cheating, and would render timings such as 7ms
> > > meaningless.
> > >
> > > (My program run with gcc and without setvbuf or other workarounds took 8
> > > minutes, or about 10Kcps, 8 times as slow as it could have been.
> > >
> > > This 8x accords with there being about 8 characters output per printf
> > > call, which include crlf (a detail which would make it marginally slower
> > > than Linux anyway).)
> > >
> > I've been mostly staying out of this conversation - I don't have a
> > Windows system available for any testing. However, I /can/ do some
> > timings on Linux.
> >
> > Testing in a terminal window on my desktop (Linux Mint with Mate, so
> > approximately Gnome 2), it took 2.1 seconds. All million numbers are
> > there, and I can scroll back through the window buffer to see them.
> > Running it multiple times did not affect the timing, though the buffer
> > for the terminal gets bigger as it still holds all the lines. (This is
> > not typical behaviour on Windows command-prompt windows.)
> >
> > Running on a Linux virtual console outside of X, it took 117 seconds on
> > the same system.
> >
> > Running within a "screen" environment, with a default 1000 line history,
> > it was 1.85 seconds - it seems likely that the shorter buffer made it
> > more efficient.
> >
> > None of that was using any special settings or commands - it's just the
> > program you gave, compiled with gcc 9 out of the box, no flags.
> >
> > Piping the output into a file (6.6 million characters), to test the
> > speed without rendering the text, was about 0.09 seconds.
> >
> > Timing for "cat" on this file, in a terminal window, was about 1 second.
> > So was the time taken to run "time ./test | cat".
> >
> > Make of all that what you will.
> >
> On a modern desktop system, parsing a printf format string, applying the
> arguments, and creating a sequence of characters to pass to stdout doesn't
> take much time.
Funny that you are saying that.
Waiting for printf to finish writing to file (on decent SSD, nontheless, so I/O does not appears
to be a major bottleneck) is what made my today's job uncomfortable.
printf of 180M floating point numbers takes more than 2 minutes which is quite disruptive
to a workflow.
> It's what happens after that stage that accounts for the
> dufferences, which can be a factor of hundreds of thousands. Scrolling
> a bit-mapped display on the CPU on every line write is going to be much
> much slower than discarding the characters.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2021-08-09 08:19 -0700 |
| Message-ID | <16c39c11-53c7-46bc-9a0a-dfd8684a52can@googlegroups.com> |
| In reply to | #162272 |
On Monday, August 9, 2021 at 5:08:44 PM UTC+3, David Brown wrote:
> On 09/08/2021 14:55, Bart wrote:
> > On 09/08/2021 11:59, Michael S wrote:
> >> On Monday, August 9, 2021 at 12:54:51 PM UTC+3, Bart wrote:
> >
> >>> At 23Mcps, I don't know what tricks the terminal driver is doing to
> >>> achieve that. Maybe it's writing into a virtual screen (a text-mode
> >>> buffer not bit-mapped), and only updating the display intermittently. Or
> >>> maybe its better at using whatever hardware acceleration exists.
> >>>
> >>
> >> I'd guess, it's much simpler.
> >> A Linux terminal maintains a big queue, which, in absence of special
> >> commands from the user,
> >> is polled by rendering thread on consumer end 50 or 60 times per second.
> >> You can see a very similar behavior if you run your "slow" exe from
> >> terminal (mintty.exe), supplied with msys2.
> >>
> >> I'd guess, something similar can be achieved with cmd.exe console by
> >> using non-default console output mode
> >> (see SetConsoleMode()) but I never tried it.
> >
> > Let's take this program:
> >
> > #include <stdio.h>
> >
> > int main(void) {
> > for (int i=0; i<1000000; ++i) {
> > printf("%d\n",i);
> > }
> > }
> >
> >
> > On Windows, using normal-speed printf, it takes 88 seconds to print
> > those 1 million numbers (about 80Kcps). But all of them get displayed.
> > (The binary to text conversion, tested using sprintf, is 0.4 seconds of
> > that.)
> >
> > How long does the program take on a normal Linux system? Does each of
> > those one million numbers get displayed? Or is it only the last
> > screenful at the time that polling for display update gets done.
> >
> > If not showing every number, and doing one million scroll operations,
> > then I'd consider that cheating, and would render timings such as 7ms
> > meaningless.
> >
> > (My program run with gcc and without setvbuf or other workarounds took 8
> > minutes, or about 10Kcps, 8 times as slow as it could have been.
> >
> > This 8x accords with there being about 8 characters output per printf
> > call, which include crlf (a detail which would make it marginally slower
> > than Linux anyway).)
> >
> I've been mostly staying out of this conversation - I don't have a
> Windows system available for any testing. However, I /can/ do some
> timings on Linux.
>
> Testing in a terminal window on my desktop (Linux Mint with Mate, so
> approximately Gnome 2), it took 2.1 seconds. All million numbers are
> there, and I can scroll back through the window buffer to see them.
Yes, they are there, in the buffer. But absolute majority of them they quite certainly never were seen on display.
It's just physically impossible, considering that display's vertical refresh
rate is measured in dozens per second.
> Running it multiple times did not affect the timing, though the buffer
> for the terminal gets bigger as it still holds all the lines. (This is
> not typical behaviour on Windows command-prompt windows.)
>
Much worse than "not typical".
For both cmd.exe and powershell not just an "out-of-the-box" default is very short (although less short for powershell), but configurable maximum is also short - 9999 lines.
> Running on a Linux virtual console outside of X, it took 117 seconds on
> the same system.
>
> Running within a "screen" environment, with a default 1000 line history,
> it was 1.85 seconds - it seems likely that the shorter buffer made it
> more efficient.
>
> None of that was using any special settings or commands - it's just the
> program you gave, compiled with gcc 9 out of the box, no flags.
>
> Piping the output into a file (6.6 million characters), to test the
> speed without rendering the text, was about 0.09 seconds.
>
> Timing for "cat" on this file, in a terminal window, was about 1 second.
> So was the time taken to run "time ./test | cat".
>
> Make of all that what you will.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-09 16:51 +0100 |
| Message-ID | <seritq$kjb$1@dont-email.me> |
| In reply to | #162274 |
On 09/08/2021 16:19, Michael S wrote: > On Monday, August 9, 2021 at 5:08:44 PM UTC+3, David Brown wrote: >> On 09/08/2021 14:55, Bart wrote: >>> On 09/08/2021 11:59, Michael S wrote: >>> How long does the program take on a normal Linux system? Does each of >>> those one million numbers get displayed? Or is it only the last >>> screenful at the time that polling for display update gets done. >>> >>> If not showing every number, and doing one million scroll operations, >>> then I'd consider that cheating, and would render timings such as 7ms >>> meaningless. >> I've been mostly staying out of this conversation - I don't have a >> Windows system available for any testing. However, I /can/ do some >> timings on Linux. >> >> Testing in a terminal window on my desktop (Linux Mint with Mate, so >> approximately Gnome 2), it took 2.1 seconds. All million numbers are >> there, and I can scroll back through the window buffer to see them. > > Yes, they are there, in the buffer. But absolute majority of them they quite certainly never were seen on display. > It's just physically impossible, considering that display's vertical refresh > rate is measured in dozens per second. I don't know exactly how today's displays work. But in the past certainly, you usually had some dedicated video memory, which is what your application wrote into via OS calls. There was a separate circuit which scanned that video memory once per frame to update the physical display (CRT, whatever). So it was quite possible to update the video memory faster than the display could be updated. So that it wouldn't show all the output even if you filmed the display and played it back in slow motion. What takes the time is rendering text into that video memory, and also scrolling that window for each new line. What's in question is whether the Linux drivers bother rendering every single change, asynchronously from the display frame rate, or only do so once per frame. So it may show 1 to 60 (for 60 rows) and the next frame it might show rows 1000 to 1059 which are the last 60 rows in the /text/ buffer. It's possible that Windows also does something of the sort, but that other parts are slow (and slower than the frame rate) so that you end up seeing all the output. However the discussion is about how some compilers make the display even slower than it is. > >> Running it multiple times did not affect the timing, though the buffer >> for the terminal gets bigger as it still holds all the lines. (This is >> not typical behaviour on Windows command-prompt windows.) >> > > Much worse than "not typical". > For both cmd.exe and powershell not just an "out-of-the-box" default is very short (although less short for powershell), but configurable maximum is also short - 9999 lines. The scrolling buffer I use is the same height as the console window - 60 lines. (Otherwise various bugs manifest themselves.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-08-09 16:47 +0100 |
| Message-ID | <87r1f2k4bc.fsf@bsb.me.uk> |
| In reply to | #162268 |
Bart <bc@freeuk.com> writes: > On 09/08/2021 01:46, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 08/08/2021 22:17, Ben Bacarisse wrote: >>>> Bart <bc@freeuk.com> writes: >>> >>>>> The 'problem' is with clang/gcc calling 'printf'. All compilers are >>>>> told to use printf, yet only these two compilers end up being slow. >>>> I thought you said the problem goes away when the output is redirected? >>>> gcc and clang don't generate code that does not call printf when the >>>> output is redirected. >>> >>> I thought I explained what might have been happening: gcc might end up >>> calling a routine in msvcrt that works a character at a time, rather >>> than a string at a time. And the former might be slower when sent to >>> the console so you don't see a problem with file output. >> gcc is a compiler. It generates code that calls printf or similar. > > Actually, it doesn't. As I said, it calls an inline version of printf > in its stdio.h, which ends up calling __mingw_vfprintf. "... or similar". I did not want to have to list all the possible printf-like functions (some of which are going to be internal ones like this) that it might call. >> After that, what happens is nothing to do with gcc. > > You're still trying to play that card. Curious spin. My spin: it's called using words correctly. There is no doubt you have a terrible C implementation (well, two actually, since you also report absurdly slow times for what you call "tcc"), but I don't see any evidence that gcc (or tcc for that matter) is the problem. If you wanted to fix it, you'd have to know what components are really contributing to the times you see. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-09 17:09 +0100 |
| Message-ID | <serk0o$bc0$1@dont-email.me> |
| In reply to | #162276 |
On 09/08/2021 16:47, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> On 09/08/2021 01:46, Ben Bacarisse wrote: >>> After that, what happens is nothing to do with gcc. >> >> You're still trying to play that card. > > Curious spin. My spin: it's called using words correctly. There is no > doubt you have a terrible C implementation (well, two actually, since > you also report absurdly slow times for what you call "tcc"), tcc and bcc can print stuff to the console as fast as anything else. If those 1000000 numbers were written to a file, and then I got the OS to display that file using TYPE, it will take 88 or whatever seconds just like the C program. If you're getting silly times like 7msec, then that's likely an illusion as discussed in recent posts, since you're only seeing a snapshot of the output once per frame. > but I > don't see any evidence that gcc (or tcc for that matter) is the problem. The problem here is NOT that Windows has slow console printing. All language/all apps will share that problem. The problem is that gcc and clang are N times slower than that, where N is the average length of the string that printf ends up outputting. There are workarounds but, out-of-the-box, that is what those products do on their Windows installations. (Note that Clang has a more official Windows binary download site than gcc, but it is just as slow. Maybe it is just trying to be compatible.)
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2021-08-08 15:30 -0700 |
| Message-ID | <2a1b4347-595a-469a-8df1-db64af9896acn@googlegroups.com> |
| In reply to | #162257 |
On Monday, August 9, 2021 at 12:17:59 AM UTC+3, Ben Bacarisse wrote:
> Bart <b...@freeuk.com> writes:
>
> > On 08/08/2021 20:21, Ben Bacarisse wrote:
> >> Bart <b...@freeuk.com> writes:
> >>
> >>>> 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.
> >> You often post times with no indication of what's being measured.
> >
> > Huh? The test program is shown above. A tcc-compiled program takes 7
> > times as long as gcc- or clang-compiled one. On Windows (I know Linux
> > has super-fast console output).
> >
> > What I'm measuring is how long between starting the program, and
> > finishing writing stuff to the screen, because on Windows you can see
> > all this output scrolling up the screen.
> You've been in the business for many years. I can't believe you don't
> know what I mean.
> >> The
> >> compiler probably has little to do with it. What C library is being
> >> used? How is the output handled?
> >
> > I don't know, but... should anyone really have to delve into the exact
> > implementation of printf to get it to do its job properly? It should
> > just work! Which means not working a magnitude slower than it should.
> I my machine is three times faster than yours (just to get a simple
> number) we are talking about three orders of magnitude. Do you think
> that's down to the implementation of printf? You certainly haven't
> posted any data to support that.
> > See my other post a few minutes after yours for further investigations.
> >
> >>> You can try bypassing printf in gcc by using sprintf to a string for a
> >>> complete line of output, then using puts() on the string. However you
> >>> shouldn't need to do this.
> >> Why do you think the problem (whatever it is) has got anything to do
> >> with gcc if the problem disappears when the output is redirected?
> >
> > The 'problem' is with clang/gcc calling 'printf'. All compilers are
> > told to use printf, yet only these two compilers end up being slow.
> I thought you said the problem goes away when the output is redirected?
> gcc and clang don't generate code that does not call printf when the
> output is redirected.
> > But if that is the case, who's fault is that, and what can one do
> > about it? Do you think it is likely to involve messing with the
> > options for these gcc or clang installations?
> >
> > Because you seem keen to put the blame elsewhere.
> Because I think the blame must be elsewhere, but I'm not going to
> install Windows (and all the other stuff one might need) just to find
> out.
That, probably, wouldn't help.
Bart and DFS are unique people with unique capabilities.
DFS more so, but Bart's ability to hit roadbles that almost nobody else hit also shouldn't be underestimated.
Out of interest, I logged into machine where I have several cygwin installations
(all coming with various versions of Altera Nios II EDS suit) ranging from 2009 to 2018.
I compiles Bart's program and run it. I looked a bit slow, but not dramatically so.
I timed it with time. Depending on the version, time varied between 90 and 370 msec.
Yes, it's very slow (under MSYS2, on my significantly older and slower home desktop, it took 20ms,
of which, I'd guess, more than half is loading program rather than running it) but not *nearly* as slow
as reported by Bart and DFS.
But then I figured out how to make it *really* slow.
First, you should find *very* old cygwin. Of all my installations only one from 2009 is old enough.
Second, you should compile/link with flag '-mno-cygwin".
Third, you should run the executive in normal windows command window rather than in cygwing window.
Only then you will be able to see the slowness.
It seems, this particular combination of tools and environment dislikes very long lines.
It's still not guaranteed, that you'll see times, reported by Bart. It depends on many factors, most
importantly, on the exact size of your command window.
Personally, I had never seen more than 2.5 or 3 seconds.
But that difference , at least, can be explained by difference in speed between my hardware
(4-5 y.o. Haswell with 32GB of RAM and decent SSD) and the hardware used by Bart.
> > What can you tell DFS to make fix this problem when using gcc?
> To get 1000-fold increase in speed, ditch Windows. If he or she must
> use Windows, find out what's taking the time.
>
> --
> Ben.
[toc] | [prev] | [next] | [standalone]
Page 9 of 20 — ← Prev page 1 … 7 8 [9] 10 11 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web