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 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-03-29 19:00 -0500 |
| Message-ID | <mfa3db$o0q$2@dont-email.me> |
| In reply to | #59066 |
Keith Thompson wrote: > Les Cargill <lcargill99@comcast.com> writes: >> fir wrote: > [...] >>> * trouble seem that if using const one would need track in code each >>> variabkle if is const or not and that is a big amount of work clowing >>> down coding and not sure if worth it >> >> No, the compiler will flag an error if you erroneously >> assign to something that is not an lvalue. > > The name of a const-qualified object is still an lvalue; it's just not a > modifiable lvalue. > A distinction without a difference to me at least. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-30 08:15 -0700 |
| Message-ID | <87bnjaldn9.fsf@kst-u.example.com> |
| In reply to | #59239 |
Les Cargill <lcargill99@comcast.com> writes:
> Keith Thompson wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>>> fir wrote:
>> [...]
>>>> * trouble seem that if using const one would need track in code each
>>>> variabkle if is const or not and that is a big amount of work clowing
>>>> down coding and not sure if worth it
>>>
>>> No, the compiler will flag an error if you erroneously
>>> assign to something that is not an lvalue.
>>
>> The name of a const-qualified object is still an lvalue; it's just not a
>> modifiable lvalue.
>
> A distinction without a difference to me at least.
Not at all. An lvalue is not just an expression that can appear on the
left hand side of an assignment; it's an expression that (potentially)
designates an object. For example, the unary "&" operator requires an
lvalue as its operand -- whether it's modifiable or not.
--
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 | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-03-30 18:23 -0500 |
| Message-ID | <mfcljh$l67$3@dont-email.me> |
| In reply to | #59284 |
Keith Thompson wrote: > Les Cargill <lcargill99@comcast.com> writes: >> Keith Thompson wrote: >>> Les Cargill <lcargill99@comcast.com> writes: >>>> fir wrote: >>> [...] >>>>> * trouble seem that if using const one would need track in code each >>>>> variabkle if is const or not and that is a big amount of work clowing >>>>> down coding and not sure if worth it >>>> >>>> No, the compiler will flag an error if you erroneously >>>> assign to something that is not an lvalue. >>> >>> The name of a const-qualified object is still an lvalue; it's just not a >>> modifiable lvalue. >> >> A distinction without a difference to me at least. > > Not at all. An lvalue is not just an expression that can appear on the > left hand side of an assignment; it's an expression that (potentially) > designates an object. For example, the unary "&" operator requires an > lvalue as its operand -- whether it's modifiable or not. > That is quite true. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-03-30 12:26 -0400 |
| Message-ID | <55197925.1000002@verizon.net> |
| In reply to | #59239 |
On 03/29/2015 08:00 PM, Les Cargill wrote: > Keith Thompson wrote: >> Les Cargill <lcargill99@comcast.com> writes: >>> fir wrote: >> [...] >>>> * trouble seem that if using const one would need track in code each >>>> variabkle if is const or not and that is a big amount of work clowing >>>> down coding and not sure if worth it >>> >>> No, the compiler will flag an error if you erroneously >>> assign to something that is not an lvalue. There are three relevant cases: A: Not an lvalue B: unmodifiable lvalue C: modifiable lvalue You've just asserted that case A is sufficient to trigger an error message, which is irrelevant, because what fir describes is case B. It's also not quite true, because all that's required is a diagnostic - it could be an error message, a warning message, or an advertisement for the local bar - the content of diagnostic messages is not regulated by the C standard. As a practical matter, many (most?) implementations issue only warning messages for at least some kinds of syntax errors or constraint violations. >> The name of a const-qualified object is still an lvalue; it's just not a >> modifiable lvalue. >> > > > A distinction without a difference to me at least. 6.5.16p2: "An assignment operator shall have a modifiable lvalue as its left operand." This paragraph is in the section labelled "Constraints" - a diagnostics is therefore mandatory if it is violated. Therefore, both case A and case B require diagnostics, so fir's case is covered.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-30 09:42 -0700 |
| Message-ID | <3cce398a-847a-4519-932b-49a51699ff40@googlegroups.com> |
| In reply to | #59289 |
W dniu poniedziałek, 30 marca 2015 18:26:22 UTC+2 użytkownik James Kuyper napisał: > because what fir describes is case B. It's Im not following it to much (const realy like bore me) i meant something close to that assume that your c code is correct, adding few hundreds of "const" keywords only to make it more 'safer' in the sence that it will ev detect assigns to const, may be not worth it (this const again is a topic on another discussion i will probably say on it more in future)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-30 10:28 -0700 |
| Message-ID | <2ec960a8-1217-4ccd-bf9e-35c51ac5847f@googlegroups.com> |
| In reply to | #59291 |
On Monday, March 30, 2015 at 5:42:22 PM UTC+1, fir wrote: > W dniu poniedziałek, 30 marca 2015 18:26:22 UTC+2 użytkownik James Kuyper napisał: > > because what fir describes is case B. It's > > Im not following it to much (const realy like > bore me) i meant something close to that > > assume that your c code is correct, adding > few hundreds of "const" keywords only to make > it more 'safer' in the sence that it will ev > detect assigns to const, may be not worth it > > (this const again is a topic on another > discussion i will probably say on it more in future) > It's a minor benefit. Writing to a value that you ought to be reading from isn't a very likely bug, that's not so say that there are no such bugs. Of more value is a guard against calling a function that modifies data, whilst being unaware that it actually performs the modification. Consistent use of const helps to protect here, but only if the function performs no modifications at all - if a function updates an employee's salary, but unexpectedly also changes his payroll number, const won't help.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-30 10:50 -0700 |
| Message-ID | <33fbb87a-9d19-4d0f-8896-cd5ce148f529@googlegroups.com> |
| In reply to | #59293 |
W dniu poniedziałek, 30 marca 2015 19:28:52 UTC+2 użytkownik Malcolm McLean napisał: > On Monday, March 30, 2015 at 5:42:22 PM UTC+1, fir wrote: > > W dniu poniedziałek, 30 marca 2015 18:26:22 UTC+2 użytkownik James Kuyper napisał: > > > because what fir describes is case B. It's > > > > Im not following it to much (const realy like > > bore me) i meant something close to that > > > > assume that your c code is correct, adding > > few hundreds of "const" keywords only to make > > it more 'safer' in the sence that it will ev > > detect assigns to const, may be not worth it > > > > (this const again is a topic on another > > discussion i will probably say on it more in future) > > > It's a minor benefit. Writing to a value that you ought to > be reading from isn't a very likely bug, that's not so say > that there are no such bugs. > Of more value is a guard against calling a function that > modifies data, whilst being unaware that it actually performs > the modification. Consistent use of const helps to protect > here, but only if the function performs no modifications > at all - if a function updates an employee's salary, > but unexpectedly also changes his payroll number, const won't > help. minor to any - esp if you take disadvantage that are very serious - more work slowing (i wrote 'clowing' before that was mistype) down the coding process - hurts readibility as imo code with const takes longer to 'read' - const may be maybe usefull but for different and more serious reasons than this seperate one as tio args const as i said it should be done other way: imo by default every arg passed should be only for read) (think i should probably not write this above at is is plain repeat what i was already saing what i think on it.. will probably say on const some few thoughts more but in future)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-30 12:09 -0700 |
| Message-ID | <5ced2f24-c422-4a0f-9819-ed78b8e349a5@googlegroups.com> |
| In reply to | #59295 |
if add something right away to language imo more sense would be to add this in situation ehen you reach for other module static data extern int SIZE_X; -> into "extern for read only" int SIZE_X; meaning that this reference is only for read (that has a clear meaning etc not such convoluted as other spoiled "const sityuations")
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-30 12:21 -0700 |
| Message-ID | <f35b7fda-2909-4ee7-8512-95ce7654248e@googlegroups.com> |
| In reply to | #59297 |
W dniu poniedziałek, 30 marca 2015 21:10:04 UTC+2 użytkownik fir napisał:
> if add something right away to language
> imo more sense would be to add this in
> situation ehen you reach for other module
> static data
>
> extern int SIZE_X;
>
> -> into
>
> "extern for read only" int SIZE_X;
>
> meaning that this reference is only
> for read (that has a clear meaning etc
> not such convoluted as other spoiled "const
> sityuations")
same fit also (forgot to mention) to inner-module references/declarations) right now
the global data reference in function
do not need explicite write down
like
void DrawPixel(int x, int y, unsigned color)
{
extern int size_x;
extern int size_y;
extern unsigned* buff;
buff[y*size_x+x] = color;
}
nearly nobody writes that global references in function bodies (though i like it and write smetimes that way), they prefer to include it
once at the top of the file
when writing that one could also specify tjat
extern int size_x is only for read (and
extern unsigned* buff; only for write )
here this soecyfication read/write has more sense imo
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-03-30 19:37 +0100 |
| Message-ID | <mfc54k$j5a$1@dont-email.me> |
| In reply to | #59293 |
On 30/03/2015 18:28, Malcolm McLean wrote: > On Monday, March 30, 2015 at 5:42:22 PM UTC+1, fir wrote: >> W dniu poniedziałek, 30 marca 2015 18:26:22 UTC+2 użytkownik James Kuyper napisał: >>> because what fir describes is case B. It's >> >> Im not following it to much (const realy like >> bore me) i meant something close to that >> >> assume that your c code is correct, adding >> few hundreds of "const" keywords only to make >> it more 'safer' in the sence that it will ev >> detect assigns to const, may be not worth it >> >> (this const again is a topic on another >> discussion i will probably say on it more in future) >> > It's a minor benefit. Writing to a value that you ought to > be reading from isn't a very likely bug, that's not so say > that there are no such bugs. > Of more value is a guard against calling a function that > modifies data, whilst being unaware that it actually performs > the modification. If it's one of your functions, you will now about it. If it's someone else's and they haven't used const, then there's not much you can do about it. But you should be reading the docs anyway. Even if const is used, in the case of a complex, nested data structure, a const at the top level won't stop a function from writing inside the structure. > Consistent use of const helps to protect > here, but only if the function performs no modifications > at all - if a function updates an employee's salary, > but unexpectedly also changes his payroll number, const won't > help. In reality things can get complicated. For example, you have a FILE* type, and want to use 'const FILE*' to ensure the file isn't written to. But that doesn't work, because even file read functions have a FILE* parameter, not const FILE*, and a warning is generated when you try and call them with const FILE*. And even reading a file will likely require updates in the descriptor that a FILE* value points to. This FILE* example makes clearer what problems can occur in relying on 'const' to make data read-only. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-30 12:20 -0700 |
| Message-ID | <87k2xyjnr4.fsf@kst-u.example.com> |
| In reply to | #59296 |
Bartc <bc@freeuk.com> writes:
[...]
> Even if const is used, in the case of a complex, nested data
> structure, a const at the top level won't stop a function from writing
> inside the structure.
"const" works perfectly well for nested data structures, where a
structure is a member of another structure. If a structure contains a
*pointer* to another structure, then of course a "const" on the first
structure won't prevent modifications to the second. They're two
different objects; as far as the language is concerned, the pointed-to
object isn't part of the object containing the pointer. You can declare
either, both, or neither of them "const", with the obvious semantics in
each case.
[...]
> In reality things can get complicated.
>
> For example, you have a FILE* type, and want to use 'const FILE*' to
> ensure the file isn't written to. But that doesn't work, because even
> file read functions have a FILE* parameter, not const FILE*, and a
> warning is generated when you try and call them with const FILE*. And
> even reading a file will likely require updates in the descriptor that
> a FILE* value points to.
>
> This FILE* example makes clearer what problems can occur in relying on
> const' to make data read-only.
I wouldn't expect defining a FILE object as "const" to affect whether I
can write to the external file. The FILE object is an object of a type
named "FILE"; I know nothing more about it than that, since it's
effectively an opaque type. (As of C11, it can even be an incomplete
type.) The external file isn't even an object; writing to the file is
not the same as modifying an object.
If you declare
const FILE *foo;
it conflicts with the semantics of the functions declared in <stdio.h>.
So don't do that. (If you don't want to modify the external file, open
it with a mode of "r" or "rb".)
--
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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-03-30 20:49 +0100 |
| Message-ID | <mfc9a3$5m9$1@dont-email.me> |
| In reply to | #59298 |
On 30/03/2015 20:20, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: >> This FILE* example makes clearer what problems can occur in relying on >> const' to make data read-only. > > I wouldn't expect defining a FILE object as "const" to affect whether I > can write to the external file. The FILE object is an object of a type > named "FILE"; I know nothing more about it than that, since it's > effectively an opaque type. (As of C11, it can even be an incomplete > type.) The external file isn't even an object; writing to the file is > not the same as modifying an object. > > If you declare > > const FILE *foo; > > it conflicts with the semantics of the functions declared in <stdio.h>. > So don't do that. (If you don't want to modify the external file, open > it with a mode of "r" or "rb".) As I said, the const FILE* example was an illustration. In user defined data, there could be similar problems in trying to protect data with the crude mechanism provided by 'const', which can in fact give a false sense of security. There might be a pointer to a FILE-like descriptor which needs to be written to even though the actual data (via further pointers or even within the descriptor) should not be modified. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-30 13:20 -0700 |
| Message-ID | <87fv8mjkyr.fsf@kst-u.example.com> |
| In reply to | #59302 |
Bartc <bc@freeuk.com> writes:
> On 30/03/2015 20:20, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>>> This FILE* example makes clearer what problems can occur in relying on
>>> const' to make data read-only.
>>
>> I wouldn't expect defining a FILE object as "const" to affect whether I
>> can write to the external file. The FILE object is an object of a type
>> named "FILE"; I know nothing more about it than that, since it's
>> effectively an opaque type. (As of C11, it can even be an incomplete
>> type.) The external file isn't even an object; writing to the file is
>> not the same as modifying an object.
>>
>> If you declare
>>
>> const FILE *foo;
>>
>> it conflicts with the semantics of the functions declared in <stdio.h>.
>> So don't do that. (If you don't want to modify the external file, open
>> it with a mode of "r" or "rb".)
>
> As I said, the const FILE* example was an illustration. In user
> defined data, there could be similar problems in trying to protect
> data with the crude mechanism provided by 'const', which can in fact
> give a false sense of security.
Not if you understand how "const" works.
> There might be a pointer to a FILE-like descriptor which needs to be
> written to even though the actual data (via further pointers or even
> within the descriptor) should not be modified.
Right. So what's the problem?
--
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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-03-30 21:32 +0100 |
| Message-ID | <mfcbr2$g90$1@dont-email.me> |
| In reply to | #59308 |
On 30/03/2015 21:20, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: >> There might be a pointer to a FILE-like descriptor which needs to be >> written to even though the actual data (via further pointers or even >> within the descriptor) should not be modified. > > Right. So what's the problem? The problem is that you can't protect such a descriptor with a simple const. You'd have to go to a lot of extra trouble, and you might end up doing the equivalent of bricking up the door to your house to ensure burglars don't get in. That will work, but... -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-30 14:07 -0700 |
| Message-ID | <87bnjajisa.fsf@kst-u.example.com> |
| In reply to | #59310 |
Bartc <bc@freeuk.com> writes:
> On 30/03/2015 21:20, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>
>>> There might be a pointer to a FILE-like descriptor which needs to be
>>> written to even though the actual data (via further pointers or even
>>> within the descriptor) should not be modified.
>>
>> Right. So what's the problem?
>
> The problem is that you can't protect such a descriptor with a simple const.
Using "const" to protect the contents of a FILE object doesn't make much
sense, because the contents are not visible to user code.
Do you have a concrete example of the problem you're talking about?
(BTW, I've never claimed that "const" is a complete solution for
protecting data.)
[...]
--
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 | 2015-03-30 12:55 -0700 |
| Message-ID | <382258e2-9143-43d7-a7f4-c65e84f1a46f@googlegroups.com> |
| In reply to | #59298 |
On Monday, March 30, 2015 at 8:20:42 PM UTC+1, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: > [...] > > Even if const is used, in the case of a complex, nested data > > structure, a const at the top level won't stop a function from writing > > inside the structure. > > "const" works perfectly well for nested data structures, where a > structure is a member of another structure. If a structure contains a > *pointer* to another structure, then of course a "const" on the first > structure won't prevent modifications to the second. They're two > different objects; as far as the language is concerned, the pointed-to > object isn't part of the object containing the pointer. You can declare > either, both, or neither of them "const", with the obvious semantics in > each case. > You can declare struct members to be const pointers, but only if nothing writes to them at all. In reality, an employee will have a name which won't change, and, fair enough, can be a const char *. But he'll also have a payroll id, which most functions keep constant. But there will probably be one or two functions that write to the payroll id - when he moves departments the first two letters might change, for example. So those functions can't treat the payroll id as const. Everything else shouldn't be writing to it, and we'd like to mark it in some way to indicate that. But there isn't a good way of doing so.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-03-30 21:27 +0100 |
| Message-ID | <mfcbi8$f35$1@dont-email.me> |
| In reply to | #59303 |
On 30/03/2015 20:55, Malcolm McLean wrote:
> On Monday, March 30, 2015 at 8:20:42 PM UTC+1, Keith Thompson wrote:
>> "const" works perfectly well for nested data structures, where a
>> structure is a member of another structure. If a structure contains a
>> *pointer* to another structure, then of course a "const" on the first
>> structure won't prevent modifications to the second. They're two
>> different objects; as far as the language is concerned, the pointed-to
>> object isn't part of the object containing the pointer. You can declare
>> either, both, or neither of them "const", with the obvious semantics in
>> each case.
>>
>
> You can declare struct members to be const pointers, but only if nothing
> writes to them at all. In reality, an employee will have a name which
> won't change,
You still have to write the name initially. And usually the struct and
the name will be created at runtime. It now starts to become a battle to
try and protect the name with const, but allow it to be written in the
first place. You will end up having to defeat the weak protection of
'const'.
Better to forget trying to use the inadequate language facilities for
this and program in proper protection.
Example:
typedef struct {
const char name[32];
} employee_rec;
employee_rec p,q,r;
Now, yes it will stop you doing this:
strcpy(p.name,"Bart");
But it might not stop you doing this:
p = q;
Ie. completely overwriting the 'read-only' name field in p!
(gcc and compatible compilers will complain about that. But not about
memcpy(&p,&q,sizeof(p)).)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-26 23:47 -0700 |
| Message-ID | <2c5e6218-841e-4395-8942-28737b99be2c@googlegroups.com> |
| In reply to | #59052 |
W dniu piątek, 27 marca 2015 05:27:19 UTC+1 użytkownik Les Cargill napisał: > fir wrote: > > > > could maybe someone remember me if given > > value can be 'consted' in half way thru code > > (for example you pass non const to fu and > > fu argument changes it to const so in fu it is const, outside not) [?] > > > > Yes. You would need to cast the thing to a "const" type before calling fu. > if really that is extremally stupid , () if function wants something to read you could pass writable thing also, this is mighty stupid
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-27 07:11 +0000 |
| Message-ID | <mf2vp1$vru$1@dont-email.me> |
| In reply to | #59052 |
On 27/03/15 04:31, Les Cargill wrote:
> fir wrote:
<snip>
>>
>> could maybe someone remember me if given
>> value can be 'consted' in half way thru code
>> (for example you pass non const to fu and
>> fu argument changes it to const so in fu it is const, outside not) [?]
>>
>
> Yes. You would need to cast the thing to a "const" type before calling fu.
Why?
Consider this code, bearing in mind that strstr is char *(const char *,
const char *), which only means that strstr does not modify the objects
pointed to by its parameters, and noting that both nonconststra and
nonconststrb are non-const, and observing that there is no cast:
#include <stdio.h>
#include <string.h>
int main(void)
{
char nonconststra[] = "needle";
char nonconststrb[] =
"greatbighaystackthatneedlesstosaymaycontainaneedleortwo";
char *p = strstr(nonconststrb, nonconststra);
if(p != NULL)
{
printf("%s\n", p);
}
return 0;
}
Why would you need to add a cast?
<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 | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-03-29 19:01 -0500 |
| Message-ID | <mfa3fr$o0q$3@dont-email.me> |
| In reply to | #59069 |
Richard Heathfield wrote:
> On 27/03/15 04:31, Les Cargill wrote:
>> fir wrote:
>
> <snip>
>
>>>
>>> could maybe someone remember me if given
>>> value can be 'consted' in half way thru code
>>> (for example you pass non const to fu and
>>> fu argument changes it to const so in fu it is const, outside not) [?]
>>>
>>
>> Yes. You would need to cast the thing to a "const" type before calling
>> fu.
>
> Why?
>
> Consider this code, bearing in mind that strstr is char *(const char *,
> const char *), which only means that strstr does not modify the objects
> pointed to by its parameters, and noting that both nonconststra and
> nonconststrb are non-const, and observing that there is no cast:
>
> #include <stdio.h>
> #include <string.h>
>
> int main(void)
> {
> char nonconststra[] = "needle";
> char nonconststrb[] =
> "greatbighaystackthatneedlesstosaymaycontainaneedleortwo";
> char *p = strstr(nonconststrb, nonconststra);
> if(p != NULL)
> {
> printf("%s\n", p);
> }
> return 0;
> }
>
> Why would you need to add a cast?
>
> <snip>
>
you would not for that case, assuming your declaration of
strstr() does not require it.
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web