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 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-24 12:48 -0800 |
| Message-ID | <ln8uhw22qo.fsf@nuthaus.mib.org> |
| In reply to | #55402 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, December 24, 2014 7:28:51 PM UTC, Ian Collins wrote:
>> Malcolm McLean wrote:
>>
>> How would you use your getCharAt function with a PascalString that was
>> const?
>>
> You simply provide function prototype that take plain PascalString *s.
Is a Pascal string a char* (or rather what a char* points to), or is it
the struct you define below?
> Caller must rigorously avoid const in his code. That's the central
> problem with it - either you use it absolutely consistently, which
> often means writing functions twice purely to accommodate const
> and non-const versions, or you avoid it.
Nope.
> In any case, Pascal string is like to be this structure
>
> struct pascalstring
> {
> int length;
> char *characters;
> }
>
> So consting won't actually protect the character array from modification.
No, a Pascal string is a character array whose zeroth element specifies
the current length. Your structure is a valid way to represent a
character string (though you have to manage allocation both for the
structure and for the character array), but it's not a Pascal string.
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-25 10:29 +1300 |
| Message-ID | <cg0ph4Fim7bU20@mid.individual.net> |
| In reply to | #55402 |
Malcolm McLean wrote:
> On Wednesday, December 24, 2014 7:28:51 PM UTC, Ian Collins wrote:
>> Malcolm McLean wrote:
>>
>> How would you use your getCharAt function with a PascalString that was
>> const?
>>
> You simply provide function prototype that take plain PascalString *s.
Say you had a NULL string in ROM:
static const PascalString nullString = { 0, NULL };
int main()
{
char c = getCharAt( &nullString, 1 );
}
> Caller must rigorously avoid const in his code. That's the central
> problem with it - either you use it absolutely consistently, which
> often means writing functions twice purely to accommodate const
> and non-const versions, or you avoid it.
I can't think why you would ever need to do that - passing a pointer to
a non-const object to function with const qualified parameters is normal.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-24 14:59 -0800 |
| Message-ID | <fbec7553-cad2-42ca-aa23-d5613db772de@googlegroups.com> |
| In reply to | #55412 |
On Wednesday, December 24, 2014 9:29:18 PM UTC, Ian Collins wrote: > Malcolm McLean wrote: > > I can't think why you would ever need to do that - passing a pointer to > a non-const object to function with const qualified parameters is normal. > Say we've got a tree, which includes nodes with keys and data members. We need both const node *getnode(const node *root, const char *key) and node *getnode(node *root, const char *key)
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2014-12-24 13:32 -0600 |
| Message-ID | <m7f47d$l3s$1@dont-email.me> |
| In reply to | #55382 |
Malcolm McLean wrote:
> On Wednesday, December 24, 2014 11:19:19 AM UTC, Bart wrote:
>>
>>> 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.
>>
> The strategy is to try to avoid bugs by setting up the compiler so
> that it is difficult if not impossible for the programmer to write
> code with errors in it.
> But of course you cant really do that. All you can do is flag certain
> classes of erroneous code which it is easy for the compiler to pick
> up. The danger is that you're driven by what's possible given current
> technology, rather than the real needs of the programmer.
>
> If it's obvious that a datum is input, there's declare it const.
>
> For example
>
> double mean(const double *x, const int N)
>
> consting the N isn't really helping, and few people would do that.
I probably *would* do that; but the strategy I choose is:
- Default to "everything is const".
- Wait for that to cause problems.
- Think furiously about why that's a problem and why this needs to be
an L-value.
then one of:
- redesign the signature to avoid that parameter
- or -
- take off the const keyword.
> But neither is consting the x really helping, unless x has been
> declared const somewhere else.
My understanding is that the parameter will be const for the lifetime of
the call - while we're in the called routine, it's const. So you
get some measure of assurance that it didn't change.
> However you're never going to want
> to take the mean of genuinely constant data. By introducing consts
> to x, we create a sort of cascade, whereby everything x touches also
> needs the const qualification. We're adding visual clutter, programmers
> can no longer glance at the function prototype and see what it does,
> they have to read through it instead.
Odd; I sorta think the opposite holds more water. It's a "write
protect tab" for a span of time/code, so you don't really
*have* to think about it any more.
> Worse, we create messes for
> functions like strstr(), which return pointers to data passed to us,
> which may be writeable or nonwritable.
>
> So Denis Ritchie opposed the introduction of const.
>
> In the case of the Pascal string, we need one function that gets
> the string length, another that gets the character data. We want
> those to be in one place, we don't want two functions calculating
> the character data offset, in case someone updates one and not the
> other. So the function can't be const.
>
By choosing to use a Pascal string type at all, you've more or
less declared "I want this to be an Abstract Data Type" - if
you wanted to mudge around with its internals, you'd just use
a plain ole 'C' null terminated string.
With Abstract Data Types, we want to have well-defined interfaces.
That means hiding the internal structure.
C++ sorta chickened out and returns a pointer to the data. Since the
conio.h stuff doesn't provide as rich a feature set as printf(), this
is more or less required.
> However we don't expose those functions. We provide a nicer interface,
> that might include functions with names like setCharAt().
>
> So
>
> void setCharAt(PascalString *ps, char ch, int i)
> {
> char *str = getcharacters(ps);
>
> /* error check to our heart's content here */
> str[i] = ch;
> }
>
> char getCharAt(PascalString *ps, int i)
> {
> char *str = getcharacters(ps);
> /*error check to our heart's content */
> return str[i];
> }
>
> However you'll find that using const just tangles up the interfacing.
> The mutability / non-mutability is implicit in the contract between
> function and caller, it's not sensible to treat it as an attribute
> of data passed to the function.
>
>
Having it be an attribute of the data allows for some measure ( a poor
measure to be sure ) of automatic cross checking.
You've also surrendered to clutter in that now you have "verbs"
for anything you want to do with said string.
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-24 09:16 -0700 |
| Message-ID | <kfniodqid6h.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #55382 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, December 24, 2014 11:19:19 AM UTC, Bart wrote: >> >> 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. > > [discussing some of the implications of using const] > > So Denis Ritchie opposed the introduction of const. [snip] You're wrong about that. During the ANSI standardization process, Dennis Ritchie objected to one particular aspect of rules related to 'const' types. But the implication in question was simply an inadvertent error (as he himself remarked, "In discussion with various X3J11 members, I learned that this section is now regarded as an inadvertant error, and no one thinks that it will last in its current form"), and indeed the passage in question did not make it into the Standard.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-24 09:22 -0700 |
| Message-ID | <ccb6ddf0-c273-49df-b99e-3d241697d509@googlegroups.com> |
| In reply to | #58844 |
On Tuesday, March 24, 2015 at 4:16:15 PM UTC, Tim Rentsch wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > So Denis Ritchie opposed the introduction of const. [snip] > > You're wrong about that. During the ANSI standardization process, > Dennis Ritchie objected to one particular aspect of rules related to > 'const' types. But the implication in question was simply an > inadvertent error (as he himself remarked, "In discussion with > various X3J11 members, I learned that this section is now regarded > as an inadvertant error, and no one thinks that it will last in its > current form"), and indeed the passage in question did not make it > into the Standard. > His formal objection might have been restricted to that. But in discussing "no alias" he makes reference to his view that it is much worse than const. That only makes sense if he disapproved of const, admittedly not as strongly as of no alias.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-25 13:57 -0700 |
| Message-ID | <kfnzj70aj77.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #58845 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Tuesday, March 24, 2015 at 4:16:15 PM UTC, Tim Rentsch wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >>> So Denis Ritchie opposed the introduction of const. [snip] >> >> You're wrong about that. During the ANSI standardization process, >> Dennis Ritchie objected to one particular aspect of rules related to >> 'const' types. But the implication in question was simply an >> inadvertent error (as he himself remarked, "In discussion with >> various X3J11 members, I learned that this section is now regarded >> as an inadvertant error, and no one thinks that it will last in its >> current form"), and indeed the passage in question did not make it >> into the Standard. > > His formal objection might have been restricted to that. > > But in discussing "no alias" he makes reference to his view that > it is much worse than const. That only makes sense if he > disapproved of const, admittedly not as strongly as of no alias. Your logic is flawed, which has led you to a wrong conclusion. His objection to const was only for the reason he mentioned. Saying something about "noalias" being worse than const doesn't magically make there be another reason that he objected to const. The problem with const (that never made it into the Standard) is that certain pointer values could not be used for writing; the problem with noalias is that certain pointer values could not be used for any access whatsoever. Obviously the second is worse than the first. But these consequences derive solely from the objections he gave in the paper; he didn't have any other reason to object to const.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-24 12:42 -0700 |
| Message-ID | <87a8z2rxlr.fsf@kst-u.example.com> |
| In reply to | #58844 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> On Wednesday, December 24, 2014 11:19:19 AM UTC, Bart wrote:
>>> 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.
>>
>> [discussing some of the implications of using const]
>>
>> So Denis Ritchie opposed the introduction of const. [snip]
>
> You're wrong about that. During the ANSI standardization process,
> Dennis Ritchie objected to one particular aspect of rules related to
> 'const' types. But the implication in question was simply an
> inadvertent error (as he himself remarked, "In discussion with
> various X3J11 members, I learned that this section is now regarded
> as an inadvertant error, and no one thinks that it will last in its
> current form"), and indeed the passage in question did not make it
> into the Standard.
In http://www.lysator.liu.se/c/dmr-on-noalias.html, a copy of an article
posted here on comp.lang.c on 1988-03-20, Dennis Ritchie discussed both
const and noalias (the latter was dropped):
By way of introduction, the important thing about `const'
is that the current wording says, in section 3.3.4, that a
pointer to a const-qualified object may be cast to a pointer
to the plain object, but "If an attempt is made to modify the
pointed-to object by means of the converted pointer, the behavior
is undefined." Because function prototypes tend to convert your
pointers to const-qualified pointers, difficulties arise.
In discussion with various X3J11 members, I learned that this
section is now regarded as an inadvertant error, and no one
thinks that it will last in its current form. Nevertheless, it
seemed wisest to keep my comments in their original strong form.
The intentions of the committee are irrelevant; only their
document matters.
[...]
One of the simplest routines,
char *strchr(const noalias char *s, int c);
can return its first parameter. This first parameter must be
declared with `const noalias;' otherwise, it would be illegal
(by the constraints on assignment, 3.3.16.1) to pass the address
of a const or noalias object. That is, the type qualifiers
in the prototype are not merely an optional pleasantry of the
interface; they are required, if one is to pass some kinds of
data to this or most other library routines.
Unfortunately, there is no way in X3J11's language for strchr
to return the value it promises to, because of the semantics
of return (3.6.6.4) and casts (3.3.4). Whether the stripping
of the const and noalias qualifiers is done by cast inside
strchr, or implicitly by its return statement, strchr returns
a pointer that (because of `const') cannot be stored through,
and (because of `noalias') cannot even be dereferenced; by the
rules, it is useless. (Incidentally, I think this observation
was made by Tom Plum several years ago; it's disconcerting that
the inconsistency remains.)
This was a complaint about an interaction between "const" and "noalias".
But there's *still* a serious problem with the strchr() and strrchr()
functions. It's not an inherent probelm with "const", just with the way
it's used in the standard library.
#include <stdio.h>
#include <string.h>
int main(void) {
const char s[] = "hello";
char *ptr = strchr(s, 'h');
*ptr = 'H';
puts(s);
}
Since strchr takes a `const char*` argument and returns a (non-const)
`char*` result, it can return a non-const pointer to a const char
object. The above program prints "Hello" on my system, violating the
"const" on the declaration of s. No diagostic is required (and, FWIW,
gcc doesn't warn).
C++ fixes this by providing two overloaded version of strchr():
const char* strchr(const char* s, int c);
char* strchr( char* s, int c);
ANSI C probably should have done something similar, but giving them
distinct names, perhaps strchr() and strcchr() (and likewise strrchr()
and strrcchr()).
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-03-24 20:02 +0000 |
| Message-ID | <mesftf$1b9$1@speranza.aioe.org> |
| In reply to | #58870 |
Keith Thompson <kst-u@mib.org> wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
(snip)
>> You're wrong about that. During the ANSI standardization process,
>> Dennis Ritchie objected to one particular aspect of rules related to
>> 'const' types.
(snip)
> In http://www.lysator.liu.se/c/dmr-on-noalias.html, a copy of an article
> posted here on comp.lang.c on 1988-03-20, Dennis Ritchie discussed both
> const and noalias (the latter was dropped):
> By way of introduction, the important thing about `const'
> is that the current wording says, in section 3.3.4, that a
> pointer to a const-qualified object may be cast to a pointer
> to the plain object, but "If an attempt is made to modify the
> pointed-to object by means of the converted pointer, the behavior
> is undefined." Because function prototypes tend to convert your
> pointers to const-qualified pointers, difficulties arise.
(snip)
> One of the simplest routines,
> char *strchr(const noalias char *s, int c);
Seems to me that you could:
x=strchr(s,c)-s+s;
or maybe you like better:
x=strchr(s,c)-(const noalias char *)s+s;
but I think most would rather just:
x=strchr(s,c);
> can return its first parameter. This first parameter must be
> declared with `const noalias;' otherwise, it would be illegal
> (by the constraints on assignment, 3.3.16.1) to pass the address
> of a const or noalias object. That is, the type qualifiers
> in the prototype are not merely an optional pleasantry of the
> interface; they are required, if one is to pass some kinds of
> data to this or most other library routines.
> Unfortunately, there is no way in X3J11's language for strchr
> to return the value it promises to, because of the semantics
> of return (3.6.6.4) and casts (3.3.4). Whether the stripping
> of the const and noalias qualifiers is done by cast inside
> strchr, or implicitly by its return statement, strchr returns
> a pointer that (because of `const') cannot be stored through,
> and (because of `noalias') cannot even be dereferenced; by the
> rules, it is useless. (Incidentally, I think this observation
> was made by Tom Plum several years ago; it's disconcerting that
> the inconsistency remains.)
(snip)
> C++ fixes this by providing two overloaded version of strchr():
> const char* strchr(const char* s, int c);
> char* strchr( char* s, int c);
> ANSI C probably should have done something similar, but giving them
> distinct names, perhaps strchr() and strcchr() (and likewise strrchr()
> and strrcchr()).
My feeling is that most C programmers would call that a dumb
way to do it.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-24 13:59 -0700 |
| Message-ID | <87twxaqfge.fsf@kst-u.example.com> |
| In reply to | #58872 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
[...]
>> C++ fixes this by providing two overloaded version of strchr():
>
>> const char* strchr(const char* s, int c);
>> char* strchr( char* s, int c);
>
>> ANSI C probably should have done something similar, but giving them
>> distinct names, perhaps strchr() and strcchr() (and likewise strrchr()
>> and strrcchr()).
>
> My feeling is that most C programmers would call that a dumb
> way to do it.
Why?
strchr and strrchr are, as far as I know, the only functions in the
standard library that let you violate const-correctness without a
diagnostic. I consider this a bug in the standard. How would you
address it?
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-03-24 21:56 +0000 |
| Message-ID | <mesmim$ikq$1@speranza.aioe.org> |
| In reply to | #58879 |
Keith Thompson <kst-u@mib.org> wrote: (snip) >>> ANSI C probably should have done something similar, but giving them >>> distinct names, perhaps strchr() and strcchr() (and likewise strrchr() >>> and strrcchr()). (snip, I wrote) >> My feeling is that most C programmers would call that a dumb >> way to do it. > strchr and strrchr are, as far as I know, the only functions in the > standard library that let you violate const-correctness without a > diagnostic. I consider this a bug in the standard. How would you > address it? If it isn't a bug in the standard, enough programmers would do it anyway. Well, I suppose the standard could require compilers to diagnose and reject all code that changed something using a (const char *). As a comparison, Fortran now has PURE functions, which are resticted from doing many things that are impure. But that includes restrictions against I/O, such as for debugging, or even a STOP statement when you give up and really want to just quit. If you make the right way too hard, people will just do it the wrong way. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-24 16:02 -0700 |
| Message-ID | <87pp7yq9r6.fsf@kst-u.example.com> |
| In reply to | #58880 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
> (snip)
>>>> ANSI C probably should have done something similar, but giving them
>>>> distinct names, perhaps strchr() and strcchr() (and likewise strrchr()
>>>> and strrcchr()).
>
> (snip, I wrote)
>
>>> My feeling is that most C programmers would call that a dumb
>>> way to do it.
>
>> strchr and strrchr are, as far as I know, the only functions in the
>> standard library that let you violate const-correctness without a
>> diagnostic. I consider this a bug in the standard. How would you
>> address it?
>
> If it isn't a bug in the standard, enough programmers would
> do it anyway.
I don't understand. Do you agree that it's a bug in the standard? If
not, are you saying that the standard *should* permit modifying a const
object without a warning?
> Well, I suppose the standard could require compilers to diagnose
> and reject all code that changed something using a (const char *).
It does. This:
char arr[] = "hello";
const char *ptr = &arr[0];
*ptr = 'H'; /* invalid */
is a constraint violation, requiring a diagnostic. The problem is that
strchr() and strrchr() let you quietly bypass this.
> As a comparison, Fortran now has PURE functions, which are
> resticted from doing many things that are impure. But that
> includes restrictions against I/O, such as for debugging, or
> even a STOP statement when you give up and really want to
> just quit.
>
> If you make the right way too hard, people will just do it
> the wrong way.
You seem to be making a more general point than I am.
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-03-25 01:51 -0500 |
| Message-ID | <gjm4ha9o6s789h3bmtrs22rjhcagcjk68q@4ax.com> |
| In reply to | #58883 |
On Tue, 24 Mar 2015 16:02:53 -0700, Keith Thompson <kst-u@mib.org> wrote: >glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> wrote: >> (snip) >>>>> ANSI C probably should have done something similar, but giving them >>>>> distinct names, perhaps strchr() and strcchr() (and likewise strrchr() >>>>> and strrcchr()). >> >> (snip, I wrote) >> >>>> My feeling is that most C programmers would call that a dumb >>>> way to do it. >> >>> strchr and strrchr are, as far as I know, the only functions in the >>> standard library that let you violate const-correctness without a >>> diagnostic. I consider this a bug in the standard. How would you >>> address it? >> >> If it isn't a bug in the standard, enough programmers would >> do it anyway. > >I don't understand. Do you agree that it's a bug in the standard? If >not, are you saying that the standard *should* permit modifying a const >object without a warning? > >> Well, I suppose the standard could require compilers to diagnose >> and reject all code that changed something using a (const char *). > >It does. This: > > char arr[] = "hello"; > const char *ptr = &arr[0]; > *ptr = 'H'; /* invalid */ > >is a constraint violation, requiring a diagnostic. The problem is that >strchr() and strrchr() let you quietly bypass this. FWIW, overloaded functions (either C++ or lcc-win style)) would allow that to be fixed fairly easily.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-25 13:50 -0700 |
| Message-ID | <kfn4mp8by3r.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #58879 |
Keith Thompson <kst-u@mib.org> writes: > glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> wrote: > > [...] > >>> C++ fixes this by providing two overloaded version of strchr(): >>> >>> const char* strchr(const char* s, int c); >>> char* strchr( char* s, int c); >>> >>> ANSI C probably should have done something similar, but giving >>> them distinct names, perhaps strchr() and strcchr() (and >>> likewise strrchr() and strrcchr()). >> >> My feeling is that most C programmers would call that a dumb >> way to do it. > > Why? > > strchr and strrchr are, as far as I know, the only functions in > the standard library that let you violate const-correctness > without a diagnostic. [snip] Doesn't the strtol() family of functions fall into the same category? Not as easily perhaps, but still a means of circumventing const-correctness.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-25 14:53 -0700 |
| Message-ID | <87egocpwvh.fsf@kst-u.example.com> |
| In reply to | #58963 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> wrote:
>> [...]
>>
>>>> C++ fixes this by providing two overloaded version of strchr():
>>>>
>>>> const char* strchr(const char* s, int c);
>>>> char* strchr( char* s, int c);
>>>>
>>>> ANSI C probably should have done something similar, but giving
>>>> them distinct names, perhaps strchr() and strcchr() (and
>>>> likewise strrchr() and strrcchr()).
>>>
>>> My feeling is that most C programmers would call that a dumb
>>> way to do it.
>>
>> Why?
>>
>> strchr and strrchr are, as far as I know, the only functions in
>> the standard library that let you violate const-correctness
>> without a diagnostic. [snip]
>
> Doesn't the strtol() family of functions fall into the same
> category? Not as easily perhaps, but still a means of
> circumventing const-correctness.
You're right:
#include <stdio.h>
#include <stdlib.h>
int main(void) {
const char s[] = "123xyz";
char *endptr;
strtol(s, &endptr, 0);
*endptr = 'X';
puts(s);
}
This prints "123Xyz" (at least on my system).
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-25 13:43 -0700 |
| Message-ID | <kfn8uekbyfi.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #58870 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> On Wednesday, December 24, 2014 11:19:19 AM UTC, Bart wrote: >>>> 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. >>> >>> [discussing some of the implications of using const] >>> >>> So Denis Ritchie opposed the introduction of const. [snip] >> >> You're wrong about that. During the ANSI standardization >> process, Dennis Ritchie objected to one particular aspect of >> rules related to 'const' types. But the implication in question >> was simply an inadvertent error (as he himself remarked, "In >> discussion with various X3J11 members, I learned that this >> section is now regarded as an inadvertant error, and no one >> thinks that it will last in its current form"), and indeed the >> passage in question did not make it into the Standard. > > In http://www.lysator.liu.se/c/dmr-on-noalias.html, a copy of an > article posted here on comp.lang.c on 1988-03-20, Dennis Ritchie > discussed both const and noalias (the latter was dropped): > > By way of introduction, the important thing about `const' is > that the current wording says, in section 3.3.4, that a > pointer to a const-qualified object may be cast to a pointer > to the plain object, but "If an attempt is made to modify the > pointed-to object by means of the converted pointer, the > behavior is undefined." Because function prototypes tend to > convert your pointers to const-qualified pointers, > difficulties arise. > > In discussion with various X3J11 members, I learned that this > section is now regarded as an inadvertant error, and no one > thinks that it will last in its current form. Nevertheless, > it seemed wisest to keep my comments in their original strong > form. The intentions of the committee are irrelevant; only > their document matters. > > [...] > > One of the simplest routines, > > char *strchr(const noalias char *s, int c); > > can return its first parameter. This first parameter must be > declared with `const noalias;' otherwise, it would be illegal > (by the constraints on assignment, 3.3.16.1) to pass the > address of a const or noalias object. That is, the type > qualifiers in the prototype are not merely an optional > pleasantry of the interface; they are required, if one is to > pass some kinds of data to this or most other library > routines. > > Unfortunately, there is no way in X3J11's language for strchr > to return the value it promises to, because of the semantics > of return (3.6.6.4) and casts (3.3.4). Whether the stripping > of the const and noalias qualifiers is done by cast inside > strchr, or implicitly by its return statement, strchr returns > a pointer that (because of `const') cannot be stored through, > and (because of `noalias') cannot even be dereferenced; by the > rules, it is useless. (Incidentally, I think this observation > was made by Tom Plum several years ago; it's disconcerting > that the inconsistency remains.) > > This was a complaint about an interaction between "const" and > "noalias". That isn't how I read it. There is a complaint about "const" and a complain about "noalias", which are both necessary for the function mentioned because they are both qualifiers, but I don't see any complaint about an interaction between them, or even any mention of any interaction between them - just that similar considerations apply because they are both qualifiers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-25 15:32 -0700 |
| Message-ID | <87a8z0pv1y.fsf@kst-u.example.com> |
| In reply to | #58961 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> In http://www.lysator.liu.se/c/dmr-on-noalias.html, a copy of an
>> article posted here on comp.lang.c on 1988-03-20, Dennis Ritchie
>> discussed both const and noalias (the latter was dropped):
>>
>> By way of introduction, the important thing about `const' is
>> that the current wording says, in section 3.3.4, that a
>> pointer to a const-qualified object may be cast to a pointer
>> to the plain object, but "If an attempt is made to modify the
>> pointed-to object by means of the converted pointer, the
>> behavior is undefined." Because function prototypes tend to
>> convert your pointers to const-qualified pointers,
>> difficulties arise.
>>
>> In discussion with various X3J11 members, I learned that this
>> section is now regarded as an inadvertant error, and no one
>> thinks that it will last in its current form. Nevertheless,
>> it seemed wisest to keep my comments in their original strong
>> form. The intentions of the committee are irrelevant; only
>> their document matters.
>>
>> [...]
>>
>> One of the simplest routines,
>>
>> char *strchr(const noalias char *s, int c);
>>
>> can return its first parameter. This first parameter must be
>> declared with `const noalias;' otherwise, it would be illegal
>> (by the constraints on assignment, 3.3.16.1) to pass the
>> address of a const or noalias object. That is, the type
>> qualifiers in the prototype are not merely an optional
>> pleasantry of the interface; they are required, if one is to
>> pass some kinds of data to this or most other library
>> routines.
>>
>> Unfortunately, there is no way in X3J11's language for strchr
>> to return the value it promises to, because of the semantics
>> of return (3.6.6.4) and casts (3.3.4). Whether the stripping
>> of the const and noalias qualifiers is done by cast inside
>> strchr, or implicitly by its return statement, strchr returns
>> a pointer that (because of `const') cannot be stored through,
>> and (because of `noalias') cannot even be dereferenced; by the
>> rules, it is useless. (Incidentally, I think this observation
>> was made by Tom Plum several years ago; it's disconcerting
>> that the inconsistency remains.)
>>
>> This was a complaint about an interaction between "const" and
>> "noalias".
>
> That isn't how I read it. There is a complaint about "const" and
> a complain about "noalias", which are both necessary for the
> function mentioned because they are both qualifiers, but I don't
> see any complaint about an interaction between them, or even any
> mention of any interaction between them - just that similar
> considerations apply because they are both qualifiers.
Ok, I think you're right.
If I understand this correctly, an early version of the ANSI C standard
stated that this:
char s[] = "hello";
const char *ptr_to_const = &s[0];
char *ptr_to_non_const = (char*)ptr_to_const;
*ptr_to_non_const = 'H';
had undefined behavior because the ptr_to_non_const was the result of a
cast from ptr_to_const. In the published standard, there is no
undefined behavior, because the object it points to is not
const-qualified.
In C as published (all three editions of the standard), this:
char s[] = "hello";
char *ptr = strchr(s, 'h');
*ptr = 'H';
is well defined; the `const` on the first parameter of strchr() doesn't
cause undefined behavior, and the assignment is ok because s itself is
modifiable. But this:
const char s[] = "hello";
char *ptr = strchr(s, 'h');
*ptr = 'H';
has undefined behavior because strchr() non-const return type bypasses
the constness of s. And this:
const char *s = "hello";
char *ptr = strchr(s, 'h');
*ptr = 'H';
is likely to crash, but is unlikely to trigger a compile-time warning.
(Which is not what Dennis Ritchie was complaining about; perhaps he
didn't notice this issue.)
--
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 | Phil Carmody <pc+usenet@asdf.org> |
|---|---|
| Date | 2015-04-09 02:05 +0300 |
| Message-ID | <87iod6usoj.fsf@bazspaz.fatphil.org> |
| In reply to | #58870 |
Keith Thompson <kst-u@mib.org> writes: [SNIP - see parent] > C++ fixes this by providing two overloaded version of strchr(): > > const char* strchr(const char* s, int c); > char* strchr( char* s, int c); > > ANSI C probably should have done something similar, but giving them > distinct names, perhaps strchr() and strcchr() (and likewise strrchr() > and strrcchr()). Alternatively, without overloading: size_t strchrn(const char *s, int c); The value you were looking for is s + return value, and is precisely as const as s was. Phil -- A well regulated militia, being necessary to the security of a free state, the right of the people to keep and bear arms, shall be well regulated.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-25 15:43 -0700 |
| Message-ID | <3db88ab4-eecb-468d-8cb1-c659bbac140d@googlegroups.com> |
| In reply to | #58844 |
W dniu wtorek, 24 marca 2015 17:16:15 UTC+1 użytkownik Tim Rentsch napisał: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > On Wednesday, December 24, 2014 11:19:19 AM UTC, Bart wrote: > >> > >> 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. > > > > [discussing some of the implications of using const] > > > > So Denis Ritchie opposed the introduction of const. [snip] > > You're wrong about that. During the ANSI standardization process, > Dennis Ritchie objected to one particular aspect of rules related to > 'const' types. But the implication in question was simply an > inadvertent error (as he himself remarked, "In discussion with > various X3J11 members, I learned that this section is now regarded > as an inadvertant error, and no one thinks that it will last in its > current form"), and indeed the passage in question did not make it > into the Standard. const.. i never used it (except very rare spare const ints like "const int n = 5", nothing more) what is really use of it? i dont seem to see it as something too much usable..
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-03-25 20:46 -0500 |
| Message-ID | <mevo3j$o77$1@dont-email.me> |
| In reply to | #58974 |
fir wrote:
> W dniu wtorek, 24 marca 2015 17:16:15 UTC+1 użytkownik Tim Rentsch napisał:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>>> On Wednesday, December 24, 2014 11:19:19 AM UTC, Bart wrote:
>>>>
>>>> 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.
>>>
>>> [discussing some of the implications of using const]
>>>
>>> So Denis Ritchie opposed the introduction of const. [snip]
>>
>> You're wrong about that. During the ANSI standardization process,
>> Dennis Ritchie objected to one particular aspect of rules related to
>> 'const' types. But the implication in question was simply an
>> inadvertent error (as he himself remarked, "In discussion with
>> various X3J11 members, I learned that this section is now regarded
>> as an inadvertant error, and no one thinks that it will last in its
>> current form"), and indeed the passage in question did not make it
>> into the Standard.
>
> const.. i never used it (except very rare spare const ints like "const int n = 5", nothing more)
> what is really use of it? i dont seem to see it as something too much usable..
>
const float angle = 90.0;
const float EPSI = (FLT_EPSILON * 1000.0);
const float TAN_UNDEF = FLT_MAX;
{
const float sinA = sin(angle);
const float cosA = cos(angle);
const float tanA = (abs(cos)>EPSI) ? (sin/cos) : TAN_UNDEF;
...
}
That's just the one "use case".
"const char * const p = ...." gets some use, too.
If there's a "const" violation down the page, I at
least have to think about things before removing
one or both of the "const"s .
I try to make as much stuff immutable as possible.
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web