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 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-13 02:15 -0800 |
| Message-ID | <0895171c-19fa-4c7c-aa11-a2613f406f7b@googlegroups.com> |
| In reply to | #54455 |
W dniu sobota, 13 grudnia 2014 10:51:05 UTC+1 użytkownik fir napisał: > W dniu piątek, 12 grudnia 2014 15:49:25 UTC+1 użytkownik fir napisał: > > W dniu piątek, 12 grudnia 2014 15:15:28 UTC+1 użytkownik Richard Heathfield napisał: > > > > > > Is it because of the people you hang around with that you are going > > > through all this? > > > > > do not understand this question (weak english) > > All in all i must say i suspect you making some kind of scary mental distaster, (and this is another example of "false deduction with no taste" right after the first one) more worse youre not feel scared with that.. this leaves the unpleasant feeling of deep sadness (and if i will feel more religiuos i would say that you should seriously ask the lord for forgiveness (not quite joking this is suspected to be really bad and terribly and exceptionaly stupid pma (poor-mind aura))) besides that ..if do some serious thought and tryin to flow on the more open form sea... may add [here some text on some good point on ya, i just cannot manage to write as some thoughts are ephemeric, but i noticed some good point too]
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-12 05:36 -0800 |
| Message-ID | <6daa8231-8b83-49cd-88ca-f27b7f49f963@googlegroups.com> |
| In reply to | #54372 |
W dniu piątek, 12 grudnia 2014 14:10:46 UTC+1 użytkownik fir napisał: > W dniu piątek, 12 grudnia 2014 13:51:57 UTC+1 użytkownik Richard Heathfield napisał: > > fir wrote: > > > > > W dniu piątek, 12 grudnia 2014 12:43:37 UTC+1 użytkownik Richard > > > Heathfield napisał: > > >> This is a reasonable argument for adding a get_file_size function (I > > >> don't insist on that exact name, of course!) to the language, > > > > > > I am much surprised so many people call clib a c language > > > > The standard library is part of the standard language. > > > > > - for me c > > > language has in some way nothing to c language > > > > Do you realise that that clause makes no sense whatsoever? > > > > > as c can be used with any > > > system (i am repeating this for some reason - i think this is important > > > not to mix c (as i see it) with c-lib to much > > > > Why do you think it's important? > > > > standard library is a part of standard language??? > > someone could say so but imo this is a bit alogical as c language can be/ is purely divided from any library > > imo c language is a set of paradigms and design choices making the language 9in no lib area) > > c-lib is just c lib, you could throw it away and compile something quite different > > Why i say this is important? becouse personally for me c-lib and c-language are so far away that i see how people mixing it as a some kind of gramatic error, when really saying about c-lib only it seem like they say obout c (but they really say about clib) I think it is better to use precise meaning when talking about c lib it is better to call it clib (not c language) > > More would be hard to explain if someone > take it, then okay, if no okay too (not a problem), but as i see it distinctly this 'blend' a bit strikes me. for example printf is not a apart of c for me it is part of clib (of course someone may use c word in wide meaning and i often use it too but it is more practical to use narrow meanings when awaliable) printf is not a part of c f(...) technique of making variable arguments calls is a part of c some parts are confusing (and i dislike this confusion) for example is sin a part of language (probably not) this is a part of clib only - but it is also a part of c-built-in compiler optymisers, and it is for me some 'design' problem that language optymisers rely on specyfic library calls -__it should be divided__ - (maybe they do not rely on clib but on some set of reserved names? (do those names like sin, cos have some special half-keyword status or so?) i do not see it clearly and would very like to know) It seem to me that Compiler must rely on something before he will treat some special names as a built in powered behavior, i hope he is basing on something like special name (as reserwed set of words) and do not base it on the fact that those are names included from c-lib if so (if it is tied to c-lib) it is a mistake and a problem imo
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-12 13:51 +0000 |
| Message-ID | <ypCiw.59714$9b1.47427@fx05.am4> |
| In reply to | #54377 |
On 12/12/2014 13:36, fir wrote:
> for example printf is not a apart of c for me it is part of clib (of course someone may use c word in wide meaning and i often use it too but it is more practical to use narrow meanings when awaliable)
>
> printf is not a part of c
Well, it is and it isn't. Compilers are quite aware of these functions
even though they are apparently not part of the language.
For example, try:
printf("%f", sin(0.5236));
and you will find that sin(0.5236) has been evaluated by the compiler
into a constant. And gcc calls 'sin' a built-in function.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-12 06:00 -0800 |
| Message-ID | <cc787159-add2-4eec-8dca-161c3a0974d8@googlegroups.com> |
| In reply to | #54378 |
W dniu piątek, 12 grudnia 2014 14:51:36 UTC+1 użytkownik Bart napisał:
> On 12/12/2014 13:36, fir wrote:
>
> > for example printf is not a apart of c for me it is part of clib (of course someone may use c word in wide meaning and i often use it too but it is more practical to use narrow meanings when awaliable)
> >
> > printf is not a part of c
>
> Well, it is and it isn't. Compilers are quite aware of these functions
> even though they are apparently not part of the language.
>
> For example, try:
>
> printf("%f", sin(0.5236));
>
> and you will find that sin(0.5236) has been evaluated by the compiler
> into a constant. And gcc calls 'sin' a built-in function.
>
>
I know see dwwn part of this post - i
really need some more claryfication on this part (how they are tied to names that they treat as built ins - is this
reference to some set of names or this
is somewhat stronger or fixed dependency on c-lib
VERY important - if someone would know
some thing i would very like to really get know
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-12-12 14:56 +0000 |
| Message-ID | <87388k9asn.fsf@bsb.me.uk> |
| In reply to | #54380 |
fir <profesor.fir@gmail.com> writes: <snip> > I know see dwwn part of this post - i > really need some more claryfication on this part (how they are tied to > names that they treat as built ins - is this > reference to some set of names or this > is somewhat stronger or fixed dependency on c-lib > > VERY important - if someone would know > some thing i would very like to really get know The language standard[1] specifies what functions are part of the standard library and what an implementation may and may no assume about them. Presumably all good C books also cover this aspect of the language. [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf is a draft of the 2011 standard. There is a similar draft for the 1999 standard called n1256.pdf. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-12 07:08 -0800 |
| Message-ID | <d3c81651-cf83-497a-831e-3afda05bb17f@googlegroups.com> |
| In reply to | #54389 |
W dniu piątek, 12 grudnia 2014 15:56:34 UTC+1 użytkownik Ben Bacarisse napisał: > fir <profesor.fir@gmail.com> writes: > <snip> > > I know see dwwn part of this post - i > > really need some more claryfication on this part (how they are tied to > > names that they treat as built ins - is this > > reference to some set of names or this > > is somewhat stronger or fixed dependency on c-lib > > > > VERY important - if someone would know > > some thing i would very like to really get know > > The language standard[1] specifies what functions are part of the > standard library and what an implementation may and may no assume about > them. Presumably all good C books also cover this aspect of the > language. > > [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf is a draft > of the 2011 standard. There is a similar draft for the 1999 standard > called n1256.pdf. > I seeking some that could answer to my specific trouble (as i presented it) those above i dont know how to use to get answer the specific question as i see it well probably sin still is not a part of core language itself (regardles that it is used in built-in way) - it is only special way tied to compilers optymiser I want to know how type is a "legal" status of this connection specyfficaly if this is a kind of legal connection to some specyfic names only - or it is in some way hard connected to c-lib [can i throw out whole c lib from my computer disk and use this built in support (for sin max min memcopy) anyway with my own high-tek-fir-lib here ?)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-12 07:32 -0800 |
| Message-ID | <92634e13-2610-4cae-9429-47435c73d4c5@googlegroups.com> |
| In reply to | #54393 |
W dniu piątek, 12 grudnia 2014 16:08:49 UTC+1 użytkownik fir napisał: > > specyfficaly if this is a kind of legal connection to some specyfic names only > - or it is in some way hard connected > to c-lib [can i throw out whole c lib from my computer disk and use this built in support (for sin max min memcopy) anyway with my own high-tek-fir-lib here ?) and what i need to get this built-in support from optymiser.. I suspect i do not need the c-lib binary (as it would be silly, as optymiser for sure (?) should not need to built in it) So the speculative options are 1) he neds to assure that those calls are the c-lib calls (how will it check if clib is linked with command line and those symbols had the same declarations as those from c-lib) 2) it only needs a declarations to reckognise it as possible built-in 3) it only needs the names ?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-12-12 15:36 +0000 |
| Message-ID | <87wq5w7ucq.fsf@bsb.me.uk> |
| In reply to | #54393 |
fir <profesor.fir@gmail.com> writes: > W dniu piątek, 12 grudnia 2014 15:56:34 UTC+1 użytkownik Ben Bacarisse napisał: >> fir <profesor.fir@gmail.com> writes: >> <snip> >> > I know see dwwn part of this post - i >> > really need some more claryfication on this part (how they are tied to >> > names that they treat as built ins - is this >> > reference to some set of names or this >> > is somewhat stronger or fixed dependency on c-lib >> > >> > VERY important - if someone would know >> > some thing i would very like to really get know >> >> The language standard[1] specifies what functions are part of the >> standard library and what an implementation may and may no assume about >> them. Presumably all good C books also cover this aspect of the >> language. >> >> [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf is a draft >> of the 2011 standard. There is a similar draft for the 1999 standard >> called n1256.pdf. >> > > I seeking some that could answer to my specific trouble (as i presented it) > those above i dont know how to use to get answer > > the specific question as i see it > > well probably sin still is not a part of core language itself > (regardles that it is used in built-in way) - it is only special way > tied to compilers optymiser > > I want to know how type is a "legal" status of this connection > > specyfficaly if this is a kind of legal connection to some specyfic names only > - or it is in some way hard connected > to c-lib [can i throw out whole c lib from my computer disk and use > this built in support (for sin max min memcopy) anyway with my own > high-tek-fir-lib here ?) I can't follow this well enough to answer your question. The specific names that matter are those of C's standard types, macros, functions and so on which are all listed in the document I linked to but I suspect that is not what you want to know. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-12 08:26 -0800 |
| Message-ID | <c9e201b9-a407-4bbd-939d-2f5f20d26128@googlegroups.com> |
| In reply to | #54396 |
W dniu piątek, 12 grudnia 2014 16:37:03 UTC+1 użytkownik Ben Bacarisse napisał:
> fir <profesor.fir@gmail.com> writes:
>
> > W dniu piątek, 12 grudnia 2014 15:56:34 UTC+1 użytkownik Ben Bacarisse napisał:
> >> fir <profesor.fir@gmail.com> writes:
> >> <snip>
> >> > I know see dwwn part of this post - i
> >> > really need some more claryfication on this part (how they are tied to
> >> > names that they treat as built ins - is this
> >> > reference to some set of names or this
> >> > is somewhat stronger or fixed dependency on c-lib
> >> >
> >> > VERY important - if someone would know
> >> > some thing i would very like to really get know
> >>
> >> The language standard[1] specifies what functions are part of the
> >> standard library and what an implementation may and may no assume about
> >> them. Presumably all good C books also cover this aspect of the
> >> language.
> >>
> >> [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf is a draft
> >> of the 2011 standard. There is a similar draft for the 1999 standard
> >> called n1256.pdf.
> >>
> >
> > I seeking some that could answer to my specific trouble (as i presented it)
> > those above i dont know how to use to get answer
> >
> > the specific question as i see it
> >
> > well probably sin still is not a part of core language itself
> > (regardles that it is used in built-in way) - it is only special way
> > tied to compilers optymiser
> >
> > I want to know how type is a "legal" status of this connection
> >
> > specyfficaly if this is a kind of legal connection to some specyfic names only
> > - or it is in some way hard connected
> > to c-lib [can i throw out whole c lib from my computer disk and use
> > this built in support (for sin max min memcopy) anyway with my own
> > high-tek-fir-lib here ?)
>
> I can't follow this well enough to answer your question. The specific
> names that matter are those of C's standard types, macros, functions and
> so on which are all listed in the document I linked to but I suspect
> that is not what you want to know.
>
probably no, as i said i need to know
what it is stricltly neccessary for the compiler to treat given symbole name as
a built-in ("intrinsic" - not real external library binary code but the "built-in powered" one)
For example if i use sin name will be treated as a built-in or need to conform for some more cndithions and what exactly are those conditions
(do the standard standarise way of treating "built-ins" ?)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-12 10:27 -0800 |
| Message-ID | <1f5ea951-8419-48fe-a519-5b2a131317cf@googlegroups.com> |
| In reply to | #54396 |
W dniu piątek, 12 grudnia 2014 16:37:03 UTC+1 użytkownik Ben Bacarisse napisał:
> fir <profesor.fir@gmail.com> writes:
>
> > W dniu piątek, 12 grudnia 2014 15:56:34 UTC+1 użytkownik Ben Bacarisse napisał:
> >> fir <profesor.fir@gmail.com> writes:
> >> <snip>
> >> > I know see dwwn part of this post - i
> >> > really need some more claryfication on this part (how they are tied to
> >> > names that they treat as built ins - is this
> >> > reference to some set of names or this
> >> > is somewhat stronger or fixed dependency on c-lib
> >> >
> >> > VERY important - if someone would know
> >> > some thing i would very like to really get know
> >>
> >> The language standard[1] specifies what functions are part of the
> >> standard library and what an implementation may and may no assume about
> >> them. Presumably all good C books also cover this aspect of the
> >> language.
> >>
> >> [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf is a draft
> >> of the 2011 standard. There is a similar draft for the 1999 standard
> >> called n1256.pdf.
> >>
> >
> > I seeking some that could answer to my specific trouble (as i presented it)
> > those above i dont know how to use to get answer
> >
> > the specific question as i see it
> >
> > well probably sin still is not a part of core language itself
> > (regardles that it is used in built-in way) - it is only special way
> > tied to compilers optymiser
> >
> > I want to know how type is a "legal" status of this connection
> >
> > specyfficaly if this is a kind of legal connection to some specyfic names only
> > - or it is in some way hard connected
> > to c-lib [can i throw out whole c lib from my computer disk and use
> > this built in support (for sin max min memcopy) anyway with my own
> > high-tek-fir-lib here ?)
>
> I can't follow this well enough to answer your question. The specific
> names that matter are those of C's standard types, macros, functions and
> so on which are all listed in the document I linked to but I suspect
> that is not what you want to know.
>
PS i found some answer saying that i can use
double f(double y)
{
double x = __builtin_sin(y);
return x;
}
and this page reference
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Other-Builtins.html#Other-Builtins
(indeed i should read it one day)
So it seem that gcc has some like internal "library" of many builtin functions
I tested it, this compiles with no
headers, ok but it gives such assembly
00000000 <_f>:
0: e9 00 00 00 00 jmp 5 <_f+0x5>
5: 90 nop
6: 90 nop
7: 90 nop
not sure how to understand it, if gcc has some builtin body does it wait to link time to put it into binary or this is some error in my understanding of this
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-12 07:46 -0800 |
| Message-ID | <c79603c8-06b6-48b5-b9c1-b14611e88e78@googlegroups.com> |
| In reply to | #54389 |
On Friday, December 12, 2014 2:56:34 PM UTC, Ben Bacarisse wrote: > fir <profesor.fir@gmail.com> writes: > > The language standard[1] specifies what functions are part of the > standard library and what an implementation may and may no assume about > them. Presumably all good C books also cover this aspect of the > language. > But the standard library is frequently vandalised. MSVC programs won't link half the string functions, for example, unless you set an obscure flag somewhere. Which some projects will ban you from doing.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2014-12-15 09:57 +0100 |
| Message-ID | <m6m7p2$nn5$1@dont-email.me> |
| In reply to | #54399 |
On 12/12/14 16:46, Malcolm McLean wrote: > On Friday, December 12, 2014 2:56:34 PM UTC, Ben Bacarisse wrote: >> fir <profesor.fir@gmail.com> writes: >> >> The language standard[1] specifies what functions are part of the >> standard library and what an implementation may and may no assume about >> them. Presumably all good C books also cover this aspect of the >> language. >> > But the standard library is frequently vandalised. > > MSVC programs won't link half the string functions, for example, unless you set an > obscure flag somewhere. Which some projects will ban you from doing. > I think MSVC is a special case - MS don't want people to use C, and go out of their way to make it difficult.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2014-12-15 09:54 +0100 |
| Message-ID | <m6m7kb$nnb$1@dont-email.me> |
| In reply to | #54378 |
On 12/12/14 14:51, BartC wrote:
> On 12/12/2014 13:36, fir wrote:
>
>> for example printf is not a apart of c for me it is part of clib (of
>> course someone may use c word in wide meaning and i often use it too
>> but it is more practical to use narrow meanings when awaliable)
>>
>> printf is not a part of c
>
> Well, it is and it isn't. Compilers are quite aware of these functions
> even though they are apparently not part of the language.
>
> For example, try:
>
> printf("%f", sin(0.5236));
>
> and you will find that sin(0.5236) has been evaluated by the compiler
> into a constant. And gcc calls 'sin' a built-in function.
>
It will then turn the "printf" into a "puts" call, since the compiler
knows exactly how both printf() and puts() work. The compiler will also
be able to check that the "%f" format argument matches the type of the
other arguments to printf.
That is one of the advantages of making the C library part of the C
standards - it lets compilers do a better job at generating good code
and at doing better compile-time checking.
For printf, this makes only a small difference - but for functions like
memcpy(), especially with small blocks, the compiler can generate far
smaller and faster code since it knows what these functions actually do.
The other key advantage to making the library part of the standards is
it means that C can be extended and enhanced in a way that minimises
conflicts with older code (by avoiding extra keywords, and making the
new identifiers available only after appropriate #include lines), in a
modular fashion so that you only "pay" for new features if you use them.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2014-12-12 10:03 -0800 |
| Message-ID | <bdebd0f6-0efb-48a8-9b6a-16d166745c2a@googlegroups.com> |
| In reply to | #54372 |
On Friday, December 12, 2014 7:10:46 AM UTC-6, fir wrote: > W dniu piątek, 12 grudnia 2014 13:51:57 UTC+1 użytkownik Richard Heathfield napisał: > > fir wrote: > > > > > W dniu piątek, 12 grudnia 2014 12:43:37 UTC+1 użytkownik Richard > > > Heathfield napisał: > > >> This is a reasonable argument for adding a get_file_size function (I > > >> don't insist on that exact name, of course!) to the language, > > > > > > I am much surprised so many people call clib a c language > > > > The standard library is part of the standard language. > > > > > - for me c > > > language has in some way nothing to c language > > > > Do you realise that that clause makes no sense whatsoever? > > > > > as c can be used with any > > > system (i am repeating this for some reason - i think this is important > > > not to mix c (as i see it) with c-lib to much > > > > Why do you think it's important? > > > > standard library is a part of standard language??? > Yes. The C language definition specifies the standard header names (stdio.h, assert.h, string.h, math.h), as well as the name, interface, and behavior of the individual library functions. For example: > 7.4.1.11 The isupper function > > Synopsis > > 1 #include <ctype.h> > int isupper(int c); > > Description > > 2 The isupper function tests for any character that is an uppercase > letter or is one of a locale-specific set of characters for which > none of iscntrl, isdigit, ispunct, or isspace is true. In the "C" > locale, isupper returns true only for the uppercase letters (as > defined in 5.2.1). The *implementation* of each function is left up to the individual compiler/library vendor, and yes, you can swap out one implementation for a different one (which you do when you port to a different platform, or you can use different implementations of the library on the same platform). But the *behavior* of the library function will be the same between the two implementations (modulo any implementation-defined or undefined behavior), and that behavior is defined by the language standard. > someone could say so but imo this is a bit alogical as c language can be/ is purely divided from any library > > imo c language is a set of paradigms and design choices making the language 9in no lib area) > > c-lib is just c lib, you could throw it away and compile something quite different > > Why i say this is important? becouse personally for me c-lib and c-language are so far away that i see how people mixing it as a some kind of gramatic error, when really saying about c-lib only it seem like they say obout c (but they really say about clib) I think it is better to use precise meaning when talking about c lib it is better to call it clib (not c language) > > More would be hard to explain if someone > take it, then okay, if no okay too (not a problem), but as i see it distinctly this 'blend' a bit strikes me.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-12-12 11:14 +0000 |
| Message-ID | <87y4qd86ir.fsf@bsb.me.uk> |
| In reply to | #54347 |
BartC <bc@freeuk.com> writes: <snip> > Those new, simple microprocessors which started emerging at that time > (actually well before 1983) must have been a breath of fresh air. The breath of fresh air came from machines with simple, orthogonal instructions sets and uniform addressing. Most early microprocessors could not match these designs (for perfectly legitimate reasons), but I remember a sort of collective sigh of relief when chips started to emerge that did so (the 68000 comes to mind). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-12 11:46 +0000 |
| Message-ID | <5AAiw.69433$gZ6.40405@fx40.am4> |
| In reply to | #54357 |
On 12/12/2014 11:14, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > <snip> >> Those new, simple microprocessors which started emerging at that time >> (actually well before 1983) must have been a breath of fresh air. > > The breath of fresh air came from machines with simple, orthogonal > instructions sets and uniform addressing. Most early microprocessors > could not match these designs (for perfectly legitimate reasons), but I > remember a sort of collective sigh of relief when chips started to > emerge that did so (the 68000 comes to mind). The instruction sets weren't so important, it was the freedom that these devices gave you to do whatever you wanted. Finally I could use my own computer without having to book a time-sharing terminal first! And not having to grapple with logins, passwords, resources and operating system restrictions. You could even start to do interesting things with sound and graphics and input that would have been out of the question on established systems that were still using serial VDUs. But sadly, current machines have now not only joined the 'establishment' but their OSes have become even more powerful and oppressive. And I would have no idea no how to make my PC even turn on an LED. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-12-12 12:05 +0000 |
| Message-ID | <87oar9844o.fsf@bsb.me.uk> |
| In reply to | #54360 |
BartC <bc@freeuk.com> writes: > On 12/12/2014 11:14, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> <snip> >>> Those new, simple microprocessors which started emerging at that time >>> (actually well before 1983) must have been a breath of fresh air. >> >> The breath of fresh air came from machines with simple, orthogonal >> instructions sets and uniform addressing. Most early microprocessors >> could not match these designs (for perfectly legitimate reasons), but I >> remember a sort of collective sigh of relief when chips started to >> emerge that did so (the 68000 comes to mind). > > The instruction sets weren't so important, it was the freedom that > these devices gave you to do whatever you wanted. > > Finally I could use my own computer without having to book a > time-sharing terminal first! And not having to grapple with logins, > passwords, resources and operating system restrictions. Sure, but that's a separate issue, isn't it? Your "breath of fresh air" quote was about machines with odd architectures. It's true that anything that is yours alone is better than a shared VAX, but that's another matter altogether. > You could even start to do interesting things with sound and graphics > and input that would have been out of the question on established > systems that were still using serial VDUs. > > But sadly, current machines have now not only joined the > establishment' but their OSes have become even more powerful and > oppressive. And I would have no idea no how to make my PC even turn on > an LED. There are Arduinos and Raspberry Pis (and others) for that these days. Certainly they operate at a higher level, but I remember my generation being sneered at for not having to solder components. The important part is the freedom to explore and invent whilst having fun. As for your oppressive OS, surely you jest? Free software (free as in speech) has altered that beyond recognition. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-12 12:27 +0000 |
| Message-ID | <gbBiw.24929$6Q5.20846@fx41.am4> |
| In reply to | #54364 |
On 12/12/2014 12:05, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> But sadly, current machines have now not only joined the >> establishment' but their OSes have become even more powerful and >> oppressive. And I would have no idea no how to make my PC even turn on >> an LED. > > There are Arduinos and Raspberry Pis (and others) for that these days. Actually I've got both of those (languishing in a drawer somewhere...). The Pi runs Linux, which despite comprising some 54,000 files on one distribution, still seems incapable of doing the slightest thing without downloading yet another massive package from the internet. The Arduino is more low-level, but to do anything with it (using the supplied 270MB PC software comprising 6000 files), involves 5 distinct steps. I've managed to eliminate Step 1. Step 2 involves compiling source code (which could be C or C++) using gcc. Eventually I will eliminate all the steps and manage to program it myself! So low-level devices are still available, but not quite as hands-on as the ones I used to use. (At the time, the software for the Arduino would have entirely filled over fifty 5MB harddrives!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <pc+usenet@asdf.org> |
|---|---|
| Date | 2014-12-18 02:11 +0200 |
| Message-ID | <87k31p6cls.fsf@bazspaz.fatphil.org> |
| In reply to | #54357 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > BartC <bc@freeuk.com> writes: > <snip> > > Those new, simple microprocessors which started emerging at that time > > (actually well before 1983) must have been a breath of fresh air. > > The breath of fresh air came from machines with simple, orthogonal > instructions sets and uniform addressing. Most early microprocessors > could not match these designs (for perfectly legitimate reasons), but I > remember a sort of collective sigh of relief when chips started to > emerge that did so (the 68000 comes to mind). > > <snip> +1 for breath of fresh air @ 68000 Having said that, that was because of the restrictions of the Z80 and the 6502 (6510), rather than the non-orthogonal abominations of the x86 family. Which alas I moved into after 68k, and couldn't wait to escape from again. However, don't be fooled by the myth of real orthogonality on the 68k; the A's and the D's were *very* different. Apart from that distinction, and A7 being special, though, pretty much all was good. POWER and Alpha have been more orthogonal than 68k in my experience. Phil -- The best part of re-inventing the wheel is that you get to pick how many sides the new one has. -- egcagrac0 on SoylentNews
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-12-14 04:15 +0000 |
| Message-ID | <m6j2sr$iq1$1@speranza.aioe.org> |
| In reply to | #54347 |
BartC <bc@freeuk.com> wrote: (snip) > Sometimes, you just have to decide if it's worthwhile crippling your > software, or discarding the simplest, most obvious and most efficient > approach to a problem, because it might not work on some odd-ball > machine that hardly anyone uses and is practically obsolete anyway. (snip, someone wrote) >>> 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. (snip) > And there weren't any minis and mainframes with ridiculous > architectures? (60-bit words for example with no way to access > character-sized chunks!) (snip) 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 things you can just feel are naturally right. Such as > byte-addressable memory, and a file system with an interface based on > the file-sizes measured in bytes (even though most memory hardware > worked in single bits, while disk drives used a bit-stream divided into > 512-byte sectors). The disks IBM made for many years allowed one to specify the block size, and even write different blocks of different length. Most disk efficient, though not memory efficient, write one block per track. That worked until tracks got longer than 32767 bytes. CMS originally used a file system with 800 byte blocks (written onto disks that like described above). Later CMS allows for 1024, 2048, or 4096 byte blocks. But within that file system, virtual blocks can be defined, such that files look like on OS disks. > Those new, simple microprocessors which started emerging at that time > (actually well before 1983) must have been a breath of fresh air. > Whatever the ANSI people were doing, there was no way they were going to > be able to ignore this new wave of machines which opened up computing to > millions. > (And anyway, also at this time, I was creating compilers and running > programs on some of these machines without any trouble at all, without > any benefit of C either. It really wasn't hard. But then I wasn't > troubled by a requirement to write programs which would work unchanged > on a 6.5-bit word computer, with a 3-word-addressable memory, and which > used signed-magnitude except on Tuesday afternoons! > Pandering to the lowest common denominator is one way of creating > 'portable' software. It's also a way of writing the least efficient and > most complicated, and ensuring it takes several times as long! If it > ever completes.) If you want support from those who sell computers like that, you have to pander to them. At least in the 1960's and 1970's, you can't ignore IBM. -- glen
[toc] | [prev] | [next] | [standalone]
Page 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web