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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-07 23:49 +0200 |
| Message-ID | <ml2e69$e8i$1@dont-email.me> |
| In reply to | #63049 |
On 07/06/15 23:17, Richard Heathfield wrote: > On 07/06/15 22:05, David Brown wrote: > > <snip> > >> * I believe there may be a theoretical opening in the standards for an >> architecture that has CHAR_BIT not equal to 8 and yet still has a >> uint8_t type. But I am certain that I will never be using such a system. > > CHAR_BIT is guaranteed to be *at least* 8. If it is not 8, it must be > greater than 8. > > The sizeof operator yields a size_t, which is the size (in bytes) of its > operand, and size_t has an unsigned integer type, which means that it > cannot represent fractional sizes. > > Since int8_t denotes a signed integer type with *exactly* 8 bits (see > 7.20.1.1(1), which makes this crystal clear), on a system with CHAR_BIT > greater than 8, it would have to have a fractional size. > > Since the sizeof operator is both (a) required to yield the size in > bytes of its operand, and (b) unable to yield the size of an int8_t on a > system with CHAR_BIT > 8, we have a contradiction. I deduce that such an > implementation would not be conforming. > That all makes sense - but the C standards have this nasty tendency to have weird loopholes hidden in them. Just because neither you nor I see a loophole here, doesn't mean there isn't one somewhere. But it certainly reduces the likelihood of a malicious ABI designer making a target with uint8_t but CHAR_BIT != 8. It is certainly possible for int8_t to exist but not be "signed char" (by using an extended signed integer type with 8 bits) - perhaps that's why I thought that there might be a loophole here too.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-07 23:37 +0100 |
| Message-ID | <ml2h0v$qb1$1@dont-email.me> |
| In reply to | #63051 |
On 07/06/15 22:49, David Brown wrote: > On 07/06/15 23:17, Richard Heathfield wrote: <snip> >> >> Since the sizeof operator is both (a) required to yield the size in >> bytes of its operand, and (b) unable to yield the size of an int8_t on a >> system with CHAR_BIT > 8, we have a contradiction. I deduce that such an >> implementation would not be conforming. >> > > That all makes sense - but the C standards have this nasty tendency to > have weird loopholes hidden in them. Just because neither you nor I see > a loophole here, doesn't mean there isn't one somewhere. In this case, it does mean precisely that. If a loophole /did/ exist, it would mean that the Standard is inconsistent, in which case you could raise a DR against it. > But it > certainly reduces the likelihood of a malicious ABI designer making a > target with uint8_t but CHAR_BIT != 8. The likelihood is reduced to 0, if the implementation is conforming. > It is certainly possible for int8_t to exist but not be "signed char" > (by using an extended signed integer type with 8 bits) - Only if CHAR_BIT == 8. > perhaps that's > why I thought that there might be a loophole here too. I can't speak for why you think things. :-) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-11 08:25 -0700 |
| Message-ID | <kfnzj32yavd.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #63052 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 07/06/15 22:49, David Brown wrote: >> On 07/06/15 23:17, Richard Heathfield wrote: > > <snip> > >>> Since the sizeof operator is both (a) required to yield the size in >>> bytes of its operand, and (b) unable to yield the size of an int8_t on a >>> system with CHAR_BIT > 8, we have a contradiction. I deduce that such an >>> implementation would not be conforming. >> >> That all makes sense - but the C standards have this nasty tendency to >> have weird loopholes hidden in them. Just because neither you nor I see >> a loophole here, doesn't mean there isn't one somewhere. > > In this case, it does mean precisely that. If a loophole /did/ exist, > it would mean that the Standard is inconsistent, in which case you > could raise a DR against it. That is assuming your earlier argument is valid, which as I explained I believe it is not.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-11 08:21 -0700 |
| Message-ID | <kfn4mlazpn0.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #63049 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 07/06/15 22:05, David Brown wrote: > > <snip> > >> * I believe there may be a theoretical opening in the standards for an >> architecture that has CHAR_BIT not equal to 8 and yet still has a >> uint8_t type. But I am certain that I will never be using such a system. > > CHAR_BIT is guaranteed to be *at least* 8. If it is not 8, it must be > greater than 8. > > The sizeof operator yields a size_t, which is the size (in bytes) of > its operand, and size_t has an unsigned integer type, which means that > it cannot represent fractional sizes. > > Since int8_t denotes a signed integer type with *exactly* 8 bits (see > 7.20.1.1(1), which makes this crystal clear), on a system with > CHAR_BIT greater than 8, it would have to have a fractional size. > > Since the sizeof operator is both (a) required to yield the size in > bytes of its operand, and (b) unable to yield the size of an int8_t on > a system with CHAR_BIT > 8, we have a contradiction. I deduce that > such an implementation would not be conforming. The flaw in your argument is the assertion that integer types cannot reprepresent fractional values. It is of course possible for integer types to represent fractional values, floating-point values, irrational values, transcendental values, or almost any other kind of values you can think of, by using padding bits and trap representations. It is possible to have a conforming implementation with CHAR_BIT > 8 but still having a type that occupies only eight bits. AFAIK there is no reason such an implementation could not use that type to provide the [u]int8_t types.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-07-11 13:54 -0500 |
| Message-ID | <mnrona$m3o$1@dont-email.me> |
| In reply to | #65288 |
On 7/11/2015 10:21 AM, Tim Rentsch wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> On 07/06/15 22:05, David Brown wrote: >> >> <snip> >> >>> * I believe there may be a theoretical opening in the standards for an >>> architecture that has CHAR_BIT not equal to 8 and yet still has a >>> uint8_t type. But I am certain that I will never be using such a system. >> >> CHAR_BIT is guaranteed to be *at least* 8. If it is not 8, it must be >> greater than 8. >> >> The sizeof operator yields a size_t, which is the size (in bytes) of >> its operand, and size_t has an unsigned integer type, which means that >> it cannot represent fractional sizes. >> >> Since int8_t denotes a signed integer type with *exactly* 8 bits (see >> 7.20.1.1(1), which makes this crystal clear), on a system with >> CHAR_BIT greater than 8, it would have to have a fractional size. >> >> Since the sizeof operator is both (a) required to yield the size in >> bytes of its operand, and (b) unable to yield the size of an int8_t on >> a system with CHAR_BIT > 8, we have a contradiction. I deduce that >> such an implementation would not be conforming. > > The flaw in your argument is the assertion that integer types > cannot reprepresent fractional values. It is of course possible > for integer types to represent fractional values, floating-point > values, irrational values, transcendental values, or almost any > other kind of values you can think of, by using padding bits and > trap representations. > > It is possible to have a conforming implementation with > CHAR_BIT > 8 but still having a type that occupies only eight > bits. AFAIK there is no reason such an implementation > could not use that type to provide the [u]int8_t types. I suppose we could if we ignored the requirement that they have no padding bits. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-20 06:33 -0700 |
| Message-ID | <kfnk2tvosvz.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65325 |
Martin Shobe <martin.shobe@yahoo.com> writes: > On 7/11/2015 10:21 AM, Tim Rentsch wrote: >> Richard Heathfield <rjh@cpax.org.uk> writes: >> >>> On 07/06/15 22:05, David Brown wrote: >>> >>> <snip> >>> >>>> * I believe there may be a theoretical opening in the standards for an >>>> architecture that has CHAR_BIT not equal to 8 and yet still has a >>>> uint8_t type. But I am certain that I will never be using such a system. >>> >>> CHAR_BIT is guaranteed to be *at least* 8. If it is not 8, it must be >>> greater than 8. >>> >>> The sizeof operator yields a size_t, which is the size (in bytes) of >>> its operand, and size_t has an unsigned integer type, which means that >>> it cannot represent fractional sizes. >>> >>> Since int8_t denotes a signed integer type with *exactly* 8 bits (see >>> 7.20.1.1(1), which makes this crystal clear), on a system with >>> CHAR_BIT greater than 8, it would have to have a fractional size. >>> >>> Since the sizeof operator is both (a) required to yield the size in >>> bytes of its operand, and (b) unable to yield the size of an int8_t on >>> a system with CHAR_BIT > 8, we have a contradiction. I deduce that >>> such an implementation would not be conforming. >> >> The flaw in your argument is the assertion that integer types >> cannot reprepresent fractional values. It is of course possible >> for integer types to represent fractional values, floating-point >> values, irrational values, transcendental values, or almost any >> other kind of values you can think of, by using padding bits and >> trap representations. >> >> It is possible to have a conforming implementation with >> CHAR_BIT > 8 but still having a type that occupies only eight >> bits. AFAIK there is no reason such an implementation >> could not use that type to provide the [u]int8_t types. > > I suppose we could if we ignored the requirement that they have no > padding bits. I think you missed the key point of my comment - sorry that wasn't expressed more clearly. The point of size_t being able to have fractional values is to be able to support units of memory that are less than a full character in width. The type referred to above occupies only eight bits, ie, only half a character if CHAR_BIT is 16, and so would have no padding bits for [u]int8_t types.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-07-20 09:51 -0500 |
| Message-ID | <moj1qt$1ae$1@dont-email.me> |
| In reply to | #65981 |
On 7/20/2015 8:33 AM, Tim Rentsch wrote: > Martin Shobe <martin.shobe@yahoo.com> writes: > >> On 7/11/2015 10:21 AM, Tim Rentsch wrote: >>> Richard Heathfield <rjh@cpax.org.uk> writes: >>> >>>> On 07/06/15 22:05, David Brown wrote: >>>> >>>> <snip> >>>> >>>>> * I believe there may be a theoretical opening in the standards for an >>>>> architecture that has CHAR_BIT not equal to 8 and yet still has a >>>>> uint8_t type. But I am certain that I will never be using such a system. >>>> >>>> CHAR_BIT is guaranteed to be *at least* 8. If it is not 8, it must be >>>> greater than 8. >>>> >>>> The sizeof operator yields a size_t, which is the size (in bytes) of >>>> its operand, and size_t has an unsigned integer type, which means that >>>> it cannot represent fractional sizes. >>>> >>>> Since int8_t denotes a signed integer type with *exactly* 8 bits (see >>>> 7.20.1.1(1), which makes this crystal clear), on a system with >>>> CHAR_BIT greater than 8, it would have to have a fractional size. >>>> >>>> Since the sizeof operator is both (a) required to yield the size in >>>> bytes of its operand, and (b) unable to yield the size of an int8_t on >>>> a system with CHAR_BIT > 8, we have a contradiction. I deduce that >>>> such an implementation would not be conforming. >>> >>> The flaw in your argument is the assertion that integer types >>> cannot reprepresent fractional values. It is of course possible >>> for integer types to represent fractional values, floating-point >>> values, irrational values, transcendental values, or almost any >>> other kind of values you can think of, by using padding bits and >>> trap representations. >>> >>> It is possible to have a conforming implementation with >>> CHAR_BIT > 8 but still having a type that occupies only eight >>> bits. AFAIK there is no reason such an implementation >>> could not use that type to provide the [u]int8_t types. >> >> I suppose we could if we ignored the requirement that they have no >> padding bits. > > I think you missed the key point of my comment - sorry that > wasn't expressed more clearly. The point of size_t being able > to have fractional values is to be able to support units of > memory that are less than a full character in width. The type > referred to above occupies only eight bits, ie, only half a > character if CHAR_BIT is 16, and so would have no padding bits > for [u]int8_t types. > Yes, I did miss that you were talking about padding bits in size_t. Sorry. However, 6.5.3.4p2 (in n1570) says that the result of the sizeof operator is an integer. I think that would deal with your objection. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-24 09:49 -0700 |
| Message-ID | <kfnr3nxh564.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65996 |
Martin Shobe <martin.shobe@yahoo.com> writes: > On 7/20/2015 8:33 AM, Tim Rentsch wrote: >> Martin Shobe <martin.shobe@yahoo.com> writes: >> >>> On 7/11/2015 10:21 AM, Tim Rentsch wrote: >>>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>> >>>>> On 07/06/15 22:05, David Brown wrote: >>>>> >>>>> <snip> >>>>> >>>>>> * I believe there may be a theoretical opening in the standards >>>>>> for an architecture that has CHAR_BIT not equal to 8 and yet >>>>>> still has a uint8_t type. But I am certain that I will never >>>>>> be using such a system. >>>>> >>>>> CHAR_BIT is guaranteed to be *at least* 8. If it is not 8, it >>>>> must be greater than 8. >>>>> >>>>> The sizeof operator yields a size_t, which is the size (in >>>>> bytes) of its operand, and size_t has an unsigned integer type, >>>>> which means that it cannot represent fractional sizes. >>>>> >>>>> Since int8_t denotes a signed integer type with *exactly* 8 bits >>>>> (see 7.20.1.1(1), which makes this crystal clear), on a system >>>>> with CHAR_BIT greater than 8, it would have to have a fractional >>>>> size. >>>>> >>>>> Since the sizeof operator is both (a) required to yield the size >>>>> in bytes of its operand, and (b) unable to yield the size of an >>>>> int8_t on a system with CHAR_BIT > 8, we have a contradiction. >>>>> I deduce that such an implementation would not be conforming. >>>> >>>> The flaw in your argument is the assertion that integer types >>>> cannot reprepresent fractional values. It is of course possible >>>> for integer types to represent fractional values, floating-point >>>> values, irrational values, transcendental values, or almost any >>>> other kind of values you can think of, by using padding bits and >>>> trap representations. >>>> >>>> It is possible to have a conforming implementation with >>>> CHAR_BIT > 8 but still having a type that occupies only eight >>>> bits. AFAIK there is no reason such an implementation could >>>> not use that type to provide the [u]int8_t types. >>> >>> I suppose we could if we ignored the requirement that they have >>> no padding bits. >> >> I think you missed the key point of my comment - sorry that >> wasn't expressed more clearly. The point of size_t being able >> to have fractional values is to be able to support units of >> memory that are less than a full character in width. The type >> referred to above occupies only eight bits, ie, only half a >> character if CHAR_BIT is 16, and so would have no padding bits >> for [u]int8_t types. > > Yes, I did miss that you were talking about padding bits in > size_t. Sorry. However, 6.5.3.4p2 (in n1570) says that the > result of the sizeof operator is an integer. I think that would > deal with your objection. 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.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-07-24 12:26 -0500 |
| Message-ID | <motscs$uk3$1@dont-email.me> |
| In reply to | #66287 |
On 7/24/2015 11:49 AM, Tim Rentsch wrote: > Martin Shobe <martin.shobe@yahoo.com> writes: > >> On 7/20/2015 8:33 AM, Tim Rentsch wrote: >>> Martin Shobe <martin.shobe@yahoo.com> writes: >>> >>>> On 7/11/2015 10:21 AM, Tim Rentsch wrote: >>>>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>>> >>>>>> On 07/06/15 22:05, David Brown wrote: >>>>>> >>>>>> <snip> >>>>>> >>>>>>> * I believe there may be a theoretical opening in the standards >>>>>>> for an architecture that has CHAR_BIT not equal to 8 and yet >>>>>>> still has a uint8_t type. But I am certain that I will never >>>>>>> be using such a system. >>>>>> >>>>>> CHAR_BIT is guaranteed to be *at least* 8. If it is not 8, it >>>>>> must be greater than 8. >>>>>> >>>>>> The sizeof operator yields a size_t, which is the size (in >>>>>> bytes) of its operand, and size_t has an unsigned integer type, >>>>>> which means that it cannot represent fractional sizes. >>>>>> >>>>>> Since int8_t denotes a signed integer type with *exactly* 8 bits >>>>>> (see 7.20.1.1(1), which makes this crystal clear), on a system >>>>>> with CHAR_BIT greater than 8, it would have to have a fractional >>>>>> size. >>>>>> >>>>>> Since the sizeof operator is both (a) required to yield the size >>>>>> in bytes of its operand, and (b) unable to yield the size of an >>>>>> int8_t on a system with CHAR_BIT > 8, we have a contradiction. >>>>>> I deduce that such an implementation would not be conforming. >>>>> >>>>> The flaw in your argument is the assertion that integer types >>>>> cannot reprepresent fractional values. It is of course possible >>>>> for integer types to represent fractional values, floating-point >>>>> values, irrational values, transcendental values, or almost any >>>>> other kind of values you can think of, by using padding bits and >>>>> trap representations. >>>>> >>>>> It is possible to have a conforming implementation with >>>>> CHAR_BIT > 8 but still having a type that occupies only eight >>>>> bits. AFAIK there is no reason such an implementation could >>>>> not use that type to provide the [u]int8_t types. >>>> >>>> I suppose we could if we ignored the requirement that they have >>>> no padding bits. >>> >>> I think you missed the key point of my comment - sorry that >>> wasn't expressed more clearly. The point of size_t being able >>> to have fractional values is to be able to support units of >>> memory that are less than a full character in width. The type >>> referred to above occupies only eight bits, ie, only half a >>> character if CHAR_BIT is 16, and so would have no padding bits >>> for [u]int8_t types. >> >> Yes, I did miss that you were talking about padding bits in >> size_t. Sorry. However, 6.5.3.4p2 (in n1570) says that the >> result of the sizeof operator is an integer. I think that would >> deal with your objection. > > 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)? It can't be conforming if it does (except for types that aren't covered by the standard. A conforming uint8_t wouldn't be one of them.) Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-30 11:16 -0700 |
| Message-ID | <kfnzj2dcxzr.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66291 |
Martin Shobe <martin.shobe@yahoo.com> writes: > On 7/24/2015 11:49 AM, Tim Rentsch wrote: >> Martin Shobe <martin.shobe@yahoo.com> writes: >> >>> On 7/20/2015 8:33 AM, Tim Rentsch wrote: >>>> Martin Shobe <martin.shobe@yahoo.com> writes: >>>> >>>>> On 7/11/2015 10:21 AM, Tim Rentsch wrote: >>>>>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>>>> >>>>>>> On 07/06/15 22:05, David Brown wrote: >>>>>>> >>>>>>> <snip> >>>>>>> >>>>>>>> * I believe there may be a theoretical opening in the standards >>>>>>>> for an architecture that has CHAR_BIT not equal to 8 and yet >>>>>>>> still has a uint8_t type. But I am certain that I will never >>>>>>>> be using such a system. >>>>>>> >>>>>>> CHAR_BIT is guaranteed to be *at least* 8. If it is not 8, it >>>>>>> must be greater than 8. >>>>>>> >>>>>>> The sizeof operator yields a size_t, which is the size (in >>>>>>> bytes) of its operand, and size_t has an unsigned integer type, >>>>>>> which means that it cannot represent fractional sizes. >>>>>>> >>>>>>> Since int8_t denotes a signed integer type with *exactly* 8 bits >>>>>>> (see 7.20.1.1(1), which makes this crystal clear), on a system >>>>>>> with CHAR_BIT greater than 8, it would have to have a fractional >>>>>>> size. >>>>>>> >>>>>>> Since the sizeof operator is both (a) required to yield the size >>>>>>> in bytes of its operand, and (b) unable to yield the size of an >>>>>>> int8_t on a system with CHAR_BIT > 8, we have a contradiction. >>>>>>> I deduce that such an implementation would not be conforming. >>>>>> >>>>>> The flaw in your argument is the assertion that integer types >>>>>> cannot reprepresent fractional values. It is of course possible >>>>>> for integer types to represent fractional values, floating-point >>>>>> values, irrational values, transcendental values, or almost any >>>>>> other kind of values you can think of, by using padding bits and >>>>>> trap representations. >>>>>> >>>>>> It is possible to have a conforming implementation with >>>>>> CHAR_BIT > 8 but still having a type that occupies only eight >>>>>> bits. AFAIK there is no reason such an implementation could >>>>>> not use that type to provide the [u]int8_t types. >>>>> >>>>> I suppose we could if we ignored the requirement that they have >>>>> no padding bits. >>>> >>>> I think you missed the key point of my comment - sorry that >>>> wasn't expressed more clearly. The point of size_t being able >>>> to have fractional values is to be able to support units of >>>> memory that are less than a full character in width. The type >>>> referred to above occupies only eight bits, ie, only half a >>>> character if CHAR_BIT is 16, and so would have no padding bits >>>> for [u]int8_t types. >>> >>> Yes, I did miss that you were talking about padding bits in >>> size_t. Sorry. However, 6.5.3.4p2 (in n1570) says that the >>> result of the sizeof operator is an integer. I think that would >>> deal with your objection. >> >> 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)? > > It can't be conforming if it does (except for types that aren't > covered by the standard. A conforming uint8_t wouldn't be one of > them.) Can you cite a passage from the Standard supporting that assertion? The Standard says implementations may have extensions provided they don't alter the behavior of any strictly conforming program. If undersized [u]int8_t types were provided only in cases where the program is not strictly conforming, as for example the '#include <Xstdint.h>' possibility I mentioned in response to Keith Thompson's post, what text in the Standard disallows that? ISTM that a scenario along these lines is explicitly allowed by 4 p6.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-07-30 23:15 -0500 |
| Message-ID | <mpesmd$g3f$1@dont-email.me> |
| In reply to | #66573 |
On 7/30/2015 1:16 PM, Tim Rentsch wrote:
> Martin Shobe <martin.shobe@yahoo.com> writes:
>
>> On 7/24/2015 11:49 AM, Tim Rentsch wrote:
>>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>>
>>>> On 7/20/2015 8:33 AM, Tim Rentsch wrote:
>>>>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>>>>
>>>>>> On 7/11/2015 10:21 AM, Tim Rentsch wrote:
>>>>>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>>>>>
>>>>>>>> On 07/06/15 22:05, David Brown wrote:
>>>>>>>>
>>>>>>>> <snip>
>>>>>>>>
>>>>>>>>> * I believe there may be a theoretical opening in the standards
>>>>>>>>> for an architecture that has CHAR_BIT not equal to 8 and yet
>>>>>>>>> still has a uint8_t type. But I am certain that I will never
>>>>>>>>> be using such a system.
>>>>>>>>
>>>>>>>> CHAR_BIT is guaranteed to be *at least* 8. If it is not 8, it
>>>>>>>> must be greater than 8.
>>>>>>>>
>>>>>>>> The sizeof operator yields a size_t, which is the size (in
>>>>>>>> bytes) of its operand, and size_t has an unsigned integer type,
>>>>>>>> which means that it cannot represent fractional sizes.
>>>>>>>>
>>>>>>>> Since int8_t denotes a signed integer type with *exactly* 8 bits
>>>>>>>> (see 7.20.1.1(1), which makes this crystal clear), on a system
>>>>>>>> with CHAR_BIT greater than 8, it would have to have a fractional
>>>>>>>> size.
>>>>>>>>
>>>>>>>> Since the sizeof operator is both (a) required to yield the size
>>>>>>>> in bytes of its operand, and (b) unable to yield the size of an
>>>>>>>> int8_t on a system with CHAR_BIT > 8, we have a contradiction.
>>>>>>>> I deduce that such an implementation would not be conforming.
>>>>>>>
>>>>>>> The flaw in your argument is the assertion that integer types
>>>>>>> cannot reprepresent fractional values. It is of course possible
>>>>>>> for integer types to represent fractional values, floating-point
>>>>>>> values, irrational values, transcendental values, or almost any
>>>>>>> other kind of values you can think of, by using padding bits and
>>>>>>> trap representations.
>>>>>>>
>>>>>>> It is possible to have a conforming implementation with
>>>>>>> CHAR_BIT > 8 but still having a type that occupies only eight
>>>>>>> bits. AFAIK there is no reason such an implementation could
>>>>>>> not use that type to provide the [u]int8_t types.
>>>>>>
>>>>>> I suppose we could if we ignored the requirement that they have
>>>>>> no padding bits.
>>>>>
>>>>> I think you missed the key point of my comment - sorry that
>>>>> wasn't expressed more clearly. The point of size_t being able
>>>>> to have fractional values is to be able to support units of
>>>>> memory that are less than a full character in width. The type
>>>>> referred to above occupies only eight bits, ie, only half a
>>>>> character if CHAR_BIT is 16, and so would have no padding bits
>>>>> for [u]int8_t types.
>>>>
>>>> Yes, I did miss that you were talking about padding bits in
>>>> size_t. Sorry. However, 6.5.3.4p2 (in n1570) says that the
>>>> result of the sizeof operator is an integer. I think that would
>>>> deal with your objection.
>>>
>>> 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)?
>>
>> It can't be conforming if it does (except for types that aren't
>> covered by the standard. A conforming uint8_t wouldn't be one of
>> them.)
>
> Can you cite a passage from the Standard supporting that
> assertion? The Standard says implementations may have extensions
> provided they don't alter the behavior of any strictly conforming
> program. If undersized [u]int8_t types were provided only in
> cases where the program is not strictly conforming, as for
> example the '#include <Xstdint.h>' possibility I mentioned in
> response to Keith Thompson's post, what text in the Standard
> disallows that? ISTM that a scenario along these lines is
> explicitly allowed by 4 p6.
>
It was my understanding that the goal was to build a standard conforming
[u]int8_t. One of the constraints is that it must appear in <stdint.h>.
Therefore, the following code must compile.
#include <stdint.h>
int main()
{
uint8_t x = 7;
return x - sizeof(uint8_t);
}
The standard says that sizeof() must return an integer. Since
<Xstdint.h> wasn't included, how does it help you get around that
requirement?
Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-02 06:07 -0700 |
| Message-ID | <kfny4htalf6.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66594 |
Martin Shobe <martin.shobe@yahoo.com> writes:
> On 7/30/2015 1:16 PM, Tim Rentsch wrote:
>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>
>>> On 7/24/2015 11:49 AM, Tim Rentsch wrote:
>>>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>>>
>>>>> On 7/20/2015 8:33 AM, Tim Rentsch wrote:
>>>>>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>>>>>
>>>>>>> On 7/11/2015 10:21 AM, Tim Rentsch wrote:
>>>>>>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>>>>>>
>>>>>>>>> On 07/06/15 22:05, David Brown wrote:
>>>>>>>>>
>>>>>>>>> <snip>
>>>>>>>>>
>>>>>>>>>> * I believe there may be a theoretical opening in the standards
>>>>>>>>>> for an architecture that has CHAR_BIT not equal to 8 and yet
>>>>>>>>>> still has a uint8_t type. But I am certain that I will never
>>>>>>>>>> be using such a system.
>>>>>>>>>
>>>>>>>>> CHAR_BIT is guaranteed to be *at least* 8. If it is not 8, it
>>>>>>>>> must be greater than 8.
>>>>>>>>>
>>>>>>>>> The sizeof operator yields a size_t, which is the size (in
>>>>>>>>> bytes) of its operand, and size_t has an unsigned integer type,
>>>>>>>>> which means that it cannot represent fractional sizes.
>>>>>>>>>
>>>>>>>>> Since int8_t denotes a signed integer type with *exactly* 8 bits
>>>>>>>>> (see 7.20.1.1(1), which makes this crystal clear), on a system
>>>>>>>>> with CHAR_BIT greater than 8, it would have to have a fractional
>>>>>>>>> size.
>>>>>>>>>
>>>>>>>>> Since the sizeof operator is both (a) required to yield the size
>>>>>>>>> in bytes of its operand, and (b) unable to yield the size of an
>>>>>>>>> int8_t on a system with CHAR_BIT > 8, we have a contradiction.
>>>>>>>>> I deduce that such an implementation would not be conforming.
>>>>>>>>
>>>>>>>> The flaw in your argument is the assertion that integer types
>>>>>>>> cannot reprepresent fractional values. It is of course possible
>>>>>>>> for integer types to represent fractional values, floating-point
>>>>>>>> values, irrational values, transcendental values, or almost any
>>>>>>>> other kind of values you can think of, by using padding bits and
>>>>>>>> trap representations.
>>>>>>>>
>>>>>>>> It is possible to have a conforming implementation with
>>>>>>>> CHAR_BIT > 8 but still having a type that occupies only eight
>>>>>>>> bits. AFAIK there is no reason such an implementation could
>>>>>>>> not use that type to provide the [u]int8_t types.
>>>>>>>
>>>>>>> I suppose we could if we ignored the requirement that they have
>>>>>>> no padding bits.
>>>>>>
>>>>>> I think you missed the key point of my comment - sorry that
>>>>>> wasn't expressed more clearly. The point of size_t being able
>>>>>> to have fractional values is to be able to support units of
>>>>>> memory that are less than a full character in width. The type
>>>>>> referred to above occupies only eight bits, ie, only half a
>>>>>> character if CHAR_BIT is 16, and so would have no padding bits
>>>>>> for [u]int8_t types.
>>>>>
>>>>> Yes, I did miss that you were talking about padding bits in
>>>>> size_t. Sorry. However, 6.5.3.4p2 (in n1570) says that the
>>>>> result of the sizeof operator is an integer. I think that would
>>>>> deal with your objection.
>>>>
>>>> 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)?
>>>
>>> It can't be conforming if it does (except for types that aren't
>>> covered by the standard. A conforming uint8_t wouldn't be one of
>>> them.)
>>
>> Can you cite a passage from the Standard supporting that
>> assertion? The Standard says implementations may have extensions
>> provided they don't alter the behavior of any strictly conforming
>> program. If undersized [u]int8_t types were provided only in
>> cases where the program is not strictly conforming, as for
>> example the '#include <Xstdint.h>' possibility I mentioned in
>> response to Keith Thompson's post, what text in the Standard
>> disallows that? ISTM that a scenario along these lines is
>> explicitly allowed by 4 p6.
>
> It was my understanding that the goal was to build a standard
> conforming [u]int8_t. One of the constraints is that it must appear in
> <stdint.h>. Therefore, the following code must compile.
>
> #include <stdint.h>
>
> int main()
> {
> uint8_t x = 7;
>
> return x - sizeof(uint8_t);
> }
>
> The standard says that sizeof() must return an integer. Since
> <Xstdint.h> wasn't included, how does it help you get around that
> requirement?
This program is already not strictly conforming. The
implementation could enable the extension on that basis,
or could simply not accept the program. I believe either
choice is conforming.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-08-02 14:31 -0400 |
| Message-ID | <Amtvx.37750$xD4.18914@fx04.iad> |
| In reply to | #66689 |
On 8/2/15 9:07 AM, Tim Rentsch wrote:
> Martin Shobe <martin.shobe@yahoo.com> writes:
>
>> On 7/30/2015 1:16 PM, Tim Rentsch wrote:
>> It was my understanding that the goal was to build a standard
>> conforming [u]int8_t. One of the constraints is that it must appear in
>> <stdint.h>. Therefore, the following code must compile.
>>
>> #include <stdint.h>
>>
>> int main()
>> {
>> uint8_t x = 7;
>>
>> return x - sizeof(uint8_t);
>> }
>>
>> The standard says that sizeof() must return an integer. Since
>> <Xstdint.h> wasn't included, how does it help you get around that
>> requirement?
>
> This program is already not strictly conforming. The
> implementation could enable the extension on that basis,
> or could simply not accept the program. I believe either
> choice is conforming.
>
But the standard makes the existence of uint8_t implementation defined
behavior, so the implementation has a Yes/No answer of whether it is
defined or not. If it is documented as having uint8_t, the standard
provides a definition of the behavior. Not being strictly conforming
does NOT give the implementation the right to not met the requirements
of the standard.
Note, that if the implementation defines that it doesn't implement
uint8_t, then I believe that the symbol uint_t is no longer in the
implementation name space, and is usable by a strictly conforming
program. (Note, strictly conforming only means that the RESULTS of the
program are not dependent on implementation defined behavior, it can use
implementation defined behavior as long as all possible definitions of
that behavior are required to produce the same result, so therefore a
strictly conforming program can test the existence of the macro
UINT8_MAX and if not defined, create its own typedef for the type
(perhaps to unsigned char). As long as nothing in the program actually
makes a difference on the value(s) produced by the program, it is still
strictly conforming.
Thus adding the code:
#ifndef UINT8_MAX
typedef unsigned char uint8_t
#endif
to the above program fixes that issue.
(I would then set x = 1 not 7, as the defined return values of main are
0, EXIT_SUCCESS, EXIT_FAILURE, and the effect of other values is
implementation defined, and thus not strictly conforming).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-09 05:31 -0700 |
| Message-ID | <kfnegjc7idc.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66718 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 8/2/15 9:07 AM, Tim Rentsch wrote:
>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>
>>> On 7/30/2015 1:16 PM, Tim Rentsch wrote:
>>>
>>> It was my understanding that the goal was to build a standard
>>> conforming [u]int8_t. One of the constraints is that it must appear in
>>> <stdint.h>. Therefore, the following code must compile.
>>>
>>> #include <stdint.h>
>>>
>>> int main()
>>> {
>>> uint8_t x = 7;
>>>
>>> return x - sizeof(uint8_t);
>>> }
>>>
>>> The standard says that sizeof() must return an integer. Since
>>> <Xstdint.h> wasn't included, how does it help you get around that
>>> requirement?
>>
>> This program is already not strictly conforming. The
>> implementation could enable the extension on that basis,
>> or could simply not accept the program. I believe either
>> choice is conforming.
>
> But the standard makes the existence of uint8_t implementation
> defined behavior, [snip elaboration]
I believe you are mistaken; there is no such stipulation. The
value UINT8_MAX is implementation-defined, but this macro is
defined if and only if uint8_t is provided, and providing it is
optional depending on the availability of a suitable type.
Moreover there is nothing in the Standard that says the set of
types an implementation provides must be fixed rather than
conditional.
> Note, that if the implementation defines that it doesn't implement
> uint8_t, then I believe that the symbol uint_t is no longer in the
> implementation name space,
The symbol uint8_t is not in the implementation name space.
Whether it is defined is determined by factors under control of
the implementation, but what the symbol means falls within the
purview of the Standard, not an implementation.
> and is usable by a strictly conforming
> program. (Note, strictly conforming only means that the RESULTS
> of the program are not dependent on implementation defined
> behavior, it can use implementation defined behavior as long as
> all possible definitions of that behavior are required to produce
> the same result, so therefore a strictly conforming program can
> test the existence of the macro UINT8_MAX and if not defined,
> create its own typedef for the type (perhaps to unsigned char).
Yes, I agree.
> As long as nothing in the program actually makes a difference on
> the value(s) produced by the program, it is still strictly
> conforming.
>
> Thus adding the code:
>
> #ifndef UINT8_MAX
> typedef unsigned char uint8_t
> #endif
>
> to the above program fixes that issue.
That's a different program. In that program the undersized
types would not be available. Different conditions, different
results.
> (I would then set x = 1 not 7, as the defined return values of
> main are 0, EXIT_SUCCESS, EXIT_FAILURE, and the effect of other
> values is implementation defined, and thus not strictly
> conforming).
Note that the program was written by Martin Shobe, not myself.
In any case it doesn't change the conclusion, the given program
is not strictly conforming no matter what value is used to
initialize x, and an implementation could choose to enable
undersized types on that basis.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-08-09 17:09 -0400 |
| Message-ID | <HkPxx.24150$bC.22991@fx11.iad> |
| In reply to | #67028 |
On 8/9/15 8:31 AM, Tim Rentsch wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> >> But the standard makes the existence of uint8_t implementation >> defined behavior, [snip elaboration] > > I believe you are mistaken; there is no such stipulation. The > value UINT8_MAX is implementation-defined, but this macro is > defined if and only if uint8_t is provided, and providing it is > optional depending on the availability of a suitable type. > Moreover there is nothing in the Standard that says the set of > types an implementation provides must be fixed rather than > conditional. 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). > >> Note, that if the implementation defines that it doesn't implement >> uint8_t, then I believe that the symbol uint_t is no longer in the >> implementation name space, > > The symbol uint8_t is not in the implementation name space. > Whether it is defined is determined by factors under control of > the implementation, but what the symbol means falls within the > purview of the Standard, not an implementation. > I suppose that depends on what you consider to be the implementation name space, I consider symbols that the implementation is given control over when a given header is included, to be in the implementation name space if that header is included (since the user is NOT allowed to mess with these symbols except in very limited conditions if the header is included). [snip] > Note that the program was written by Martin Shobe, not myself. > In any case it doesn't change the conclusion, the given program > is not strictly conforming no matter what value is used to > initialize x, and an implementation could choose to enable > undersized types on that basis. > Not being strictly conforming in NOT good enough. To change defined behavior you need the presence of undefined behavior. (see 4p3)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-05 09:58 -0700 |
| Message-ID | <kfn8u8kyf9t.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #67045 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 8/9/15 8:31 AM, Tim Rentsch wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> But the standard makes the existence of uint8_t implementation
>>> defined behavior, [snip elaboration]
>>
>> I believe you are mistaken; there is no such stipulation. The
>> value UINT8_MAX is implementation-defined, but this macro is
>> defined if and only if uint8_t is provided, and providing it is
>> optional depending on the availability of a suitable type.
>> Moreover there is nothing in the Standard that says the set of
>> types an implementation provides must be fixed rather than
>> conditional.
>
> 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.
>>> Note, that if the implementation defines that it doesn't implement
>>> uint8_t, then I believe that the symbol uint_t is no longer in the
>>> implementation name space,
>>
>> The symbol uint8_t is not in the implementation name space.
>> Whether it is defined is determined by factors under control of
>> the implementation, but what the symbol means falls within the
>> purview of the Standard, not an implementation.
>
> I suppose that depends on what you consider to be the implementation
> name space, I consider symbols that the implementation is given
> control over when a given header is included, to be in the
> implementation name space if that header is included (since the user
> is NOT allowed to mess with these symbols except in very limited
> conditions if the header is included).
If the particular name in question is chosen by the Standard then
to me it makes more sense to say the name belongs to the Standard,
not the implementation. The name size_t, for example, is set by
the Standard, not the implementation; it sounds funny to say size_t
is "in the implementation name space," since the implementation has no
say in the matter. In any case I'm not sure the distinction is of
any consequence here (although I do think the distinction is one
worth making for other reasons).
Getting back to the main point, I believe the name uint8_t is
/always/ in the (Standard or implementation) reserved name space
(assuming #include <stdint.h> has been done), because of 7.1.3p1,
specifically the last item:
Each identifier with file scope listed in any of the
following subclauses (including the future library
directions) is reserved for use as a macro name and as an
identifier with file scope in the same name space if any of
its associated headers is included.
The text says "each identifier ... is reserved ...". That
phrasing seems pretty clearcut - the identifer is listed,
therefore it is reserved.
>> Note that the program was written by Martin Shobe, not myself.
>> In any case it doesn't change the conclusion, the given program
>> is not strictly conforming no matter what value is used to
>> initialize x, and an implementation could choose to enable
>> undersized types on that basis.
>
> Not being strictly conforming in NOT good enough. To change defined
> behavior you need the presence of undefined behavior. (see 4p3)
The point of 4p3 (added in C99) is only to identify a key
distinction between unspecified behavior and undefined behavior.
The historical documents (ie, on the www.open-std.org website)
leading up the C99 make this clear. It has no special relevance
for extensions, which have been in the Standard essentially
unchanged since C90. In any case 4p3 is irrelevant to the
current discussion, since the question we are trying to answer
falls under the heading of the "otherwise correct" condition.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-05 19:29 -0700 |
| Message-ID | <lnpp1wuvpo.fsf@kst-u.example.com> |
| In reply to | #69506 |
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. 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.
J.3.13 (which is informative, not normative) says that:
The values or expressions assigned to the macros specified in
the headers <float.h>, <limits.h>, and <stdint.h>
which, if taken literally, implies that the value of UINT8_MAX
is implementation-defined, but I think that was either a minor
oversight or an unwillingness to take the extra effort to exclude
values that aren't really implementation-defined.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-06 14:38 -0700 |
| Message-ID | <kfnfv2rqlck.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #69565 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-06 17:46 -0700 |
| Message-ID | <lnfv2rt5rw.fsf@kst-u.example.com> |
| In reply to | #69681 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> 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.
Its implementation-defined value shall be equal to or greater in
magnitude (absolute value) than the corresponding value given below,
with the same sign, except where stated to be exactly the given
value.
I think that's just a bit of sloppy wording.
3.19.1 defines an "implementation-defined value" as an "unspecified
value where each implementation documents how the choice is made",
and an "unspecified value" as a "valid value of the relevant type
where this International Standard imposes no requirements on which
value is chosen in any instance". So the value of INT_LEAST8_MAX,
for example, is said to be "implementation-defined", but that
contradicts the definition of the term, since the standard does
impose *some* requirements on which value can be chosen (it can't
be 42, for example).
IMHO the fix for that would be to tweak the definition of
"implementation-defined value", so it can apply to values for
which the standard imposes *some* requirements without requiring
one specific value.
The most literal reading of 7.20.2p2 is that the value of
UINT8_MAX is implementation-defined. A more sensible reading,
IMHO, is that values that are stated to have exact values are *not*
implementation-defined. That requires a slightly strained parsing
of the sentence.
I would not consider an implementation to be non-conforming because
it doesn't document the value of UINT8_MAX.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-07 23:50 -0700 |
| Message-ID | <kfn37ypmmkg.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #69709 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> 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. > > Its implementation-defined value shall be equal to or greater in > magnitude (absolute value) than the corresponding value given below, > with the same sign, except where stated to be exactly the given > value. > > I think that's just a bit of sloppy wording. That isn't how it seems to me, since the special case of exact values is mentioned specifically. > 3.19.1 defines an "implementation-defined value" as an "unspecified > value where each implementation documents how the choice is made", > and an "unspecified value" as a "valid value of the relevant type > where this International Standard imposes no requirements on which > value is chosen in any instance". So the value of INT_LEAST8_MAX, > for example, is said to be "implementation-defined", but that > contradicts the definition of the term, since the standard does > impose *some* requirements on which value can be chosen (it can't > be 42, for example). That falls under "valid", not under requirements. The only valid values for INT_LEAST8_MAX are 127 or higher, and the only valid value for UINT8_MAX is 255. > IMHO the fix for that would be to tweak the definition of > "implementation-defined value", so it can apply to values for > which the standard imposes *some* requirements without requiring > one specific value. In my view that would be awkward and unnecessary. I don't see anything wrong with the value of X is implementation-defined even if, like here, there is only one valid value for X. > The most literal reading of 7.20.2p2 is that the value of > UINT8_MAX is implementation-defined. Yes, and I believe that is what was intended. > A more sensible reading, IMHO, is that values that are stated > to have exact values are *not* implementation-defined. I agree that someone could make a reasonable argument that this would be a more sensible /decision/, but I don't think it's a more sensible /reading/. > That requires a slightly strained parsing of the sentence. Right, and that's why I think it's not a more sensible reading. > I would not consider an implementation to be non-conforming because > it doesn't document the value of UINT8_MAX. In this case I see no reason not to take the Standard at its word, and would therefore label such an implementation as non-conforming. Of course this is unlikely to matter, as I expect most implementations would simply say the values in the implementation's system header values supply the required documentation for implementation-defined values.
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web