Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #54051 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2014-12-07 14:48 -0800 |
| Last post | 2014-12-12 02:24 -0800 |
| Articles | 19 on this page of 299 — 34 participants |
Back to article view | Back to comp.lang.c
which one is better fir <profesor.fir@gmail.com> - 2014-12-07 14:48 -0800
Re: which one is better Siri Crews <chine.bleu@yahoo.com> - 2014-12-07 16:14 -0800
Re: which one is better glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-08 01:28 +0000
Re: which one is better Siri Crews <chine.bleu@yahoo.com> - 2014-12-07 19:01 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-08 00:32 -0800
Re: which one is better Siri Crews <chine.bleu@yahoo.com> - 2014-12-08 01:40 -0800
which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-07 19:00 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-08 00:35 -0800
Re: which one is better gordonb.7ngx1@burditt.org (Gordon Burditt) - 2014-12-16 06:28 -0600
Re: which one is better BartC <bc@freeuk.com> - 2014-12-16 13:08 +0000
Re: which one is better Richard Damon <Richard@Damon-Family.org> - 2014-12-16 23:49 -0500
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-16 05:15 -0800
Re: which one is better gordonb.9nipv@burditt.org (Gordon Burditt) - 2014-12-17 02:22 -0600
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-17 01:21 -0800
Re: which one is better Robert Wessel <robertwessel2@yahoo.com> - 2014-12-18 02:21 -0600
Re: which one is better Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-11 12:34 +0100
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 05:33 -0800
Re: which one is better Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-11 16:27 +0100
Re: which one is better gordonb.cx8yb@burditt.org (Gordon Burditt) - 2014-12-16 06:58 -0600
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 15:05 +0000
Re: which one is better Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-11 16:31 +0100
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 17:11 +0000
Re: which one is better Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-11 18:44 +0100
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 10:19 -0800
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 20:07 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-11 20:52 +0000
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 22:10 +0000
Re: which one is better Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-11 22:57 +0100
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-11 15:34 +0000
Re: which one is better Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-11 16:45 +0100
Re: which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 07:56 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-11 16:08 +0000
Re: which one is better Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-11 17:19 +0100
Re: which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 08:35 -0800
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 17:09 +0000
Re: which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 09:58 -0800
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 20:13 +0000
Re: which one is better glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-11 20:18 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-11 12:57 -0800
Re: which one is better Robert Wessel <robertwessel2@yahoo.com> - 2014-12-12 01:55 -0600
Re: which one is better Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-12-12 03:03 -0500
Re: which one is better Robert Wessel <robertwessel2@yahoo.com> - 2014-12-12 02:30 -0600
Re: which one is better glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-14 04:03 +0000
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 17:04 +0000
Re: which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 08:53 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-11 17:49 +0000
Re: which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 10:18 -0800
Re: which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 10:43 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 11:50 -0800
Re: which one is better John Bode <jfbode1029@gmail.com> - 2014-12-11 12:10 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-11 20:30 +0000
Re: which one is better John Bode <jfbode1029@gmail.com> - 2014-12-11 13:19 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 13:32 -0800
Re: which one is better gordonb.ygnb6@burditt.org (Gordon Burditt) - 2014-12-16 08:00 -0600
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-16 06:23 -0800
Re: which one is better gordonb.ne8xc@burditt.org (Gordon Burditt) - 2014-12-17 02:38 -0600
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-17 01:29 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-17 02:31 -0800
Re: which one is better gordonb.dwhy1@burditt.org (Gordon Burditt) - 2014-12-19 02:50 -0600
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-19 05:03 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-17 01:48 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-17 01:57 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-17 02:21 -0800
Re: which one is better Phil Carmody <pc+usenet@asdf.org> - 2014-12-18 01:53 +0200
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 00:42 -0800
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-18 11:33 +0100
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 02:46 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 03:00 -0800
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-18 12:35 +0100
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 03:53 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 12:10 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 04:45 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 04:55 -0800
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-18 14:50 +0100
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 07:16 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 07:36 -0800
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-18 16:42 +0100
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 07:52 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:06 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 03:58 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 04:09 -0800
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-18 14:51 +0100
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-18 08:24 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 08:29 -0800
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-18 10:56 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 12:08 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 04:15 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-18 12:55 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 05:12 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 13:19 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 05:41 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 13:49 +0000
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 13:09 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 05:22 -0800
Re: which one is better Phil Carmody <pc+usenet@asdf.org> - 2014-12-23 12:32 +0200
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-24 02:10 -0800
Re: which one is better John Bode <jfbode1029@gmail.com> - 2014-12-11 13:35 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-11 22:08 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-11 22:00 +0000
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-11 22:08 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-11 15:38 -0800
Re: which one is better glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-12 02:29 +0000
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 20:26 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-11 12:56 -0800
Re: which one is better Robert Wessel <robertwessel2@yahoo.com> - 2014-12-12 02:05 -0600
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 00:44 -0800
Re: which one is better Robert Wessel <robertwessel2@yahoo.com> - 2014-12-18 02:24 -0600
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 20:17 +0000
Re: which one is better Phil Carmody <pc+usenet@asdf.org> - 2014-12-18 01:14 +0200
Re: which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 06:15 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 06:25 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-11 15:00 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 07:28 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 07:42 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 08:01 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 08:37 -0800
Re: which one is better Nobody <nobody@nowhere.invalid> - 2014-12-14 05:46 +0000
Re: which one is better John Bode <jfbode1029@gmail.com> - 2014-12-11 08:14 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 08:26 -0800
Re: which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 08:32 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-11 16:45 +0000
Re: which one is better glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-12 02:35 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-11 20:36 -0800
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-12 05:14 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-12 06:20 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 09:23 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-12 10:22 +0000
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 10:43 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-12 11:11 +0000
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 11:43 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 04:47 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 12:51 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 05:10 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 13:25 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 05:57 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 14:15 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 06:49 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 14:51 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 06:57 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-13 01:50 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-13 02:15 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 05:36 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-12 13:51 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 06:00 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-12 14:56 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 07:08 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 07:32 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-12 15:36 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 08:26 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 10:27 -0800
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-12 07:46 -0800
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-15 09:57 +0100
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-15 09:54 +0100
Re: which one is better John Bode <jfbode1029@gmail.com> - 2014-12-12 10:03 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-12 11:14 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-12 11:46 +0000
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-12 12:05 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-12 12:27 +0000
Re: which one is better Phil Carmody <pc+usenet@asdf.org> - 2014-12-18 02:11 +0200
Re: which one is better glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-14 04:15 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-13 21:19 -0800
Re: which one is better Richard Damon <Richard@Damon-Family.org> - 2014-12-12 22:51 -0500
Re: which one is better gordonb.3w2i6@burditt.org (Gordon Burditt) - 2014-12-16 09:09 -0600
Re: which one is better Lynn McGuire <lmc@winsim.com> - 2014-12-11 16:12 -0600
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-11 14:29 -0800
Re: which one is better Lynn McGuire <lmc@winsim.com> - 2014-12-11 17:32 -0600
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-11 15:39 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-11 23:55 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-11 15:57 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-12 00:29 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-11 16:52 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-12 10:47 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-12 03:40 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 11:52 +0000
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-12 13:00 +0100
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 12:43 +0000
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-12 13:51 +0100
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 12:59 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-12 13:29 +0000
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 14:10 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-12 15:01 +0000
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 15:47 +0000
Re: which one is better gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-12 16:07 +0000
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-12 17:51 -0800
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-12 21:10 -0800
Re: which one is better Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-12-13 01:40 +0000
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-12 18:17 -0800
Re: which one is better Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-12-13 02:29 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-13 10:25 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-13 13:43 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-13 22:44 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-13 15:24 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-14 01:07 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-13 19:18 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-14 12:01 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-14 12:44 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-14 20:57 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-14 13:24 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-14 13:29 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-14 14:03 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-14 14:34 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-14 15:08 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-14 15:55 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 00:52 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-17 08:05 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 00:25 -0800
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-14 14:33 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-14 23:28 +0000
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-14 15:42 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-15 01:07 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 02:44 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-15 11:02 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 03:13 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 03:26 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-15 11:19 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 03:31 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-15 11:50 +0000
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-15 11:59 +0000
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-15 10:50 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-15 18:57 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 04:15 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 04:31 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 04:39 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 04:43 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 04:52 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 05:10 -0800
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-15 12:43 +0100
Re: which one is better BartC <bc@freeuk.com> - 2014-12-15 11:59 +0000
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-15 14:03 +0100
Re: which one is better BartC <bc@freeuk.com> - 2014-12-15 13:28 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 06:09 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 06:35 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-16 03:13 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-15 14:06 +0000
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-15 10:46 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 10:53 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-15 19:20 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 12:18 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 12:40 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 04:03 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 03:05 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-15 11:32 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 03:38 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-15 17:20 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 09:40 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-15 17:59 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-15 10:34 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 10:01 -0800
Re: which one is better gordonb.3j8fq@burditt.org (Gordon Burditt) - 2014-12-16 10:18 -0600
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-15 18:08 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 10:37 -0800
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-15 21:05 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 14:10 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 14:18 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-15 22:22 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 14:58 -0800
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-15 15:34 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 17:25 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-16 02:55 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-16 03:20 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-16 03:37 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 05:00 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-15 01:41 +0000
Re: which one is better Robert Wessel <robertwessel2@yahoo.com> - 2014-12-18 02:33 -0600
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-18 00:42 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-14 21:47 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-14 15:55 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-14 16:03 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-15 00:54 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-16 10:55 +0000
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-16 11:11 +0000
Re: which one is better Ian Collins <ian-news@hotmail.com> - 2014-12-15 14:01 +1300
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-15 10:09 +0100
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-12 15:58 +0100
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 15:41 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-12 18:27 +0000
Re: which one is better Ian Collins <ian-news@hotmail.com> - 2014-12-13 08:42 +1300
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 19:59 +0000
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-12 07:39 -0800
Re: which one is better gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-12 16:05 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-12 08:16 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 16:43 +0000
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-12 14:01 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-12 06:15 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-12 16:10 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-12 08:28 -0800
Re: which one is better gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-12 15:27 +0000
Re: which one is better gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-12 14:39 +0000
Re: which one is better Morris Dovey <mrdovey@iedu.com> - 2014-12-12 11:11 -0600
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 09:34 -0800
Re: which one is better Ian Collins <ian-news@hotmail.com> - 2014-12-12 21:47 +1300
Re: which one is better Ken Brody <kenbrody@spamcop.net> - 2014-12-16 12:30 -0500
Re: which one is better Stephen Sprunk <stephen@sprunk.org> - 2014-12-16 12:21 -0600
Re: which one is better Robert Wessel <robertwessel2@yahoo.com> - 2014-12-16 13:06 -0600
Re: which one is better Stephen Sprunk <stephen@sprunk.org> - 2014-12-16 16:44 -0600
Re: which one is better Robert Wessel <robertwessel2@yahoo.com> - 2014-12-16 18:21 -0600
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 01:04 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 02:06 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 02:24 -0800
Page 15 of 15 — ← Prev page 1 … 13 14 [15]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-12 08:16 -0800 |
| Message-ID | <lnppbokfmr.fsf@nuthaus.mib.org> |
| In reply to | #54369 |
David Brown <david.brown@hesbynett.no> writes:
> On 12/12/14 13:43, Richard Heathfield wrote:
[...]
>> We already had int, short int, and long int. (We didn't actually need short
>> int or long int, either.)
>
> But those don't cover the range of integer types supported by modern
> processors or modern cpus, and they don't give good enough
> specifications of the sizes for applications that need to know exact types.
>
> Compilers have always been free to implement "extended integer types"
> providing such features - the <stdint.h> types gave a standard defined
> way to name these types (when they exist on the target).
Well, sort of. "Extended integer types" were introduced by the C99
standard. C90 compilers could provide additional integer types (some
did provide long long, for example), but as a language extension.
Which means that a conforming C90 compiler must diagnose "long long"
as a syntax error, and the language did not require long long to
behave like other integer types.
Incidentally, I haven't seen any compilers that implement extended
integer types as specified by the C99 and C11 standards. gcc comes
close with its support for `__int128` and `unsigned __int128` on
some platforms, but intmax_t is still only 64 bits, which would
be non-conforming if __int128 were an extended integer type as
described in the standard.
> It would have been possible for the C standards to specify that a char
> is 8-bit, short is 16-bit, int is 32-bit and long is 64-bit. Then we
> would not need the <stdint.h> types (at least, not until 128-bit types
> become common). But that's not the way the C standards are written.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-12 16:43 +0000 |
| Message-ID | <tWEiw.180523$td6.85972@fx30.am4> |
| In reply to | #54404 |
Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 12/12/14 13:43, Richard Heathfield wrote: > [...] >>> We already had int, short int, and long int. (We didn't actually need >>> short int or long int, either.) >> >> But those don't cover the range of integer types supported by modern >> processors or modern cpus, and they don't give good enough >> specifications of the sizes for applications that need to know exact >> types. >> >> Compilers have always been free to implement "extended integer types" >> providing such features - the <stdint.h> types gave a standard defined >> way to name these types (when they exist on the target). > > Well, sort of. "Extended integer types" were introduced by the C99 > standard. C90 compilers could provide additional integer types (some > did provide long long, for example), but as a language extension. > Which means that a conforming C90 compiler must diagnose "long long" > as a syntax error, To be more precise, it must issue a diagnostic message, but it does not have to diagnose "long long" as a syntax error, just as long as it diagnoses it in some way. The semantics of the message is left up to the implementation, and is not required to be helpful or even meaningful. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-12-12 14:01 +0000 |
| Message-ID | <878uid7ys6.fsf@bsb.me.uk> |
| In reply to | #54358 |
rick.c.hodgin@gmail.com writes:
> Ben Bacarisse wrote:
>> I'll try to remember that when you say
>> something is obvious (or goes without saying)
>> you mean that a typedef and two macros can
>> make it correct on at least one system!
>
> I view such syntax semantics as they relate to
> subtle differences in naming conventions across
> compilers to be well understood as the cost of
> doing business in C, and something to be worked
> through.
I don't get this at all. The cost of programming in C is to be
accurate. You need to know the exact names of functions, and the types
of their parameters, to use them correctly. It was exactly existence of
subtle differences between a whole slew of related functions that it
seemed worth pointing out that fseek64 is not _fseeki64 and that neither
uses int64.
> I apologized because you either do not understand
> such things and I presumed too much of your
> skills and abilities,
That does not require an apology. In fact it's quite rude to apologise
in such a situation. Note that it's fine to apologise for assuming too
much knowledge ("I'm sorry, I thought you were knew the Windows API")
but not for assuming an ability ("I'm sorry you are stupid").
> or because you were being
> strict and explicit, and I wasn't being that way
> when you needed me to be.
Should you decide that it is the latter, and not the former, I accept
your apology.
> I was not trying to offend you. For me such
> subtle differences are intuitively understood in
> most cases, and certainly in the __int64 to int64
> fseek64() to _fseeki64(), and ftell64() to _ftelli64()
> forms. Even now reading these lines... it seems
> obvious and inherently intuitive.
That seems like an odd point of view for a programmer. I am at least
dimly aware of a large number of related functions on different systems:
lseek, lseek64, fseek, fseeko, fseek64 and _fseeki64 to name those that
come to mind. The offset types for these are various, and aren't even
fixed by knowing the function name. None of them use a type called
int64. What is "obvious and inherently intuitive" to you is not so to
me.
> It's difficult for me to know your purpose when
> there are things which to me seem so obvious
> being pointed out to me as fundamental errors
> in my writing.
How could this possibly be a fundamental error?
> It makes me think you're just
> being difficult to be difficult. I hope I'm wrong
> about that because it's a very sad way to be.
I am being picky for the sake of being picky. I did not want it to be
difficult for anyone. My normal reply to a detail like this is "yes,
thanks" or "ah, yes, that was too vague of me" or something like that.
I like the fact that mistakes get spotted on Usenet, though I rarely
like it when they are mine.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | rick.c.hodgin@gmail.com |
|---|---|
| Date | 2014-12-12 06:15 -0800 |
| Message-ID | <ba798ce5-fb06-42ef-b6ef-afa37a162463@googlegroups.com> |
| In reply to | #54381 |
On Friday, December 12, 2014 9:01:22 AM UTC-5, Ben Bacarisse wrote:
> rick.c.hodgin@gmail.com writes:
>
> > Ben Bacarisse wrote:
> >> I'll try to remember that when you say
> >> something is obvious (or goes without saying)
> >> you mean that a typedef and two macros can
> >> make it correct on at least one system!
> >
> > I view such syntax semantics as they relate to
> > subtle differences in naming conventions across
> > compilers to be well understood as the cost of
> > doing business in C, and something to be worked
> > through.
>
> I don't get this at all. The cost of programming in C is to be
> accurate. You need to know the exact names of functions, and the types
> of their parameters, to use them correctly. It was exactly existence of
> subtle differences between a whole slew of related functions that it
> seemed worth pointing out that fseek64 is not _fseeki64 and that neither
> uses int64.
I wasn't writing software, I was explaining a concept. When you get
above 2GB you need to move to their 64-bit counterparts.
> > I apologized because you either do not understand
> > such things and I presumed too much of your
> > skills and abilities,
>
> That does not require an apology. In fact it's quite rude to apologise
> in such a situation. Note that it's fine to apologise for assuming too
> much knowledge ("I'm sorry, I thought you were knew the Windows API")
> but not for assuming an ability ("I'm sorry you are stupid").
>
> > or because you were being
> > strict and explicit, and I wasn't being that way
> > when you needed me to be.
>
> Should you decide that it is the latter, and not the former, I accept
> your apology.
>
> > I was not trying to offend you. For me such
> > subtle differences are intuitively understood in
> > most cases, and certainly in the __int64 to int64
> > fseek64() to _fseeki64(), and ftell64() to _ftelli64()
> > forms. Even now reading these lines... it seems
> > obvious and inherently intuitive.
>
> That seems like an odd point of view for a programmer. I am at least
> dimly aware of a large number of related functions on different systems:
> lseek, lseek64, fseek, fseeko, fseek64 and _fseeki64 to name those that
> come to mind. The offset types for these are various, and aren't even
> fixed by knowing the function name. None of them use a type called
> int64. What is "obvious and inherently intuitive" to you is not so to
> me.
What is obvious and intuitive to me is that there are a large variation
of those types of functions on different systems, and rather than saying
"you use _fseeki64() and _ftelli64() on Windows, and x and y on platform
Q, and z and a on platform R [and so on]" I simply said you use fseek64()
and ftell64(), thinking that it is obvious you'll find the appropriate
one for your target platform.
> > It's difficult for me to know your purpose when
> > there are things which to me seem so obvious
> > being pointed out to me as fundamental errors
> > in my writing.
>
> How could this possibly be a fundamental error?
You indicated in your response with an exclamation point that in order
for my comment to be correct on even one system... Sounds like you
were viewing it as a fundamental error.
> > It makes me think you're just
> > being difficult to be difficult. I hope I'm wrong
> > about that because it's a very sad way to be.
>
> I am being picky for the sake of being picky. I did not want it to be
> difficult for anyone. My normal reply to a detail like this is "yes,
> thanks" or "ah, yes, that was too vague of me" or something like that.
> I like the fact that mistakes get spotted on Usenet, though I rarely
> like it when they are mine.
I don't view my post as a mistake. I view it as a conveyance of a
concept that, while related to the C language, was not in explicit C
source code. And even beyond that, there are times when I'm able to
recognize the idea of the thing I'd like to pass along to someone as
assistance, but am not in front of a computer with a C compiler and
cannot test the exact syntax, so I post the general framework thinking
that there is benefit there, and someone can find my left out comma,
or mistyped this or that, and use my knowledge while working through
a few specifics themselves. And if they can't, they'll ask, and when
I later return to a computer with a C compiler I'll test it out for
them and post it exactly, etc. However, I view us as a community, and
whereas each of us may have lots of overlapping knowledge, such as
being able to fixup another person's work in most areas, there are
still areas where each of us have unique backgrounds, experience, and
expertise. In those areas I can see the need for being precise. But
in the general concepts, most of the time, especially in the type of
discourse as seen in this thread regarding the limitations of fseek()
and ftell() on binary files ... it seems beyond superfluous.
Perhaps we are just at different places on this. I'm fine with that,
and what I've conveyed here is an attempt to convey my reasoning and
thinking, and not to argue the point.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-12-12 16:10 +0000 |
| Message-ID | <87ppbo7ss7.fsf@bsb.me.uk> |
| In reply to | #54383 |
rick.c.hodgin@gmail.com writes:
> On Friday, December 12, 2014 9:01:22 AM UTC-5, Ben Bacarisse wrote:
>> rick.c.hodgin@gmail.com writes:
>>
>> > Ben Bacarisse wrote:
>> >> I'll try to remember that when you say
>> >> something is obvious (or goes without saying)
>> >> you mean that a typedef and two macros can
>> >> make it correct on at least one system!
>> >
>> > I view such syntax semantics as they relate to
>> > subtle differences in naming conventions across
>> > compilers to be well understood as the cost of
>> > doing business in C, and something to be worked
>> > through.
>>
>> I don't get this at all. The cost of programming in C is to be
>> accurate. You need to know the exact names of functions, and the types
>> of their parameters, to use them correctly. It was exactly existence of
>> subtle differences between a whole slew of related functions that it
>> seemed worth pointing out that fseek64 is not _fseeki64 and that neither
>> uses int64.
>
> I wasn't writing software, I was explaining a concept. When you get
> above 2GB you need to move to their 64-bit counterparts.
So I now see. It would have saved some time if you'd said that. The
presence of what are actual function names, brackets and all, made me
think you were talking about function with those actual names (maybe you
didn't know there were functions with those exact names?) Had you, at
the time, used your eloquent summary of what you meant ("use the 64-bit
counterparts") the whole thing would have been avoided.
<snip>
>> I am being picky for the sake of being picky. I did not want it to be
>> difficult for anyone. My normal reply to a detail like this is "yes,
>> thanks" or "ah, yes, that was too vague of me" or something like that.
>> I like the fact that mistakes get spotted on Usenet, though I rarely
>> like it when they are mine.
>
> I don't view my post as a mistake. I view it as a conveyance of a
> concept that, while related to the C language, was not in explicit C
> source code.
It's not pedantic for anyone to interpret "use fseek64() and ftell64()" as
suggesting that those functions be used. It's simply what was said.
Conveying the general idea of switching to other functions is better
done by being explicitly vague.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | rick.c.hodgin@gmail.com |
|---|---|
| Date | 2014-12-12 08:28 -0800 |
| Message-ID | <c1cac13e-d671-40f0-8b8b-69c94fe50594@googlegroups.com> |
| In reply to | #54403 |
On Friday, December 12, 2014 11:10:58 AM UTC-5, Ben Bacarisse wrote:
> rick.c.hodgin@gmail.com writes:
>
> > On Friday, December 12, 2014 9:01:22 AM UTC-5, Ben Bacarisse wrote:
> >> rick.c.hodgin@gmail.com writes:
> >>
> >> > Ben Bacarisse wrote:
> >> >> I'll try to remember that when you say
> >> >> something is obvious (or goes without saying)
> >> >> you mean that a typedef and two macros can
> >> >> make it correct on at least one system!
> >> >
> >> > I view such syntax semantics as they relate to
> >> > subtle differences in naming conventions across
> >> > compilers to be well understood as the cost of
> >> > doing business in C, and something to be worked
> >> > through.
> >>
> >> I don't get this at all. The cost of programming in C is to be
> >> accurate. You need to know the exact names of functions, and the types
> >> of their parameters, to use them correctly. It was exactly existence of
> >> subtle differences between a whole slew of related functions that it
> >> seemed worth pointing out that fseek64 is not _fseeki64 and that neither
> >> uses int64.
> >
> > I wasn't writing software, I was explaining a concept. When you get
> > above 2GB you need to move to their 64-bit counterparts.
>
> So I now see. It would have saved some time if you'd said that. The
> presence of what are actual function names, brackets and all, made me
> think you were talking about function with those actual names (maybe you
> didn't know there were functions with those exact names?) Had you, at
> the time, used your eloquent summary of what you meant ("use the 64-bit
> counterparts") the whole thing would have been avoided.
>
> <snip>
> >> I am being picky for the sake of being picky. I did not want it to be
> >> difficult for anyone. My normal reply to a detail like this is "yes,
> >> thanks" or "ah, yes, that was too vague of me" or something like that.
> >> I like the fact that mistakes get spotted on Usenet, though I rarely
> >> like it when they are mine.
> >
> > I don't view my post as a mistake. I view it as a conveyance of a
> > concept that, while related to the C language, was not in explicit C
> > source code.
>
> It's not pedantic for anyone to interpret "use fseek64() and ftell64()" as
> suggesting that those functions be used. It's simply what was said.
> Conveying the general idea of switching to other functions is better
> done by being explicitly vague.
I resign.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2014-12-12 15:27 +0000 |
| Message-ID | <m6f1g9$fjq$1@news.xmission.com> |
| In reply to | #54381 |
In article <878uid7ys6.fsf@bsb.me.uk>, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: ... >I don't get this at all. The cost of programming in C is to be >accurate. You need to know the exact names of functions, and the types >of their parameters, to use them correctly. In case it has escaped your attention, we are *NOT* programming in C when we type in messages on this newsgroup. We are DISCUSSING concepts and ideas. -- Given Bush and his insanely expensive wars (*), that we will be paying for for generations to come, the only possible response a sensible person need ever give, when a GOPer/TeaBagger says anything about "deficits", is a polite snicker. (*) Obvious money transfers between the taxpayers and Bush's moneyed interests. Someday, we'll actually figure out a way to have a war where the money just gets moved around and nobody (on either side) gets injured or killed. That will be an accomplishment of which we will be justly proud.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2014-12-12 14:39 +0000 |
| Message-ID | <m6eunq$cpm$1@news.xmission.com> |
| In reply to | #54358 |
In article <81a65884-2cf6-4e55-9fb5-0849f20745a7@googlegroups.com>, <rick.c.hodgin@gmail.com> wrote: ... >It's difficult for me to know your purpose when >there are things which to me seem so obvious >being pointed out to me as fundamental errors >in my writing. It makes me think you're just >being difficult to be difficult. I hope I'm wrong >about that because it's a very sad way to be. Welcome to the wonderful world of the CLC regs. It is a wild and twisted psychology, fun to watch and comment upon, but don't get too close to it, or you'll drive yourself crazy. Reading this exchange between Rick & Ben, I can tell exactly where Ben is coming from (given how well I understand CLC psychology, having been observing it for decades now), and Rick's wonder/confusion at how anyone could be so bent and twisted. And no, I'm not a reg, nor is Rick. Yes, we post frequently, but we all know that the term "reg" describes those who've drunk the KoolAid. That is, those who think that the CLC way of interacting with people is normal. The CLC way isn't normal even by Usenet standards, much less in the larger scheme of things. -- The whole rightwing media machinery exists to be an endless spigot of almost-reasonable-sounding excuses for their listeners to use to self-justify their racism. For them to be able to say to themselves (and others), "Oh no, I don't hate Obama because he's black, I hate him because he's _______________".
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2014-12-12 11:11 -0600 |
| Message-ID | <m6f7km$ne5$1@speranza.aioe.org> |
| In reply to | #54386 |
On 12/12/14 8:39 AM, Kenny McCormack wrote: > Welcome to the wonderful world of the CLC regs. It is a wild and twisted > psychology, fun to watch and comment upon, but don't get too close to it, > or you'll drive yourself crazy. > > Reading this exchange between Rick & Ben, I can tell exactly where Ben is > coming from (given how well I understand CLC psychology, having been > observing it for decades now), and Rick's wonder/confusion at how anyone > could be so bent and twisted. > > And no, I'm not a reg, nor is Rick. Yes, we post frequently, but we all > know that the term "reg" describes those who've drunk the KoolAid. That > is, those who think that the CLC way of interacting with people is normal. > > The CLC way isn't normal even by Usenet standards, much less in the larger > scheme of things. "When the debate is lost slander becomes the tool of the loser." ...Socrates I would suggest that you've wasted "decades" of observation time. -- Morris Dovey http://www.iedu.com/Solar/
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-12 09:34 -0800 |
| Message-ID | <9397d761-23af-4428-92d4-f539be659e4b@googlegroups.com> |
| In reply to | #54410 |
W dniu piątek, 12 grudnia 2014 18:12:07 UTC+1 użytkownik Morris Dovey napisał: > "When the debate is lost slander becomes the tool of the loser." > ...Socrates > > I would suggest that you've wasted "decades" of observation time. > there is always world of open form presumably unlimited inteligence waiting anyway, so no need to be so pesymistic (though i agree, some poor mind attacks can make some a bit sad for some time)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-12 21:47 +1300 |
| Message-ID | <cevodnFftjcU1@mid.individual.net> |
| In reply to | #54316 |
Lynn McGuire wrote: > What are you going to do when the file size is greater than 2 GB? Just hope you aren't on Windows... -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ken Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2014-12-16 12:30 -0500 |
| Message-ID | <m6pq6h$nfv$1@dont-email.me> |
| In reply to | #54339 |
On 12/12/2014 3:47 AM, Ian Collins wrote: > Lynn McGuire wrote: > >> What are you going to do when the file size is greater than 2 GB? > > Just hope you aren't on Windows... NTFS supports file sizes larger than 2GB and the Windows API supports 64-bit file offsets. -- Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-12-16 12:21 -0600 |
| Message-ID | <m6pt71$59l$2@dont-email.me> |
| In reply to | #54718 |
On 16-Dec-14 11:30, Ken Brody wrote: > On 12/12/2014 3:47 AM, Ian Collins wrote: >> Lynn McGuire wrote: >>> What are you going to do when the file size is greater than 2 GB? >> >> Just hope you aren't on Windows... > > NTFS supports file sizes larger than 2GB and the Windows API supports > 64-bit file offsets. Does the Win32 API do so by default, though, or do you have to call a special API for "large" files? What about Win16 programs running on a Win32 NTFS system? I assume Win64 would support large files by default, but that could be wrong as well. Note that even some POSIX systems are weird about large files, so it's not just a Windows problem. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2014-12-16 13:06 -0600 |
| Message-ID | <1fv09alj76olspebcar4jvnpugnr7em2gr@4ax.com> |
| In reply to | #54724 |
On Tue, 16 Dec 2014 12:21:41 -0600, Stephen Sprunk <stephen@sprunk.org> wrote: >On 16-Dec-14 11:30, Ken Brody wrote: >> On 12/12/2014 3:47 AM, Ian Collins wrote: >>> Lynn McGuire wrote: >>>> What are you going to do when the file size is greater than 2 GB? >>> >>> Just hope you aren't on Windows... >> >> NTFS supports file sizes larger than 2GB and the Windows API supports >> 64-bit file offsets. > >Does the Win32 API do so by default, though, or do you have to call a >special API for "large" files? Most* of the Win32 file functions have supported 64 bit filesizes and whatnot since day one. Some of them are a bit clumsy to use, since as they take pairs of 32 bit parameters. A set of "better" functions were added quite a while ago (at least to WinXP, perhaps before), which use better 64 bit types. The original SetFilePointer** function (and a link to the newer SetFilePointerEx): http://msdn.microsoft.com/en-us/library/windows/desktop/aa365541(v=vs.85).aspx *There were a couple of partial exceptions - GetDiskFreeSpace returned the number of clusters (disk blocks), and the size of those, in 32 bit fields. Any program depending on that (and not using the ...Ex version) is starting to run into problems these days. **Which basically does both ftell and fseek. >What about Win16 programs running on a Win32 NTFS system? Win16 programs are stuck dealing with 32 bit lengths, although you can thunk down to the native Win32 functions if you really want. >I assume Win64 would support large files by default, but that could be >wrong as well. It's mostly unchanged from Win64, although all Win64 systems support the "better" functions (and Win16 becomes a non-issue).
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-12-16 16:44 -0600 |
| Message-ID | <m6qcj9$8h9$1@dont-email.me> |
| In reply to | #54733 |
On 16-Dec-14 13:06, Robert Wessel wrote: > Stephen Sprunk <stephen@sprunk.org> wrote: >> On 16-Dec-14 11:30, Ken Brody wrote: >>> NTFS supports file sizes larger than 2GB and the Windows API >>> supports 64-bit file offsets. >> >> Does the Win32 API do so by default, though, or do you have to call >> a special API for "large" files? > > Most* of the Win32 file functions have supported 64 bit filesizes > and whatnot since day one. ... > > *There were a couple of partial exceptions - GetDiskFreeSpace > returned the number of clusters (disk blocks), and the size of those, > in 32 bit fields. Any program depending on that (and not using the > ...Ex version) is starting to run into problems these days. I've been seeing installers reporting bizarre free disk space values for at least a decade, so that's nothing new. Fortunately, few apps seem to care about disk space after that point--unless they get a write error because the disk is full. There's a related problem at a lower layer; a few years ago, HDD vendors had to switch to larger sectors (up to 64kB) because the counts were overflowing. Such HDDs emulate 512-byte sectors for drivers that don't understand the new size, but such drivers can't access any emulated sectors beyond the overflow point. But at least that problem wasn't visible to (most) userland code. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2014-12-16 18:21 -0600 |
| Message-ID | <vih19aldjn2jj3m20mh779glgks9imfhvl@4ax.com> |
| In reply to | #54768 |
On Tue, 16 Dec 2014 16:44:12 -0600, Stephen Sprunk <stephen@sprunk.org> wrote: >On 16-Dec-14 13:06, Robert Wessel wrote: >> Stephen Sprunk <stephen@sprunk.org> wrote: >>> On 16-Dec-14 11:30, Ken Brody wrote: >>>> NTFS supports file sizes larger than 2GB and the Windows API >>>> supports 64-bit file offsets. >>> >>> Does the Win32 API do so by default, though, or do you have to call >>> a special API for "large" files? >> >> Most* of the Win32 file functions have supported 64 bit filesizes >> and whatnot since day one. ... >> >> *There were a couple of partial exceptions - GetDiskFreeSpace >> returned the number of clusters (disk blocks), and the size of those, >> in 32 bit fields. Any program depending on that (and not using the >> ...Ex version) is starting to run into problems these days. > >I've been seeing installers reporting bizarre free disk space values for >at least a decade, so that's nothing new. Fortunately, few apps seem to >care about disk space after that point--unless they get a write error >because the disk is full. I think everyone has, but it's not (until recently) the fault* of GetDiskFreeSpace. NTFS volumes are most commonly formatted with 4KB clusters, so GetFreeDiskSpace doesn't overflow until you hit 16TB of free space. NTFS volumes can have smaller blocks (IIRC, 1KB is the lower limit, so that might potentially be overflowing on single drive volumes now). *I suspect a lot of that code is probably just multiplying the three numbers (cluster-count, sectors-per-cluster and bytes-per-sector) from GetFreeDiskSpace into a 32 bit long. And then it's semi-random as to whether or not you have enough free disk space... I have in several instances gotten past brain dead installers by allocating additional space on the volume. >There's a related problem at a lower layer; a few years ago, HDD vendors >had to switch to larger sectors (up to 64kB) because the counts were >overflowing. Such HDDs emulate 512-byte sectors for drivers that don't >understand the new size, but such drivers can't access any emulated >sectors beyond the overflow point. But at least that problem wasn't >visible to (most) userland code. HDDs have largely switched to 4KB sectors, and support 512 byte sector via emulation. This was not so much much an issue of hitting the 32 bit limit in sector counts, as 512 byte sectors have been wastefully small for many years, with the situation only getting worse. Especially since most volumes are formatted with 4KB blocks anyway. At least some of the HDD vendors are shipping utilities with their >2TB drives that allow you to partition the drive into two smaller drives. The emulation is actually pretty low cost for most FSs, so long as the blocks are aligned properly. If the FS is writing 4KB as a string of eight 512 byte sectors, so long as it's aligned with the physical 4KB block, the translation is trivial. If the FS wriotes an unaligned block or a single sector, the drive has to do a much more expensive read-modify-write cycle. When it became claear that 4KB sectors were coming, a lot of partition management programs got little tweaks to make sure their file systems were aligned. There are certatinly device drivers out there that will choke on sector numbers larger than 32 bits, but I suspect that many of those wouldn't handle 4KB sectors either. Most OS's are fine, OTOH, as is the hardware. Back in the DOS/FAT days, people did do strange things to the cluster and sector sizes (at least inside the drivers) to allow larger volumes, since there were limits on both the filesystem, BIOS, OS and hardware at various places that limited the number of sectors you could address. FAT16, for example, could only address 64K clusters - which made unreasonably large cluster sizes the only way you deal with large disk volumes (somewhere around 256MB).
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-12 01:04 -0800 |
| Message-ID | <0e038766-a155-4041-b803-479c6b436602@googlegroups.com> |
| In reply to | #54316 |
W dniu czwartek, 11 grudnia 2014 23:13:11 UTC+1 użytkownik Lynn McGuire napisał: > > What are you going to do when the file size is greater than 2 GB? > dont care (that would be an error of 'wrong data given' as this is case i was not assumedto handle) (im speaking seriously i do not wrote quasi-general codes)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-12 02:06 -0800 |
| Message-ID | <b0261cca-f751-4971-a347-fc0c20711695@googlegroups.com> |
| In reply to | #54340 |
W dniu piątek, 12 grudnia 2014 10:04:28 UTC+1 użytkownik fir napisał: > W dniu czwartek, 11 grudnia 2014 23:13:11 UTC+1 użytkownik Lynn McGuire napisał: > > > > What are you going to do when the file size is greater than 2 GB? > > > dont care (that would be an error of 'wrong data given' as this is case i was not assumedto handle) > (im speaking seriously i do not wrote quasi-general codes) (ps how it would behave i dont know, probably ftell anf stat wil return an error code so my brog will show message box and exit - not shure though, worse thing it would be if it will result in incorrect value - someone can say what would be happen here as i dont know how this api behaves in such case)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-12 02:24 -0800 |
| Message-ID | <6a6f2cb7-5701-46e4-bf0e-5f0fe258eba5@googlegroups.com> |
| In reply to | #54343 |
W dniu piątek, 12 grudnia 2014 11:06:35 UTC+1 użytkownik fir napisał: > W dniu piątek, 12 grudnia 2014 10:04:28 UTC+1 użytkownik fir napisał: > > W dniu czwartek, 11 grudnia 2014 23:13:11 UTC+1 użytkownik Lynn McGuire napisał: > > > > > > What are you going to do when the file size is greater than 2 GB? > > > > > dont care (that would be an error of 'wrong data given' as this is case i was not assumedto handle) > > (im speaking seriously i do not wrote quasi-general codes) > > (ps how it would behave i dont know, probably ftell anf stat wil return an error code so my brog will show message box and exit - not shure though, worse thing it would be if it will result in incorrect value - someone can say what would be happen here as i dont know how this api behaves in such case) considering this: what i should do in general (if i would wrote general way).. i should probably use the same return type as the api is using,, this type is typedefed so i dont know if i should check in static what it reeally is or check in runtime if this is larger type then int i want to convert it to (and if wider then ExiT_erroR check by sizeof? this is ugly to do so those sre troubles of quasi general coding i am a bit distasted and just prefer to kick it out, if i would do it safe i will check what exactly this typedefed type is (then sadly it assurement could blow out when headers change that [this makes the thought that some downcasting could raise an exception same as div by zero]) then check if it is value not bigger than i assume to handle if so runtime error
[toc] | [prev] | [standalone]
Page 15 of 15 — ← Prev page 1 … 13 14 [15]
Back to top | Article view | comp.lang.c
csiph-web