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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-18 14:57 +0200 |
| Message-ID | <mluf7o$90i$1@speranza.aioe.org> |
| In reply to | #63409 |
On 17.06.2015 16:34, Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: > >> On Wednesday, June 17, 2015 at 3:02:49 PM UTC+2, Ben Bacarisse wrote: [...] >>> That's not the right question. The size of a type is not 100% >>> guaranteed to tell you the range of values it can represent, and "bytes" >>> in C are not always 8 bits (though they are on all the systems you care >>> about). It's much better to ask for exactly what you want: >>> >>> #include <limits.h> >>> >>> /* >>> * Find the smallest standard unsigned type that can hold a Unicode code >>> * point. >>> */ >>> >>> #if UCHAR_MAX >= 0x1fffff >>> typedef unsigned char unicode_cp; >>> #elif USHRT_MAX >= 0x1fffff >>> typedef unsigned short unicode_cp; >>> #elif UINT_MAX >= 0x1fffff >>> typedef unsigned int unicode_cp; >>> #else >>> typedef unsigned long unicode_cp; >>> #endif >> >> I found somethiing like this while googling and it works on Cygwin 32 and 64: >> >> #if UINT_MAX != 0xFFFFFFFF >> # error Only systems with 32-bit wide integers (int) are supported >> #endif >> >> Which is kind of a showstopper, but it does what I want right now so >> that there isn't a false sense of security for those who use the >> compiled code. > > Not sure what you be this being a showstopper. The #error "stops the > show" but you don't need to copy that. There is always a type available > that can store the values you want. I've included some dynamic typedefs now, I like these a lot as they make changing the type of commonly used variables easy to do as well as document. The code is here BTW, if anyone wants to have a look: https://github.com/morphex/smash_xml -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-18 15:35 +0100 |
| Message-ID | <87fv5pqe35.fsf@bsb.me.uk> |
| In reply to | #63504 |
"Morten W. Petersen" <morphex@gmail.com> writes:
> On 17.06.2015 16:34, Ben Bacarisse wrote:
>> "Morten W. Petersen" <morphex@gmail.com> writes:
>>
>>> On Wednesday, June 17, 2015 at 3:02:49 PM UTC+2, Ben Bacarisse wrote:
> [...]
>>>> That's not the right question. The size of a type is not 100%
>>>> guaranteed to tell you the range of values it can represent, and "bytes"
>>>> in C are not always 8 bits (though they are on all the systems you care
>>>> about). It's much better to ask for exactly what you want:
>>>>
>>>> #include <limits.h>
>>>>
>>>> /*
>>>> * Find the smallest standard unsigned type that can hold a Unicode code
>>>> * point.
>>>> */
>>>>
>>>> #if UCHAR_MAX >= 0x1fffff
>>>> typedef unsigned char unicode_cp;
>>>> #elif USHRT_MAX >= 0x1fffff
>>>> typedef unsigned short unicode_cp;
>>>> #elif UINT_MAX >= 0x1fffff
>>>> typedef unsigned int unicode_cp;
>>>> #else
>>>> typedef unsigned long unicode_cp;
>>>> #endif
>>>
>>> I found somethiing like this while googling and it works on Cygwin 32 and 64:
>>>
>>> #if UINT_MAX != 0xFFFFFFFF
>>> # error Only systems with 32-bit wide integers (int) are supported
>>> #endif
>>>
>>> Which is kind of a showstopper, but it does what I want right now so
>>> that there isn't a false sense of security for those who use the
>>> compiled code.
>>
>> Not sure what you be this being a showstopper. The #error "stops the
>> show" but you don't need to copy that. There is always a type available
>> that can store the values you want.
>
> I've included some dynamic typedefs now, I like these a lot as they make
> changing the type of commonly used variables easy to do as well as
> document.
>
> The code is here BTW, if anyone wants to have a look:
>
> https://github.com/morphex/smash_xml
Some random remarks.
__inline__ is a reserved identifier.
You seem to print errors using printf, but it's usually better to use
the stderr stream.
There's a lot of:
#ifdef DEBUG
printf(....);
#endif
lines. I'd write a debug printing macro:
#ifdef DEBUG
#define DPRINT(x) printf x
#else
#define DPRINT(x)
#endif
and the you write lines like
DPRINT(("Address: %i\n", &attribute[index]));
Note the double (())s. In modern C you can make this a little neater
using a macro with a variable number of arguments.
Comments like this
(character >= 0x00C0 && character <= 0x00D6) || /* [#xC0-#xD6] */
(character >= 0x00D8 && character <= 0x00F6) || /* [#xD8-#xF6] */
(character >= 0x00F8 && character <= 0x02FF) || /* [#xF8-#x2FF] */
(character >= 0x0370 && character <= 0x037D) || /* [x370-#x37D] */
are unhelpful -- you are telling me pretty much th only thing I already
know!
There's a lot of
offset+(index*UNICODE_STORAGE_BYTES)
when indexing into a character buffer. I can't see any way in which it
makes sense for UNICODE_STORAGE_BYTES to be anything other than 1. What
future cases are you covering here?
The whole idea of keeping the input as a char array and repeatedly
calling a function to turn four bytes into a code point looks a bit odd
to me. Why not read the data into an array of type unicode_char once
and for all?
I'm not sure I understand the reason you write hex numbers all over the
place. None of the systems you are targeting use anything by ASCII as
the source character set, so '<' means 0x3c on all the systems you care
about, and it's so very much easier to read.
I think you should read a bit more about XML! I just went to check a
couple of things and found this:
"All XML processors *must* be able to read entities in both the UTF-8
and UTF-16 encodings"
The encoding you are using is optional but should be signalled with
encoding="ISO-10646-UCS-4".
>
> -Morten
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-18 15:44 +0100 |
| Message-ID | <87a8vxqdnr.fsf@bsb.me.uk> |
| In reply to | #63516 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: <too many quoted lines> Sorry, I forgot to trim before sending. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-18 08:18 -0700 |
| Message-ID | <ca9bd1db-4b25-4795-8449-094e329342ec@googlegroups.com> |
| In reply to | #63516 |
On Thursday, June 18, 2015 at 3:35:36 PM UTC+1, Ben Bacarisse wrote: > > I think you should read a bit more about XML! I just went to check a > couple of things and found this: > > "All XML processors *must* be able to read entities in both the UTF-8 > and UTF-16 encodings" > > The encoding you are using is optional but should be signalled with > encoding="ISO-10646-UCS-4". > It's rather a poor formal specification. The first weakness is that it allows recursive definitions which are a nuisance to implement and make it easy to create small malicious input files. The second one is that a human producing an xml file just wants the naked tags. He can't be expected to remember an encoding specification like the one you gave above. So in reality the decoder should be prepared to accept such input, which in theory is disallowed (to prevent an HTML-like situation where malformed files are so common decoders have to have hundreds of little hacks to display them). The third one is that UTF-8 is rapidly emerging as the unicode format of choice, anything else is increasingly being seen as a bit of a nuisance, certainly for data transfer and backing store, though 16 bit wchar apis still linger on in GUI systems.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-18 16:42 +0100 |
| Message-ID | <874mm5qazr.fsf@bsb.me.uk> |
| In reply to | #63524 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Thursday, June 18, 2015 at 3:35:36 PM UTC+1, Ben Bacarisse wrote: >> >> I think you should read a bit more about XML! I just went to check a >> couple of things and found this: >> >> "All XML processors *must* be able to read entities in both the UTF-8 >> and UTF-16 encodings" >> >> The encoding you are using is optional but should be signalled with >> encoding="ISO-10646-UCS-4". >> > It's rather a poor formal specification. The first weakness is that it allows > recursive definitions which are a nuisance to implement and make it > easy to create small malicious input files. Can you give an example? > The second one is that a human > producing an xml file just wants the naked tags. He can't be expected > to remember an encoding specification like the one you gave above. That may be why it's optional for the only encodings that must be supported. That does not seem like a problem to me. > So in reality the decoder should be prepared to accept such input, which > in theory is disallowed (to prevent an HTML-like situation where malformed > files are so common decoders have to have hundreds of little hacks to > display them). The HTML situation is a mess. It seems wise to try to avoid it. I'd say that the problem is with any specification for a new file format that was is ambiguous as the one you seem to be suggesting. > The third one is that UTF-8 is rapidly emerging as the unicode > format of choice, anything else is increasingly being seen as a bit of a > nuisance, certainly for data transfer and backing store, though 16 bit wchar > apis still linger on in GUI systems. How is this a problem in the XML specification? Do you mean it's a mistake to require UTF-16 support? Is the Windows world ready for Unicode tools that are not expected to support UTF-16? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-17 08:19 -0700 |
| Message-ID | <lnr3pal5wa.fsf@nuthaus.mib.org> |
| In reply to | #63403 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> "Morten W. Petersen" <morphex@gmail.com> writes:
> <snip>
>> So an unsigned int seems to be the right way to go. Is it possible at
>> compile time to see the size of shorts, ints and long to choose the
>> smallest type with at least 4 bytes?
>
> That's not the right question. The size of a type is not 100%
> guaranteed to tell you the range of values it can represent, and "bytes"
> in C are not always 8 bits (though they are on all the systems you care
> about). It's much better to ask for exactly what you want:
>
> #include <limits.h>
>
> /*
> * Find the smallest standard unsigned type that can hold a Unicode code
> * point.
> */
>
> #if UCHAR_MAX >= 0x1fffff
> typedef unsigned char unicode_cp;
> #elif USHRT_MAX >= 0x1fffff
> typedef unsigned short unicode_cp;
> #elif UINT_MAX >= 0x1fffff
> typedef unsigned int unicode_cp;
> #else
> typedef unsigned long unicode_cp;
> #endif
>
> <snip>
You might consider dropping the types narrower than unsigned int:
#if UINT_MAX >= 0x1fffff
typedef unsigned int unicode_cp;
#else
typedef unsigned long unicode_cp;
#endif
Unsigned types narrower than unsigned int promote to *signed* int in
many contexts; that can lead to unpleasant surprises. Dropping the
narrower types is unlikely to matter on most systems (though I have used
a system, the Cray T3E, where the change would make unicode_cp 64 bits
rather than 32.)
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-17 16:35 +0100 |
| Message-ID | <87a8vytkkb.fsf@bsb.me.uk> |
| In reply to | #63419 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> "Morten W. Petersen" <morphex@gmail.com> writes: >> <snip> >>> So an unsigned int seems to be the right way to go. Is it possible at >>> compile time to see the size of shorts, ints and long to choose the >>> smallest type with at least 4 bytes? >> >> That's not the right question. The size of a type is not 100% >> guaranteed to tell you the range of values it can represent, and "bytes" >> in C are not always 8 bits (though they are on all the systems you care >> about). It's much better to ask for exactly what you want: >> >> #include <limits.h> >> >> /* >> * Find the smallest standard unsigned type that can hold a Unicode code >> * point. >> */ >> >> #if UCHAR_MAX >= 0x1fffff >> typedef unsigned char unicode_cp; >> #elif USHRT_MAX >= 0x1fffff >> typedef unsigned short unicode_cp; >> #elif UINT_MAX >= 0x1fffff >> typedef unsigned int unicode_cp; >> #else >> typedef unsigned long unicode_cp; >> #endif >> >> <snip> > > You might consider dropping the types narrower than unsigned int: > > #if UINT_MAX >= 0x1fffff > typedef unsigned int unicode_cp; > #else > typedef unsigned long unicode_cp; > #endif > > Unsigned types narrower than unsigned int promote to *signed* int in > many contexts; that can lead to unpleasant surprises. That's a good point and one I had qualms about since I'd explained that very problem to the OP in and earlier posting. > Dropping the > narrower types is unlikely to matter on most systems (though I have used > a system, the Cray T3E, where the change would make unicode_cp 64 bits > rather than 32.) Ah, that's interesting. I was not sure that it had 32-bit shorts. Did it use the same trick of adding high bits to the address to select half words that you've described for bytes? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-17 08:49 -0700 |
| Message-ID | <32a549fc-8ae4-46f8-b81a-9bc311334b8b@googlegroups.com> |
| In reply to | #63421 |
On Wednesday, June 17, 2015 at 5:35:10 PM UTC+2, Ben Bacarisse wrote: > Keith Thompson <kst-u@mib.org> writes: [...] > > #if UINT_MAX >= 0x1fffff > > typedef unsigned int unicode_cp; > > #else > > typedef unsigned long unicode_cp; > > #endif > > > > Unsigned types narrower than unsigned int promote to *signed* int in > > many contexts; that can lead to unpleasant surprises. > > That's a good point and one I had qualms about since I'd explained that > very problem to the OP in and earlier posting. Ah yes, that's good to know. And then for example integer types on 16-bit systems don't get promoted to long? I guess one can't test for everything in a couple of lines, and I'll be updating the test suite to do different tests. I guess anyone who compiles source should also run any test suites so I added a note about that in the readme. -Morten
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-17 11:56 -0400 |
| Message-ID | <558198B5.9090702@verizon.net> |
| In reply to | #63422 |
On 06/17/2015 11:49 AM, Morten W. Petersen wrote: > On Wednesday, June 17, 2015 at 5:35:10 PM UTC+2, Ben Bacarisse wrote: >> Keith Thompson <kst-u@mib.org> writes: > [...] >>> #if UINT_MAX >= 0x1fffff >>> typedef unsigned int unicode_cp; >>> #else >>> typedef unsigned long unicode_cp; >>> #endif >>> >>> Unsigned types narrower than unsigned int promote to *signed* int in >>> many contexts; that can lead to unpleasant surprises. >> >> That's a good point and one I had qualms about since I'd explained that >> very problem to the OP in and earlier posting. > > Ah yes, that's good to know. And then for example integer types on 16-bit systems don't get promoted to long? The integer promotions are precisely defined by section 6.3.1.1p2 of the C standard: > The following may be used in an expression wherever an int or unsigned int may > be used: > — An object or expression with an integer type (other than int or unsigned int) > whose integer conversion rank is less than or equal to the rank of int and > unsigned int. > — A bit-field of type _Bool, int, signed int, or unsigned int. > If an int can represent all values of the original type (as restricted by the width, for a > bit-field), the value is converted to an int; otherwise, it is converted to an unsigned > int. These are called the integer promotions.58) All other types are unchanged by the > integer promotions. Thus, the integer promotions always result in either 'int' or an 'unsigned int'; nothing ever gets promoted to long (though expressions that are already of type 'long' remain 'long' when the integer promotions apply).
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-18 09:46 +0200 |
| Message-ID | <mltt0m$q1k$1@speranza.aioe.org> |
| In reply to | #63424 |
On 17.06.2015 17:56, James Kuyper wrote: > The integer promotions are precisely defined by section 6.3.1.1p2 of the > C standard: > >> The following may be used in an expression wherever an int or unsigned int may >> be used: >> — An object or expression with an integer type (other than int or unsigned int) >> whose integer conversion rank is less than or equal to the rank of int and >> unsigned int. >> — A bit-field of type _Bool, int, signed int, or unsigned int. >> If an int can represent all values of the original type (as restricted by the width, for a >> bit-field), the value is converted to an int; otherwise, it is converted to an unsigned >> int. These are called the integer promotions.58) All other types are unchanged by the >> integer promotions. > > Thus, the integer promotions always result in either 'int' or an > 'unsigned int'; nothing ever gets promoted to long (though expressions > that are already of type 'long' remain 'long' when the integer > promotions apply). Aha, OK. :) -Morten
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-17 09:14 -0700 |
| Message-ID | <lneglal3ca.fsf@nuthaus.mib.org> |
| In reply to | #63422 |
"Morten W. Petersen" <morphex@gmail.com> writes:
> On Wednesday, June 17, 2015 at 5:35:10 PM UTC+2, Ben Bacarisse wrote:
>> Keith Thompson <kst-u@mib.org> writes:
> [...]
>> > #if UINT_MAX >= 0x1fffff
>> > typedef unsigned int unicode_cp;
>> > #else
>> > typedef unsigned long unicode_cp;
>> > #endif
>> >
>> > Unsigned types narrower than unsigned int promote to *signed* int in
>> > many contexts; that can lead to unpleasant surprises.
>>
>> That's a good point and one I had qualms about since I'd explained that
>> very problem to the OP in and earlier posting.
>
> Ah yes, that's good to know. And then for example integer types on
> 16-bit systems don't get promoted to long?
If an expression of an integer type narrower than int is the operand of
an arithmetic operator, it's promoted to signed int if signed int can
represent all the values in the range of the narrow type, or to unsigned
int otherwise.
The underlying idea is that there are no arithmetic operations on types
narrower than int and unsigned int. Any operands narrower than int must
be promoted before they can be used in computations. See the draft
standard <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf>,
and search for "integer promotions" and "usual arithmetic conversions".
--
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 | gordonb.446bm@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2015-06-18 01:56 -0500 |
| Message-ID | <C-2dnQqaCuMe9h_InZ2dnUU7-QudnZ2d@posted.internetamerica> |
| In reply to | #63422 |
> I guess one can't test for everything in a couple of lines, and > I'll be updating the test suite to do different tests. I guess > anyone who compiles source should also run any test suites so I > added a note about that in the readme. There's another way to deal with this problem, maybe a little clunky, and you can do all the testing you want (except if you're trying to cross-compile): write a program to decide what type to use as unicode_cp. Use all the code you need, not just the preprocessor, and you're not limited to compile-time constants. You can also have it determine whether the type is big-endian, non-endian, or little-endian. Use an hour of CPU time if you really need to. It needs to run on the target machine, though. The program is also allowed to write out a detailed error message and exit with an error code if there is no suitable type available. At the end, have it *WRITE* a file "unicode_cp.h" which includes a typedef of unicode_cp, a #define for endianness, and any other stuff you need in there. It is also possible, in the case of cross-compilation or special circumstances, to hand-edit the produced file if needed. Your build code, possibly written using "make" or "gmake", would compile and run this little program to create "unicode_cp.h", which is then included by almost all of the rest of your code. It's not that different from the way lex and yacc parsers are mixed with C code, or a configure program that makes a config.h include file based on checking what functions are available in the C library and which include files are present. Lex creates a header file with the definitions for all the token numbers which is then included by the yacc parser code and anything else that needs it. Other application code that needs to deal with the type of unicode_cp should also include "unicode_cp.h" (and a header file which prototypes some of the XML parser functions it is using).
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-18 09:54 +0200 |
| Message-ID | <mltteo$r3h$1@speranza.aioe.org> |
| In reply to | #63479 |
On 18.06.2015 08:56, Gordon Burditt wrote: >> I guess one can't test for everything in a couple of lines, and >> I'll be updating the test suite to do different tests. I guess >> anyone who compiles source should also run any test suites so I >> added a note about that in the readme. > > There's another way to deal with this problem, maybe a little clunky, > and you can do all the testing you want (except if you're trying > to cross-compile): write a program to decide what type to use as > unicode_cp. Use all the code you need, not just the preprocessor, > and you're not limited to compile-time constants. You can also > have it determine whether the type is big-endian, non-endian, or > little-endian. Use an hour of CPU time if you really need to. It > needs to run on the target machine, though. The program is also > allowed to write out a detailed error message and exit with an error > code if there is no suitable type available. > > At the end, have it *WRITE* a file "unicode_cp.h" which includes a > typedef of unicode_cp, a #define for endianness, and any other stuff > you need in there. It is also possible, in the case of cross-compilation > or special circumstances, to hand-edit the produced file if needed. > > Your build code, possibly written using "make" or "gmake", would > compile and run this little program to create "unicode_cp.h", which > is then included by almost all of the rest of your code. It's not > that different from the way lex and yacc parsers are mixed with C > code, or a configure program that makes a config.h include file > based on checking what functions are available in the C library and > which include files are present. Lex creates a header file with > the definitions for all the token numbers which is then included > by the yacc parser code and anything else that needs it. > > Other application code that needs to deal with the type of unicode_cp > should also include "unicode_cp.h" (and a header file which > prototypes some of the XML parser functions it is using). Ah yes, this is a good suggestion. :) As for cross-compiling, well if the target is known one can include a pre-generated .h file in the source distribution. Although I don't know whether distros like Debian compile directly on each architecture or cross-compile? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-17 09:08 -0700 |
| Message-ID | <lnioaml3lp.fsf@nuthaus.mib.org> |
| In reply to | #63421 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> Dropping the
>> narrower types is unlikely to matter on most systems (though I have used
>> a system, the Cray T3E, where the change would make unicode_cp 64 bits
>> rather than 32.)
>
> Ah, that's interesting. I was not sure that it had 32-bit shorts. Did
> it use the same trick of adding high bits to the address to select half
> words that you've described for bytes?
No, the T3E used 64-bit Alpha CPUs. The predefined integer types were:
- char, 8 bits
- short, 32 bits
- int, 64 bits
- long, 64 bits
- long long, 64 bits
There was no 16-bit integer type.
Cray vector systems (T90 et al) were similar, but with 64-bit short.
They used the high-order-bits trick to construct byte pointers in
software. (String processing code ran remarkably slowly, but of
course they were heavily optimized for floating-point performance.)
--
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 | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-22 16:53 +0200 |
| Message-ID | <mm97fj$dq4$1@speranza.aioe.org> |
| In reply to | #63421 |
On 17.06.2015 17:35, Ben Bacarisse wrote:
> Keith Thompson <kst-u@mib.org> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> "Morten W. Petersen" <morphex@gmail.com> writes:
>>> <snip>
>>>> So an unsigned int seems to be the right way to go. Is it possible at
>>>> compile time to see the size of shorts, ints and long to choose the
>>>> smallest type with at least 4 bytes?
>>>
>>> That's not the right question. The size of a type is not 100%
>>> guaranteed to tell you the range of values it can represent, and "bytes"
>>> in C are not always 8 bits (though they are on all the systems you care
>>> about). It's much better to ask for exactly what you want:
>>>
>>> #include <limits.h>
>>>
>>> /*
>>> * Find the smallest standard unsigned type that can hold a Unicode code
>>> * point.
>>> */
>>>
>>> #if UCHAR_MAX >= 0x1fffff
>>> typedef unsigned char unicode_cp;
>>> #elif USHRT_MAX >= 0x1fffff
>>> typedef unsigned short unicode_cp;
>>> #elif UINT_MAX >= 0x1fffff
>>> typedef unsigned int unicode_cp;
>>> #else
>>> typedef unsigned long unicode_cp;
>>> #endif
>>>
>>> <snip>
>>
>> You might consider dropping the types narrower than unsigned int:
>>
>> #if UINT_MAX >= 0x1fffff
>> typedef unsigned int unicode_cp;
>> #else
>> typedef unsigned long unicode_cp;
>> #endif
>>
>> Unsigned types narrower than unsigned int promote to *signed* int in
>> many contexts; that can lead to unpleasant surprises.
>
> That's a good point and one I had qualms about since I'd explained that
> very problem to the OP in and earlier posting.
I'm experiencing some issues with this typedef thing and arrays.
There's a type definition:
typedef unsigned int unicode_char;
And the code:
unicode_char compare_to3[] = {0x2d,0x2d,0x00};
printf("compare_to3: %s\n", compare_to3[1]);
This causes a segmentation violation. What I'm thinking is that
the array gets initialized to one element (integer).
What's wrong here?
-Morten
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-22 16:32 +0100 |
| Message-ID | <mm99nj$3i8$2@dont-email.me> |
| In reply to | #63815 |
On 22/06/15 15:53, Morten W. Petersen wrote:
<snip>
>
> I'm experiencing some issues with this typedef thing and arrays.
>
> There's a type definition:
>
> typedef unsigned int unicode_char;
>
> And the code:
>
> unicode_char compare_to3[] = {0x2d,0x2d,0x00};
> printf("compare_to3: %s\n", compare_to3[1]);
>
> This causes a segmentation violation. What I'm thinking is that
> the array gets initialized to one element (integer).
>
> What's wrong here?
%s is the conversion specifier for strings, not for unsigned ints.
Here's the fix:
printf("compare_to3: %u\n", compare_to3[1]);
--
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 | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-22 18:21 +0200 |
| Message-ID | <mm9cl2$ri0$2@speranza.aioe.org> |
| In reply to | #63818 |
On 22.06.2015 17:32, Richard Heathfield wrote:
> On 22/06/15 15:53, Morten W. Petersen wrote:
> <snip>
>>
>> I'm experiencing some issues with this typedef thing and arrays.
>>
>> There's a type definition:
>>
>> typedef unsigned int unicode_char;
>>
>> And the code:
>>
>> unicode_char compare_to3[] = {0x2d,0x2d,0x00};
>> printf("compare_to3: %s\n", compare_to3[1]);
>>
>> This causes a segmentation violation. What I'm thinking is that
>> the array gets initialized to one element (integer).
>>
>> What's wrong here?
>
> %s is the conversion specifier for strings, not for unsigned ints.
> Here's the fix:
>
> printf("compare_to3: %u\n", compare_to3[1]);
Mm, yeah, getting better at printf formatting.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-22 16:33 +0100 |
| Message-ID | <87ioafiwr4.fsf@bsb.me.uk> |
| In reply to | #63815 |
"Morten W. Petersen" <morphex@gmail.com> writes:
<snip>
This is really a new topic...
> I'm experiencing some issues with this typedef thing and arrays.
>
> There's a type definition:
>
> typedef unsigned int unicode_char;
>
> And the code:
>
> unicode_char compare_to3[] = {0x2d,0x2d,0x00};
> printf("compare_to3: %s\n", compare_to3[1]);
>
> This causes a segmentation violation. What I'm thinking is that
> the array gets initialized to one element (integer).
>
> What's wrong here?
You have written, in effect,
printf("compare_to3: %s\n", 45);
%s expect the corresponding argument to be a pointer to the start of a
null terminated char array. 45 is just a number. (What's probably
happening is that printf is trying to print the characters found at
address 45 an up. That won't end well!)
By using your own integer type (C has an integer type for "wide"
characters) you are going to excluded from almost all the help the C
library might otherwise offer. However, it's still not clear what
version of C you are aiming to use. printf support for wchar_t arrays
is in C99 for example and my not work (or be otherwise unsuitable) on
one or more of your target platforms.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-22 18:20 +0200 |
| Message-ID | <mm9cjb$ri0$1@speranza.aioe.org> |
| In reply to | #63819 |
On 22.06.2015 17:33, Ben Bacarisse wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
> <snip>
>
> This is really a new topic...
>
>> I'm experiencing some issues with this typedef thing and arrays.
>>
>> There's a type definition:
>>
>> typedef unsigned int unicode_char;
>>
>> And the code:
>>
>> unicode_char compare_to3[] = {0x2d,0x2d,0x00};
>> printf("compare_to3: %s\n", compare_to3[1]);
>>
>> This causes a segmentation violation. What I'm thinking is that
>> the array gets initialized to one element (integer).
>>
>> What's wrong here?
>
> You have written, in effect,
>
> printf("compare_to3: %s\n", 45);
>
> %s expect the corresponding argument to be a pointer to the start of a
> null terminated char array. 45 is just a number. (What's probably
> happening is that printf is trying to print the characters found at
> address 45 an up. That won't end well!)
>
> By using your own integer type (C has an integer type for "wide"
> characters) you are going to excluded from almost all the help the C
> library might otherwise offer. However, it's still not clear what
> version of C you are aiming to use. printf support for wchar_t arrays
> is in C99 for example and my not work (or be otherwise unsuitable) on
> one or more of your target platforms.
Ah yes, I couldn't figure out what was going wrong, I think I had an
%lx etc. there as well before.
Turns out I had allocated too little memory and the reason the search
function (which came after that printf) failed.
It failed consistenly with the same values so I didn't understand
what was wrong at first, started looking at the XML file and could
not for the life of me understand what was wrong.
I'm aiming at c90. A little because I'd like to implement a processor
using a breadboard and then it's nice to keep things simple so that
any compiler will do. But mostly because one can expect just about
any compiler to support it.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-22 13:05 -0400 |
| Message-ID | <mm9f5m$s54$1@dont-email.me> |
| In reply to | #63815 |
On 06/22/2015 10:53 AM, Morten W. Petersen wrote:
...
> I'm experiencing some issues with this typedef thing and arrays.
>
> There's a type definition:
>
> typedef unsigned int unicode_char;
>
> And the code:
>
> unicode_char compare_to3[] = {0x2d,0x2d,0x00};
> printf("compare_to3: %s\n", compare_to3[1]);
>
> This causes a segmentation violation. What I'm thinking is that
> the array gets initialized to one element (integer).
>
> What's wrong here?
That depends upon what you're trying to do.
You're passing an unsigned int to printf(), when the corresponding
format specifier expects a char*; that just doesn't work.
Do you want to see the numeric value of compare_to3[1] (which is 0x2d,
or 45)? Then use a format string of "%u".
Do want to print the character represented by 45 according to whichever
character encoding is used by your standard library? In that case, use
printf("compare_to3: %c\n", compare_to3[1]);
Do you wamt to display the character represented by the Unicode code
point 0x2d2d00? C did not specify such functionality until C2011. If you
can find a fully conforming implementation of C2011, then you should
first convert the values stored in compare_to3[] into the correspond
Unicode code point value, and store it in a char32_t variable. Beware
unsigned wraparound - force the calculations to be done in a type known
to be big enough to avoid that problem, such as unsigned long or
char32_t itself.
Then call c32rtomb() to convert that to a multi-byte string. Note that
null-terminating a multi-byte string may first require undoing some
shift states; the appropriate sequence can be generating by using
c32rtomb() to convert a null character. The resulting string can then be
displayed using the "%s" format specifier you wrote above.
I started writing example code, but c32rtomb() is a somewhat complicated
function, and I don't have a compiler where I can test whether my code
even compiles, much less works correctly. This is something I've never
done before, and I make enough mistakes as it is when writing the first
draft of code doing something I've done hundreds of times before. I
figured I'd let myself in for less embarrassment if I didn't attempt it.
Good luck!
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web