Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #63008 > unrolled thread
| Started by | bilsch01 <king621@comcast.net> |
|---|---|
| First post | 2015-06-06 04:58 -0700 |
| Last post | 2015-07-26 01:00 +0200 |
| Articles | 20 on this page of 112 — 19 participants |
Back to article view | Back to comp.lang.c
counting bytes bilsch01 <king621@comcast.net> - 2015-06-06 04:58 -0700
Re: counting bytes Bartc <bc@freeuk.com> - 2015-06-06 13:05 +0100
Re: counting bytes bilsch01 <king621@comcast.net> - 2015-06-06 05:24 -0700
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-06 05:41 -0700
Re: counting bytes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-06 14:00 +0100
Re: counting bytes Bartc <bc@freeuk.com> - 2015-06-06 13:52 +0100
Re: counting bytes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-06-06 10:27 -0400
Re: counting bytes jt@toerring.de (Jens Thoms Toerring) - 2015-06-06 22:31 +0000
THANKS EVERYBODY FOR THE INFO bilsch01 <king621@comcast.net> - 2015-06-06 23:35 -0700
Re: THANKS EVERYBODY FOR THE INFO Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-07 10:08 +0100
Re: THANKS EVERYBODY FOR THE INFO Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-07 09:22 -0700
Re: THANKS EVERYBODY FOR THE INFO Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-07 18:07 +0100
Re: THANKS EVERYBODY FOR THE INFO Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-08 04:03 -0700
Re: THANKS EVERYBODY FOR THE INFO Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:12 -0700
Re: THANKS EVERYBODY FOR THE INFO Keith Thompson <kst-u@mib.org> - 2015-06-07 08:01 -0700
Re: counting bytes gordonb.3gcai@burditt.org (Gordon Burditt) - 2015-06-07 05:02 -0500
Re: counting bytes David Brown <david.brown@hesbynett.no> - 2015-06-07 15:32 +0200
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-06-07 12:48 -0700
Re: counting bytes David Brown <david.brown@hesbynett.no> - 2015-06-07 23:05 +0200
Re: counting bytes Richard Heathfield <rjh@cpax.org.uk> - 2015-06-07 22:17 +0100
Re: counting bytes David Brown <david.brown@hesbynett.no> - 2015-06-07 23:49 +0200
Re: counting bytes Richard Heathfield <rjh@cpax.org.uk> - 2015-06-07 23:37 +0100
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:25 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:21 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-11 13:54 -0500
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 06:33 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-20 09:51 -0500
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-24 09:49 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-24 12:26 -0500
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 11:16 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-30 23:15 -0500
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 06:07 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-02 14:31 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-09 05:31 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-09 17:09 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 09:58 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-09-05 19:29 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 14:38 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-09-06 17:46 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-07 23:50 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-09-06 22:00 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-07 23:24 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-24 20:03 -0400
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-24 22:13 -0500
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 02:22 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-25 11:39 -0500
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 09:48 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-25 14:04 -0500
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 14:22 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-25 11:07 -0400
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-25 12:43 -0400
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-25 13:32 -0400
Re: counting bytes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-25 20:14 +0000
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-25 17:24 -0400
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 14:42 -0700
Re: counting bytes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-25 23:02 +0000
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-25 19:17 -0400
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 16:37 -0700
Re: counting bytes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-26 06:10 +0000
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-26 08:31 -0400
Re: counting bytes Bartc <bc@freeuk.com> - 2015-07-30 21:32 +0100
Re: counting bytes raltbos@xs4all.nl (Richard Bos) - 2015-07-31 13:25 +0000
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-31 11:31 -0400
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-31 11:30 -0700
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-31 14:29 -0400
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-31 12:14 -0700
Re: counting bytes David Kleinecke <dkleinecke@gmail.com> - 2015-07-31 17:39 -0700
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-31 23:32 -0400
Re: counting bytes David Kleinecke <dkleinecke@gmail.com> - 2015-08-01 16:41 -0700
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-08-01 20:23 -0400
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-31 11:01 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-25 19:42 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 12:16 -0700
Re: counting bytes Bartc <bc@freeuk.com> - 2015-07-30 22:04 +0100
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 06:10 -0700
Re: counting bytes David Kleinecke <dkleinecke@gmail.com> - 2015-07-25 19:10 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-25 22:16 -0400
Re: counting bytes David Kleinecke <dkleinecke@gmail.com> - 2015-07-25 19:46 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 11:52 -0700
Re: counting bytes raltbos@xs4all.nl (Richard Bos) - 2015-07-31 08:51 +0000
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 06:19 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-01 09:39 -0400
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-08-01 13:06 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-01 20:43 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 06:52 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-02 15:14 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-09 07:54 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-09 16:43 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 10:48 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-11 17:50 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 06:36 -0700
Re: counting bytes raltbos@xs4all.nl (Richard Bos) - 2015-07-20 15:14 +0000
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-24 09:38 -0700
Re: counting bytes raltbos@xs4all.nl (Richard Bos) - 2015-07-25 19:12 +0000
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 12:18 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-11 17:03 -0700
Re: counting bytes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 00:15 +0000
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-11 17:42 -0700
Re: counting bytes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 02:46 +0000
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-12 12:33 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 06:48 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-20 11:18 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-24 09:58 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-24 11:14 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 11:02 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-30 13:10 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-01 10:53 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-06-07 14:46 -0700
Re: counting bytes David Brown <david.brown@hesbynett.no> - 2015-06-08 09:05 +0200
Re: counting bytes Siri Cruz <chine.bleu@yahoo.com> - 2015-06-06 05:06 -0700
Re: counting bytes bartekltg <bartekltg@gmail.com> - 2015-07-26 00:58 +0200
Re: counting bytes bartekltg <bartekltg@gmail.com> - 2015-07-26 01:00 +0200
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-09-06 22:00 -0400 |
| Message-ID | <cd6Hx.27215$aH5.2010@fx08.iad> |
| In reply to | #69681 |
On 9/6/15 5:38 PM, Tim Rentsch wrote: > Keith Thompson <kst-u@mib.org> writes: > >> Tim Rentsch <txr@alumni.caltech.edu> writes: >>> Richard Damon <Richard@Damon-Family.org> writes: >> >> [...] >> >>>> UINT8_MAX has only one allowed value, 255, any other value (other than >>>> not defined) is non-conforming. (The fixed sized maxes are a bit >>>> strange only having a single possible value). >>> >>> I won't disagree, but even so the Standard says the value is >>> implementation-defined. Look it up if you don't believe me - >>> it's listed in both 7.20.3 and J.3.13. >> >> N1570 7.20.3 doesn't mention UINT8_MAX. > > Sorry, I had the wrong section. It's 7.20.2. > >> It's mentioned implicitly in 7.20.2.1, which says that UINTN_MAX >> is exactly 2^N-1, not that it's implementation-defined. > > Please see 7.20.2 p2, which does. > The value is implementation-define in the fact that there are two possibilities, 255 or not defined, and which choice is used must be documented.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-07 23:24 -0700 |
| Message-ID | <kfn7fo1mnrx.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #69725 |
Richard Damon <Richard@Damon-Family.org> writes: > On 9/6/15 5:38 PM, Tim Rentsch wrote: >> Keith Thompson <kst-u@mib.org> writes: >> >>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>>> Richard Damon <Richard@Damon-Family.org> writes: >>> >>> [...] >>> >>>>> UINT8_MAX has only one allowed value, 255, any other value (other than >>>>> not defined) is non-conforming. (The fixed sized maxes are a bit >>>>> strange only having a single possible value). >>>> >>>> I won't disagree, but even so the Standard says the value is >>>> implementation-defined. Look it up if you don't believe me - >>>> it's listed in both 7.20.3 and J.3.13. >>> >>> N1570 7.20.3 doesn't mention UINT8_MAX. >> >> Sorry, I had the wrong section. It's 7.20.2. >> >>> It's mentioned implicitly in 7.20.2.1, which says that UINTN_MAX >>> is exactly 2^N-1, not that it's implementation-defined. >> >> Please see 7.20.2 p2, which does. > > The value is implementation-define in the fact that there are two > possibilities, 255 or not defined, and which choice is used must be > documented. That isn't really how the text in the Standard reads, but as long as you agree that UINT8_MAX is implementation-defined I suppose it doesn't matter.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-07-24 20:03 -0400 |
| Message-ID | <rnAsx.228181$k44.141483@fx15.iad> |
| In reply to | #66287 |
On 7/24/15 12:49 PM, Tim Rentsch wrote: > That's true, but the Standard also allows extensions. If types > narrower than CHAR_BIT bits were provided as an extension, > doesn't it seem reasonable to also extend sizeof to give a > non-integral value for those types (not to be confused with > 'extended integer types', which has a specific meaning)? I don't > see any reason why there couldn't be such an extension, provided > of course the usual condition about strictly conforming programs > holds. > Extension should not change the defined behavior of things and MUST NOT change the behavior of a strictly conforming program. Let us assume that we have this strange size_t that can express fractions of at least 1/2 (0.5), and the type with that size is tiny_t I presume you intend that 2*sizeof(tiny_t) == sizeof(char) and that sizeof(tiny_t) == sizeof(char)/2 This violates the above rule as a strictly conforming program can do assert(sizeof(char)/2 * 2 == 0) and not have the assert fire, but it will in your case. (sizeof(char) MUST be 1, as an integral type, 1/2 MUST be 0, and 0*2 MUST be 0)
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-07-24 22:13 -0500 |
| Message-ID | <mouuqj$erh$1@dont-email.me> |
| In reply to | #66322 |
On 7/24/2015 7:03 PM, Richard Damon wrote: > On 7/24/15 12:49 PM, Tim Rentsch wrote: > >> That's true, but the Standard also allows extensions. If types >> narrower than CHAR_BIT bits were provided as an extension, >> doesn't it seem reasonable to also extend sizeof to give a >> non-integral value for those types (not to be confused with >> 'extended integer types', which has a specific meaning)? I don't >> see any reason why there couldn't be such an extension, provided >> of course the usual condition about strictly conforming programs >> holds. >> > > Extension should not change the defined behavior of things and MUST NOT > change the behavior of a strictly conforming program. > > Let us assume that we have this strange size_t that can express > fractions of at least 1/2 (0.5), and the type with that size is tiny_t > > I presume you intend that 2*sizeof(tiny_t) == sizeof(char) and that > sizeof(tiny_t) == sizeof(char)/2 I don't think sizeof(tiny_t) would equal sizeof(char)/2. The first would need to hold to make it a useful extension. [snip] Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-25 02:22 -0700 |
| Message-ID | <3b074a69-ad66-466a-a819-a2bbbeae2bda@googlegroups.com> |
| In reply to | #66324 |
On Saturday, July 25, 2015 at 4:14:02 AM UTC+1, Martin Shobe wrote: > On 7/24/2015 7:03 PM, Richard Damon wrote: > > > I presume you intend that 2*sizeof(tiny_t) == sizeof(char) and that > > sizeof(tiny_t) == sizeof(char)/2 > > I don't think sizeof(tiny_t) would equal sizeof(char)/2. The first would > need to hold to make it a useful extension. > typedef tiny_t int4; /* tiny_t is a 4 bit nyble */ sizeof(tiny_t) == 1; tiny_t array[10]; sizeof(array) = 5; tiny_t *dynamic = malloc(sizeof(tiny_t) * N); /* doesnt break but wastes memory*/ tiny_t dynamic_good - malloc( sizeof(tiny_t, N) ); /* extension to sizeof() that rounds up */ tiny_t *ptr = &array[1]; /* OK */ sizeof(ptr) <= sizeof(void *); /* may not hold, for efficiency reasons, because you'll need an extra 3 bits in a tiny_t pointer. On 64 bit machine's you can insert them above the real memory, but on 32 bitters with 4GB of RAM, it won't work, and we can't reduce the efficiency of such functions as memcpy just to support bit types */
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-07-25 11:39 -0500 |
| Message-ID | <mp0e1e$rdq$1@dont-email.me> |
| In reply to | #66326 |
On 7/25/2015 4:22 AM, Malcolm McLean wrote: > On Saturday, July 25, 2015 at 4:14:02 AM UTC+1, Martin Shobe wrote: >> On 7/24/2015 7:03 PM, Richard Damon wrote: >> >>> I presume you intend that 2*sizeof(tiny_t) == sizeof(char) and that >>> sizeof(tiny_t) == sizeof(char)/2 >> >> I don't think sizeof(tiny_t) would equal sizeof(char)/2. The first would >> need to hold to make it a useful extension. >> > typedef tiny_t int4; /* tiny_t is a 4 bit nyble */ > sizeof(tiny_t) == 1; Under Tim's extension, this would evaluate to 0. > tiny_t array[10]; > sizeof(array) = 5; > tiny_t *dynamic = malloc(sizeof(tiny_t) * N); /* doesnt break but wastes memory*/ Under Tim's extension, this wouldn't waste memory (at least not any more than malloc does anyway.) > tiny_t dynamic_good - malloc( sizeof(tiny_t, N) ); /* extension to sizeof() that rounds up */ > > tiny_t *ptr = &array[1]; /* OK */ > sizeof(ptr) <= sizeof(void *); /* may not hold, for efficiency reasons, > because you'll need an extra 3 bits in a tiny_t pointer. On 64 bit > machine's you can insert them above the real memory, but on 32 bitters > with 4GB of RAM, it won't work, and we can't reduce the efficiency > of such functions as memcpy just to support bit types */ That's not certain to hold in any case, void * would have to be able to round trip pointers to tiny_t whatever the relative sizes. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-25 09:48 -0700 |
| Message-ID | <100e7b60-196b-40b0-9e6b-7145a9d978da@googlegroups.com> |
| In reply to | #66336 |
On Saturday, July 25, 2015 at 5:39:56 PM UTC+1, Martin Shobe wrote: > On 7/25/2015 4:22 AM, Malcolm McLean wrote: > > > That's not certain to hold in any case, void * would have to be able to > round trip pointers to tiny_t whatever the relative sizes. > That requirement means no-one will implement narrow byte types on small computers, which is where they are needed. A 64 bitter can store three extra bits in the pointer, but, unless you are working on some massive dataset, you're unlikely to need to be miserly with memory when you've got gigabytes plugged in.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-07-25 14:04 -0500 |
| Message-ID | <mp0mgv$stn$1@dont-email.me> |
| In reply to | #66338 |
On 7/25/2015 11:48 AM, Malcolm McLean wrote: > On Saturday, July 25, 2015 at 5:39:56 PM UTC+1, Martin Shobe wrote: >> On 7/25/2015 4:22 AM, Malcolm McLean wrote: >> >> >> That's not certain to hold in any case, void * would have to be able to >> round trip pointers to tiny_t whatever the relative sizes. >> > That requirement means no-one will implement narrow byte types > on small computers, which is where they are needed. A 64 bitter > can store three extra bits in the pointer, but, unless you are > working on some massive dataset, you're unlikely to need to be > miserly with memory when you've got gigabytes plugged in. The question isn't whether or not anyone will ever implement it. The question is whether or not it can be done while still conforming. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-25 14:22 -0700 |
| Message-ID | <897b32d0-6e75-416e-921b-4260cac34dfe@googlegroups.com> |
| In reply to | #66349 |
On Saturday, July 25, 2015 at 8:04:39 PM UTC+1, Martin Shobe wrote: > On 7/25/2015 11:48 AM, Malcolm McLean wrote: > > On Saturday, July 25, 2015 at 5:39:56 PM UTC+1, Martin Shobe wrote: > >> On 7/25/2015 4:22 AM, Malcolm McLean wrote: > >> > >> > >> That's not certain to hold in any case, void * would have to be able to > >> round trip pointers to tiny_t whatever the relative sizes. > >> > > That requirement means no-one will implement narrow byte types > > on small computers, which is where they are needed. A 64 bitter > > can store three extra bits in the pointer, but, unless you are > > working on some massive dataset, you're unlikely to need to be > > miserly with memory when you've got gigabytes plugged in. > > The question isn't whether or not anyone will ever implement it. The > question is whether or not it can be done while still conforming. > You an easily enough add another 3 bits to 32 bit void *s. But better add another 32 bits to avoid alignment problems. Which is a high price to pay for a feature that will only be used in a small amount of admittedly very processor-intensive work. Then whilst you'll support conforming C code, you'll break everything that assumes sizeof(void *) == sizeof(typex *), which is probably quite a bit of real code out there.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-07-25 11:07 -0400 |
| Message-ID | <%CNsx.310016$Pb6.253583@fx04.iad> |
| In reply to | #66324 |
On 7/24/15 11:13 PM, Martin Shobe wrote: > On 7/24/2015 7:03 PM, Richard Damon wrote: >> On 7/24/15 12:49 PM, Tim Rentsch wrote: >> >>> That's true, but the Standard also allows extensions. If types >>> narrower than CHAR_BIT bits were provided as an extension, >>> doesn't it seem reasonable to also extend sizeof to give a >>> non-integral value for those types (not to be confused with >>> 'extended integer types', which has a specific meaning)? I don't >>> see any reason why there couldn't be such an extension, provided >>> of course the usual condition about strictly conforming programs >>> holds. >>> >> >> Extension should not change the defined behavior of things and MUST NOT >> change the behavior of a strictly conforming program. >> >> Let us assume that we have this strange size_t that can express >> fractions of at least 1/2 (0.5), and the type with that size is tiny_t >> >> I presume you intend that 2*sizeof(tiny_t) == sizeof(char) and that >> sizeof(tiny_t) == sizeof(char)/2 > > I don't think sizeof(tiny_t) would equal sizeof(char)/2. The first would > need to hold to make it a useful extension. > > [snip] > > Martin Shobe > It would be a very strange type of math where x * 2 / 2 != x (assuming no overflow).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-25 12:43 -0400 |
| Message-ID | <55B3BCA6.20408@verizon.net> |
| In reply to | #66334 |
On 07/25/2015 11:07 AM, Richard Damon wrote: > On 7/24/15 11:13 PM, Martin Shobe wrote: >> On 7/24/2015 7:03 PM, Richard Damon wrote: >>> On 7/24/15 12:49 PM, Tim Rentsch wrote: >>> >>>> That's true, but the Standard also allows extensions. If types >>>> narrower than CHAR_BIT bits were provided as an extension, >>>> doesn't it seem reasonable to also extend sizeof to give a >>>> non-integral value for those types (not to be confused with >>>> 'extended integer types', which has a specific meaning)? I don't >>>> see any reason why there couldn't be such an extension, provided >>>> of course the usual condition about strictly conforming programs >>>> holds. >>>> >>> >>> Extension should not change the defined behavior of things and MUST NOT >>> change the behavior of a strictly conforming program. >>> >>> Let us assume that we have this strange size_t that can express >>> fractions of at least 1/2 (0.5), and the type with that size is tiny_t >>> >>> I presume you intend that 2*sizeof(tiny_t) == sizeof(char) and that >>> sizeof(tiny_t) == sizeof(char)/2 >> >> I don't think sizeof(tiny_t) would equal sizeof(char)/2. The first would >> need to hold to make it a useful extension. >> >> [snip] >> >> Martin Shobe >> > > It would be a very strange type of math where x * 2 / 2 != x (assuming > no overflow). The extension, as I understand it, means that the result of a sizeof expression is normally of type size_t, but has some kind of floating point type when applied to types like tiny_t. In that case, sizeof(char)/2 would be evaluated as an integer expression with a value of 0, while the multiplication and both equality comparisons would be evaluated in that floating point type. Therefore, the first would be true, and the second would be false. Such an extension would not be a conforming one if it applied to either a standard type or any type that a standard typedef refers to, because sizeof expressions involving any such type would have values that are testably outside the range permitted for a conforming implementation. It would be OK if the type is __tiny_t, but tine_t is from the name space reserved to the users, and therefore could not be used for such a type. I'll make one exception to that: while all of the standard identifiers related to the size-named typedefs are reserved for all values of N, it is impossible for any fully conforming implementation of C to support [u]intN_t for N<8. Therefore, I can't see that there's any harm in allowing such an extension to apply to those types. I see that the original discussion was about int8_t. Code involving #include <stdint> and sizeof(int8_t) should either fail with a diagnostic because the type isn't supported, or sizeof(int8_t) must be 1 - otherwise it's a non-conforming; labeling it an extension doesn't make a difference - it's a non-conforming extension.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-07-25 13:32 -0400 |
| Message-ID | <kKPsx.135439$gG6.86658@fx31.iad> |
| In reply to | #66337 |
On 7/25/15 12:43 PM, James Kuyper wrote: > On 07/25/2015 11:07 AM, Richard Damon wrote: >> On 7/24/15 11:13 PM, Martin Shobe wrote: >>> On 7/24/2015 7:03 PM, Richard Damon wrote: >>>> On 7/24/15 12:49 PM, Tim Rentsch wrote: >>>> >>>>> That's true, but the Standard also allows extensions. If types >>>>> narrower than CHAR_BIT bits were provided as an extension, >>>>> doesn't it seem reasonable to also extend sizeof to give a >>>>> non-integral value for those types (not to be confused with >>>>> 'extended integer types', which has a specific meaning)? I don't >>>>> see any reason why there couldn't be such an extension, provided >>>>> of course the usual condition about strictly conforming programs >>>>> holds. >>>>> >>>> >>>> Extension should not change the defined behavior of things and MUST NOT >>>> change the behavior of a strictly conforming program. >>>> >>>> Let us assume that we have this strange size_t that can express >>>> fractions of at least 1/2 (0.5), and the type with that size is tiny_t >>>> >>>> I presume you intend that 2*sizeof(tiny_t) == sizeof(char) and that >>>> sizeof(tiny_t) == sizeof(char)/2 >>> >>> I don't think sizeof(tiny_t) would equal sizeof(char)/2. The first would >>> need to hold to make it a useful extension. >>> >>> [snip] >>> >>> Martin Shobe >>> >> >> It would be a very strange type of math where x * 2 / 2 != x (assuming >> no overflow). > > The extension, as I understand it, means that the result of a sizeof > expression is normally of type size_t, but has some kind of floating > point type when applied to types like tiny_t. In that case, > sizeof(char)/2 would be evaluated as an integer expression with a value > of 0, while the multiplication and both equality comparisons would be > evaluated in that floating point type. Therefore, the first would be > true, and the second would be false. > Not quite, the extension described having size_t being some form of extended type that supported some fractional values as an 'extension' to the standard. That doesn't work. If sizeof(tiny_t) doesn't return a size_t but some other type (the idea here isn't a 'floating point' type, but more likely a scaled type with a fixed and limited fraction) it might be possible to work out rules to make it a conforming extension, but I am not so sure. There likely will be some surprises. Some questions, will void* be able to hold a tiny_t* (and round trip a value), or do we need another extension to create an extended equivalent of void with the extra information needed? I suppose also that converting this extended size_t to a size_t (for example to call malloc) will round any fractions up, I would need to think about this longer to make sure that there aren't other situations where you really want it to round down! One case where you would need to be very careful is using things like memset on an array of tiny_t, especially if we want to clear an odd number of elements, it won't work right. Creating such a type for a machine that had some significant support for a type smaller than char might make great sense. The key is that it should be clear that it IS an extension (and maybe even need to use a different operator than sizeof, maybe __sizeof or __sizeof_nybble so it is clear it is doing something different) and definitely not for a type like uint8_t when CHAR_BIT > 8.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-25 20:14 +0000 |
| Message-ID | <mp0qn7$l63$1@speranza.aioe.org> |
| In reply to | #66346 |
Richard Damon <Richard@damon-family.org> wrote: > On 7/25/15 12:43 PM, James Kuyper wrote: (snip on extension for types smaller than char) >> The extension, as I understand it, means that the result of a sizeof >> expression is normally of type size_t, but has some kind of floating >> point type when applied to types like tiny_t. In that case, >> sizeof(char)/2 would be evaluated as an integer expression with a value >> of 0, while the multiplication and both equality comparisons would be >> evaluated in that floating point type. Therefore, the first would be >> true, and the second would be false. > Not quite, the extension described having size_t being some form of > extended type that supported some fractional values as an 'extension' to > the standard. That doesn't work. > If sizeof(tiny_t) doesn't return a size_t but some other type (the idea > here isn't a 'floating point' type, but more likely a scaled type with a > fixed and limited fraction) it might be possible to work out rules to > make it a conforming extension, but I am not so sure. Seems to me another choice is a new operator like sizeof, but different. This problem will become more common if systems move to a 16 bit unicode char, but want to keep an 8 bit type. (snip) -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-25 17:24 -0400 |
| Message-ID | <55B3FE86.5060506@verizon.net> |
| In reply to | #66353 |
On 07/25/2015 04:14 PM, glen herrmannsfeldt wrote: ... > This problem will become more common if systems move to a 16 bit > unicode char, but want to keep an 8 bit type. Why not just use char16_t (new in C2011) for 16-bit unicode, and leave char unchanged? I mean - that's what char16_t is FOR. If you didn't want to have any 8-bit type, I could understand making char a 16-bit type, with char16_t a typedef for 'unsigned char'. However, if you want to keep an 8-bit type, why not call it 'char'?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-25 14:42 -0700 |
| Message-ID | <5724aa2f-aa8b-4f42-a693-7e340fd76585@googlegroups.com> |
| In reply to | #66360 |
On Saturday, July 25, 2015 at 10:24:31 PM UTC+1, James Kuyper wrote: > On 07/25/2015 04:14 PM, glen herrmannsfeldt wrote: > ... > > This problem will become more common if systems move to a 16 bit > > unicode char, but want to keep an 8 bit type. > > Why not just use char16_t (new in C2011) for 16-bit unicode, and leave > char unchanged? I mean - that's what char16_t is FOR. If you didn't want > to have any 8-bit type, I could understand making char a 16-bit type, > with char16_t a typedef for 'unsigned char'. However, if you want to > keep an 8-bit type, why not call it 'char'? > char ought to be able to hold a character. The problem with conventions such as using size_t for an index variable or char for a byte (but not character data) is that whilst they make sense to those who have grown up with C, they act as a barrier to new people coming in. Then whilst 16 bit chars did seem the obvious solution to internationalisation, experience has shown that it causes endless problems. Windows programs are always breaking, just because the compiler can't decide whether strings are 16 bit or 8 bit, and because some of the window creation functions take a largely useless string parameter. I've currently got to use a GUI library that mixed and matches WCHARs, uint16_t s, and its own internal wide character type, leading to a welter of incompatible but essentially equivalent string functions. UTF-8 works, and most string handling functions aren't expected to read English or match up characters to glyphs, so the vast majority of code can be unicode naive.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-25 23:02 +0000 |
| Message-ID | <mp14hk$9ld$1@speranza.aioe.org> |
| In reply to | #66360 |
James Kuyper <jameskuyper@verizon.net> wrote: (snip, I wrote) >> This problem will become more common if systems move to a 16 bit >> unicode char, but want to keep an 8 bit type. > Why not just use char16_t (new in C2011) for 16-bit unicode, and leave > char unchanged? I mean - that's what char16_t is FOR. If you didn't want > to have any 8-bit type, I could understand making char a 16-bit type, > with char16_t a typedef for 'unsigned char'. However, if you want to > keep an 8-bit type, why not call it 'char'? We have names for many prejudices, but maybe not yet one for people who think 8 bits will always be enough. OK, how about bitism. Consider a host system that only allow for 16 bit character data. Yes you can keep char as the eight bit data type, but you get stuck very quickly. It would be much nicer to have 16 bit char, and 8 bit uint8_t, if all character data used 16 bits. -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-25 19:17 -0400 |
| Message-ID | <55B41918.2030101@verizon.net> |
| In reply to | #66372 |
On 07/25/2015 07:02 PM, glen herrmannsfeldt wrote: > James Kuyper <jameskuyper@verizon.net> wrote: > > (snip, I wrote) >>> This problem will become more common if systems move to a 16 bit >>> unicode char, but want to keep an 8 bit type. > >> Why not just use char16_t (new in C2011) for 16-bit unicode, and leave >> char unchanged? I mean - that's what char16_t is FOR. If you didn't want >> to have any 8-bit type, I could understand making char a 16-bit type, >> with char16_t a typedef for 'unsigned char'. However, if you want to >> keep an 8-bit type, why not call it 'char'? > > We have names for many prejudices, but maybe not yet one for > people who think 8 bits will always be enough. > > OK, how about bitism. Luckily, that has nothing to do with what I was talking about. You were th one who wants "to keep an 8-bit type", so if any bitism is involved, you're the source, not me. All I'm asking is, if you intend to support an 8-bit type anyway, why shouldn't it be named [[un]signed] char? I think that would minimize the associated problems, which would otherwise be quite substantial. If you wanted to do away with types smaller than 16 bits entirely, then making char a 16 bit type is not merely a good idea, but in fact mandatory. Ordinary character strings could use UCS-2, while multibyte strings could use UTF-16. char16_t would be a typedef for unsigned char. Whether wchar_t would be a synonym for char16_t or char32_t would your choice, but there doesn't seem to be any other reasonable options if you're looking for Unicode encodings.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-25 16:37 -0700 |
| Message-ID | <a1806e9e-643c-4350-9039-64acfec236c5@googlegroups.com> |
| In reply to | #66374 |
On Sunday, July 26, 2015 at 12:17:55 AM UTC+1, James Kuyper wrote: > > If you wanted to do away with types smaller than 16 bits entirely, then > making char a 16 bit type is not merely a good idea, but in fact > mandatory. Ordinary character strings could use UCS-2, while multibyte > strings could use UTF-16. char16_t would be a typedef for unsigned char. > Whether wchar_t would be a synonym for char16_t or char32_t would your > choice, but there doesn't seem to be any other reasonable options if > you're looking for Unicode encodings. > Then everything breaks. Much better to use UTF-8 and waste 8 bits of space per character for every string. A modern computer can store the entire text of the Encyclopaedia Britannica in shorts without really making much impact on memory, so unless you really have a lot of string data, the compatibility issue will be far for serious than memory conservation.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-26 06:10 +0000 |
| Message-ID | <mp1tld$h7v$1@speranza.aioe.org> |
| In reply to | #66374 |
James Kuyper <jameskuyper@verizon.net> wrote: (snip, someone wrote) >>> Why not just use char16_t (new in C2011) for 16-bit unicode, and leave >>> char unchanged? I mean - that's what char16_t is FOR. If you didn't want >>> to have any 8-bit type, I could understand making char a 16-bit type, >>> with char16_t a typedef for 'unsigned char'. However, if you want to >>> keep an 8-bit type, why not call it 'char'? >> We have names for many prejudices, but maybe not yet one for >> people who think 8 bits will always be enough. >> OK, how about bitism. > Luckily, that has nothing to do with what I was talking about. You were > th one who wants "to keep an 8-bit type", so if any bitism is involved, > you're the source, not me. All I'm asking is, if you intend to support > an 8-bit type anyway, why shouldn't it be named [[un]signed] char? I > think that would minimize the associated problems, which would otherwise > be quite substantial. Maybe charbitism? Separate from character processing, there are many uses for an eight bit type. Processing image data using eight bits per pixel, or eight bits per R, G, or B, per pixel. That should be completely orthogonal to the bits per character. Do note that Java does just find with a 16 bit unsigned char, and signed 8, 16, 32, and 64 bit integer types. > If you wanted to do away with types smaller than 16 bits entirely, then > making char a 16 bit type is not merely a good idea, but in fact > mandatory. Ordinary character strings could use UCS-2, while multibyte > strings could use UTF-16. char16_t would be a typedef for unsigned char. > Whether wchar_t would be a synonym for char16_t or char32_t would your > choice, but there doesn't seem to be any other reasonable options if > you're looking for Unicode encodings. -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-26 08:31 -0400 |
| Message-ID | <mp2jsn$8o0$1@dont-email.me> |
| In reply to | #66396 |
On 07/26/2015 02:10 AM, glen herrmannsfeldt wrote: > James Kuyper <jameskuyper@verizon.net> wrote: > > (snip, someone wrote) >>>> Why not just use char16_t (new in C2011) for 16-bit unicode, and leave >>>> char unchanged? I mean - that's what char16_t is FOR. If you didn't want >>>> to have any 8-bit type, I could understand making char a 16-bit type, >>>> with char16_t a typedef for 'unsigned char'. However, if you want to >>>> keep an 8-bit type, why not call it 'char'? > >>> We have names for many prejudices, but maybe not yet one for >>> people who think 8 bits will always be enough. > >>> OK, how about bitism. > >> Luckily, that has nothing to do with what I was talking about. You were >> th one who wants "to keep an 8-bit type", so if any bitism is involved, >> you're the source, not me. All I'm asking is, if you intend to support >> an 8-bit type anyway, why shouldn't it be named [[un]signed] char? I >> think that would minimize the associated problems, which would otherwise >> be quite substantial. > > Maybe charbitism? > > Separate from character processing, there are many uses for > an eight bit type. Processing image data using eight bits per > pixel, or eight bits per R, G, or B, per pixel. That should > be completely orthogonal to the bits per character. > > Do note that Java does just find with a 16 bit unsigned char, > and signed 8, 16, 32, and 64 bit integer types. But we're talking about C here, with a long-standing requirement that sizeof(char)==1, and that the value of a sizeof expression has an unsigned integer type. You're talking about making a radical change to very basic properties of the language just you can use char rather than wchar_t or char16_t for your 16-bit character type. That's asking for trouble, and I'm sure that's what you'd get. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web