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 | 20 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 9 of 15 — ← Prev page 1 … 7 8 [9] 10 11 … 15 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-13 21:19 -0800 |
| Message-ID | <lnbnn6iza8.fsf@nuthaus.mib.org> |
| In reply to | #54481 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[...]
> The CDC 60 bit machines used six bit characters. When they added
> lower case, it was 6 or 12 bits for each character. That must also
> complicate fseek().
>
> I believe some Cray machines have 64 bit char.
[...]
Some of them may have. The ones I worked on had a UNIX-like operating
system, and had CHAR_BIT==8. Access to 8-bit bytes was implemented
by the compiler in software; there was no hardware support for
addressing chunks of memory smaller than a 64-bit word.
There were earlier non-UNIX operating systems for some of the
older Cray vector systems -- but I'm not sure they had C compilers
(Fortran was the big thing for that kind of system).
--
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 Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2014-12-12 22:51 -0500 |
| Message-ID | <xJOiw.988664$Q61.836105@fx13.iad> |
| In reply to | #54331 |
On 12/11/14, 11:36 PM, rick.c.hodgin@gmail.com wrote: > glen herrmannsfeldt wrote: >> Have you used VM/CMS? > > Nope. And, FWIW... > > I do not believe a standard should be written > for the fringes. It should be the standard. The > fringes then self-identify because they are not > part of the standard (such as VM/CMS), standing > out in and of themselves because of their > obtuse peculiarities. > > Best regards, > Rick C. Hodgin > Sounds like you would just prefer to live within the POSIX C standard rather than the ISO C standard. And as a point of information, even on your Windows machine there are files that you can open that will fail to give you their "length" by trying to fseek to their end.
[toc] | [prev] | [next] | [standalone]
| From | gordonb.3w2i6@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2014-12-16 09:09 -0600 |
| Message-ID | <uuudnbgHaaap1g3JnZ2dnUU7-VWdnZ2d@posted.internetamerica> |
| In reply to | #54270 |
>> Well, stat() and fstat() simply query the inode, so in terms of >> disk activity, I'd say they are the preferred option. stat() has to do a name lookup. That can take a lot of directory searching disk I/O. fstat() is probably going to just get info out of kernel memory tables. > What alternate method does fseek(END) use on a binary file that then > results in erroneously positioning the file pointer to some location > other than the end of the populated disk content when requested? On CP/M, a file consisted of disk BLOCKS (typically 128-bytes for a single-density floppy), and the size of a file was a multiple of a disk block. Nothing tracked the size of the file to the byte level. There was no place to store that on the disk. There was also no way to ask the OS to write a "partial block". A directory entry had 32 bytes: 12 for user number + filename + ext, with attribute bits in the high-order bit. 1 byte for block count in units of 128 bytes (up to 16k per extent) 1 byte for the extent number 16 for the allocation chunk number (a chunk was 1k) (where the data blocks were) 2 bytes for a modification date, I think. It was also your job (the C library) to pack bytes in to blocks. You read a whole block or wrote a whole block. Not a partial block. (For some definitions of "writing a partial block", the hardware controller for a floppy disk or hard disk simply can't do it. Modern controllers probably can't either.). Any implementation of fread() and fwrite() (and related stuff like fgetc(), fputc(), fprintf(), etc.) would have to deal with packing and unpacking bytes into blocks. Most binary files under CP/M were executables. The command interpreter just read the whole thing into memory and branched to it. A little uninitialized crap read from disk was not different from uninitialized crap left in memory from the last program. The program knew where its own end was. You'd probably get fseek(END) to position the file pointer to the end of the last populated BLOCK. If your last block was only partly full, you'd get extra stuff filling out the last block. If you wanted ASCII nul characters as fillers, filling the last block with them (e.g. on fclose() or fflush()) was the C library's job. > And under what conditions on a binary file would ftell() not accurately > report the byte-by-byte exact file position as by the last fseek() > or result of an fread() or fwrite() moving the pointer? A C implementation could track the end-of-file location to the byte for a newly-written file. But there's no place to store that info on disk! So when you closed the file and re-opened it (e.g. in a different program) that info got lost. You could conceivably invent your own scheme to put the amount of data in the last block in the last 2 bytes of the last block. If there are less than two bytes free, add another block to put that info in it. However, you'd need to re-write every program that writes binary files to follow that convention, or only try to use it on files you knew were written with this system. > As I say... I've never seen one to date and I've used the fseek() / > ftell() method since sometime beginning on/around 1989. That's at least a decade too late.
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lmc@winsim.com> |
|---|---|
| Date | 2014-12-11 16:12 -0600 |
| Message-ID | <m6d4ss$pd6$1@dont-email.me> |
| In reply to | #54051 |
On 12/7/2014 4:48 PM, fir wrote:
> I got two functions to get file size
>
>
> int GetFileSize(FILE* file)
> {
> int seek_pos = ftell(file);
> int error = fseek(file, 0, SEEK_END);
>
> if(error) ERROR_EXIT("seek1 error");
>
> int file_length = ftell(file) ;
> error = fseek(file, seek_pos, SEEK_SET);
>
> if(error) ERROR_EXIT("seek2 error");
>
> return file_length;
> }
>
>
> int GetFileSize_2(char *filename)
> {
> struct stat st;
>
> if (stat(filename, &st) == 0)
> return (int) st.st_size;
>
> ERROR_EXIT_("error obtaining file size for &s", filename);
>
> return -1;
> }
>
> could not decide which one would be better and why.. the better would be probably this one which makes less disk activity etc.. not sure what is the difference here
What are you going to do when the file size is greater than 2 GB?
Lynn
[toc] | [prev] | [next] | [standalone]
| From | rick.c.hodgin@gmail.com |
|---|---|
| Date | 2014-12-11 14:29 -0800 |
| Message-ID | <8b3d4ca3-fba9-4cf2-9655-769ac1493d2e@googlegroups.com> |
| In reply to | #54316 |
On Thursday, December 11, 2014 5:13:11 PM UTC-5, Lynn McGuire wrote: > What are you going to do when the file size is greater than 2 GB? > Lynn Use fseek64() and ftell64(). Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lmc@winsim.com> |
|---|---|
| Date | 2014-12-11 17:32 -0600 |
| Message-ID | <m6d9iv$alb$1@dont-email.me> |
| In reply to | #54318 |
On 12/11/2014 4:29 PM, rick.c.hodgin@gmail.com wrote: > On Thursday, December 11, 2014 5:13:11 PM UTC-5, Lynn McGuire wrote: >> What are you going to do when the file size is greater than 2 GB? >> Lynn > > Use fseek64() and ftell64(). > > Best regards, > Rick C. Hodgin And use int64 for the return type. Lynn
[toc] | [prev] | [next] | [standalone]
| From | rick.c.hodgin@gmail.com |
|---|---|
| Date | 2014-12-11 15:39 -0800 |
| Message-ID | <6fb30f35-bbdc-41dc-8f46-94c10327afff@googlegroups.com> |
| In reply to | #54321 |
On Thursday, December 11, 2014 6:33:14 PM UTC-5, Lynn McGuire wrote: > On 12/11/2014 4:29 PM, rick.c.hodgin@gmail.com wrote: > > On Thursday, December 11, 2014 5:13:11 PM UTC-5, Lynn McGuire wrote: > >> What are you going to do when the file size is greater than 2 GB? > > Use fseek64() and ftell64(). > > And use int64 for the return type. Well that goes without saying, yes? :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-12-11 23:55 +0000 |
| Message-ID | <87tx11agiu.fsf@bsb.me.uk> |
| In reply to | #54323 |
rick.c.hodgin@gmail.com writes: > On Thursday, December 11, 2014 6:33:14 PM UTC-5, Lynn McGuire wrote: >> On 12/11/2014 4:29 PM, rick.c.hodgin@gmail.com wrote: >> > On Thursday, December 11, 2014 5:13:11 PM UTC-5, Lynn McGuire wrote: >> >> What are you going to do when the file size is greater than 2 GB? >> > Use fseek64() and ftell64(). >> >> And use int64 for the return type. > > Well that goes without saying, yes? :-) Eh? Why does that go without saying? I don't even know a system on which it's correct, let along obvious (though I admit to be being quite parochial is such matters these days). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | rick.c.hodgin@gmail.com |
|---|---|
| Date | 2014-12-11 15:57 -0800 |
| Message-ID | <b0ac2b7c-8f52-4007-9d1b-8d0107868a2f@googlegroups.com> |
| In reply to | #54324 |
On Thursday, December 11, 2014 6:55:14 PM UTC-5, Ben Bacarisse wrote: > rick.c.hodgin@gmail.com writes: > > > On Thursday, December 11, 2014 6:33:14 PM UTC-5, Lynn McGuire wrote: > >> On 12/11/2014 4:29 PM, rick.c.hodgin@gmail.com wrote: > >> > On Thursday, December 11, 2014 5:13:11 PM UTC-5, Lynn McGuire wrote: > >> >> What are you going to do when the file size is greater than 2 GB? > >> > Use fseek64() and ftell64(). > >> > >> And use int64 for the return type. > > > > Well that goes without saying, yes? :-) > > Eh? Why does that go without saying? I don't even know a system on > which it's correct, let along obvious (though I admit to be being quite > parochial is such matters these days). 64-bits ... 64-bits. http://msdn.microsoft.com/en-us/library/75yw9bf3.aspx http://msdn.microsoft.com/en-us/library/0ys3hc0b.aspx Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-12-12 00:29 +0000 |
| Message-ID | <87h9x1aexv.fsf@bsb.me.uk> |
| In reply to | #54325 |
rick.c.hodgin@gmail.com writes: > On Thursday, December 11, 2014 6:55:14 PM UTC-5, Ben Bacarisse wrote: >> rick.c.hodgin@gmail.com writes: >> >> > On Thursday, December 11, 2014 6:33:14 PM UTC-5, Lynn McGuire wrote: >> >> On 12/11/2014 4:29 PM, rick.c.hodgin@gmail.com wrote: >> >> > On Thursday, December 11, 2014 5:13:11 PM UTC-5, Lynn McGuire wrote: >> >> >> What are you going to do when the file size is greater than 2 GB? >> >> > Use fseek64() and ftell64(). >> >> >> >> And use int64 for the return type. >> > >> > Well that goes without saying, yes? :-) >> >> Eh? Why does that go without saying? I don't even know a system on >> which it's correct, let along obvious (though I admit to be being quite >> parochial is such matters these days). > > 64-bits ... 64-bits. > > http://msdn.microsoft.com/en-us/library/75yw9bf3.aspx > http://msdn.microsoft.com/en-us/library/0ys3hc0b.aspx Neither is about a function called ftell64 (or fseek64), and neither says the return type is int64. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | rick.c.hodgin@gmail.com |
|---|---|
| Date | 2014-12-11 16:52 -0800 |
| Message-ID | <7eedb124-0988-4eb4-851f-c34a82191ae9@googlegroups.com> |
| In reply to | #54327 |
On Thursday, December 11, 2014 7:29:25 PM UTC-5, Ben Bacarisse wrote:
> rick.c.hodgin@gmail.com writes:
>
> > On Thursday, December 11, 2014 6:55:14 PM UTC-5, Ben Bacarisse wrote:
> >> rick.c.hodgin@gmail.com writes:
> >>
> >> > On Thursday, December 11, 2014 6:33:14 PM UTC-5, Lynn McGuire wrote:
> >> >> On 12/11/2014 4:29 PM, rick.c.hodgin@gmail.com wrote:
> >> >> > On Thursday, December 11, 2014 5:13:11 PM UTC-5, Lynn McGuire wrote:
> >> >> >> What are you going to do when the file size is greater than 2 GB?
> >> >> > Use fseek64() and ftell64().
> >> >>
> >> >> And use int64 for the return type.
> >> >
> >> > Well that goes without saying, yes? :-)
> >>
> >> Eh? Why does that go without saying? I don't even know a system on
> >> which it's correct, let along obvious (though I admit to be being quite
> >> parochial is such matters these days).
> >
> > 64-bits ... 64-bits.
> >
> > http://msdn.microsoft.com/en-us/library/75yw9bf3.aspx
> > http://msdn.microsoft.com/en-us/library/0ys3hc0b.aspx
>
> Neither is about a function called ftell64 (or fseek64), and neither
> says the return type is int64.
My apologies, Ben. To me it was obvious. But, to be explicit, some
translation is required.
Microsoft uses __int64 to indicate a 64-bit signed integer:
typedef __int64 int64;
And a define is needed to translate common use names into real names:
#define fseek64(x,y,z) _fseeki64(x,y,z)
#define ftell64(x) _ftelli64(x)
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-12-12 10:47 +0000 |
| Message-ID | <874mt19mbe.fsf@bsb.me.uk> |
| In reply to | #54328 |
rick.c.hodgin@gmail.com writes: > On Thursday, December 11, 2014 7:29:25 PM UTC-5, Ben Bacarisse wrote: >> rick.c.hodgin@gmail.com writes: >> >> > On Thursday, December 11, 2014 6:55:14 PM UTC-5, Ben Bacarisse wrote: >> >> rick.c.hodgin@gmail.com writes: >> >> >> >> > On Thursday, December 11, 2014 6:33:14 PM UTC-5, Lynn McGuire wrote: >> >> >> On 12/11/2014 4:29 PM, rick.c.hodgin@gmail.com wrote: >> >> >> > On Thursday, December 11, 2014 5:13:11 PM UTC-5, Lynn McGuire wrote: >> >> >> >> What are you going to do when the file size is greater than 2 GB? >> >> >> > Use fseek64() and ftell64(). >> >> >> >> >> >> And use int64 for the return type. >> >> > >> >> > Well that goes without saying, yes? :-) >> >> >> >> Eh? Why does that go without saying? I don't even know a system on >> >> which it's correct, let along obvious (though I admit to be being quite >> >> parochial is such matters these days). >> > >> > 64-bits ... 64-bits. >> > >> > http://msdn.microsoft.com/en-us/library/75yw9bf3.aspx >> > http://msdn.microsoft.com/en-us/library/0ys3hc0b.aspx >> >> Neither is about a function called ftell64 (or fseek64), and neither >> says the return type is int64. > > My apologies, Ben. What for? > To me it was obvious. To me it was just obviously wrong. The only function called ftell64 that I've ever used had a return type of long long. > But, to be explicit, some > translation is required. > > Microsoft uses __int64 to indicate a 64-bit signed integer: > typedef __int64 int64; > > And a define is needed to translate common use names into real names: > #define fseek64(x,y,z) _fseeki64(x,y,z) > #define ftell64(x) _ftelli64(x) 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! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | rick.c.hodgin@gmail.com |
|---|---|
| Date | 2014-12-12 03:40 -0800 |
| Message-ID | <81a65884-2cf6-4e55-9fb5-0849f20745a7@googlegroups.com> |
| In reply to | #54355 |
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 apologized because you either do not understand such things and I presumed too much of your skills and abilities, or because you were being strict and explicit, and I wasn't being that way when you needed me to be. 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. 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. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-12 11:52 +0000 |
| Message-ID | <PFAiw.83920$c73.23527@fx27.am4> |
| In reply to | #54358 |
rick.c.hodgin@gmail.com wrote: > 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. Yes, but you didn't work them through. > > I apologized because you either do not understand > such things and I presumed too much of your > skills and abilities, or because you were being > strict and explicit, and I wasn't being that way > when you needed me to be. He was being strict and explicit. You weren't. It wasn't Ben that needed you to be strict and explicit. It was you that needed to be strict and explicit. Had you been strict and explicit, you wouldn't have been pulled up like that. > > I was not trying to offend you. I think it would take a lot more than that to offend Ben. He's been doing Usenet for a while. > 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. One man's obvious is another man's obscure. For example, it is obvious to me that the new int types in C99 (I refer specifically to long long int and the various intn_t types) were unnecessary and pointless, but I doubt very much whether it's obvious to everybody. > > 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. You're wrong about that. He's not being difficult to be difficult. He's being precise, and that not to be difficult, but because precision is a good thing in a programmer. -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2014-12-12 13:00 +0100 |
| Message-ID | <m6elbl$at1$1@dont-email.me> |
| In reply to | #54362 |
On 12/12/14 12:52, Richard Heathfield wrote: > One man's obvious is another man's obscure. For example, it is obvious to me > that the new int types in C99 (I refer specifically to long long int and the > various intn_t types) were unnecessary and pointless, but I doubt very much > whether it's obvious to everybody. > As a great fan of the standardised intN_t types, and a hater of home-made fixed size types, I am very curious about why you think they are obviously unnecessary and pointless.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-12 12:43 +0000 |
| Message-ID | <BpBiw.169215$u67.40064@fx08.am4> |
| In reply to | #54363 |
David Brown wrote: > On 12/12/14 12:52, Richard Heathfield wrote: > >> One man's obvious is another man's obscure. For example, it is obvious to >> me that the new int types in C99 (I refer specifically to long long int >> and the various intn_t types) were unnecessary and pointless, but I doubt >> very much whether it's obvious to everybody. >> > > As a great fan of the standardised intN_t types, and a hater of > home-made fixed size types, I am very curious about why you think they > are obviously unnecessary and pointless. We already had int, short int, and long int. (We didn't actually need short int or long int, either.) -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2014-12-12 13:51 +0100 |
| Message-ID | <m6eoc4$orr$1@dont-email.me> |
| In reply to | #54367 |
On 12/12/14 13:43, Richard Heathfield wrote: > David Brown wrote: > >> On 12/12/14 12:52, Richard Heathfield wrote: >> >>> One man's obvious is another man's obscure. For example, it is obvious to >>> me that the new int types in C99 (I refer specifically to long long int >>> and the various intn_t types) were unnecessary and pointless, but I doubt >>> very much whether it's obvious to everybody. >>> >> >> As a great fan of the standardised intN_t types, and a hater of >> home-made fixed size types, I am very curious about why you think they >> are obviously unnecessary and pointless. > > 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). 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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-12 12:59 +0000 |
| Message-ID | <pEBiw.86780$5z5.51476@fx42.am4> |
| In reply to | #54369 |
David Brown wrote: > On 12/12/14 13:43, Richard Heathfield wrote: >> David Brown wrote: >> >>> On 12/12/14 12:52, Richard Heathfield wrote: >>> >>>> One man's obvious is another man's obscure. For example, it is obvious >>>> to me that the new int types in C99 (I refer specifically to long long >>>> int and the various intn_t types) were unnecessary and pointless, but I >>>> doubt very much whether it's obvious to everybody. >>>> >>> >>> As a great fan of the standardised intN_t types, and a hater of >>> home-made fixed size types, I am very curious about why you think they >>> are obviously unnecessary and pointless. >> >> 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, There is no upper limit on the size of int. It must be at least 16 bits, but can be as wide as you like. If you need a smaller type, char must be at least 8 bits. If you need a smaller type than 8 bits, you're out of luck even with the C99 types. As for modern processors or modern cpus, the C Standard doesn't trouble itself with such trivialities. :-) > and they don't give good enough > specifications of the sizes for applications that need to know exact > types. This is probably where we're going to fall out. I would argue that applications don't need to know exact sizes. You only need to know that the type is, or is not, big enough to express the range of values that you wish to store in it. > > 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). > > 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. I think that would have been a mistake, but yes, it could have worked. And if so, then when the inevitable time came for a 128-bit type, it should have been called very long, not long long. (Thereafter, you can have very very long, very very very long, and so on.) > 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. No. They're written in such a way that the implementor is free to offer a 4096-bit int type if need be. (The day may well come when this won't sound quite so ludicrous as it does at the time of writing.) -- 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-12 13:29 +0000 |
| Message-ID | <J4Ciw.154969$MH.84653@fx12.am4> |
| In reply to | #54371 |
On 12/12/2014 12:59, Richard Heathfield wrote: > David Brown wrote: >> and they don't give good enough >> specifications of the sizes for applications that need to know exact >> types. > > This is probably where we're going to fall out. I would argue that > applications don't need to know exact sizes. You only need to know that the > type is, or is not, big enough to express the range of values that you wish > to store in it. You haven't been writing the right sorts of applications then. For example, you sometimes have to create a struct where the fields match exactly those used in a foreign function or across some interface. Or you really need to minimise storage where a 16-bit int would be perfect, but just using 'short' won't guarantee anything. Or, you are implementing another language, and wish to use C as a target, and that other language does specify such widths in detail so you need to generate just the right int and float types. Or, you are specifying an interface in C to be called by outside functions or applications, and you need to have something less vague than an 'int' or 'long'. Etc. >> 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. > > No. They're written in such a way that the implementor is free to offer a > 4096-bit int type if need be. (The day may well come when this won't sound > quite so ludicrous as it does at the time of writing.) Whatever happens, using an array of exact 16-bit ints will use 1/256 the memory and bandwidth as an array of 4096-bit widths. And 99% of the values that people want to store in integers will still fit into a 32-bit or 64-bit size. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-12 14:10 +0000 |
| Message-ID | <JHCiw.28064$0o3.9096@fx45.am4> |
| In reply to | #54375 |
BartC wrote: > On 12/12/2014 12:59, Richard Heathfield wrote: >> David Brown wrote: > >>> and they don't give good enough >>> specifications of the sizes for applications that need to know exact >>> types. >> >> This is probably where we're going to fall out. I would argue that >> applications don't need to know exact sizes. You only need to know that >> the type is, or is not, big enough to express the range of values that >> you wish to store in it. > > You haven't been writing the right sorts of applications then. I am in the exact centre of the observable universe, and from where I'm standing all the applications I've been writing have been the right sorts. :-) > For example, you sometimes have to create a struct where the fields > match exactly those used in a foreign function or across some interface. If you can do it with intn_t types, you can do it with chars, ints, and longs. > > Or you really need to minimise storage where a 16-bit int would be > perfect, but just using 'short' won't guarantee anything. A guy on sci.crypt once told me it was impossible to implement his encryption algorithm in ISO C, because he needed a 19-bit integer type. I showed him how to do this in ISO C. It's not hard. Here, let me see if I can find it for you. (Here goes Google Groups... back in a minute.) Minute? Ha! <39F9F783.1C550CE4@eton.powernet.co.uk> This shows how, with a little tweaking (I seem to have used unsigned int when unsigned long int would have been wiser), you can store n-bit integers for any n you like (limited only by the size of the int that you use to report its value). It didn't take long to implement. I've never needed it since, because I don't generally have a use for exactly-n-bit types, but it's there now. > > Or, you are implementing another language, and wish to use C as a > target, and that other language does specify such widths in detail so > you need to generate just the right int and float types. How about "you are having an argument on Usenet, and need a spurious justification for fixed-width types"? :-) > > Or, you are specifying an interface in C to be called by outside > functions or applications, and you need to have something less vague > than an 'int' or 'long'. Etc. I don't think that either int or long is vague. In fact, I think they are very precisely defined. > >>> 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. >> >> No. They're written in such a way that the implementor is free to offer a >> 4096-bit int type if need be. (The day may well come when this won't >> sound quite so ludicrous as it does at the time of writing.) > > Whatever happens, using an array of exact 16-bit ints will use 1/256 the > memory and bandwidth as an array of 4096-bit widths. See above Message-ID. > And 99% of the values that people want to store in integers will still > fit into a 32-bit or 64-bit size. It is probably just as accurate to say that 99% of the values that people want to store in integers will still fit into an 8-bit size. -- 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]
Page 9 of 15 — ← Prev page 1 … 7 8 [9] 10 11 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web