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 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-23 01:33 +0000 |
| Message-ID | <VD3mw.244924$v42.74562@fx19.am4> |
| In reply to | #55323 |
On 23/12/2014 00:18, Ian Collins wrote: > Malcolm McLean wrote: >> it's only a minor problem. We provide >> >> int (size_t if you must) getlength(void *pascal_string) >> >> and >> >> char *getcharacters(void *pascal_string) > > You'd want "const char*" there. Messing with the characters and > inadvertently changing the size isn't a good idea. Do you mean in place of 'void *pascal_string' or as the result type? If the latter, then I'm struggling to figure out what it helps, and how. (And if the former, then I have views about that too!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-23 14:41 +1300 |
| Message-ID | <cfrvifFim7bU10@mid.individual.net> |
| In reply to | #55325 |
BartC wrote: > On 23/12/2014 00:18, Ian Collins wrote: >> Malcolm McLean wrote: > >>> it's only a minor problem. We provide >>> >>> int (size_t if you must) getlength(void *pascal_string) >>> >>> and >>> >>> char *getcharacters(void *pascal_string) >> >> You'd want "const char*" there. Messing with the characters and >> inadvertently changing the size isn't a good idea. > > Do you mean in place of 'void *pascal_string' or as the result type? If > the latter, then I'm struggling to figure out what it helps, and how. > > (And if the former, then I have views about that too!) Both. The function is what C++ folks call a getter. It doesn't alter the sate of the object so the parameter should be const. It is returning a pointer only a part of the object (the characters). In this case, it should return by value but this isn't practical in this case so cost char* is the safe option. Otherwise consider what happens to the object if the string is shortened while leaving the size unchanged. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-12-23 10:07 +0000 |
| Message-ID | <87wq5ik7co.fsf@bsb.me.uk> |
| In reply to | #55326 |
Ian Collins <ian-news@hotmail.com> writes: > BartC wrote: >> On 23/12/2014 00:18, Ian Collins wrote: >>> Malcolm McLean wrote: >> >>>> it's only a minor problem. We provide >>>> >>>> int (size_t if you must) getlength(void *pascal_string) >>>> >>>> and >>>> >>>> char *getcharacters(void *pascal_string) >>> >>> You'd want "const char*" there. Messing with the characters and >>> inadvertently changing the size isn't a good idea. >> >> Do you mean in place of 'void *pascal_string' or as the result type? If >> the latter, then I'm struggling to figure out what it helps, and how. >> >> (And if the former, then I have views about that too!) > > Both. > > The function is what C++ folks call a getter. It doesn't alter the > sate of the object so the parameter should be const. s/should be const/should be a pointer to const/ > It is returning a pointer only a part of the object (the > characters). In this case, it should return by value but this isn't > practical in this case so cost char* is the safe option. Otherwise > consider what happens to the object if the string is shortened while > leaving the size unchanged. That's logically not possible for a Pascal strings. Pascal strings can (at least in theory) have embedded nulls. The only way to shorten one is to alter the length component. (Mind you, I agree that the result should be const char *.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-23 02:36 -0800 |
| Message-ID | <34f6eb82-6cfb-492c-a5da-316169166aa5@googlegroups.com> |
| In reply to | #55326 |
On Tuesday, December 23, 2014 1:41:44 AM UTC, Ian Collins wrote: > > > Do you mean in place of 'void *pascal_string' or as the result type? If > > the latter, then I'm struggling to figure out what it helps, and how. > > > > (And if the former, then I have views about that too!) > > Both. > > The function is what C++ folks call a getter. It doesn't alter the sate > of the object so the parameter should be const. > We don't know the internals of the Pascal string. Maybe the length field is set to minus one on string initialisation, and the characters aciiz. The idea is that the first time you need the length you do a pass over the string, then you store it for future use, obviously resetting to -1 on a length-changing write. So opaque pointers shouldn't be const. Making the return const * is const poisoning.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-23 07:44 -0800 |
| Message-ID | <ln7fxi2wx3.fsf@nuthaus.mib.org> |
| In reply to | #55347 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> We don't know the internals of the Pascal string.
Some of us do. See my other reply in this thread.
--
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-24 09:00 +1300 |
| Message-ID | <cftvugFim7bU12@mid.individual.net> |
| In reply to | #55347 |
Malcolm McLean wrote: > On Tuesday, December 23, 2014 1:41:44 AM UTC, Ian Collins wrote: >> >>> Do you mean in place of 'void *pascal_string' or as the result type? If >>> the latter, then I'm struggling to figure out what it helps, and how. >>> >>> (And if the former, then I have views about that too!) >> >> Both. >> >> The function is what C++ folks call a getter. It doesn't alter the sate >> of the object so the parameter should be const. >> > We don't know the internals of the Pascal string. In this case we do. Even in cases where we don't, a proper opaque pointer type, not void* should be used. FILE* is a good example. > Maybe the length field is set to minus one on string initialisation, > and the characters aciiz. The idea is that the first time you need > the length you do a pass over the string, then you store it > for future use, obviously resetting to -1 on a length-changing > write. That seems like a highly contrived argument to avoid the use of const. If the string can contain any character value, how can you "do a pass over the string" to determine the length? > So opaque pointers shouldn't be const. They should for functions that don't modify the object pointed to. > Making the return const * is const poisoning. Providing an easy means to corrupt the state its state is object poisoning... -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-23 10:42 +0000 |
| Message-ID | <OGbmw.146505$AC.64105@fx29.am4> |
| In reply to | #55326 |
On 23/12/2014 01:41, Ian Collins wrote: > BartC wrote: >> On 23/12/2014 00:18, Ian Collins wrote: >>> Malcolm McLean wrote: >>>> char *getcharacters(void *pascal_string) >>> >>> You'd want "const char*" there. Messing with the characters and >>> inadvertently changing the size isn't a good idea. >> >> Do you mean in place of 'void *pascal_string' or as the result type? If >> the latter, then I'm struggling to figure out what it helps, and how. > The function is what C++ folks call a getter. It doesn't alter the sate > of the object so the parameter should be const. > > It is returning a pointer only a part of the object (the characters). In > this case, it should return by value but this isn't practical in this > case so cost char* is the safe option. Otherwise consider what happens > to the object if the string is shortened while leaving the size unchanged. How would the string be shortened? The string could be modified, yes, but the length can only be changed by modifying the pascal_string object. (The caller can do that anyway, unless the contents of pascal_string are somehow made opaque.) And maybe the string contents are intended to be mutable; I'm fairly sure you could modify individual characters in a Pascal string. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-24 08:50 +1300 |
| Message-ID | <cftvbdFim7bU11@mid.individual.net> |
| In reply to | #55348 |
BartC wrote: > On 23/12/2014 01:41, Ian Collins wrote: >> BartC wrote: >>> On 23/12/2014 00:18, Ian Collins wrote: >>>> Malcolm McLean wrote: > >>>>> char *getcharacters(void *pascal_string) >>>> >>>> You'd want "const char*" there. Messing with the characters and >>>> inadvertently changing the size isn't a good idea. >>> >>> Do you mean in place of 'void *pascal_string' or as the result type? If >>> the latter, then I'm struggling to figure out what it helps, and how. > >> The function is what C++ folks call a getter. It doesn't alter the sate >> of the object so the parameter should be const. >> >> It is returning a pointer only a part of the object (the characters). In >> this case, it should return by value but this isn't practical in this >> case so cost char* is the safe option. Otherwise consider what happens >> to the object if the string is shortened while leaving the size unchanged. > > How would the string be shortened? > > The string could be modified, yes, but the length can only be changed by > modifying the pascal_string object. (The caller can do that anyway, > unless the contents of pascal_string are somehow made opaque.) > > And maybe the string contents are intended to be mutable; I'm fairly > sure you could modify individual characters in a Pascal string. I think you missed the point. Say the string was a file name, initialised to "some file with a long name" and you change it to "a short name". What happens when you try and open the file? If the length is unchanged, the name will now be "a short nameth a long name". The correct option for modifying the string is to match the getter with a setter. Now you can ensure the getter does not mutate the string and its return value can not be used to mutate the string. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-23 20:02 +0000 |
| Message-ID | <QTjmw.222172$7A5.184137@fx17.am4> |
| In reply to | #55366 |
Ian Collins wrote: > BartC wrote: <snip> >> >> And maybe the string contents are intended to be mutable; I'm fairly >> sure you could modify individual characters in a Pascal string. > > I think you missed the point. > > Say the string was a file name, initialised to "some file with a long > name" and you change it to "a short name". What happens when you try > and open the file? If the length is unchanged, the name will now be "a > short nameth a long name". And it came to pass that the short name, the name that nameth the long name, became the name by which all knoweth the long name, even unto the tenth generation. And the programmer saw that it was good. And then the programmer said unto the filesystem, where is the file that I gave unto you for safe keeping, the file that I gave the very long name? And the filesystem said unto the programmer, verily, I know not. For someone hath shortened the name, but what they changed it to, they did not vouchsafe unto me. And the programmer said unto the filesystem, ah, thou hast a good point there. And is there a backup? And the filesystem laughed in the programmer's face. And darkness was upon the face of the data. -- 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 | "Chris M. Thomasson" <no@spam.invalid> |
|---|---|
| Date | 2014-12-23 12:30 -0800 |
| Message-ID | <m7cjdk$p27$1@speranza.aioe.org> |
| In reply to | #55368 |
> "Richard Heathfield" wrote in message > news:QTjmw.222172$7A5.184137@fx17.am4... [...] > And it came to pass that the short name, the name that nameth the long > name, > became the name by which all knoweth the long name, even unto the tenth > generation. And the programmer saw that it was good. > And then the programmer said unto the filesystem, where is the file that I > gave unto you for safe keeping, the file that I gave the very long name? > And the filesystem said unto the programmer, verily, I know not. For > someone > hath shortened the name, but what they changed it to, they did not > vouchsafe > unto me. > And the programmer said unto the filesystem, ah, thou hast a good point > there. And is there a backup? > And the filesystem laughed in the programmer's face. And darkness was upon > the face of the data. Damn filesystem, and race-conditions to boot!!!! Casting darkness everywhere it legally can. ;^o
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-23 21:12 +0000 |
| Message-ID | <QUkmw.272469$v42.24018@fx19.am4> |
| In reply to | #55366 |
On 23/12/2014 19:50, Ian Collins wrote: > BartC wrote: >> On 23/12/2014 01:41, Ian Collins wrote: >>> It is returning a pointer only a part of the object (the characters). In >>> this case, it should return by value but this isn't practical in this >>> case so cost char* is the safe option. Otherwise consider what happens >>> to the object if the string is shortened while leaving the size >>> unchanged. >> >> How would the string be shortened? >> >> The string could be modified, yes, but the length can only be changed by >> modifying the pascal_string object. (The caller can do that anyway, >> unless the contents of pascal_string are somehow made opaque.) >> >> And maybe the string contents are intended to be mutable; I'm fairly >> sure you could modify individual characters in a Pascal string. > > I think you missed the point. > > Say the string was a file name, initialised to "some file with a long > name" and you change it to "a short name". What happens when you try > and open the file? If the length is unchanged, the name will now be "a > short nameth a long name". > The correct option for modifying the string is to match the getter with > a setter. Now you can ensure the getter does not mutate the string and > its return value can not be used to mutate the string. The getcharacters() function wouldn't be able to return a meaningful result anyway without some length information. Presumably we now need getlength(), setlength(), getcharacters() and setcharacters(). Then, how would setcharacters work? Does it replace the entire string, or does it change one character or a substring of the existing one? (Two entirely different operations.) What about extending the string? What are we doing here anyway; are we /implementing/ a library for working with Pascal strings (in which case why are we wasting our time using getter/setter functions), or making an interface to be used from outside (in which case I would expect getcharacters() to extract a C-compatible string, writeable depending on the docs). The design of the library needs some careful thought; just sprinkling consts about is not a substitute, and is likely to tie you up in knots and distract both you and the reader of the code from what matters. Malcolm's 'const poisoning' is an apt description! (I've actually implemented a getcharacter() type of function for a counted string type. The context there is a little unusual: preparing strings so that they are suitable for passing to an unknown DLL function. I can tell you that using 'const' here would be no help at all!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-24 10:50 +1300 |
| Message-ID | <cfu6dsFim7bU13@mid.individual.net> |
| In reply to | #55373 |
BartC wrote: > On 23/12/2014 19:50, Ian Collins wrote: >> BartC wrote: >>> On 23/12/2014 01:41, Ian Collins wrote: > >>>> It is returning a pointer only a part of the object (the characters). In >>>> this case, it should return by value but this isn't practical in this >>>> case so cost char* is the safe option. Otherwise consider what happens >>>> to the object if the string is shortened while leaving the size >>>> unchanged. >>> >>> How would the string be shortened? >>> >>> The string could be modified, yes, but the length can only be changed by >>> modifying the pascal_string object. (The caller can do that anyway, >>> unless the contents of pascal_string are somehow made opaque.) >>> >>> And maybe the string contents are intended to be mutable; I'm fairly >>> sure you could modify individual characters in a Pascal string. >> >> I think you missed the point. >> >> Say the string was a file name, initialised to "some file with a long >> name" and you change it to "a short name". What happens when you try >> and open the file? If the length is unchanged, the name will now be "a >> short nameth a long name". > >> The correct option for modifying the string is to match the getter with >> a setter. Now you can ensure the getter does not mutate the string and >> its return value can not be used to mutate the string. > > The getcharacters() function wouldn't be able to return a meaningful > result anyway without some length information. Presumably we now need > getlength(), setlength(), getcharacters() and setcharacters(). If the internal representation is null terminated, it could simply return the buffer (like C++ string data() or c_str() members). A size getter would be needed to check for embedded nulls (if they are allowed). > Then, how would setcharacters work? Does it replace the entire string, > or does it change one character or a substring of the existing one? (Two > entirely different operations.) What about extending the string? > > What are we doing here anyway; are we /implementing/ a library for > working with Pascal strings (in which case why are we wasting our time > using getter/setter functions), or making an interface to be used from > outside (in which case I would expect getcharacters() to extract a > C-compatible string, writeable depending on the docs). If you want a writable string, copy the data. > The design of the library needs some careful thought; just sprinkling > consts about is not a substitute, and is likely to tie you up in knots > and distract both you and the reader of the code from what matters. > Malcolm's 'const poisoning' is an apt description! It's still better than object poisoning! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-23 14:06 -0800 |
| Message-ID | <494aaec1-3c7a-479c-90a4-b256c1d97018@googlegroups.com> |
| In reply to | #55374 |
On Tuesday, December 23, 2014 9:51:04 PM UTC, Ian Collins wrote: > > > What are we doing here anyway; are we /implementing/ a library for > > working with Pascal strings (in which case why are we wasting our time > > using getter/setter functions), or making an interface to be used from > > outside (in which case I would expect getcharacters() to extract a > > C-compatible string, writeable depending on the docs). > > If you want a writable string, copy the data. > Basically we want to take in a string from Pascal, manipulate it in C, then pass the results back to Pascal, or vice versa, pass a string from C to Pascal, and get the Pascal routine results back into the C programs. We need to know quite a bit about the Pascal interface before we can achieve all this successfully. Modifying the Pascal memory structure in place might be the only option, or it might be absolutely prohibited (because Pascal make various undocumented optimisations based on the assumption that strings are constant). Most likely it's something that you can avoid if determined, but is the natural way to implement many Pascal idioms in C. However normally you can build things on top of a getCstringfromPascal(), and createPascalStringfromCstring() function. The Pascal memory structure might be mappable onto a C struct, or you might have to construct it bitwise, depending on the degree of portability you need.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-12-23 22:22 +0000 |
| Message-ID | <20141223141323.231@kylheku.com> |
| In reply to | #55348 |
On 2014-12-23, BartC <bc@freeuk.com> wrote: > On 23/12/2014 01:41, Ian Collins wrote: >> BartC wrote: >>> On 23/12/2014 00:18, Ian Collins wrote: >>>> Malcolm McLean wrote: > >>>>> char *getcharacters(void *pascal_string) >>>> >>>> You'd want "const char*" there. Messing with the characters and >>>> inadvertently changing the size isn't a good idea. >>> >>> Do you mean in place of 'void *pascal_string' or as the result type? If >>> the latter, then I'm struggling to figure out what it helps, and how. > >> The function is what C++ folks call a getter. It doesn't alter the sate >> of the object so the parameter should be const. >> >> It is returning a pointer only a part of the object (the characters). In >> this case, it should return by value but this isn't practical in this >> case so cost char* is the safe option. Otherwise consider what happens >> to the object if the string is shortened while leaving the size unchanged. > > How would the string be shortened? The string could be shortened without updating the size if it is a hybrid representation: a Pascal string that is null terminated. I think that is obviously the idea here! This hybrid representation allows us to cheaply produce a C string without making a copy of the object, just by returning the "const char *" address of the data. (On the other hand, the hybrid representation does not allow null characters to be constituents of a string, erasing one small advantage of Pascal strings.) If we return "char *", the caller can write a null into the middle of the string, thereby shortening its C string representation, while the length field of the Pascal view continues to indicate that the string is longer. If we return "const char *", the caller needs to use a cast to do that.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-24 00:10 +0000 |
| Message-ID | <1wnmw.309290$td6.28533@fx30.am4> |
| In reply to | #55376 |
On 23/12/2014 22:22, Kaz Kylheku wrote: > On 2014-12-23, BartC <bc@freeuk.com> wrote: >> On 23/12/2014 01:41, Ian Collins wrote: >>> Otherwise consider what happens >>> to the object if the string is shortened while leaving the size unchanged. >> >> How would the string be shortened? > > The string could be shortened without updating the size if it is a > hybrid representation: a Pascal string that is null terminated. > I think that is obviously the idea here! That hybrid rep won't work well with two ways of determining the end of the string. The count field must be the primary method. In that case, writing an embedded null won't really shorten it, it'll just corrupt it. > This hybrid representation allows us to cheaply produce a C string > without making a copy of the object, just by returning the "const char *" > address of the data. Or a char* string can also be returned, because sometimes you do want to modify it in but not alter the length. With "const char*" you now need two ways of getting that string pointer. If this is inside a routine that has been asked by its caller to obtain the string part of a Pascal string, it won't know if the caller will want to write to it or not. Simplest then to use char*, and leave it to the caller code, if it's so paranoid it can't trust itself to not corrupt strings it shouldn't be writing to, to apply any const casts if it has to. > (On the other hand, the hybrid representation > does not allow null characters to be constituents of a string, erasing > one small advantage of Pascal strings.) The length field is a significant advantage. In fact, having a Pascal string type even limited to 80 characters, passed around by value, would form a very useful little C library for string processing, as very often short strings are the most common. (I've just tested some compiler apps, and the average length of strings they use is from 4 to 8 characters.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-24 14:21 +1300 |
| Message-ID | <cfuionFim7bU15@mid.individual.net> |
| In reply to | #55377 |
BartC wrote:
> On 23/12/2014 22:22, Kaz Kylheku wrote:
>> On 2014-12-23, BartC <bc@freeuk.com> wrote:
>>> On 23/12/2014 01:41, Ian Collins wrote:
>
>>>> Otherwise consider what happens
>>>> to the object if the string is shortened while leaving the size unchanged.
>>>
>>> How would the string be shortened?
>>
>> The string could be shortened without updating the size if it is a
>> hybrid representation: a Pascal string that is null terminated.
>> I think that is obviously the idea here!
>
> That hybrid rep won't work well with two ways of determining the end of
> the string. The count field must be the primary method. In that case,
> writing an embedded null won't really shorten it, it'll just corrupt it.
No, a terminating null would be at data[size]. Writing any other null
to the data may or may not corrupt the data, depending on whether
embedded nulls are allowed.
>> This hybrid representation allows us to cheaply produce a C string
>> without making a copy of the object, just by returning the "const char *"
>> address of the data.
>
> Or a char* string can also be returned, because sometimes you do want to
> modify it in but not alter the length. With "const char*" you now need
> two ways of getting that string pointer. If this is inside a routine
> that has been asked by its caller to obtain the string part of a Pascal
> string, it won't know if the caller will want to write to it or not.
So provide a function like copyOutString( char*, size_t).
> Simplest then to use char*, and leave it to the caller code, if it's so
> paranoid it can't trust itself to not corrupt strings it shouldn't be
> writing to, to apply any const casts if it has to.
No, all that gives you is a gateway to subtle and hard to find memory
corruption bugs. Why introduce a new gets()? If you want the string to
be mutable, provide the functions to do this, don't expose the guts of
the object. Consider what happens if you write past the end, or..
>> (On the other hand, the hybrid representation
>> does not allow null characters to be constituents of a string, erasing
>> one small advantage of Pascal strings.)
>
> The length field is a significant advantage. In fact, having a Pascal
> string type even limited to 80 characters, passed around by value, would
> form a very useful little C library for string processing, as very often
> short strings are the most common.
>
> (I've just tested some compiler apps, and the average length of strings
> they use is from 4 to 8 characters.)
..the implementation does in fact use a short string optimisation, say
it's something like
struct String
{
uint8_t size;
char shortString[7];
char* data;
}
and you write 8 characters.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-24 11:19 +0000 |
| Message-ID | <Nixmw.139727$0o3.126620@fx45.am4> |
| In reply to | #55378 |
On 24/12/2014 01:21, Ian Collins wrote:
> BartC wrote:
>> Simplest then to use char*, and leave it to the caller code, if it's so
>> paranoid it can't trust itself to not corrupt strings it shouldn't be
>> writing to, to apply any const casts if it has to.
>
> No, all that gives you is a gateway to subtle and hard to find memory
> corruption bugs. Why introduce a new gets()? If you want the string to
> be mutable, provide the functions to do this, don't expose the guts of
> the object. Consider what happens if you write past the end, or..
OK, we're obviously never going to agree. My main concern is avoiding a
proliferation of 'const' everywhere that will introduce clutter and
obscure the clarity of the code.
Since most string parameters are going to be 'in' parameters, not 'out'
or 'inout' ones, then they /will/ be everywhere using your method.
And take an innocuous-looking function as strstr(), which returns a
location in its first string parameter. Its prototype is like this:
char* strstr(const char* str, const char* searchstr);
While it takes pains to show that it doesn't write to the 'str'
parameter, it then proceeds to return a writeable pointer into that string!
If we try and make the result const char*, then we run into problems
when we *do* need to write to that part of str.
To get around this is C++, apparently two overloads are used, one with a
char* result, and one with a const char* result. This is too achieve
what we could have got without bothering with const in the first place!
> ..the implementation does in fact use a short string optimisation, say
> it's something like
>
> struct String
> {
> uint8_t size;
> char shortString[7];
> char* data;
> }
(Not a particular efficient way of implementing a short string. I used a
scheme, in a language that normally uses counted strings, where I can
have a short string field inside a struct that can store up to 8
characters, in a field width of 8 characters!)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-24 04:55 -0800 |
| Message-ID | <b315520b-d339-4bf8-89cd-b2e4f5e298ed@googlegroups.com> |
| In reply to | #55380 |
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.
But neither is consting the x really helping, unless x has been
declared const somewhere else. 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. 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.
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.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-25 08:28 +1300 |
| Message-ID | <cg0ifaFim7bU18@mid.individual.net> |
| 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.
Isn't one of the needs of the programmer to know whether a function is
going to modify his/her data?
> 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.
No one would do that...
> But neither is consting the x really helping, unless x has been
> declared const somewhere else. 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.
Good, nothing in the call chain in going to inadvertently modify the data.
> 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.
Nonsense, they can glance at the function prototype and see is isn't
going to modify the data. They can see the parameter is input only.
> Worse, we create messes for
> functions like strstr(), which return pointers to data passed to us,
> which may be writeable or nonwritable.
strstr() was FUBAR from day one..
> 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.
>
> 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.
No, it clarifies it.
> 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.
Why not? Making ps const in getCharAt clearly expressed the contract in
the function prototype which is where it belongs.
How would you use your getCharAt function with a PascalString that was
const?
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-24 12:27 -0800 |
| Message-ID | <56e6e567-b8be-4d8b-a5c7-96b82fc12162@googlegroups.com> |
| In reply to | #55394 |
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.
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.
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.
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web