Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #55280 > unrolled thread
| Started by | Dexterr <dejangru@gmail.com> |
|---|---|
| First post | 2014-12-22 06:08 -0800 |
| Last post | 2015-03-31 09:12 +0200 |
| Articles | 20 on this page of 208 — 29 participants |
Back to article view | Back to comp.lang.c
my solution for Pascal strings Dexterr <dejangru@gmail.com> - 2014-12-22 06:08 -0800
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-22 14:21 +0000
Re: my solution for Pascal strings Dexterr <dejangru@gmail.com> - 2014-12-22 06:55 -0800
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-22 07:36 -0800
Re: my solution for Pascal strings Dexterr <dejangru@gmail.com> - 2014-12-22 07:43 -0800
Re: my solution for Pascal strings Richard Heathfield <invalid@see.sig.invalid> - 2014-12-22 15:49 +0000
Re: my solution for Pascal strings Dexterr <dejangru@gmail.com> - 2014-12-22 08:01 -0800
Re: my solution for Pascal strings Richard Heathfield <invalid@see.sig.invalid> - 2014-12-22 16:34 +0000
Re: my solution for Pascal strings Dexterr <dejangru@gmail.com> - 2014-12-22 08:46 -0800
Re: my solution for Pascal strings Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-12-25 15:36 +0100
Re: my solution for Pascal strings Dexterr <dejangru@gmail.com> - 2014-12-25 13:14 -0800
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-22 09:24 -0800
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-22 17:49 +0000
Re: my solution for Pascal strings Dexterr <dejangru@gmail.com> - 2014-12-22 10:55 -0800
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-22 19:33 +0000
Re: my solution for Pascal strings Richard Heathfield <invalid@see.sig.invalid> - 2014-12-22 19:41 +0000
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-22 22:35 +0000
Re: my solution for Pascal strings Richard Heathfield <invalid@see.sig.invalid> - 2014-12-22 22:41 +0000
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-22 16:16 -0800
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-23 13:18 +1300
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-23 01:33 +0000
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-23 14:41 +1300
Re: my solution for Pascal strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-23 10:07 +0000
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-23 02:36 -0800
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-23 07:44 -0800
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-24 09:00 +1300
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-23 10:42 +0000
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-24 08:50 +1300
Re: my solution for Pascal strings Richard Heathfield <invalid@see.sig.invalid> - 2014-12-23 20:02 +0000
Re: my solution for Pascal strings "Chris M. Thomasson" <no@spam.invalid> - 2014-12-23 12:30 -0800
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-23 21:12 +0000
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-24 10:50 +1300
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-23 14:06 -0800
Re: my solution for Pascal strings Kaz Kylheku <kaz@kylheku.com> - 2014-12-23 22:22 +0000
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-24 00:10 +0000
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-24 14:21 +1300
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-24 11:19 +0000
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 04:55 -0800
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-25 08:28 +1300
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 12:27 -0800
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-24 12:48 -0800
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-25 10:29 +1300
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 14:59 -0800
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2014-12-24 13:32 -0600
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 09:16 -0700
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-24 09:22 -0700
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 13:57 -0700
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-24 12:42 -0700
Re: my solution for Pascal strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-24 20:02 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-24 13:59 -0700
Re: my solution for Pascal strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-24 21:56 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-24 16:02 -0700
Re: my solution for Pascal strings Robert Wessel <robertwessel2@yahoo.com> - 2015-03-25 01:51 -0500
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 13:50 -0700
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-25 14:53 -0700
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 13:43 -0700
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-25 15:32 -0700
Re: my solution for Pascal strings Phil Carmody <pc+usenet@asdf.org> - 2015-04-09 02:05 +0300
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-25 15:43 -0700
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-25 20:46 -0500
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-25 23:33 -0700
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-26 03:02 -0700
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-26 23:34 -0500
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-27 12:38 -0700
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-28 12:02 +1300
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-27 16:39 -0700
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-27 17:18 -0700
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-28 13:34 +1300
Re: my solution for Pascal strings Richard Damon <Richard@Damon-Family.org> - 2015-03-27 22:09 -0400
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-28 05:41 -0700
Re: my solution for Pascal strings raltbos@xs4all.nl (Richard Bos) - 2015-03-29 15:24 +0000
Re: my solution for Pascal strings Bartc <bc@freeuk.com> - 2015-03-26 10:37 +0000
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-26 05:56 -0700
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-26 06:23 -0700
Re: my solution for Pascal strings asetofsymbols@gmail.com - 2015-03-26 10:07 -0700
Re: my solution for Pascal strings asetofsymbols@gmail.com - 2015-03-26 10:16 -0700
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-26 06:30 -0700
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-26 08:39 -0700
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-26 09:26 -0700
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-26 10:53 -0700
Re: my solution for Pascal strings Bartc <bc@freeuk.com> - 2015-03-26 18:19 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-26 11:33 -0700
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-26 12:08 -0700
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-26 12:24 -0700
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-26 23:46 -0500
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-26 23:44 -0500
Re: my solution for Pascal strings Kaz Kylheku <kaz@kylheku.com> - 2015-03-27 04:53 +0000
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-26 23:42 -0500
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-27 07:04 +0000
Re: my solution for Pascal strings Bartc <bc@freeuk.com> - 2015-03-27 10:43 +0000
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-27 10:50 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-27 08:23 -0700
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-27 12:54 -0700
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-28 16:20 -0500
Re: my solution for Pascal strings Melzzzzz <mel@zzzzz.com> - 2015-03-28 22:23 +0100
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-29 10:28 +1300
Re: my solution for Pascal strings Melzzzzz <mel@zzzzz.com> - 2015-03-28 22:29 +0100
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-29 10:35 +1300
Re: my solution for Pascal strings Melzzzzz <mel@zzzzz.com> - 2015-03-28 22:44 +0100
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-29 10:57 +1300
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-28 15:09 -0700
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-28 21:46 +0000
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-29 09:54 -0500
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-29 15:54 +0100
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-29 19:04 -0500
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-30 08:00 +0100
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-30 07:58 -0500
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-30 14:29 +0100
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 07:35 -0700
Re: my solution for Pascal strings Bartc <bc@freeuk.com> - 2015-03-27 16:14 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-27 12:15 -0700
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-28 08:30 +1300
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 14:56 -0700
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-29 11:10 +1300
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-28 20:04 -0700
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-29 17:14 +1300
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 13:03 -0700
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-31 16:40 +1300
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-26 23:31 -0500
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-26 23:42 -0700
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-29 19:00 -0500
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-30 08:15 -0700
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-30 18:23 -0500
Re: my solution for Pascal strings James Kuyper <jameskuyper@verizon.net> - 2015-03-30 12:26 -0400
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-30 09:42 -0700
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-30 10:28 -0700
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-30 10:50 -0700
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-30 12:09 -0700
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-30 12:21 -0700
Re: my solution for Pascal strings Bartc <bc@freeuk.com> - 2015-03-30 19:37 +0100
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-30 12:20 -0700
Re: my solution for Pascal strings Bartc <bc@freeuk.com> - 2015-03-30 20:49 +0100
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-30 13:20 -0700
Re: my solution for Pascal strings Bartc <bc@freeuk.com> - 2015-03-30 21:32 +0100
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-30 14:07 -0700
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-30 12:55 -0700
Re: my solution for Pascal strings Bartc <bc@freeuk.com> - 2015-03-30 21:27 +0100
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-26 23:47 -0700
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-27 07:11 +0000
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-29 19:01 -0500
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-30 07:57 +0100
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-30 18:32 -0500
Re: my solution for Pascal strings James Kuyper <jameskuyper@verizon.net> - 2015-03-30 19:59 -0400
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-30 19:22 -0500
Re: my solution for Pascal strings Kaz Kylheku <kaz@kylheku.com> - 2015-03-30 23:53 +0000
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-30 19:25 -0500
Re: my solution for Pascal strings Kaz Kylheku <kaz@kylheku.com> - 2015-03-31 01:12 +0000
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-31 07:04 +0100
Re: my solution for Pascal strings Robert Wessel <robertwessel2@yahoo.com> - 2015-03-31 01:24 -0500
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-31 07:46 +0100
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2014-12-24 13:18 -0600
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-25 08:19 +1300
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-24 20:05 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-24 12:18 -0800
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-24 20:39 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-24 12:57 -0800
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-24 21:22 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-24 14:53 -0800
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-24 23:46 +0000
Re: my solution for Pascal strings Phil Carmody <pc+usenet@asdf.org> - 2015-01-03 01:48 +0200
Re: my solution for Pascal strings Phil Carmody <pc+usenet@asdf.org> - 2015-01-03 01:43 +0200
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-24 12:05 -0800
Re: my solution for Pascal strings Richard Heathfield <invalid@see.sig.invalid> - 2014-12-24 20:20 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-24 12:34 -0800
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 12:37 -0800
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-25 10:15 +1300
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 13:43 -0800
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-25 10:52 +1300
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 15:02 -0800
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-25 16:51 +1300
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-24 21:28 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 02:21 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 02:39 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 02:52 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 03:09 -0800
Re: my solution for Pascal strings Richard Damon <Richard@Damon-Family.org> - 2014-12-25 09:32 -0500
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 06:50 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 11:59 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 11:38 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 11:55 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 03:33 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 02:56 -0800
Re: my solution for Pascal strings David Thompson <dave.thompson2@verizon.net> - 2015-01-12 15:33 -0500
Re: my solution for Pascal strings Kaz Kylheku <kaz@kylheku.com> - 2014-12-23 05:17 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-23 07:43 -0800
Re: my solution for Pascal strings raltbos@xs4all.nl (Richard Bos) - 2014-12-23 20:42 +0000
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-23 11:48 +1300
Re: my solution for Pascal strings Richard Heathfield <invalid@see.sig.invalid> - 2014-12-22 23:55 +0000
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-23 13:21 +1300
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-23 11:55 +1300
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-23 12:12 +1300
Re: my solution for Pascal strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-22 23:33 +0000
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-23 12:59 +1300
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-22 23:03 +0000
Re: my solution for Pascal strings CHIN Dihedral <dihedral88888@gmail.com> - 2015-03-26 04:04 -0700
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-26 11:22 +0000
Re: my solution for Pascal strings dmaxime66@gmail.com - 2014-12-28 09:37 -0800
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-28 18:17 +0000
Re: my solution for Pascal strings dmaxime66@gmail.com - 2014-12-30 05:28 -0800
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-31 08:29 +1300
Re: my solution for Pascal strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-30 23:56 +0000
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-29 07:59 +1300
Re: my solution for Pascal strings Max <dmaxime66@gmail.com> - 2014-12-30 05:24 -0800
Re: my solution for Pascal strings James Kuyper <jameskuyper@verizon.net> - 2014-12-30 11:29 -0500
Re: my solution for Pascal strings Max <dmaxime66@gmail.com> - 2014-12-30 10:23 -0800
Re: my solution for Pascal strings James Kuyper <jameskuyper@verizon.net> - 2014-12-30 14:22 -0500
Re: my solution for Pascal strings "D. Aaron Sawyer" <aaron@110.net> - 2014-12-22 12:32 -0400
Re: my solution for Pascal strings "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-03-31 09:12 +0200
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | Phil Carmody <pc+usenet@asdf.org> |
|---|---|
| Date | 2015-01-03 01:43 +0200 |
| Message-ID | <87fvbs3g04.fsf@bazspaz.fatphil.org> |
| In reply to | #55400 |
Keith Thompson <kst-u@mib.org> writes:
> [snip]
/aol
> If I were designing a new language with no need for backward
> compatibility, "const" (i.e., read-only) would be the default,
> and you'd need to add a keyword to specify that an object may
> be modified. It just wasn't possible to do that for C.
It we have a blank slate, I've occasionally thought it would
be nice if there was a deep-const as well as a shallow-const,
such that everything pointed to recursively through the
pointer is treated as read-only in that context.
Then again, I've also thought that "as-const-as" would be
nice too. Basically to get some cheap C++-like overloading.
E.g.:
as_const_as(s1) char * strstr(char *s1, const char *s2);
would be the superposition of:
const char * strstr(const char *s1, const char *s2);
char * strstr( char *s1, const char *s2);
where the former is chosen if applicable, else the latter.
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-24 12:05 -0800 |
| Message-ID | <lnlhlw24qg.fsf@nuthaus.mib.org> |
| In reply to | #55380 |
BartC <bc@freeuk.com> writes:
> On 24/12/2014 01:21, Ian Collins wrote:
>> BartC wrote:
>>> Simplest then to use char*, and leave it to the caller code, if it's so
>>> paranoid it can't trust itself to not corrupt strings it shouldn't be
>>> writing to, to apply any const casts if it has to.
>>
>> No, all that gives you is a gateway to subtle and hard to find memory
>> corruption bugs. Why introduce a new gets()? If you want the string to
>> be mutable, provide the functions to do this, don't expose the guts of
>> the object. Consider what happens if you write past the end, or..
>
> OK, we're obviously never going to agree. My main concern is avoiding a
> proliferation of 'const' everywhere that will introduce clutter and
> obscure the clarity of the code.
>
> Since most string parameters are going to be 'in' parameters, not 'out'
> or 'inout' ones, then they /will/ be everywhere using your method.
>
> And take an innocuous-looking function as strstr(), which returns a
> location in its first string parameter. Its prototype is like this:
>
> char* strstr(const char* str, const char* searchstr);
>
> While it takes pains to show that it doesn't write to the 'str'
> parameter, it then proceeds to return a writeable pointer into that string!
Yes, and that is a problem. strstr() lets you violate const correctness
without a cast; it lets you (attempt to) modify a const object without
using a cast. For example:
#include <string.h>
#include <stdio.h>
int main(void) {
const char s[] = "hello, world";
char *w = strstr(s, "world");
*w = 'W';
puts(s);
}
This has undefined behavior. When I compile it with gcc, it prints
"hello, World"; with clang it dies with a segmentation fault.
I'm fairly sure that strstr is the *only* function in the C standard
library that has this problem. A better solution would have been to
introduce two functions, one with const and one withouit:
const char *strcstr(const char *s1, const char *s2);
char *strstr (const char *s1, char *s2);
but the ANSI committee didn't do that. (It would have broken some
existing code, but IMHO it would have been worth that cost.)
[...]
> To get around this is C++, apparently two overloads are used, one with a
> char* result, and one with a const char* result. This is too achieve
> what we could have got without bothering with const in the first place!
Part of the goal is to let the compiler enforce read-only semantics.
How would you do that without const?
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-24 20:20 +0000 |
| Message-ID | <feFmw.147590$6Q5.18130@fx41.am4> |
| In reply to | #55398 |
Keith Thompson wrote: <snip> > I'm fairly sure that strstr is the *only* function in the C standard > library that has this problem. A better solution would have been to > introduce two functions, one with const and one withouit: > > const char *strcstr(const char *s1, const char *s2); > char *strstr (const char *s1, char *s2); Presumably YMTW char *strstr(char *s1, const char *s2) ? <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-24 12:34 -0800 |
| Message-ID | <lnd27823ei.fsf@nuthaus.mib.org> |
| In reply to | #55401 |
Richard Heathfield <invalid@see.sig.invalid> writes:
> Keith Thompson wrote:
> <snip>
>
>> I'm fairly sure that strstr is the *only* function in the C standard
>> library that has this problem. A better solution would have been to
>> introduce two functions, one with const and one withouit:
>>
>> const char *strcstr(const char *s1, const char *s2);
>> char *strstr (const char *s1, char *s2);
>
> Presumably YMTW char *strstr(char *s1, const char *s2) ?
>
> <snip>
Y, TWIMTW. THX.
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-24 12:37 -0800 |
| Message-ID | <784b185c-6d7f-45ec-b91e-9ca96ac29aa2@googlegroups.com> |
| In reply to | #55398 |
On Wednesday, December 24, 2014 8:05:36 PM UTC, Keith Thompson wrote: > > Part of the goal is to let the compiler enforce read-only semantics. > How would you do that without const? > You don't. Const is there because it's something that a relatively simple compiler can easily check. Not because pre-const C was really causing problems. I'm not saying that never ever is a bug caught by const which otherwise would have slipped through to a much later stage. But passing a data item that is meant to be constant to a function which modifies it isn't a mistake that a real programmer is very likely to make. And if he does make it, most likely that's because he swapped the parameters around, and that type of bug comes out very early in testing. Programmers know when they want to write to an array and when they want to read from it. Arguably const helps to document which parameter is which. But it doesn't help much.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-25 10:15 +1300 |
| Message-ID | <cg0onsFim7bU19@mid.individual.net> |
| In reply to | #55404 |
Malcolm McLean wrote: > On Wednesday, December 24, 2014 8:05:36 PM UTC, Keith Thompson wrote: >> >> Part of the goal is to let the compiler enforce read-only semantics. >> How would you do that without const? >> > You don't. > > Const is there because it's something that a relatively simple compiler > can easily check. Not because pre-const C was really causing problems. How can a relatively simple compiler check what the code in some library function you are calling will do with the parameter? > I'm not saying that never ever is a bug caught by const which > otherwise would have slipped through to a much later stage. But > passing a data item that is meant to be constant to a function > which modifies it isn't a mistake that a real programmer is very > likely to make. You'd be surprised. A large, originally closed source, operating system code base I was involved with had more than a few crashes when the default option for string literals was changed from writable to read only. > Programmers know when they want to write to an array and when they > want to read from it. Arguably const helps to document which > parameter is which. But it doesn't help much. Every little helps, if the compiler can pick up silly errors early, let it. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-24 13:43 -0800 |
| Message-ID | <17d690fa-ef1d-4df6-8b8f-ae3a6391b460@googlegroups.com> |
| In reply to | #55409 |
On Wednesday, December 24, 2014 9:15:48 PM UTC, Ian Collins wrote: > Malcolm McLean wrote: > > How can a relatively simple compiler check what the code in some library > function you are calling will do with the parameter? > You tell the compiler that the pointer is const / not const, and it believes you. It can also detect writes to const-qualified pointers in code it compiles, easily enough, though not write via aliases. But of course if the library function isn't written in C, then you're relying on the human programmer who gave the function a const prototype to honour that. > > You'd be surprised. A large, originally closed source, operating system > code base I was involved with had more than a few crashes when the > default option for string literals was changed from writable to read only. > But how many of those were of this sort char *path = "/unix/path"; tonativeseparators(path); fp = fopen(path, "r"); it should of course have square brackets rather than a char *, but the programmer wasn't inadvertently modifying data that he intended to keep constant, at least on a DOS system. > > Every little helps, if the compiler can pick up silly errors early, > let it. > If const was cost-free then I'd absolutely agree with. But it isn't. There is a genuine argument to be had, which ultimately comes down to human psychology, so not proveable in a technical sense.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-25 10:52 +1300 |
| Message-ID | <cg0qs6Fim7bU21@mid.individual.net> |
| In reply to | #55413 |
Malcolm McLean wrote: > On Wednesday, December 24, 2014 9:15:48 PM UTC, Ian Collins wrote: >> Malcolm McLean wrote: >> >> How can a relatively simple compiler check what the code in some library >> function you are calling will do with the parameter? >> > You tell the compiler that the pointer is const / not const, and it > believes you. It can also detect writes to const-qualified pointers > in code it compiles, easily enough, though not write via aliases. Which is why we const, is it not? > But of course if the library function isn't written in C, then you're > relying on the human programmer who gave the function a const > prototype to honour that. Why does the language matter? The compiler knows nothing about the internals of a third party function. >> You'd be surprised. A large, originally closed source, operating system >> code base I was involved with had more than a few crashes when the >> default option for string literals was changed from writable to read only. >> > But how many of those were of this sort > > char *path = "/unix/path"; > > tonativeseparators(path); > > fp = fopen(path, "r"); > > > it should of course have square brackets rather than a char *, but the > programmer wasn't inadvertently modifying data that he intended to > keep constant, at least on a DOS system. He/she was messing with string literals that other code quite rightly assumes where constant. >> Every little helps, if the compiler can pick up silly errors early, >> let it. >> > If const was cost-free then I'd absolutely agree with. But it isn't. Whether is is or isn't cost-free is irrelevant. It exists as does real constant data. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-24 15:02 -0800 |
| Message-ID | <c5f3d3dc-013d-4add-95e2-70265eb5474f@googlegroups.com> |
| In reply to | #55414 |
On Wednesday, December 24, 2014 9:52:16 PM UTC, Ian Collins wrote: > > Whether is is or isn't cost-free is irrelevant. It exists as does real > constant data. > You can deprecate it.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-25 16:51 +1300 |
| Message-ID | <cg1ft4Fim7bU22@mid.individual.net> |
| In reply to | #55419 |
Malcolm McLean wrote: > On Wednesday, December 24, 2014 9:52:16 PM UTC, Ian Collins wrote: >> >> Whether is is or isn't cost-free is irrelevant. It exists as does real >> constant data. >> > You can deprecate it. Eh? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-24 21:28 -0800 |
| Message-ID | <lnvbl0z4am.fsf@nuthaus.mib.org> |
| In reply to | #55424 |
Ian Collins <ian-news@hotmail.com> writes:
> Malcolm McLean wrote:
>> On Wednesday, December 24, 2014 9:52:16 PM UTC, Ian Collins wrote:
>>> Whether is is or isn't cost-free is irrelevant. It exists as does real
>>> constant data.
>>>
>> You can deprecate it.
>
> Eh?
I think he's advocating deprecating the "const" keyword.
Fortunately, this will never happen.
--
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 | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-25 02:21 -0800 |
| Message-ID | <6a867dcb-cc22-4df0-bda0-042fe6c6f763@googlegroups.com> |
| In reply to | #55425 |
W dniu czwartek, 25 grudnia 2014 06:28:41 UTC+1 użytkownik Keith Thompson napisał: > Ian Collins <ian-news@hotmail.com> writes: > > Malcolm McLean wrote: > >> On Wednesday, December 24, 2014 9:52:16 PM UTC, Ian Collins wrote: > >>> Whether is is or isn't cost-free is irrelevant. It exists as does real > >>> constant data. > >>> > >> You can deprecate it. > > > > Eh? > > I think he's advocating deprecating the "const" keyword. > > Fortunately, this will never happen. > I agree with mc-mclean here In my own work on core c improvements (c2) i noticed few years ago that "red only" is/should really be in general property of given reference not neccessary whole entity I do not use const in my co coding so i realy do not even know how it works, only was working on this on higher level of meanings not bothered to test ;/, but if it has this bad cascading enforcements it is obviously wrong may some give some example of this cons violations (as i was never testing it, do the compilers complain when you put non const to const argument?) (if so const may be deprecated;/ in general c comitee should listen to me and put whole set of my improvements into c and everyone will be happy then)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-25 02:39 -0800 |
| Message-ID | <ddb497a4-0291-4ae0-9c7a-921d276a0971@googlegroups.com> |
| In reply to | #55426 |
W dniu czwartek, 25 grudnia 2014 11:21:17 UTC+1 użytkownik fir napisał:
> (if so const may be deprecated;/ in general c comitee should listen to me and put whole set of my improvements into c and everyone will be happy then)
(esp if people are hungry for
efficiency: static arguments
void foo(static int x)
{
}
can spped up codes (by giving the effective ways to erote code lanes)
shared statics
void foo()
{
static f = 0;
///
}
void foo()
{
main.f = 10;
foo();
}
may spead the code same way
accelerated sse types
float4 x,y,z;
z=x/y;
also (by greatly easing vector optymisations)
arithmetic types like
void foo( int(100) x )
{
return sin(x);
}
may extremally speed up the compiler generated code (say 50 maybe 100, 200 times speed ups may be observable) by giving to compilers
tools for greatly tabelarise down whle branches of complex calculations)
also inviting naturally resizable arrays
in core c would be a great "sea change" in c world, not to mention many syntax
simplifications
if(x,y = z, a) d,f,g = e,r,t;
clean modular suport, clean user defined operator support , log waiting full arrays support foo(a[]) - where a is not only begining but also end information,
and yet some more things of my terrific 10 years of heavy teory work on spirit of c
(i took ocassion to sum up part of the things)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-25 02:52 -0800 |
| Message-ID | <a92603c5-87eb-4e4d-ad63-edb33b31e0ad@googlegroups.com> |
| In reply to | #55427 |
W dniu czwartek, 25 grudnia 2014 11:39:34 UTC+1 użytkownik fir napisał:
> shared statics
>
> void foo()
> {
> static f = 0;
> ///
> }
>
> void foo()
> {
> main.f = 10;
> foo();
> }
>
sorry mistypes i mean
void foo()
{
static f = 0;
///
}
void main()
{
foo.f = 10;
foo();
}
also main general form
module main;
links stdlib;
char b[] main( char a[])
{
char c[100];
for(int i=0; i<100; i++)
c[i] = rand()%256;
return c;
}
may be mentioned though i was mantioning this about one year ago here it is always nice to see such unix-spirit programcommunications build-in
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-25 03:09 -0800 |
| Message-ID | <dcbf3d41-2c6b-4107-b416-f4ed8b041504@googlegroups.com> |
| In reply to | #55428 |
W dniu czwartek, 25 grudnia 2014 11:52:49 UTC+1 użytkownik fir napisał:
> void foo()
> {
> static f = 0;
> ///
> }
>
ps recently wonder if apart to this static, register, heap, stack storage there also tls storage keywords should be specified
i mean if given static ram should be shared for threads or common
void foo()
{
// shared static int tab[100];
thread static int tab2[100];
}
scacks also can be common or local this way
also think if manual therad or core assigment should be used
void main()
{
core(0) foo();
core(1) foo();
core(2) foo();
core(3) foo();
}
not fully clear yet,
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2014-12-25 09:32 -0500 |
| Message-ID | <_dVmw.641149$Lq6.442052@fx29.iad> |
| In reply to | #55431 |
On 12/25/14 6:09 AM, fir wrote:
> W dniu czwartek, 25 grudnia 2014 11:52:49 UTC+1 użytkownik fir napisał:
>> void foo()
>> {
>> static f = 0;
>> ///
>> }
>>
> ps recently wonder if apart to this static, register, heap, stack storage there also tls storage keywords should be specified
> i mean if given static ram should be shared for threads or common
>
You mean like _Thread_local (with a define in thread.h to make an alias
named thread_local)
> void foo()
> {
> // shared static int tab[100];
>
> thread static int tab2[100];
>
> }
> scacks also can be common or local this way
>
> also think if manual therad or core assigment should be used
>
> void main()
> {
> core(0) foo();
> core(1) foo();
> core(2) foo();
> core(3) foo();
> }
>
> not fully clear yet,
>
>
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-25 06:50 -0800 |
| Message-ID | <8777ceda-c332-4040-873d-757b5aefe7b2@googlegroups.com> |
| In reply to | #55433 |
W dniu czwartek, 25 grudnia 2014 15:32:37 UTC+1 użytkownik Richard Damon napisał:
> On 12/25/14 6:09 AM, fir wrote:
> > W dniu czwartek, 25 grudnia 2014 11:52:49 UTC+1 użytkownik fir napisał:
> >> void foo()
> >> {
> >> static f = 0;
> >> ///
> >> }
> >>
> > ps recently wonder if apart to this static, register, heap, stack storage there also tls storage keywords should be specified
> > i mean if given static ram should be shared for threads or common
> >
>
> You mean like _Thread_local (with a define in thread.h to make an alias
> named thread_local)
>
probably. )i do nt lnow what _Thread_local exactly is as im ot coding much multithreading) The thing that this thread statics (and stacks) are probably
runtime managed a bit worries me, as in general c-spirit is more nicely static, - so maybe some more static solution could be done (and maybe could be used to spare. reuse some static ram, not sure) - but dont to much matter right now pronably..
> > void foo()
> > {
> > // shared static int tab[100];
> >
> > thread static int tab2[100];
> >
> > }
> > scacks also can be common or local this way
> >
> > also think if manual therad or core assigment should be used
> >
> > void main()
> > {
> > core(0) foo();
> > core(1) foo();
> > core(2) foo();
> > core(3) foo();
> > }
> >
> > not fully clear yet,
> >
> >
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-25 11:59 -0800 |
| Message-ID | <19c90841-b883-4f9a-a012-54b849cc0e3a@googlegroups.com> |
| In reply to | #55435 |
ps some other idea i also consider, maybe not strictly related to new c but more in abstract language is an stack of errors (and diagnostic messages stack) there is atways a trouble what to do with errors, packing them on some stack of errors seem to be quite good option for me, this stack can be managed on caller plains in any place, explored cleared and more
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-25 11:38 -0800 |
| Message-ID | <d4e6b9c7-c555-4663-8520-a3c379812894@googlegroups.com> |
| In reply to | #55428 |
har b[] main( char a[])
{
char c[100];
for(int i=0; i<100; i++)
c[i] = rand()%256;
return c;
}
ps as nothing special to do right now maybe
i comment on this quite important form
char b[] main(char a[])
{
}
in general i am expecting all in and out
arguments of the function in new c
to belong on the upper scope, thus a[]
and b[] are arrays of the upper scope
a[] will be some size chunk of chars (its length
is avaliable by "length of" operator), it is passed
as a pair of values denoting the chunk span
in memor (does not important right now if begin pointer
plus end pointer or some other form, for simplicity may
be assumed that pair of pointers)
b[] may be zero sized chunk on upper scope, may be
probebly also some given size chynk on upper scope
though this is a little variation
I am considering three types of arrays in c2 right now
1) fixed size, 2) resizable (to some limit, resize without
reallocation by logical space reserve and binding and unbinding
phys ram pages). 3) reallocable, reallocable are just reallocked
on heap by realloc
- not sure if i just could enforce this main retirn array chunk
form to be just reallocable - for simplicity probably i may assume
that temporarily
such form of program
char b[] main( char a[])
{
char c[100];
for(int i=0; i<100; i++)
c[i] = rand()%256;
return c;
}
looks more like c[] would be just made on stack, (not sure if i
should allow some kind of optymistation when c[100[ in reality would
be placed already in the b[] place on upper scope, for simplicity again
i may assume that c[100[ is done on stack and return c means
realloc b[100];
b[]=c[]; //memcopy
so maybe better would be to write it
char b[] main( char a[])
{
resize b[100];
for(int i=0; i<100; i++) b[i] = rand()%256;
//return b[]; //optional
}
this all my look like conceptual mess for a while but
probably nothing better just cant be done (i am not
quite sure but i not seen anything), at least it is
general (flaexible) should work and is efficient
such program may be used like
program.exe input.bmp > output.bmp
unix should copy input.bmp to some memory region, pass
two pointers, also pass two pointers to an empty
resizalbe/relocable array, and pass the pointers too,
program.exe will resize and fill the output chunk, os
then should put the output ram chunk to another program or
to console or fill the file output.bmp like here,
very lightweight mechanism
there is maybe something here what i somewhat dislike but as i said i see no better option, in general the ability to
pass and take resizable the arrays without copying etc is some important advantage present c is lacking of, it will make c coding more 'flexible'
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-25 11:55 -0800 |
| Message-ID | <cf8fde1a-71df-4b52-b560-820f031f437a@googlegroups.com> |
| In reply to | #55437 |
W dniu czwartek, 25 grudnia 2014 20:38:09 UTC+1 użytkownik fir napisał:
> such form of program
>
> char b[] main( char a[])
> {
> char c[100];
>
> for(int i=0; i<100; i++)
> c[i] = rand()%256;
>
> return c;
>
> }
>
> looks more like c[] would be just made on stack, (not sure if i
> should allow some kind of optymistation when c[100[ in reality would
> be placed already in the b[] place on upper scope, for simplicity again
well maybe it could look like
char[] main(char a[])
{
output char c[100];
for(int i=0; i<100; i++)
c[i] = rand()%256;
return c;
}
this way returned array could ba also fixed size (os could read this fixed value form executable file image,
seem to be okay not to expect reallocable arrays always, also work on fixed ones (simpler case)
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web