Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #63176 > unrolled thread
| Started by | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| First post | 2015-06-10 22:32 -0700 |
| Last post | 2015-06-10 23:07 -0700 |
| Articles | 20 on this page of 182 — 25 participants |
Back to article view | Back to comp.lang.c
Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-10 22:32 -0700
Re: Reason for segmentation violation Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2015-06-11 07:52 +0200
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-11 07:19 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-11 15:46 +0100
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-11 11:23 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-11 12:08 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-11 15:44 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-11 12:55 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-11 16:29 -0400
Re: Reason for segmentation violation gordonb.h0fbo@burditt.org (Gordon Burditt) - 2015-06-17 23:51 -0500
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-17 23:10 -0700
Re: Reason for segmentation violation gordonb.0vo9r@burditt.org (Gordon Burditt) - 2015-06-18 03:30 -0500
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 02:40 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-11 21:00 +0100
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-11 19:58 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-11 23:42 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-12 08:33 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-12 02:36 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-12 11:07 +0100
Re: Reason for segmentation violation gwowen <gwowen@gmail.com> - 2015-06-12 04:55 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-12 13:17 +0100
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-12 13:32 +0100
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-12 13:20 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-13 23:55 -0700
Restrictions on inline functions (Was: Reason for segmentation violation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-14 10:30 +0100
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-12 11:10 -0400
Re: Reason for segmentation violation David Thompson <dave.thompson2@verizon.net> - 2015-06-21 12:46 -0400
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-12 08:35 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-12 12:21 -0400
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-12 10:48 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-12 19:12 +0100
Re: Reason for segmentation violation David Kleinecke <dkleinecke@gmail.com> - 2015-06-12 08:49 -0700
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-12 09:13 -0700
Re: Reason for segmentation violation David Kleinecke <dkleinecke@gmail.com> - 2015-06-13 08:55 -0700
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-12 08:56 -0700
Re: Reason for segmentation violation glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-12 09:41 +0000
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-12 08:29 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 00:03 -0700
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-14 00:58 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 02:14 -0700
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-14 04:26 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 06:29 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-14 15:06 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 07:25 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-14 16:59 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 11:51 -0700
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-14 16:43 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 14:16 -0700
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-14 20:35 -0400
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-15 01:19 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 03:57 -0700
Re: Reason for segmentation violation Bartc <bc@freeuk.com> - 2015-06-15 12:26 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 04:47 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-15 15:02 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 07:08 -0700
Re: Reason for segmentation violation Bartc <bc@freeuk.com> - 2015-06-15 18:56 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 20:09 -0700
Re: Reason for segmentation violation Bartc <bc@freeuk.com> - 2015-06-16 09:31 +0100
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 10:09 +0100
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-16 02:36 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 11:01 +0100
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 12:37 +0100
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-16 08:40 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-16 10:32 -0700
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-17 07:54 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 05:28 -0700
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-18 00:34 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 09:13 +0200
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-19 21:17 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-20 23:28 +0200
Re: Reason for segmentation violation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-15 05:26 -0700
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-15 06:20 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 14:25 +0100
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-15 07:52 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 18:29 +0100
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-15 11:15 -0700
Re: Reason for segmentation violation raltbos@xs4all.nl (Richard Bos) - 2015-06-18 20:41 +0000
Re: Reason for segmentation violation Bartc <bc@freeuk.com> - 2015-06-15 18:48 +0100
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-15 11:04 -0700
Re: Reason for segmentation violation raltbos@xs4all.nl (Richard Bos) - 2015-06-18 20:44 +0000
Re: Reason for segmentation violation David Brown <david.brown@hesbynett.no> - 2015-06-19 10:39 +0200
Re: Reason for segmentation violation gwowen <gwowen@gmail.com> - 2015-06-16 00:58 -0700
Re: Reason for segmentation violation raltbos@xs4all.nl (Richard Bos) - 2015-06-18 20:40 +0000
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-18 17:06 -0400
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 14:56 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 23:04 +0100
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-18 18:18 -0400
Re: Reason for segmentation violation David Brown <david.brown@hesbynett.no> - 2015-06-19 10:26 +0200
Re: Reason for segmentation violation David Kleinecke <dkleinecke@gmail.com> - 2015-06-19 08:57 -0700
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-15 08:54 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 06:24 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-15 14:32 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 05:43 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-14 23:28 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 16:31 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-15 01:27 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 05:34 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-15 15:00 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 20:37 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 09:58 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-16 10:37 -0700
Re: Reason for segmentation violation luser droog <luser.droog@gmail.com> - 2015-06-15 17:51 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 21:02 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-16 00:51 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 22:30 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-17 00:35 -0400
Re: Reason for segmentation violation Rosario19 <Ros@invalid.invalid> - 2015-06-19 18:51 +0200
Re: Reason for segmentation violation luser droog <luser.droog@gmail.com> - 2015-06-15 22:40 -0700
Re: Reason for segmentation violation luser droog <luser.droog@gmail.com> - 2015-06-15 23:23 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-16 11:07 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-16 23:54 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 10:51 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 03:46 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 04:17 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 14:02 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 06:15 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 15:34 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 07:58 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 16:04 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 08:16 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 14:57 +0200
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 15:35 +0100
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 15:44 +0100
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 08:18 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 16:42 +0100
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 08:19 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 16:35 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 08:49 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-17 11:56 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 09:46 +0200
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 09:14 -0700
Re: Reason for segmentation violation gordonb.446bm@burditt.org (Gordon Burditt) - 2015-06-18 01:56 -0500
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 09:54 +0200
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 09:08 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-22 16:53 +0200
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 16:32 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-22 18:21 +0200
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-22 16:33 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-22 18:20 +0200
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-22 13:05 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-22 19:47 +0200
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 13:52 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 06:05 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 15:39 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 08:02 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 16:12 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 10:46 +0200
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-17 16:12 +0100
Re: Reason for segmentation violation Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:28 -0700
Re: Reason for segmentation violation Ian Collins <ian-news@hotmail.com> - 2015-06-18 07:32 +1200
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 22:02 +0200
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 13:16 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 22:32 +0200
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-23 06:52 +0200
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-17 16:16 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 22:44 +0200
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-17 17:39 -0400
Re: Reason for segmentation violation Robert Wessel <robertwessel2@yahoo.com> - 2015-06-18 01:57 -0500
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 09:29 +0200
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-17 13:57 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 23:10 +0200
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-17 14:22 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 23:41 +0200
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-18 00:40 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 09:18 +0200
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 08:52 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 09:27 -0700
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 11:00 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 07:48 -0700
Re: Reason for segmentation violation Bartc <bc@freeuk.com> - 2015-06-14 16:53 +0100
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-14 10:59 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 11:45 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-14 20:01 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 12:40 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-14 21:00 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 13:13 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 13:17 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-14 16:36 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 13:43 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-14 14:50 -0400
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-12 03:21 -0700
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-10 23:07 -0700
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-19 10:39 +0200 |
| Message-ID | <mm0kd5$eff$1@dont-email.me> |
| In reply to | #63554 |
On 18/06/15 22:44, Richard Bos wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > >> On Monday, June 15, 2015 at 6:48:53 PM UTC+1, Bart wrote: >>> >>> A lot of us also get confused so whether it is England that is a >>> country, or the UK. (And if the UK is a country, how did they manage to >>> wangle four national soccer teams? And still lose...) >>> >> England is a country. The UK is a state. > > England is a country; the UK is the vestiges of its erstwhile empire; > Scotland is a subjugated province. > You will end up in killfiles with statements like that! It's quite simple - Scotland is a country, England is a country, Wales is a country, and Northern Ireland is a country. Together with some bits and pieces like the Falklands (which are not a country), they form the combined country of the United Kingdom. (There is no absolute definition of what being a country actually means.) England, Wales and Northern Ireland are governed by English law. Scotland is governed by Scottish law, which is completely different even though most of the laws are the same. Great Britain is more a geographical term, covering the main island and some - but not all - of the smaller islands around. Northern Ireland is not in Great Britain at all, but each of the other three countries (Scotland, England, and Wales) have islands that are not part of Great Britain. The British Isles is also geographic - it covers Ireland (Northern Ireland and Eire) as well. See, it's not that complicated :-) And as for football, we need to have separate national teams because you couldn't get Scots and English footballers to play under the same flag (it's okay at the club level, because they get paid absurd amounts). But for rugby, the countries sometimes play each other, and sometimes gang together as the British Lions - and still lose against the Kiwis.
[toc] | [prev] | [next] | [standalone]
| From | gwowen <gwowen@gmail.com> |
|---|---|
| Date | 2015-06-16 00:58 -0700 |
| Message-ID | <a6401bb1-ae8f-4703-a0ab-19d13205dae7@googlegroups.com> |
| In reply to | #63300 |
On Monday, June 15, 2015 at 6:48:53 PM UTC+1, Bart wrote: > I use 'England' interchangeably with 'the UK', 'Britain', and 'Great > Britain'. I think a lot of people do. That would probably annoy those > who come from Scotland, Wales or NI. Yes, yes it does. :) > A lot of us also get confused so whether it is England that is a > country, or the UK. (And if the UK is a country, how did they manage to > wangle four national soccer teams? And still lose...) If you invent a sport, you get to organise it how you see fit, at least until a corrupt little Swiss weasel comes along to run it as his personal fiefdom.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-06-18 20:40 +0000 |
| Message-ID | <55832c8a.4299390@news.xs4all.nl> |
| In reply to | #63279 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Monday, June 15, 2015 at 12:26:23 PM UTC+1, Bart wrote: > > > > You will have to take care with sorting. You don't want Australia being > > seen as having priority over Zimbabwe for example, nor the other way around. > > > Do you call our country Great Britain or the United Kingdom? The vestigial English Empire. Richard
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-18 17:06 -0400 |
| Message-ID | <558332C6.7040706@verizon.net> |
| In reply to | #63552 |
On 06/18/2015 04:40 PM, Richard Bos wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > >> On Monday, June 15, 2015 at 12:26:23 PM UTC+1, Bart wrote: >>> >>> You will have to take care with sorting. You don't want Australia being >>> seen as having priority over Zimbabwe for example, nor the other way around. >>> >> Do you call our country Great Britain or the United Kingdom? > > The vestigial English Empire. I've frequently heard of the British Empire. Haven't heard of the English Empire before. Victoria became Empress of India in 1876, and that title continued through to George VI in 1948. but as far as I can tell, no one has ever had the title "Empress" or "Emperor" of [Great] Britain (or England, for that matter). So I'm not sure I understand the legal status (if any) of the term "British Empire" (or "English Empire"). I suppose it's in the same category as the "American Empire", used to describe US overseas possessions.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-18 14:56 -0700 |
| Message-ID | <fec74a0b-4cfb-4115-b688-22f9d461e858@googlegroups.com> |
| In reply to | #63556 |
On Thursday, June 18, 2015 at 10:06:23 PM UTC+1, James Kuyper wrote: > > I've frequently heard of the British Empire. Haven't heard of the > English Empire before. > Victoria became Empress of India in 1876, and that title continued > through to George VI in 1948. but as far as I can tell, no one has ever > had the title "Empress" or "Emperor" of [Great] Britain (or England, for > that matter). So I'm not sure I understand the legal status (if any) of > the term "British Empire" (or "English Empire"). > The Russian emperor was an emperor, whilst Victoria was only a queen. So diplomatic protocol dictated that he took precedence over her, despite the fact that Britain was then a richer and more important country. Victoria disliked that, so Disraeli came up with the scheme of declaring her Empress of India.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-18 23:04 +0100 |
| Message-ID | <mlvf7a$bmp$2@dont-email.me> |
| In reply to | #63556 |
On 18/06/15 22:06, James Kuyper wrote: > On 06/18/2015 04:40 PM, Richard Bos wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >>> Do you call our country Great Britain or the United Kingdom? >> >> The vestigial English Empire. > > I've frequently heard of the British Empire. Haven't heard of the > English Empire before. We're still working on it, and admittedly we're a little behind schedule. Cut us some slack, please. -- 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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-18 18:18 -0400 |
| Message-ID | <558343AC.5080804@verizon.net> |
| In reply to | #63562 |
On 06/18/2015 06:04 PM, Richard Heathfield wrote: > On 18/06/15 22:06, James Kuyper wrote: >> On 06/18/2015 04:40 PM, Richard Bos wrote: >>> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >>>> Do you call our country Great Britain or the United Kingdom? >>> >>> The vestigial English Empire. >> >> I've frequently heard of the British Empire. Haven't heard of the >> English Empire before. > > We're still working on it, and admittedly we're a little behind > schedule. Cut us some slack, please. If it's already vestigial before it's even come into existence, that's pretty impressive schedule slippage. :-)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-19 10:26 +0200 |
| Message-ID | <mm0jm3$b5d$2@dont-email.me> |
| In reply to | #63563 |
On 19/06/15 00:18, James Kuyper wrote: > On 06/18/2015 06:04 PM, Richard Heathfield wrote: >> On 18/06/15 22:06, James Kuyper wrote: >>> On 06/18/2015 04:40 PM, Richard Bos wrote: >>>> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >>>>> Do you call our country Great Britain or the United Kingdom? >>>> >>>> The vestigial English Empire. >>> >>> I've frequently heard of the British Empire. Haven't heard of the >>> English Empire before. >> >> We're still working on it, and admittedly we're a little behind >> schedule. Cut us some slack, please. > > If it's already vestigial before it's even come into existence, that's > pretty impressive schedule slippage. :-) > But as usual, Americans beat us with something bigger, more expensive, and even more behind schedule: <http://www.f-16.net/forum/viewtopic.php?f=58&t=27011> :-)
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-06-19 08:57 -0700 |
| Message-ID | <addb5c18-5b10-4065-81a1-7ed7482682e1@googlegroups.com> |
| In reply to | #63552 |
On Thursday, June 18, 2015 at 1:40:23 PM UTC-7, Richard Bos wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > > On Monday, June 15, 2015 at 12:26:23 PM UTC+1, Bart wrote: > > > > > > You will have to take care with sorting. You don't want Australia being > > > seen as having priority over Zimbabwe for example, nor the other way around. > > > > > Do you call our country Great Britain or the United Kingdom? > > The vestigial English Empire. > > Richard Acronym EE or VEE ?
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-06-15 08:54 -0400 |
| Message-ID | <VVzfx.64054$sE4.23639@fx01.iad> |
| In reply to | #63268 |
On 6/15/15 4:19 AM, Malcolm McLean wrote: > On Monday, June 15, 2015 at 1:35:40 AM UTC+1, Richard Damon wrote: >> >> You seem to be wanting to tie your hands on the requirements for some >> nebulous "Neutrality" issue. >> > It's a political rather than engineering consideration. > Some Indians opposed UTF-8 because Hindi characters were given the > "minor language" slots with 4 byte codes, which implicitly declares > that Hindi isn't such an important language. > Ok, the question is do these "customers" (not sure your exact relationship to them) have text editors to prepare the XML in UCS-4? and do they stick to the principles enough to use that and make their files bigger then they could otherwise be? (A UTF-8 XML file will ALWAYS be smaller, as the XML syntax characters take just 1 byte in it, instead of 4, and nothing gets bigger). It turns out that it isn't that hard to auto-detect which format (UTF-8, UTF-16, UCS-4, including all byte orders) a file is in by looking at the first 4 bytes of the file, so supporting all versions isn't hard. As I said before, Internally I don't have as much of a preference, (and neither should your 'customers') UCS-4 has advantages in some application (but I don't think it applies here), and UTF-8 can have some advantages in processing speed (as you are processing less bytes of data). What I think would be more important is to get the "Internationalization" subtleties right (things like collation ordering, and proper handling of combining characters), which isn't as dependent on encoding, but dealing with some of the built in complexity of Unicode in any encoding.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-15 06:24 -0700 |
| Message-ID | <468508e1-c25e-4048-b8b3-62033507d619@googlegroups.com> |
| In reply to | #63277 |
On Monday, June 15, 2015 at 2:54:21 PM UTC+2, Richard Damon wrote: > On 6/15/15 4:19 AM, Malcolm McLean wrote: > > On Monday, June 15, 2015 at 1:35:40 AM UTC+1, Richard Damon wrote: > >> > >> You seem to be wanting to tie your hands on the requirements for some > >> nebulous "Neutrality" issue. > >> > > It's a political rather than engineering consideration. > > Some Indians opposed UTF-8 because Hindi characters were given the > > "minor language" slots with 4 byte codes, which implicitly declares > > that Hindi isn't such an important language. > > > > Ok, the question is do these "customers" (not sure your exact > relationship to them) have text editors to prepare the XML in UCS-4? and > do they stick to the principles enough to use that and make their files > bigger then they could otherwise be? (A UTF-8 XML file will ALWAYS be > smaller, as the XML syntax characters take just 1 byte in it, instead of > 4, and nothing gets bigger). > > It turns out that it isn't that hard to auto-detect which format (UTF-8, > UTF-16, UCS-4, including all byte orders) a file is in by looking at the > first 4 bytes of the file, so supporting all versions isn't hard. > > As I said before, Internally I don't have as much of a preference, (and > neither should your 'customers') UCS-4 has advantages in some > application (but I don't think it applies here), and UTF-8 can have some > advantages in processing speed (as you are processing less bytes of data). > > What I think would be more important is to get the > "Internationalization" subtleties right (things like collation ordering, > and proper handling of combining characters), which isn't as dependent > on encoding, but dealing with some of the built in complexity of Unicode > in any encoding. Ah, that's interesting, about combining characters and so on. My guess is that there should be quite a bit of information on these, and probably some libraries or data collections as well. There are no customers for this project. This is something I do on my own time, because I'm interested in learning more about C and Assembler. I also like standards and diversity, and would like to make a contribution towards that. Because nobody is paying for this project, I'm able to do whatever I want, although the goal is ultimately a fast and secure XML parser and writer. The first use-case I thought about, was different applications that read and write XML data. If that's a webserver or a text editor doesn't matter. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-15 14:32 +0100 |
| Message-ID | <87ioap14hr.fsf@bsb.me.uk> |
| In reply to | #63268 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, June 15, 2015 at 1:35:40 AM UTC+1, Richard Damon wrote: >> >> You seem to be wanting to tie your hands on the requirements for some >> nebulous "Neutrality" issue. >> > It's a political rather than engineering consideration. > Some Indians opposed UTF-8 because Hindi characters were given the > "minor language" slots with 4 byte codes, No, that was the Amalgamated Union of Scribes and Scriveners who sent dozens of tablets to the Unicode committee objecting to having 4-byte UTF-8 encodings forced upon them. Didn't do them any good -- probably because no one on the committee could read Linear B. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-15 05:43 -0700 |
| Message-ID | <9e1d9436-6dc4-4e79-aa7d-fd5c8714e6a1@googlegroups.com> |
| In reply to | #63264 |
On Monday, June 15, 2015 at 2:35:40 AM UTC+2, Richard Damon wrote: > On 6/14/15 5:16 PM, Morten W. Petersen wrote: > > On Sunday, June 14, 2015 at 10:43:49 PM UTC+2, Richard Damon wrote: > >> On 6/14/15 2:51 PM, Morten W. Petersen wrote: > > [...] [...] > > I'm going to run with the 32-bit storage and most likely 32- or > > 24-bit internal storage format for now, to keep things simple. I > > might also look at storing characters as 21 bits later, and the right > > way to do that is using a struct, right? > > A struct won't help you make the items not by byte aligned. The only > practical way to do that is to use a "bit array" with access functions > that extract a given bit string out of an array of bytes with masking > and shifting. (Your 24 bit format will basically need the same thing, > only you don't need the masking, and all the shifts are multiple of 8. OK. > > The 4 or 3 byte internal storage will be based on global defines, so > > it will be possible to compare the two approaches precisely. > > > For internal storage, if you do need to use UCS-4, I would just use 4 > bytes, as the overhead for building the native type from 24 bits is > going to be costly. Unless you data file is so big that you risk running > out of memory, the savings of 3 byte encoding are going to be lost. If > you really are going to be memory limited, you probably want to look at > reworking the algorithm to not need all the data in RAM at once. (But > see also my discussing that doing the processing in UTF-8) Hm, OK. Well, in general it sounds like using 3 bytes per character will save RAM, but it will make different operations slower. Is it possible to set some "global" value for a function call (in this case the character width), or does this have to be passed along in each function call? If it has to be passed along in each function call, I guess one can pass the character width as an environment variable to a define and then compile two libraries for example? > > OK. Hm, well it does give a significant saving in required memory, > > but maybe other ways of storing the data like dictionaries, word > > counters and so on is smarter then. Are there any classic ways of > > reducing the size of many different strings or "tokens" while still > > being fast for example for searching? > > What method can be done to compress the storage of data depends a LOT on > what you are doing with it. Again, UTF-8 will typically give you T least > as much of a savings unless you data has a lot of esoteric characters. Yup. > > There isn't some way of expanding 24-bit values to 32-bit values > > without a lot of overhead using something like a bitwise operator and > > remembering the position one is at? > > > > The simple way would be something like: > > uint8_t c24[some size]; > /* Fill c24, each character uses 3 entries */ > > uint32_t c32 = c24[i] | (c24[i+1] << 8) | (c24[i+2] << 16); > > Note that this will take at least 3 instructions to fetch the data on an > optimal machine, and could easily take 7 instructions (3 load, 2 shifts, > 2 ors) on a typical machine (compared to a single instruction for a 32 > bit load). OK, thanks for that snippet, I'll test it and variants of it out to understand how that works exactly. [...] > Again WHY is being neutral important for files. > > Also, is the a big reason you can't just work in UTF-8 internally. UCS-4 > has it place, and some applications do benefit with using it internally. > These would be applications that need to be able to randomly access code > points in a buffer (not from memorized location), or know how many code > points are in a string. From what you have described so far, I don't see > any of these applying. > > You seem to be wanting to tie your hands on the requirements for some > nebulous "Neutrality" issue. Well, see the thread on why I'm choosing neutrality, I think it's fairly well explained there. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-14 23:28 +0100 |
| Message-ID | <87zj412ac4.fsf@bsb.me.uk> |
| In reply to | #63247 |
"Morten W. Petersen" <morphex@gmail.com> writes: > On Sunday, June 14, 2015 at 5:59:17 PM UTC+2, Ben Bacarisse wrote: <snip> >> On a side issue, the code seemed to be reading a 32-bit encoding for the >> data. That's not wrong just rather odd -- it's a rare encoding and it >> usually needs "endianness" to be taking into account. > > Well, I thought an XML library that bases itself on the 32-bit > encoding which doesn't discriminate against any characters, or rather > groups of characters, is a good idea. Right, but that's not my point. Ideally, you should accept all of the common transfer encodings for Unicode rather than just one rather unusual one. But as I say, there's nothing wrong with accepting only one. After all, there are utilities to convert between encodings, so you need only accept one. In confirming what encoding you expect to see, I came across quite a lot of things that need attention. First, storing characters in longs could be very wasteful. On my system, long is 8 bytes not 4. Also, you can't assume that putting bytes into a union will give you the long value you expect. That depends on the system architecture. To get a predictable value you need to construct it arithmetically using shifts or multiplies. In one place you allocate *attribute = malloc(...) and later free(attribute). You allocate 1024 bytes for a buffer, read up to 1024 bytes into it and then set buffer[read+1] = 0. Some of the logic just looks wrong to me. For example, I don't think compare_unicode_character_array does what it should, certainly considering how you use it to check for white space. I think you need to code in smaller chunks and with more tests along the way. You have a lot of unneeded casts and sizeof expressions. For example, the return from malloc does not need a cast (and it's often considered a bad idea to use one) whilst sizeof (char) is guaranteed to be 1. There are many places where a "const" would help to tell the reader that a function does not modify a pointer target (for example, in compare_unicode_character_array). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-14 16:31 -0700 |
| Message-ID | <e8a4c839-1754-4903-a353-ec6f79c445d0@googlegroups.com> |
| In reply to | #63261 |
On Monday, June 15, 2015 at 12:29:13 AM UTC+2, Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: > > > On Sunday, June 14, 2015 at 5:59:17 PM UTC+2, Ben Bacarisse wrote: > <snip> > >> On a side issue, the code seemed to be reading a 32-bit encoding for the > >> data. That's not wrong just rather odd -- it's a rare encoding and it > >> usually needs "endianness" to be taking into account. > > > > Well, I thought an XML library that bases itself on the 32-bit > > encoding which doesn't discriminate against any characters, or rather > > groups of characters, is a good idea. > > Right, but that's not my point. Ideally, you should accept all of the > common transfer encodings for Unicode rather than just one rather > unusual one. But as I say, there's nothing wrong with accepting only > one. After all, there are utilities to convert between encodings, so > you need only accept one. Yep. And it shouldn't be too hard to create some functions that will convert between formats. But 32-bit Unicode is an easy place to start. > In confirming what encoding you expect to see, I came across quite a lot > of things that need attention. First, storing characters in longs could > be very wasteful. On my system, long is 8 bytes not 4. Also, you can't > assume that putting bytes into a union will give you the long value you > expect. That depends on the system architecture. To get a predictable > value you need to construct it arithmetically using shifts or > multiplies. Yes, OK. So I need to use this then? #include <stdint.h> int32_t my_32bit_int; > In one place you allocate *attribute = malloc(...) and later > free(attribute). Which line numbers are you refering to here? https://github.com/morphex/smash_xml/blob/2e6f8288f511d03efad26fc22b8972d73571e073/decode_xml.c I'm not that familiar with the semantics of pointers so please do point it out. But my understanding of the attribute* variables is that I'm passing a pointer to a pointer, and that modifiable pointer is set to the memory that is allocated and the main() code makes use of that. It used to sigsegv but now it works as it should. > You allocate 1024 bytes for a buffer, read up to 1024 bytes into it and > then set buffer[read+1] = 0. Ah I think you're looking at old code, see the link above. But I guess buffer[read] = 0 is also invalid, because it is element number 1025. Right? > Some of the logic just looks wrong to me. For example, I don't think > compare_unicode_character_array does what it should, certainly > considering how you use it to check for white space. I think you need > to code in smaller chunks and with more tests along the way. Well, it has been altered a bit now. I thought it could be necessary with a function that compares to an array of characters, but a lot of these cases have only a few possible characters that match and a simple if x == xx || y == yy or even a macro would be better and faster. > You have a lot of unneeded casts and sizeof expressions. For example, > the return from malloc does not need a cast (and it's often considered a > bad idea to use one) whilst sizeof (char) is guaranteed to be 1. Aha, didn't know that about sizeof char being guaranteed. > There are many places where a "const" would help to tell the reader that > a function does not modify a pointer target (for example, in > compare_unicode_character_array). Yep, the buffer that has data from the file won't be modified by most functions, but it will have to be filled with new data on bigger XML files. Is there some good standard way of dealing with reading of files (how big should the buffer be for example) and passing them on to code that handles that data? Very long term it would be interesting to optimize the code to make use of more CPU cores using for example multiple processes and shared memory. I've looked a bit on threading and running things over multiple cores and it looks like the smartest thing to do is run multiple processes as all cores or CPUs on a system can be utilized at the same time. And the Apache APR looks like a good candidate for this. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-15 01:27 +0100 |
| Message-ID | <87oakh24u3.fsf@bsb.me.uk> |
| In reply to | #63262 |
"Morten W. Petersen" <morphex@gmail.com> writes: > On Monday, June 15, 2015 at 12:29:13 AM UTC+2, Ben Bacarisse wrote: >> "Morten W. Petersen" <morphex@gmail.com> writes: >> >> > On Sunday, June 14, 2015 at 5:59:17 PM UTC+2, Ben Bacarisse wrote: >> <snip> >> >> On a side issue, the code seemed to be reading a 32-bit encoding for the >> >> data. That's not wrong just rather odd -- it's a rare encoding and it >> >> usually needs "endianness" to be taking into account. >> > >> > Well, I thought an XML library that bases itself on the 32-bit >> > encoding which doesn't discriminate against any characters, or rather >> > groups of characters, is a good idea. >> >> Right, but that's not my point. Ideally, you should accept all of the >> common transfer encodings for Unicode rather than just one rather >> unusual one. But as I say, there's nothing wrong with accepting only >> one. After all, there are utilities to convert between encodings, so >> you need only accept one. > > Yep. And it shouldn't be too hard to create some functions that will > convert between formats. But 32-bit Unicode is an easy place to > start. > >> In confirming what encoding you expect to see, I came across quite a lot >> of things that need attention. First, storing characters in longs could >> be very wasteful. On my system, long is 8 bytes not 4. Also, you can't >> assume that putting bytes into a union will give you the long value you >> expect. That depends on the system architecture. To get a predictable >> value you need to construct it arithmetically using shifts or >> multiplies. > > Yes, OK. So I need to use this then? > > #include <stdint.h> > > int32_t my_32bit_int; int_least32_t is better, but you want to use C90. There are, however, public-domain versions of a stdint-like header you can use. Either that or you do some pre-processor juggling yourself find the right type. But that's the first step. Once you have an efficient target type you need to turn byte sequences into the right values. The union idea is non-portable -- you need to uses shifts instead (and unsigned types). BTW, your desire to use C90 is not consistent with using inline all over the place. >> In one place you allocate *attribute = malloc(...) and later >> free(attribute). > > Which line numbers are you refering to here? Just search for free(attribute) in the link you originally posted. > https://github.com/morphex/smash_xml/blob/2e6f8288f511d03efad26fc22b8972d73571e073/decode_xml.c You've changed the variable name in this version so search for free(attribute_storage). > I'm not that familiar with the semantics of pointers so please do point it out. > > But my understanding of the attribute* variables is that I'm passing a > pointer to a pointer, and that modifiable pointer is set to the memory > that is allocated and the main() code makes use of that. It used to > sigsegv but now it works as it should. Ah, unfortunately incorrect code does sometimes not raise an exception. Do you have access to a memory checking system like valgrind? >> You allocate 1024 bytes for a buffer, read up to 1024 bytes into it and >> then set buffer[read+1] = 0. > > Ah I think you're looking at old code, see the link above. But I guess > buffer[read] = 0 is also invalid, because it is element number 1025. > Right? Yes, that a problem too. But it's unlikely that a single null byte is what you need anyway. Many code points have a zero byte and they must not be taken to signal the end of anything. >> Some of the logic just looks wrong to me. For example, I don't think >> compare_unicode_character_array does what it should, certainly >> considering how you use it to check for white space. I think you need >> to code in smaller chunks and with more tests along the way. > > Well, it has been altered a bit now. No, the logic looks the same to me, and valgrind reports the same error as before. I really think you should try creating smaller, tested, units. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-15 05:34 -0700 |
| Message-ID | <33dd7bd9-6510-4924-8d2c-4f2079de4c7b@googlegroups.com> |
| In reply to | #63263 |
On Monday, June 15, 2015 at 2:27:56 AM UTC+2, Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: [...] > > Yes, OK. So I need to use this then? > > > > #include <stdint.h> > > > > int32_t my_32bit_int; > > int_least32_t is better, but you want to use C90. There are, however, > public-domain versions of a stdint-like header you can use. Either that > or you do some pre-processor juggling yourself find the right type. > > But that's the first step. Once you have an efficient target type you > need to turn byte sequences into the right values. The union idea is > non-portable -- you need to uses shifts instead (and unsigned types). > > BTW, your desire to use C90 is not consistent with using inline all over > the place. Well, inline makes it easy to break up the code, and with define conditionals the worst that can happen is that systems that don't support inlining will have the function overhead. If macros should come later I don't know, but I'm also thinking profiling will be simpler with the code broken up in many small (inlined) functions. Yes, I saw an example of shifting in this thread that I'll have a look at. > No, the logic looks the same to me, and valgrind reports the same error > as before. > > I really think you should try creating smaller, tested, units. Yes, unit-testing is a good idea, same for Valgrind. :) -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-15 15:00 +0100 |
| Message-ID | <87a8w11371.fsf@bsb.me.uk> |
| In reply to | #63275 |
"Morten W. Petersen" <morphex@gmail.com> writes: <snip> > Yes, I saw an example of shifting in this thread that I'll have a look > at. Just a heads-up: the posted example was not portable. I don't know how much you really care about portability. It's easy to say that you want your code to run on as many systems as possible, but to achieve that you need to know every corner of the language. Even doing this: unsigned char bytes[N]; ... bytes[1] << 8 ... with 8-bit chars is not portable because bytes[1] will promote to int. If it's a 16-bit int, the shift will be undefined when the top bit of the byte is set. bytes[2] << 16 is worse or course, though both are safe on a system with 32-bit ints. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-15 20:37 -0700 |
| Message-ID | <39fcc3a7-a8f5-4c61-bb65-de028cf50290@googlegroups.com> |
| In reply to | #63285 |
On Monday, June 15, 2015 at 4:01:00 PM UTC+2, Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: > <snip> > > Yes, I saw an example of shifting in this thread that I'll have a look > > at. > > Just a heads-up: the posted example was not portable. I don't know how > much you really care about portability. It's easy to say that you want > your code to run on as many systems as possible, but to achieve that you > need to know every corner of the language. OK. Well I don't know what constitutes being portable, but for example running on every architecture that Debian GNU/Linux, *BSD, Windows and Mac OS X runs on for example could be a reasonable goal. But for now I'm happy with it running on my 64-bit machine in both Linux and Windows. > Even doing this: > > unsigned char bytes[N]; > ... bytes[1] << 8 ... > > with 8-bit chars is not portable because bytes[1] will promote to int. > If it's a 16-bit int, the shift will be undefined when the top bit of > the byte is set. bytes[2] << 16 is worse or course, though both are > safe on a system with 32-bit ints. Hm, OK. When you're saying the top bit you mean the sign, whether or not it is a positive number? Do you have any alternatives? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-16 09:58 +0100 |
| Message-ID | <87d20wyqpj.fsf@bsb.me.uk> |
| In reply to | #63327 |
"Morten W. Petersen" <morphex@gmail.com> writes: > On Monday, June 15, 2015 at 4:01:00 PM UTC+2, Ben Bacarisse wrote: >> "Morten W. Petersen" <morphex@gmail.com> writes: >> <snip> >> > Yes, I saw an example of shifting in this thread that I'll have a look >> > at. >> >> Just a heads-up: the posted example was not portable. I don't know how >> much you really care about portability. It's easy to say that you want >> your code to run on as many systems as possible, but to achieve that you >> need to know every corner of the language. > > OK. Well I don't know what constitutes being portable, but for > example running on every architecture that Debian GNU/Linux, *BSD, > Windows and Mac OS X runs on for example could be a reasonable goal. That's going to make life much simpler. (Presuming you mean modern Windows when you say Windows.) > But for now I'm happy with it running on my 64-bit machine in both > Linux and Windows. > >> Even doing this: >> >> unsigned char bytes[N]; >> ... bytes[1] << 8 ... >> >> with 8-bit chars is not portable because bytes[1] will promote to int. >> If it's a 16-bit int, the shift will be undefined when the top bit of >> the byte is set. bytes[2] << 16 is worse or course, though both are >> safe on a system with 32-bit ints. > > Hm, OK. When you're saying the top bit you mean the sign, whether or > not it is a positive number? Not quite. bytes[1] is unsigned so the deliberately vague term "top bit of the byte" does not indicate the sign, just the most significant bit of the value. Say bytes[1] is 128. This unsigned char value is promoted to int and it is this signed integer value of 128 that gets shifted. On a 16-bit machine 128 x 2^8 can't be represented as an int, and the C language standard says that the result is undefined. > Do you have any alternatives? You just need to prevent the promotion: (unsigned)bytes[1] << 8 But all of your targets have (at least) 32-bit integers, and you never need to shift more than 16 bits so (bytes[0] << 16) + (bytes[1] << 8) + bytes[2] is portable to your targets. The use of a union to get the numeric value of three or four consecutive bytes is not portable to all of your targets, and some will have a 64-bit long, so there is the issue of wasted space using long. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web