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 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-16 10:37 -0700 |
| Message-ID | <3d81d04e-3b78-483e-a7b1-59a987e44e0c@googlegroups.com> |
| In reply to | #63337 |
On Tuesday, June 16, 2015 at 10:58:56 AM UTC+2, Ben Bacarisse wrote: [...] > That's going to make life much simpler. (Presuming you mean modern > Windows when you say Windows.) Yeah. Windows XP and beyond. > 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. Aha, great. Thanks for that. :) -Morten
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2015-06-15 17:51 -0700 |
| Message-ID | <95ada0d8-a49a-4234-9457-0cb74a8e8261@googlegroups.com> |
| In reply to | #63275 |
On Monday, June 15, 2015 at 7:34:09 AM UTC-5, Morten W. Petersen wrote: > On Monday, June 15, 2015 at 2:27:56 AM UTC+2, Ben Bacarisse wrote: > > 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. > IMO, the decision between using a function-like macro vs an inline-function should not be based on any notions of "efficiency". If the compiler does inlining at all, then two will be exactly the same, efficiency-wise, all else being equal. Rather, you should make a macro if you need to do transformations of the source text. And use inline functions if you need type checking on the arguments and 'single-evaluation' of expressions whose value is needed multiple times. IF in doubt, go with a function. You only "need" a macro for stuff that functions can't do (like stringifying and concatenating tokens).
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-15 21:02 -0700 |
| Message-ID | <49ac4d91-7046-4abe-8226-ebde9167cdaf@googlegroups.com> |
| In reply to | #63322 |
On Tuesday, June 16, 2015 at 2:52:06 AM UTC+2, luser droog wrote: [...] > IMO, the decision between using a function-like macro vs > an inline-function should not be based on any notions of > "efficiency". If the compiler does inlining at all, then > two will be exactly the same, efficiency-wise, all else > being equal. > > Rather, you should make a macro if you need to do > transformations of the source text. Well, what you're saying is going against what this document says: https://gcc.gnu.org/onlinedocs/cpp/Macros.html But as you say, it's IYO, so I guess it's a matter of style. > And use inline functions if you need type checking on > the arguments and 'single-evaluation' of expressions > whose value is needed multiple times. > > IF in doubt, go with a function. You only "need" a macro > for stuff that functions can't do (like stringifying and > concatenating tokens). What do you mean when you say "single-evaluation"? -Morten
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-16 00:51 -0400 |
| Message-ID | <mlo9ub$2q9$1@dont-email.me> |
| In reply to | #63328 |
On 06/16/2015 12:02 AM, Morten W. Petersen wrote:
> On Tuesday, June 16, 2015 at 2:52:06 AM UTC+2, luser droog wrote:
> [...]
>> IMO, the decision between using a function-like macro vs
>> an inline-function should not be based on any notions of
>> "efficiency". If the compiler does inlining at all, then
>> two will be exactly the same, efficiency-wise, all else
>> being equal.
>>
>> Rather, you should make a macro if you need to do
>> transformations of the source text.
>
> Well, what you're saying is going against what this document says:
>
> https://gcc.gnu.org/onlinedocs/cpp/Macros.html
I see no contradiction; could you explain the contradiction you believe
to be present?
>> And use inline functions if you need type checking on
>> the arguments and 'single-evaluation' of expressions
>> whose value is needed multiple times.
>>
>> IF in doubt, go with a function. You only "need" a macro
>> for stuff that functions can't do (like stringifying and
>> concatenating tokens).
>
> What do you mean when you say "single-evaluation"?
Before compiling and executing the following program, try to predict
what it's output will be. The difference between the max_macro() and
max_func() is that max_func() only does single evaluation of it's arguments.
#include <stdio.h>
#define max_macro(a,b) ((a) > (b) ? (a) : (b))
static inline int max_func(int a, int b) {return a > b ? a : b; }
int main(void)
{
int i = 5;
int j = 7;
int k = max_macro(i++,j--);
printf("i:%d j:%d k:%d\n", i, j, k);
k = max_func(i++, j--);
printf("i:%d j:%d k:%d\n", i, j, k);
}
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-15 22:30 -0700 |
| Message-ID | <28ba6cf8-0c11-424f-af73-dca9f36e17cd@googlegroups.com> |
| In reply to | #63329 |
On Tuesday, June 16, 2015 at 6:51:44 AM UTC+2, James Kuyper wrote:
> On 06/16/2015 12:02 AM, Morten W. Petersen wrote:
> > On Tuesday, June 16, 2015 at 2:52:06 AM UTC+2, luser droog wrote:
> > [...]
> >> IMO, the decision between using a function-like macro vs
> >> an inline-function should not be based on any notions of
> >> "efficiency". If the compiler does inlining at all, then
> >> two will be exactly the same, efficiency-wise, all else
> >> being equal.
> >>
> >> Rather, you should make a macro if you need to do
> >> transformations of the source text.
> >
> > Well, what you're saying is going against what this document says:
> >
> > https://gcc.gnu.org/onlinedocs/cpp/Macros.html
>
> I see no contradiction; could you explain the contradiction you believe
> to be present?
Well, the document I'm refering to talks about using macros as a replacement of a function call, while I read luser droog as being on about using macros purely as a way of altering the C file before it gets compiled.
> >> And use inline functions if you need type checking on
> >> the arguments and 'single-evaluation' of expressions
> >> whose value is needed multiple times.
> >>
> >> IF in doubt, go with a function. You only "need" a macro
> >> for stuff that functions can't do (like stringifying and
> >> concatenating tokens).
> >
> > What do you mean when you say "single-evaluation"?
>
> Before compiling and executing the following program, try to predict
> what it's output will be. The difference between the max_macro() and
> max_func() is that max_func() only does single evaluation of it's arguments.
>
> #include <stdio.h>
> #define max_macro(a,b) ((a) > (b) ? (a) : (b))
> static inline int max_func(int a, int b) {return a > b ? a : b; }
>
> int main(void)
> {
> int i = 5;
> int j = 7;
> int k = max_macro(i++,j--);
> printf("i:%d j:%d k:%d\n", i, j, k);
> k = max_func(i++, j--);
> printf("i:%d j:%d k:%d\n", i, j, k);
> }
Well, I reset i and j before the function call to make it easier to compare. Then I used "gcc -E" and got to see what things looked like after the preprocessor did its job.
So it looks like the macro takes its arguments "literally". :)
I'm thinking that if I use macros as replacement of functions, I should avoid doing things that alter the arguments as a part of the call.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-17 00:35 -0400 |
| Message-ID | <mlqtc8$92h$1@dont-email.me> |
| In reply to | #63330 |
On 06/16/2015 01:30 AM, Morten W. Petersen wrote:
> On Tuesday, June 16, 2015 at 6:51:44 AM UTC+2, James Kuyper wrote:
>> On 06/16/2015 12:02 AM, Morten W. Petersen wrote:
>>> On Tuesday, June 16, 2015 at 2:52:06 AM UTC+2, luser droog wrote:
>>> [...]
>>>> IMO, the decision between using a function-like macro vs
>>>> an inline-function should not be based on any notions of
>>>> "efficiency". If the compiler does inlining at all, then
>>>> two will be exactly the same, efficiency-wise, all else
>>>> being equal.
>>>>
>>>> Rather, you should make a macro if you need to do
>>>> transformations of the source text.
>>>
>>> Well, what you're saying is going against what this document says:
>>>
>>> https://gcc.gnu.org/onlinedocs/cpp/Macros.html
>>
>> I see no contradiction; could you explain the contradiction you believe
>> to be present?
>
> Well, the document I'm refering to talks about using macros as a replacement of a function call, while I read luser droog as being on about using macros purely as a way of altering the C file before it gets compiled.
Yes, macros are defined in terms of rearranging the text of your
program. And yes, a function-like macro, in particular, can rearrange
the text of the program so that it behaves as if there was function
called. So that's not a contradiction. Examples:
#define max_macro(a,b) ((a)>(b) ? (a) : (b))
int max_func(int a, int b) { return a > b ? a : b; }
#define decimal_string_to_long(nptr, endptr) \
strtol((nptr), (endptr), 10)
#define ENTRY(base, name) { #name, offsetof(struct base,name) }
With those macros defined, the code
k = max_macro(i, j);
gets converted during translation phase 4 into:
k = ((i) > (j) ? (i) : (j));
which behaves essentially the same as if it had called max_func(i,j).
However,
k = max_macro(i++, j++);
Gets converted to
k = ((i++) > (j++)) ? (i++) : (j++));
Which does not behave as if it had called max_func(i++,j++), because
either i++ or j++ will get evaluated twice, and the value returned will
be the value after the increment.
The code
result = decimal_string_to_long(src, endsrc);
gets converted to
result = strtol((src), (endsrc), 10);
and therefore works exactly like a function, even if it's arguments have
side-effects (such as src++).
The code
struct table {
char *name;
size_t offset;
} = {
ENTRY(table, name),
ENTRY(table, offset),
ENTRY(tm, tm_year)
};
DOES NOT behave as though ENTRY were a function, because you could not
legally put a function in that location. It does, however, work
precisely as intended: the code after translation phase 4 is:
struct table {
char *name;
size_t offset;
} = {
{ "name", offsetof(struct table, name) },
{ "offset", offsetof(struct table, offset) },
{ "tm_year", offsetsof(struct tm, tm_year) }
};
Is that clear?
...
>>> What do you mean when you say "single-evaluation"?
>>
>> Before compiling and executing the following program, try to predict
>> what it's output will be. The difference between the max_macro() and
>> max_func() is that max_func() only does single evaluation of it's arguments.
>>
>> #include <stdio.h>
>> #define max_macro(a,b) ((a) > (b) ? (a) : (b))
>> static inline int max_func(int a, int b) {return a > b ? a : b; }
>>
>> int main(void)
>> {
>> int i = 5;
>> int j = 7;
>> int k = max_macro(i++,j--);
>> printf("i:%d j:%d k:%d\n", i, j, k);
>> k = max_func(i++, j--);
>> printf("i:%d j:%d k:%d\n", i, j, k);
>> }
>
> Well, I reset i and j before the function call to make it easier to compare. Then I used "gcc -E" and got to see what things looked like after the preprocessor did its job.
>
> So it looks like the macro takes its arguments "literally". :)
>
> I'm thinking that if I use macros as replacement of functions, I should avoid doing things that alter the arguments as a part of the call.
It's often dangerous to pass expressions with side-effects to
function-like macros, because they may be evaluated more than once (or
might not even be evaluated at all, depending upon the macro). However,
if you know for sure that a function-like macro uses a given argument
exactly once, then there's no problem.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2015-06-19 18:51 +0200 |
| Message-ID | <f0i8oa5qi9cq2m04p6a53sng32tgninnl6@4ax.com> |
| In reply to | #63390 |
On Wed, 17 Jun 2015 00:35:34 -0400, James Kuyper wrote:
>On 06/16/2015 01:30 AM, Morten W. Petersen wrote:
>> On Tuesday, June 16, 2015 at 6:51:44 AM UTC+2, James Kuyper wrote:
>>> On 06/16/2015 12:02 AM, Morten W. Petersen wrote:
>>>> On Tuesday, June 16, 2015 at 2:52:06 AM UTC+2, luser droog wrote:
>>>> [...]
>>>>> IMO, the decision between using a function-like macro vs
>>>>> an inline-function should not be based on any notions of
>>>>> "efficiency". If the compiler does inlining at all, then
>>>>> two will be exactly the same, efficiency-wise, all else
>>>>> being equal.
>>>>>
>>>>> Rather, you should make a macro if you need to do
>>>>> transformations of the source text.
>>>>
>>>> Well, what you're saying is going against what this document says:
>>>>
>>>> https://gcc.gnu.org/onlinedocs/cpp/Macros.html
>>>
>>> I see no contradiction; could you explain the contradiction you believe
>>> to be present?
>>
>> Well, the document I'm refering to talks about using macros as a replacement of a function call, while I read luser droog as being on about using macros purely as a way of altering the C file before it gets compiled.
>
>Yes, macros are defined in terms of rearranging the text of your
>program. And yes, a function-like macro, in particular, can rearrange
>the text of the program so that it behaves as if there was function
>called. So that's not a contradiction. Examples:
>
>#define max_macro(a,b) ((a)>(b) ? (a) : (b))
>int max_func(int a, int b) { return a > b ? a : b; }
>#define decimal_string_to_long(nptr, endptr) \
> strtol((nptr), (endptr), 10)
>#define ENTRY(base, name) { #name, offsetof(struct base,name) }
>
>With those macros defined, the code
>
> k = max_macro(i, j);
>
>gets converted during translation phase 4 into:
>
> k = ((i) > (j) ? (i) : (j));
>
>which behaves essentially the same as if it had called max_func(i,j).
>However,
>
> k = max_macro(i++, j++);
>
>Gets converted to
>
> k = ((i++) > (j++)) ? (i++) : (j++));
>
>Which does not behave as if it had called max_func(i++,j++), because
>either i++ or j++ will get evaluated twice, and the value returned will
>be the value after the increment.
so i understand the K&R book when speak of macro with args...
#define G(a,b) if(a) goto b
if it is called with
G(++j!=0, label);
or
G(++j>4, label);
or
G(++j<4&&--i>3, label);
is j in each "or" line evalued one, or 2 times?
if i see above, in how i understood: one time only
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2015-06-15 22:40 -0700 |
| Message-ID | <baa260c4-73f8-454a-97c1-52505e6b2305@googlegroups.com> |
| In reply to | #63328 |
On Monday, June 15, 2015 at 11:02:56 PM UTC-5, Morten W. Petersen wrote: > On Tuesday, June 16, 2015 at 2:52:06 AM UTC+2, luser droog wrote: > [...] > > IMO, the decision between using a function-like macro vs > > an inline-function should not be based on any notions of > > "efficiency". If the compiler does inlining at all, then > > two will be exactly the same, efficiency-wise, all else > > being equal. > > > > Rather, you should make a macro if you need to do > > transformations of the source text. > > Well, what you're saying is going against what this document says: > > https://gcc.gnu.org/onlinedocs/cpp/Macros.html > > But as you say, it's IYO, so I guess it's a matter of style. > Well, yes. It is opinion. It is my own. But I think it reflects the "general opinion" around here. I learned it here. But the linked document addresses /how/, and my comments were directed toward /when/ and /how-to-choose/. I don't think there's any direct conflict, but a different focus. > > And use inline functions if you need type checking on > > the arguments and 'single-evaluation' of expressions > > whose value is needed multiple times. > > > > IF in doubt, go with a function. You only "need" a macro > > for stuff that functions can't do (like stringifying and > > concatenating tokens). > > What do you mean when you say "single-evaluation"? > James beat me to it, but I've got my own example: http://stackoverflow.com/questions/16243509/explanation-of-c-faqs-unsafe-macro/16243542#16243542 But, let it be understood that I love macros. When they're in their place, doing their proper work. Not howling at the moon scratching at the cabinets. My favorite thing is X-Macros: http://stackoverflow.com/questions/6635851/real-world-use-of-x-macros/6636596#6636596 And in my newest project, I use them as much as possible. And loads of other macros, too. But it any of them could be functions, they would be. https://github.com/luser-dr00g/inca/blob/master/inca3.c But depending on how "functional" your style is, you may need to rely on more functions and fewer macros. Where by "functional" I mean the mathematical sense of just a mapping from the Cartesian product of the argument types to the result type. If you're using lots of side-effects, updating global data, you need more sequence points all over the place to avoid undefined behavior of attempting to write more than once to an object or -- much harder to understand, and thus avoid -- writing and reading the same object where the value read is not involved in the calculation of the result. eg. int a[5],i=2; a[i]=i++; //UB: the `i` in `a[i]` is not used in result value. (I think I got that example right. As I say, this half of the double-write UB is still hard for me to fully grasp.) So the point is, macros can obscure things like this in expressions, making little bugs really hard to track down. A function-call establishes a sequence point between the evaluation of its arguments, the evaluation of the function, and the evaluation of the remaining expression of which the function call was a part. A macro, by contrast doesn't do any of this.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2015-06-15 23:23 -0700 |
| Message-ID | <b26d74c5-5653-4f59-a3ab-0a79c28544c0@googlegroups.com> |
| In reply to | #63331 |
On Tuesday, June 16, 2015 at 12:40:37 AM UTC-5, luser droog wrote: > > But depending on how "functional" your style is, you may > need to rely on more functions and fewer macros. Where by > "functional" I mean the mathematical sense of just a mapping > from the Cartesian product of the argument types to the > result type. > > If you're using lots of side-effects, updating global data, > you need more sequence points all over the place to avoid > undefined behavior of attempting to write more than once to > an object or -- much harder to understand, and thus avoid -- > writing and reading the same object where the value read > is not involved in the calculation of the result. eg. > > int a[5],i=2; > a[i]=i++; //UB: the `i` in `a[i]` is not used in result value. > > (I think I got that example right. As I say, this half of the > double-write UB is still hard for me to fully grasp.) > A better example is the thread where this came up: https://groups.google.com/d/topic/comp.lang.c/Yc9sjY6Bzsg/discussion and, yes, a macro was involved. But I was too embarrassed to say so at first. > So the point is, macros can obscure things like this in expressions, > making little bugs really hard to track down. A function-call > establishes a sequence point between the evaluation of its arguments, > the evaluation of the function, and the evaluation of the remaining > expression of which the function call was a part. A macro, by contrast > doesn't do any of this.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-16 11:07 -0700 |
| Message-ID | <1f8e2d9f-f64a-4cf4-a8ef-d3ca6208e00f@googlegroups.com> |
| In reply to | #63332 |
On Tuesday, June 16, 2015 at 8:23:15 AM UTC+2, luser droog wrote: > On Tuesday, June 16, 2015 at 12:40:37 AM UTC-5, luser droog wrote: [...] > > If you're using lots of side-effects, updating global data, > > you need more sequence points all over the place to avoid > > undefined behavior of attempting to write more than once to > > an object or -- much harder to understand, and thus avoid -- > > writing and reading the same object where the value read > > is not involved in the calculation of the result. eg. > > > > int a[5],i=2; > > a[i]=i++; //UB: the `i` in `a[i]` is not used in result value. > > > > (I think I got that example right. As I say, this half of the > > double-write UB is still hard for me to fully grasp.) > > > > A better example is the thread where this came up: > https://groups.google.com/d/topic/comp.lang.c/Yc9sjY6Bzsg/discussion > and, yes, a macro was involved. But I was too embarrassed to say so > at first. OK. Well the discussion you referred to ends up concluding that using pointers was better and that memcpy did what you wanted. I think in general it is a good idea to make the code easy to read by keeping things simple. If a significant performance gain can be made by using some less obvious hacks then OK, that can be justified. -Morten
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-16 23:54 -0700 |
| Message-ID | <4da682e4-ed28-4982-9b40-d261657b2b10@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). OK. Well I see different versions of stdint.h are available, and I'm thinking I want to include as little external code as possible. Do you or anyone else here know of an include file I could use that has just int32_t? I don't see the project needing any other integer than that. Later I'll probably add an internal storage optimization where each character uses 21 bits and then a compile-time option and/or runtime option for 32 or 21 bits. > BTW, your desire to use C90 is not consistent with using inline all over > the place. Yeah, inching towards C90 as recommended. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-17 10:51 +0100 |
| Message-ID | <87a8vywtmc.fsf@bsb.me.uk> |
| In reply to | #63392 |
"Morten W. Petersen" <morphex@gmail.com> writes: > 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). > > OK. Well I see different versions of stdint.h are available, and I'm > thinking I want to include as little external code as possible. > > Do you or anyone else here know of an include file I could use that > has just int32_t? I don't see the project needing any other integer > than that. The type want is actually int_least32_t (or uint_least32_t). There is no reason why your program should not compile simply because an exact width type is not available. But your comparatively narrow range of targets means that for C90 the type to use is just int (or unsigned int). None of your targets have an int type that is smaller than 32 bits, and I don't think any of them have a wider int type whist at the time having a 32-bit short. But this brings up another issue. If you are writing a complete application the internal representation of your data matters only to you, but if you plan to write an XML parsing library (i.e. a parser that other programs can use) then your choice of representation becomes more significant. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-17 03:46 -0700 |
| Message-ID | <ceb39bed-8861-440b-a8e0-002fb7a787f2@googlegroups.com> |
| In reply to | #63393 |
On Wednesday, June 17, 2015 at 11:51:15 AM UTC+2, Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: [...] > > OK. Well I see different versions of stdint.h are available, and I'm > > thinking I want to include as little external code as possible. > > > > Do you or anyone else here know of an include file I could use that > > has just int32_t? I don't see the project needing any other integer > > than that. > > The type want is actually int_least32_t (or uint_least32_t). There is > no reason why your program should not compile simply because an exact > width type is not available. > > But your comparatively narrow range of targets means that for C90 the > type to use is just int (or unsigned int). None of your targets have an > int type that is smaller than 32 bits, and I don't think any of them > have a wider int type whist at the time having a 32-bit short. Then I have to ask, what kinds of other targets that have less than 32 bit ints are there today that are alive (and even growing)? A quick and easy way for the current targets is to pass around unsigned shorts then? > But this brings up another issue. If you are writing a complete > application the internal representation of your data matters only to > you, but if you plan to write an XML parsing library (i.e. a parser that > other programs can use) then your choice of representation becomes more > significant. Well, the first idea I had for a project was a XML validator which was going to be superduper fast using assembly and everything. Then I found that it had to be valid Unicode as well. Then I found that you have to keep track of the state as well to properly validate, and when keeping a state, why not keep the entire structure in memory? And when you have it all in memory, it's fairly easy to write it out as well when you know your way around the code. What started as one project grew into another and it keeps growing. I think it would be healthy and smart to avoid scope creep, so yes, it would be nice to integrate with other projects at this level instead of for example writing a DOM manipulator as well. So targets and integration are issues I need to figure out. If unsigned shorts are 32 bits on the current targets then that should be good enough for now. -Morten
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-17 04:17 -0700 |
| Message-ID | <782db9bc-c3e8-4f7b-b84c-e842ab6590de@googlegroups.com> |
| In reply to | #63395 |
On Wednesday, June 17, 2015 at 12:47:04 PM UTC+2, Morten W. Petersen wrote: > On Wednesday, June 17, 2015 at 11:51:15 AM UTC+2, Ben Bacarisse wrote: > > "Morten W. Petersen" <morphex@gmail.com> writes: > [...] > > > OK. Well I see different versions of stdint.h are available, and I'm > > > thinking I want to include as little external code as possible. > > > > > > Do you or anyone else here know of an include file I could use that > > > has just int32_t? I don't see the project needing any other integer > > > than that. > > > > The type want is actually int_least32_t (or uint_least32_t). There is > > no reason why your program should not compile simply because an exact > > width type is not available. > > > > But your comparatively narrow range of targets means that for C90 the > > type to use is just int (or unsigned int). None of your targets have an > > int type that is smaller than 32 bits, and I don't think any of them > > have a wider int type whist at the time having a 32-bit short. [...] > A quick and easy way for the current targets is to pass around unsigned shorts then? I'll answer this one myself. I took a sizeof on shorts, ints and longs, and on Cygwin 32 and 64 shorts are always 2 bytes or 16 bits. Ints are 4 and longs are 8 bytes on 64 bit. 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? For integrators, how do they know which type used is used for the internal storage? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-17 14:02 +0100 |
| Message-ID | <87eglav66m.fsf@bsb.me.uk> |
| In reply to | #63396 |
"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> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-17 06:15 -0700 |
| Message-ID | <ab524698-9b50-40e1-8833-9799cf883385@googlegroups.com> |
| In reply to | #63403 |
On Wednesday, June 17, 2015 at 3:02:49 PM UTC+2, Ben Bacarisse wrote: > "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 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. In your example Ben, are there any caveats? For example someone who has a DOM manipulator and has access to the memory storage and functions, will they have to do anything in particular to make things work, as opposed to integrators knowing that a Unicode character an integer and is 32 bits wide? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-17 15:34 +0100 |
| Message-ID | <878ubiv1y2.fsf@bsb.me.uk> |
| In reply to | #63406 |
"Morten W. Petersen" <morphex@gmail.com> writes: > On Wednesday, June 17, 2015 at 3:02:49 PM UTC+2, Ben Bacarisse wrote: >> "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 > > 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. > In your example Ben, are there any caveats? For example someone who > has a DOM manipulator and has access to the memory storage and > functions, will they have to do anything in particular to make things > work, as opposed to integrators knowing that a Unicode character an > integer and is 32 bits wide? I don't understand, sorry. Do you mean you hope to provide a general-use XML library? If so, whatever you do you will annoy some people to the extent that they can't use your functions. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-17 07:58 -0700 |
| Message-ID | <37e54134-f63c-411f-9347-b27c59587a64@googlegroups.com> |
| In reply to | #63409 |
On Wednesday, June 17, 2015 at 4:34:20 PM UTC+2, Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: [...] > > 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. Well, it "bombs out" as some might say, and stops the compile process if things are uncertain. See below.. > > In your example Ben, are there any caveats? For example someone who > > has a DOM manipulator and has access to the memory storage and > > functions, will they have to do anything in particular to make things > > work, as opposed to integrators knowing that a Unicode character an > > integer and is 32 bits wide? > > I don't understand, sorry. Do you mean you hope to provide a > general-use XML library? If so, whatever you do you will annoy some > people to the extent that they can't use your functions. Ah yes. Can't please everyone etc. :) But what you're basically saying is that the suggestion with typedef to select the type is a good one, not easy to get burned on anything? What if I create functions that use a 32-bit int, and then wrapper functions around these, for example to promote to long long and other types? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-17 16:04 +0100 |
| Message-ID | <87r3patlyf.fsf@bsb.me.uk> |
| In reply to | #63412 |
"Morten W. Petersen" <morphex@gmail.com> writes: > On Wednesday, June 17, 2015 at 4:34:20 PM UTC+2, Ben Bacarisse wrote: >> "Morten W. Petersen" <morphex@gmail.com> writes: <snip> >> > In your example Ben, are there any caveats? For example someone who >> > has a DOM manipulator and has access to the memory storage and >> > functions, will they have to do anything in particular to make things >> > work, as opposed to integrators knowing that a Unicode character an >> > integer and is 32 bits wide? >> >> I don't understand, sorry. Do you mean you hope to provide a >> general-use XML library? If so, whatever you do you will annoy some >> people to the extent that they can't use your functions. > > Ah yes. Can't please everyone etc. :) > > But what you're basically saying is that the suggestion with typedef > to select the type is a good one, not easy to get burned on anything? I don't know your intentions so I find it hard to be more helpful. But if you can't be burned by a decision, it was not an interesting one! Choosing wide character arrays and a type of your own for the elements is certainly in the interesting category, and bound to be a problem for some people. > What if I create functions that use a 32-bit int, and then wrapper > functions around these, for example to promote to long long and other > types? Why would you do that? I'm being to feel I have no handle on what you are trying to do. (BTW, you should avoid, if you can, terms with technical meanings in C like "promote". I think you are talking about providing adaptor functions or shims as they are sometimes called.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-17 08:16 -0700 |
| Message-ID | <04dc89cd-9b61-43d1-b842-e8ac1a6c97de@googlegroups.com> |
| In reply to | #63414 |
On Wednesday, June 17, 2015 at 5:05:04 PM UTC+2, Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: [...] > > But what you're basically saying is that the suggestion with typedef > > to select the type is a good one, not easy to get burned on anything? > > I don't know your intentions so I find it hard to be more helpful. But > if you can't be burned by a decision, it was not an interesting one! True. :) > Choosing wide character arrays and a type of your own for the elements > is certainly in the interesting category, and bound to be a problem for > some people. OK. > > What if I create functions that use a 32-bit int, and then wrapper > > functions around these, for example to promote to long long and other > > types? > > Why would you do that? I'm being to feel I have no handle on what you > are trying to do. (BTW, you should avoid, if you can, terms with > technical meanings in C like "promote". I think you are talking about > providing adaptor functions or shims as they are sometimes called.) Well, it's about selling the library I guess. Do small things that for some could be a headache. Kind of like documented interfaces if you will, which have a comment describing anything that's important. There should be functions there to operate on the parsed data. Function to search for something, function to get a string. And in that example, it could be entirely OK to create a function that accepts for example wchar_t types and returns a position in an integer size that's typically used on systems that have wchar_t. This function set will when I get to that point be so optimized and feature-complete that integrators don't care about the internal storage and all that jazz. -Morten
[toc] | [prev] | [next] | [standalone]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web