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 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-25 03:33 -0800 |
| Message-ID | <a2c0ba59-2828-45f0-8ed8-b0bc36f77c4d@googlegroups.com> |
| In reply to | #55427 |
W dniu czwartek, 25 grudnia 2014 11:39:34 UTC+1 użytkownik fir napisał:
> and yet some more things of my terrific 10 years of heavy teory work on spirit of c
> (i took ocassion to sum up part of the things)
ps tooking occasion i may allso mention this one
int `this is some free name` = 10;
void `some function name`()
{
}
this is fun but probably somewhat worth looking.. i took occasion to sum some most important pices, sadly i do not even have one summaric document as this all is born in haos and spreaded acros the years, i only make some sum-ups once a few years
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-25 02:56 -0800 |
| Message-ID | <5840b8cf-9a11-4736-a67e-172e200102c6@googlegroups.com> |
| In reply to | #55426 |
W dniu czwartek, 25 grudnia 2014 11:21:17 UTC+1 użytkownik fir napisał: > > (if so const may be deprecated;/ in general c comitee should listen to me and put whole set of my improvements into c and everyone will be happy then) (sadly i doubt if they will just listen to me and develop c this way, so i will have to wrote c2 compiler on my own and it will take yet 10 years or so, right now im tinkering with pe format and foggy tutorials)
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2015-01-12 15:33 -0500 |
| Message-ID | <tsb8bapjekrp432iq4ar7oe1dd8he9isd9@4ax.com> |
| In reply to | #55398 |
On Wed, 24 Dec 2014 12:05:27 -0800, Keith Thompson <kst-u@mib.org> wrote: > BartC <bc@freeuk.com> writes: <snip> > > char* strstr(const char* str, const char* searchstr); > > > > While it takes pains to show that it doesn't write to the 'str' > > parameter, it then proceeds to return a writeable pointer into that string! > > Yes, and that is a problem. strstr() lets you violate const correctness > without a cast; <snip> > I'm fairly sure that strstr is the *only* function in the C standard > library that has this problem. <snip> Not the only one; the others, conveniently identified by C++(99) 21.4 [lib.c.strings] as needing overloads to fix const safety, are str[r]chr, strpbrk, memchr, and the wcs/wchar variants.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-12-23 05:17 +0000 |
| Message-ID | <20141222210551.3@kylheku.com> |
| In reply to | #55322 |
On 2014-12-23, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Monday, December 22, 2014 10:35:49 PM UTC, Bart wrote: >> >> (3) (You've gone back to using a single byte code for the string length, >> even though the OP decided to use an int. And that count field is likely >> padded out to an int anyway. But this depends on how important the >> Pascal compatibility is; no solution presented so far will exactly match >> how Pascal is likely to implement it.) >> > You want to pass the Pascal string around as bit buffers. Internally > Pascal may store as length byte + characters, 2 length bytes + > characters, 4 length bytes + characters, the size_t answer of 8 > length bytes + characters, and it might even use non-native endianness. > > it's only a minor problem. We provide > > int (size_t if you must) getlength(void *pascal_string) For Pete's sake, don't create API's in which the role of your important data type is played by void *. This will not give the users any diagnostics if they make mistakes like: getlength(&ps); /* oops, should have been getlength(ps) */ You want: typedef struct pascal_string pascal_string; /* incomplete struct */ int getlength(const pascal_string *); Not only is this safer, but in the .c file you can just complete the struct type, and not have to convert between void * and another type in every function.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-23 07:43 -0800 |
| Message-ID | <lnbnmu2wyz.fsf@nuthaus.mib.org> |
| In reply to | #55322 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> You want to pass the Pascal string around as bit buffers. Internally
> Pascal may store as length byte + characters, 2 length bytes +
> characters, 4 length bytes + characters, the size_t answer of 8
> length bytes + characters, and it might even use non-native endianness.
[...]
In the version of Pascal I used (UCSD Pascal), the length of a string
was stored as a single byte, and could not exceed 255.
A string was a packed array of char, with element 0 holding the length
and the first character of the string itself in element 1. If you
turned off range checking, you could even refer to the length byte as
s[0].
The default length of a declared string variable was 80:
S: string; (* equivalent to "S: string[80];", same
representation as
S: packed array[0..80] of char;" */
S_Big: string[255]; (* can hold a string up to 255 characters plus
the length byte *)
Representations that use more than one byte for the length are certainly
possible, but they're not "Pascal strings" as I understand the term.
--
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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2014-12-23 20:42 +0000 |
| Message-ID | <5499d2fd.12046375@news.xs4all.nl> |
| In reply to | #55322 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Monday, December 22, 2014 10:35:49 PM UTC, Bart wrote: > > > > (3) (You've gone back to using a single byte code for the string length, > > even though the OP decided to use an int. And that count field is likely > > padded out to an int anyway. But this depends on how important the > > Pascal compatibility is; no solution presented so far will exactly match > > how Pascal is likely to implement it.) > > > You want to pass the Pascal string around as bit buffers. Internally > Pascal may store as length byte + characters, 2 length bytes + > characters, 4 length bytes + characters, the size_t answer of 8 > length bytes + characters, and it might even use non-native endianness. No, that's the problem. It has to store _allocated_ length, _current_ length, and characters. And only the latter two are accessible by the user-programmer, so it has to hide the first one. But it's there. And if you pass a string from one to the other, for any other purposes than an immediate copy to a "natural" string (for the receiving language), you'd better pass all three or you _will_ get buffer overflows. But you're not allowed to pass all three in user code, because user code is not to know even of the existence, or the location, let alone the content, of the first field. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-23 11:48 +1300 |
| Message-ID | <cfrleqFim7bU4@mid.individual.net> |
| In reply to | #55305 |
Richard Heathfield wrote:
>
> Something like this:
>
>
> t_pascalstring *pascalstring_create(const char *s)
> {
> size_t len = 0;
> int okay = 1;
> t_pascalstring *new = NULL;
> if(s != NULL && *s != '\0')
> {
> new = malloc(sizeof *new);
> if(new == NULL)
> {
> okay = 0;
> }
> else
> {
> new->ps = NULL;
> new->size = 0;
> }
> }
> if(okay)
> {
> len = strlen(s);
Things will go horribly wrong here if s is null...
I would make the first line something like
if( s == NULL ) return NULL;
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-22 23:55 +0000 |
| Message-ID | <tb2mw.121655$8q6.17676@fx25.am4> |
| In reply to | #55315 |
Ian Collins wrote:
> Richard Heathfield wrote:
>>
>> Something like this:
>>
>
>>
>> t_pascalstring *pascalstring_create(const char *s)
>> {
>> size_t len = 0;
>> int okay = 1;
>> t_pascalstring *new = NULL;
>> if(s == NULL || *s == '\0')
>> {
okay = 0;
}
if(okay)
{
>> new = malloc(sizeof *new);
>> if(new == NULL)
>> {
>> okay = 0;
>> }
>> else
>> {
>> new->ps = NULL;
>> new->size = 0;
>> }
>> }
>> if(okay)
>> {
>> len = strlen(s);
>
> Things will go horribly wrong here if s is null...
Oh dear. And I thought I was being so careful. (I even compiled the darn
thing!) Code fixed (above).
> I would make the first line something like
>
> if( s == NULL ) return NULL;
Whereas I would set okay to 0 and then let the flow continue to the end of
the function. Different folks, different strokes.
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-23 13:21 +1300 |
| Message-ID | <cfrqt5Fim7bU9@mid.individual.net> |
| In reply to | #55320 |
Richard Heathfield wrote: > Ian Collins wrote: > >> I would make the first line something like >> >> if( s == NULL ) return NULL; > > Whereas I would set okay to 0 and then let the flow continue to the end of > the function. Different folks, different strokes. While I prefer to avoid early return in C, I do make an exception for testing invariants before any work that could change the programme state. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-23 11:55 +1300 |
| Message-ID | <cfrlq8Fim7bU5@mid.individual.net> |
| In reply to | #55305 |
Richard Heathfield wrote:
>
> t_pascalstring *pascalstring_create(const char *s)
> {
> size_t len = 0;
> int okay = 1;
> t_pascalstring *new = NULL;
> if(s != NULL && *s != '\0')
> {
> new = malloc(sizeof *new);
> if(new == NULL)
> {
> okay = 0;
> }
> else
> {
> new->ps = NULL;
> new->size = 0;
> }
> }
> if(okay)
> {
> len = strlen(s);
> if(len > UCHAR_MAX)
> {
> okay = 0;
> }
> }
> if(okay)
> {
> new->ps = malloc(len);
It'll also get upset here (new not allocated) if s is an empty string.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-23 12:12 +1300 |
| Message-ID | <cfrmrdFim7bU6@mid.individual.net> |
| In reply to | #55316 |
Ian Collins wrote:
> Richard Heathfield wrote:
>>
>> t_pascalstring *pascalstring_create(const char *s)
>> {
>> size_t len = 0;
>> int okay = 1;
>> t_pascalstring *new = NULL;
>> if(s != NULL && *s != '\0')
>> {
>> new = malloc(sizeof *new);
>> if(new == NULL)
>> {
>> okay = 0;
>> }
>> else
>> {
>> new->ps = NULL;
>> new->size = 0;
>> }
>> }
>> if(okay)
>> {
>> len = strlen(s);
>> if(len > UCHAR_MAX)
>> {
>> okay = 0;
>> }
>> }
>> if(okay)
>> {
>> new->ps = malloc(len);
>
> It'll also get upset here (new not allocated) if s is an empty string.
>
A slightly shorter and hopefully safer solution:
t_pascalstring*
pascalstring_create( const char *s )
{
if( s == NULL ) return NULL;
const size_t len = *s == '\0' ? 0 : strlen(s);
if( len > UCHAR_MAX ) return NULL;
t_pascalstring* new = malloc( sizeof *new );
if( new != NULL )
{
new->size = len;
new->ps = malloc( new->size );
if( new->ps != NULL )
{
memcpy( new->ps, s, new->size );
}
else
{
pascalstring_destroy( &new );
}
}
return new;
}
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-12-22 23:33 +0000 |
| Message-ID | <m7a9u7$25o$1@dont-email.me> |
| In reply to | #55318 |
Ian Collins <ian-news@hotmail.com> writes:
> Ian Collins wrote:
<snip>
>> It'll also get upset here (new not allocated) if s is an empty string.
>>
> A slightly shorter and hopefully safer solution:
>
> t_pascalstring*
> pascalstring_create( const char *s )
> {
> if( s == NULL ) return NULL;
>
> const size_t len = *s == '\0' ? 0 : strlen(s);
Am I missing something? Did you mean to use 1 when strlen(s) is zero?
If so, you also need to adjust the size below because you don't want the
length to be reported as 1.
Personally, I'd make the string part always be null-terminated. It
avoids the problem of allocating a zero-length string, and it means the
string part can sometimes be used on its own where a C string is
expected.
>
> if( len > UCHAR_MAX ) return NULL;
>
> t_pascalstring* new = malloc( sizeof *new );
>
> if( new != NULL )
> {
> new->size = len;
> new->ps = malloc( new->size );
>
> if( new->ps != NULL )
> {
> memcpy( new->ps, s, new->size );
> }
> else
> {
> pascalstring_destroy( &new );
> }
> }
>
> return new;
> }
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-23 12:59 +1300 |
| Message-ID | <cfrpjnFim7bU7@mid.individual.net> |
| In reply to | #55319 |
Ben Bacarisse wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>
>> Ian Collins wrote:
> <snip>
>>> It'll also get upset here (new not allocated) if s is an empty string.
>>>
>> A slightly shorter and hopefully safer solution:
>>
>> t_pascalstring*
>> pascalstring_create( const char *s )
>> {
>> if( s == NULL ) return NULL;
>>
>> const size_t len = *s == '\0' ? 0 : strlen(s);
>
> Am I missing something? Did you mean to use 1 when strlen(s) is zero?
> If so, you also need to adjust the size below because you don't want the
> length to be reported as 1.
The twin perils of premature optimisation and coding without tests!
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-22 23:03 +0000 |
| Message-ID | <Qq1mw.121178$6Q5.2216@fx41.am4> |
| In reply to | #55305 |
On 22/12/2014 19:41, Richard Heathfield wrote:
> t_pascalstring *pascalstring_create(const char *s)
> {
> size_t len = 0;
> int okay = 1;
> t_pascalstring *new = NULL;
> if(s != NULL && *s != '\0')
> {
> new = malloc(sizeof *new);
> if(new == NULL)
> {
> okay = 0;
> }
> else
> {
> new->ps = NULL;
> new->size = 0;
> }
(4) Something else I'd spotted but then lost (and Ian's post reminded
me): it seems here that for empty strings, you set the pointer to NULL.
This is workable, but in C, an empty string "" is perfectly valid. This
is likely to cause problems every time you want to interface a
t_pascalstring type to wherever a C string is used. (The lack of a
terminator would also be a problem in many instances, but needing extra
logic to deal with a char* pointer that might be NULL when representing
"" is an unnecessary one.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | CHIN Dihedral <dihedral88888@gmail.com> |
|---|---|
| Date | 2015-03-26 04:04 -0700 |
| Message-ID | <ef3e6f32-cea0-4e3a-b664-0032310a9628@googlegroups.com> |
| In reply to | #55305 |
On Tuesday, December 23, 2014 at 3:41:42 AM UTC+8, Richard Heathfield wrote:
> Dexterr wrote:
>
> > On Monday, December 22, 2014 6:49:39 PM UTC+1, Bart wrote:
> >> On 22/12/2014 14:55, Dexterr wrote:
> >>
> >> > Thanks Mr Bart but it's not allowed to use a string.h function. Thats a
> >> > problem.
> >>
> >> But are you allowed to create your own versions? Here I've created a
> >> version of strlen(), and replaces strcpy() by a loop (but it no longer
> >> copies the terminating zero).
> >>
> >> #include <stdio.h>
> >> #include <stdlib.h>
> >>
> >> typedef struct PascalString {
> >> int size;
> >> char *string;
> >> } PString;
> >>
> >> int mystrlen(char* s) {
> >> int length=0;
> >> if (s==NULL) return 0;
> >> while (*s++) ++length;
> >> return length;
> >> }
> >>
> >> PString newPascalString(char *stringC) {
> >> int i;
> >> int length = mystrlen(stringC);
> >>
> >> PString pascal_string;
> >> pascal_string.size = length;
> >> pascal_string.string = malloc(length);
> >> for (i=0; i<length; ++i) pascal_string.string[i]=stringC[i];
> >>
> >> return pascal_string;
> >> }
> >>
> >> void printPascalString(PString ps) {
> >> if (ps.size)
> >> printf("%.*s",ps.size,ps.string);
> >> }
> >>
> >> int main()
> >> {
> >> char *c_string = "Mississippi";
> >> PString ps;
> >> ps = newPascalString(c_string);
> >>
> >> printPascalString(ps);
> >> puts("");
> >>
> >> return 0;
> >> }
> >>
> >> --
> >> Bartc
> >
> > Thanks Mr Bart.
> >
> > This solution is great. I have learn a lot from this. But, one more
> > question. In valgrind there is a memory leak. I am not good in memory
> > dinamic allocation. Probably we should free some memory. Maybe the answer
> > is here pascal_string.string = malloc(length);
> >
> > Now, I am not sure where to put free ? In main or newPascalString function
> > ?
>
> newPascalString() allocates storage for a Pascal-style string. If you
> release the storage at that point, you can't use the string.
>
> main() contains the high-level logic of the program. Releasing one memory
> block in main() won't do you much harm, but it's not really what main is
> for.
>
> The right way to do this is (if do it one must) is to put all the Pascal
> string code into a library, and this should include a mechanism for
> destroying the string.
>
> Something like this:
>
> /******** pascalstring.h ***********/
> #ifndef H_PASCALSTRING
> #define H_PASCALSTRING 1
> #include <stdio.h>
> typedef struct t_pascalstring_ t_pascalstring;
> t_pascalstring *pascalstring_create(const char *);
> int pascalstring_write(FILE *, const t_pascalstring *);
> int pascalstring_getlength(const t_pascalstring *);
> void pascalstring_destroy(t_pascalstring **);
> #endif
> /******** pascalstring.h ***********/
>
> /******** pascalstring.c ***********/
> #include "pascalstring.h"
> #include <stdlib.h>
> #include <string.h> /* see below */
> #include <limits.h>
>
> struct t_pascalstring_
> {
> unsigned char size;
> char *ps;
> };
>
> t_pascalstring *pascalstring_create(const char *s)
> {
> size_t len = 0;
> int okay = 1;
> t_pascalstring *new = NULL;
> if(s != NULL && *s != '\0')
> {
> new = malloc(sizeof *new);
> if(new == NULL)
> {
> okay = 0;
> }
> else
> {
> new->ps = NULL;
> new->size = 0;
> }
> }
> if(okay)
> {
> len = strlen(s);
> if(len > UCHAR_MAX)
> {
> okay = 0;
> }
> }
> if(okay)
> {
> new->ps = malloc(len);
> if(new->ps != NULL)
> {
> memcpy(new->ps, s, len); /* see below */
> new->size = len;
> }
> else
> {
> okay = 0;
> }
> }
> if(!okay)
> {
> pascalstring_destroy(&new);
> }
> return new;
> }
> int pascalstring_write(FILE *fpout, const t_pascalstring *ps)
> {
> int rc = -1; /* error return */
> if(fpout != NULL && ps != NULL)
> {
> rc = fprintf(fpout,
> "%.*s",
> pascalstring_getlength(ps), ps->ps);
> }
> return rc;
> }
> int pascalstring_getlength(const t_pascalstring *ps)
> {
> int rc = -1;
> if(ps != NULL)
> {
> rc = ps->size;
> }
> return rc;
> }
> void pascalstring_destroy(t_pascalstring **old)
> {
> if(old != NULL)
> {
> if(*old != NULL)
> {
> free((*old)->ps);
> free(*old);
> *old = NULL;
> }
> }
> }
> /******** pascalstring.c ***********/
>
> /******** main.c ***********/
> #include <stdio.h>
> #include <stdlib.h>
> #include "pascalstring.h"
>
> int main(void)
> {
> int rc = -1;
> const char *cs = "Mississippi";
> t_pascalstring *p = pascalstring_create(cs);
> if(p != NULL)
> {
> rc = pascalstring_write(stdout, p);
> putchar('\n');
> pascalstring_destroy(&p);
> }
> return rc == 0 ? EXIT_SUCCESS : EXIT_FAILURE;
> }
>
> /******** main.c ***********/
>
> Note: if you really aren't allowed to use <string.h>, the ONLY thing you
> have to do is write this:
>
> void my_memcpy(void *vleft, const void *vright, size_t len)
> {
> unsigned char *left = vleft;
> unsigned char *right = vright;
> while(len--)
> {
> *left++ = *right++;
> }
> }
>
> and then replace
>
> memcpy(new->ps, s, len);
>
> with
>
> my_memcpy(new->ps, s, len);
>
>
> What this gives you is a robust type that is easily extensible but difficult
> for calling code to break (not impossible, mark you - but difficult). I
> invite you to compare and contrast this response with other technical
> responses you've received. In what ways is it similar? In what ways is it
> different? Do you understand why it's different? What advantages and
> disadvantages does my way of writing the code entail?
>
> All these are important questions - far more important, in fact, than the
> actual exercise.
>
> --
> 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
C is a lower level language, and
malloc might fail.
There are various situations that
C compiled programs could fail
without uttering any message in
different run time enviroments .
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-26 11:22 +0000 |
| Message-ID | <mf0q4o$utl$1@dont-email.me> |
| In reply to | #59014 |
On 26/03/15 11:04, CHIN Dihedral wrote: > On Tuesday, December 23, 2014 at 3:41:42 AM UTC+8, Richard Heathfield wrote: <snip> >> >> What this gives you is a robust type that is easily extensible but difficult >> for calling code to break (not impossible, mark you - but difficult). I >> invite you to compare and contrast this response with other technical >> responses you've received. In what ways is it similar? In what ways is it >> different? Do you understand why it's different? What advantages and >> disadvantages does my way of writing the code entail? >> >> All these are important questions - far more important, in fact, than the >> actual exercise. >> > C is a lower level language, and > malloc might fail. It is certainly the case with computers that, when one calls upon them for a resource, they might respond with a "no". This is true in any programming language. This is why, in my example code, I returned NULL from the function for creating a string in the event that the allocation request could not be satisfied. It is up to the calling code to ensure that the return value is checked against NULL before proceeding. > There are various situations that > C compiled programs could fail > without uttering any message in > different run time enviroments . That's up to the programmer. -- 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 | dmaxime66@gmail.com |
|---|---|
| Date | 2014-12-28 09:37 -0800 |
| Message-ID | <65bee6c5-4a2b-4f29-87ba-9fb0887ed856@googlegroups.com> |
| In reply to | #55281 |
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
>
> typedef struct PascalString {
> int size;
> char *string;
> } PString;
>
> PString newPascalString(char *stringC) {
> int i;
> int length = strlen(stringC);
> PString pascal_string;
> pascal_string.size = length;
> pascal_string.string = malloc(length+1);
> strcpy(pascal_string.string, stringC);
>
> return pascal_string;
> }
>
> void printPascalString(PString ps) {
> if (ps.size)
> printf("%.*s",ps.size,ps.string);
> }
>
> int main()
> {
> char *c_string = "Mississippi";
> PString ps;
> ps = newPascalString(c_string);
>
> printPascalString(ps);
> puts("");
>
> return 0;
> }
>
> --
> Bartc
Hello Bart,
I think you chose a dangerous way in your example: in the called function newPascalString you have allocated pascal_string as automatic variable and return it by the function. Some compilers do not copy the structures returning from functions but only its handle and in this case the handle of a struct lost in the stack. So if you, in the main function, add a call to a function (eg printf) between function calls "newPascalString" and "printPascalString", you could not find your data.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-28 18:17 +0000 |
| Message-ID | <1PXnw.188595$AC.10050@fx29.am4> |
| In reply to | #55552 |
On 28/12/2014 17:37, dmaxime66@gmail.com wrote:
>> typedef struct PascalString {
>> int size;
>> char *string;
>> } PString;
>> PString newPascalString(char *stringC) {
>> PString pascal_string;
>> return pascal_string;
>> }
> I think you chose a dangerous way in your example: in the called function newPascalString you have allocated pascal_string as automatic variable and return it by the function. Some compilers do not copy the structures returning from functions but only its handle and in this case the handle of a struct lost in the stack. So if you, in the main function, add a call to a function (eg printf) between function calls "newPascalString" and "printPascalString", you could not find your data.
Which compilers do that?
C stipulates that structs are treated like value types. An
implementation might decide to use handles or pointers, but the effect
should be the same as thought structs are passed, returned, assigned and
copied by value.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | dmaxime66@gmail.com |
|---|---|
| Date | 2014-12-30 05:28 -0800 |
| Message-ID | <0366b828-8212-46b5-adfc-2a2af6687a5b@googlegroups.com> |
| In reply to | #55554 |
> > Which compilers do that? > > C stipulates that structs are treated like value types. An > implementation might decide to use handles or pointers, but the effect > should be the same as thought structs are passed, returned, assigned and > copied by value. > > -- > Bartc First, I apologize for my English, and then I try to explain the reason for my comment: I might be okay with you (and Ian Collins) if we discuss about to study and understand the current compilers but there is a prior. I think that everyone working as developer has had to put his hand on the old programs compiling them with their original compilers. It happened to me a lot of times and particularly remember two compilers that made me go crazy for this kind of problems: One was the Lattice and the other of Greenhills. ps: I am sorry to have forgotten the 'c' of your name in the previous post.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-31 08:29 +1300 |
| Message-ID | <cggco2Fm4qrU7@mid.individual.net> |
| In reply to | #55578 |
dmaxime66@gmail.com wrote: >> >> Which compilers do that? >> >> C stipulates that structs are treated like value types. An >> implementation might decide to use handles or pointers, but the >> effect should be the same as thought structs are passed, returned, >> assigned and copied by value. >> >> -- Bartc > > > First, I apologize for my English, and then I try to explain the > reason for my comment: I might be okay with you (and Ian Collins) if > we discuss about to study and understand the current compilers but > there is a prior. I think that everyone working as developer has had > to put his hand on the old programs compiling them with their > original compilers. It happened to me a lot of times and particularly > remember two compilers that made me go crazy for this kind of > problems: One was the Lattice and the other of Greenhills. I don't think I've ever encountered a compiler that didn't handle returning a structure by value. Even if such an ancient compiler did exist, maintaining compatibility with it shouldn't be a consideration in any fresh code. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web