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 | 12 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 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-20 06:48 -0700 |
| Message-ID | <kfnbnf7os84.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65370 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: > [...] >> 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. > > Padding bits don't contribute to the value of an integer object. > A footnote (in N1570 6.2.6.2p5) says: > > Some combinations of padding bits might generate trap > representations, for example, if one padding bit is a parity > bit. Regardless, no arithmetic operation on valid values > can generate a trap representation other than as part of an > exceptional condition such as an overflow. All other combinations > of padding bits are alternative object representations of the > value specified by the value bits. Yes, if padding bits don't result in trap representations then having padding bits makes no difference. The point of what I was saying is that some combinations of padding bits (specifically in size_t, but perhaps some other integral types as well) could be trap representations, which of course yield undefined behavior if they are accessed. Taking advantage of the latitude of undefined behavior is what allows representation of non-integral values. >> 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'm skeptical. The combination of undefined behavior resulting from trap representatons and the Standard allowing an extremely wide range of extensions is enormously powerful. In some sense it's an academic question since such an implementation will in all likelihood never be produced. But I think it's interesting to consider the possibility.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-20 11:18 -0700 |
| Message-ID | <lnwpxug0bb.fsf@kst-u.example.com> |
| In reply to | #65985 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
>>> 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'm skeptical.
>
> The combination of undefined behavior resulting from trap
> representatons and the Standard allowing an extremely wide
> range of extensions is enormously powerful. In some sense
> it's an academic question since such an implementation will
> in all likelihood never be produced. But I think it's
> interesting to consider the possibility.
Sure -- but I still don't think it's a possibility.
Extensions can take advantage of undefined behavior, but your proposed
extension (using padding bits and trap representations in size_t to
represent fractional values) introduces undefined behavior where it
doesn't currently exist. I believe it is therefore non-conforming.
I believe that this program:
#include <stdio.h>
#include <stdint.h>
int main(void) {
#ifdef UINT8_MAX
if (sizeof (uint8_t) < (size_t)1) {
puts("I am confused");
}
else {
puts("ok");
}
#else
puts("ok");
#endif
return 0;
}
is strictly conforming (subject to the usual caveats about the puts call
failing) and must print "ok".
--
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-07-24 09:58 -0700 |
| Message-ID | <kfnmvylh4r0.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66036 |
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:
>
> [...]
>
>>>> 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'm skeptical.
>>
>> The combination of undefined behavior resulting from trap
>> representatons and the Standard allowing an extremely wide
>> range of extensions is enormously powerful. In some sense
>> it's an academic question since such an implementation will
>> in all likelihood never be produced. But I think it's
>> interesting to consider the possibility.
>
> Sure -- but I still don't think it's a possibility.
>
> Extensions can take advantage of undefined behavior, but your proposed
> extension (using padding bits and trap representations in size_t to
> represent fractional values) introduces undefined behavior where it
> doesn't currently exist. I believe it is therefore non-conforming.
>
> I believe that this program:
>
> #include <stdio.h>
> #include <stdint.h>
>
> int main(void) {
> #ifdef UINT8_MAX
> if (sizeof (uint8_t) < (size_t)1) {
> puts("I am confused");
> }
> else {
> puts("ok");
> }
> #else
> puts("ok");
> #endif
> return 0;
> }
>
> is strictly conforming (subject to the usual caveats about the puts call
> failing) and must print "ok".
Sure, but that doesn't mean there can't an extension that provides
these types, as long as they are provided only to (some subset of)
programs that are not strictly conforming.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-24 11:14 -0700 |
| Message-ID | <lna8ulzam2.fsf@kst-u.example.com> |
| In reply to | #66288 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> 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:
>>
>> [...]
>>
>>>>> 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'm skeptical.
>>>
>>> The combination of undefined behavior resulting from trap
>>> representatons and the Standard allowing an extremely wide
>>> range of extensions is enormously powerful. In some sense
>>> it's an academic question since such an implementation will
>>> in all likelihood never be produced. But I think it's
>>> interesting to consider the possibility.
>>
>> Sure -- but I still don't think it's a possibility.
>>
>> Extensions can take advantage of undefined behavior, but your proposed
>> extension (using padding bits and trap representations in size_t to
>> represent fractional values) introduces undefined behavior where it
>> doesn't currently exist. I believe it is therefore non-conforming.
>>
>> I believe that this program:
>>
>> #include <stdio.h>
>> #include <stdint.h>
>>
>> int main(void) {
>> #ifdef UINT8_MAX
>> if (sizeof (uint8_t) < (size_t)1) {
>> puts("I am confused");
>> }
>> else {
>> puts("ok");
>> }
>> #else
>> puts("ok");
>> #endif
>> return 0;
>> }
>>
>> is strictly conforming (subject to the usual caveats about the puts call
>> failing) and must print "ok".
>
> Sure, but that doesn't mean there can't an extension that provides
> these types, as long as they are provided only to (some subset of)
> programs that are not strictly conforming.
If you enable the extension only in the presence of a #pragma, for
example, then sure, it would be valid. A conforming implementation
could have a "#pragma LANGUAGE FORTRAN" that turns it into a Fortran
compiler.
Types smaller than CHAR_BIT bits are permitted as an extension only in
the sense that just about *anything* is permitted as an extension.
Using such a type to define uint8_t on a system where CHAR_BIT > 8 would
not, I think, be conforming. In addition, I think it would be a bad
idea; it would break some assumptions that C programmers can reasonably
depend on, such as that any object's representation can be treated as an
array of unsigned char -- or that sizeof yields an integer.
--
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-07-30 11:02 -0700 |
| Message-ID | <kfn4mkled7c.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66298 |
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:
>>>> Keith Thompson <kst-u@mib.org> writes:
>>>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>
>>> [...]
>>>
>>>>>> 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'm skeptical.
>>>>
>>>> The combination of undefined behavior resulting from trap
>>>> representatons and the Standard allowing an extremely wide
>>>> range of extensions is enormously powerful. In some sense
>>>> it's an academic question since such an implementation will
>>>> in all likelihood never be produced. But I think it's
>>>> interesting to consider the possibility.
>>>
>>> Sure -- but I still don't think it's a possibility.
>>>
>>> Extensions can take advantage of undefined behavior, but your proposed
>>> extension (using padding bits and trap representations in size_t to
>>> represent fractional values) introduces undefined behavior where it
>>> doesn't currently exist. I believe it is therefore non-conforming.
>>>
>>> I believe that this program:
>>>
>>> #include <stdio.h>
>>> #include <stdint.h>
>>>
>>> int main(void) {
>>> #ifdef UINT8_MAX
>>> if (sizeof (uint8_t) < (size_t)1) {
>>> puts("I am confused");
>>> }
>>> else {
>>> puts("ok");
>>> }
>>> #else
>>> puts("ok");
>>> #endif
>>> return 0;
>>> }
>>>
>>> is strictly conforming (subject to the usual caveats about the puts call
>>> failing) and must print "ok".
>>
>> Sure, but that doesn't mean there can't an extension that provides
>> these types, as long as they are provided only to (some subset of)
>> programs that are not strictly conforming.
>
> If you enable the extension only in the presence of a #pragma, for
> example, then sure, it would be valid. A conforming implementation
> could have a "#pragma LANGUAGE FORTRAN" that turns it into a Fortran
> compiler.
Yes, but a program doesn't need #pragma to put it outside the
realm of being strictly conforming. For example, if a source
file has '#include <Xstdint.h>' (and assuming of course that it
isn't skipped by pre-processors conditionals) then the program is
not strictly conforming.
> Types smaller than CHAR_BIT bits are permitted as an extension
> only in the sense that just about *anything* is permitted as an
> extension.
>
> Using such a type to define uint8_t on a system where CHAR_BIT > 8
> would not, I think, be conforming.
I understand the gut reaction. Can you cite a passage in the
Standard that supports this assertion? I don't know of one.
> In addition, I think it would be a bad idea; it would break some
> assumptions that C programmers can reasonably depend on, such as
> that any object's representation can be treated as an array of
> unsigned char -- or that sizeof yields an integer.
Perhaps, but I think that depends on how the extension is
presented. If it were presented in a way that such types
were provided only when there is some explicit indication
that they should be (eg, like the #include mentioned above),
why is that bad?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-30 13:10 -0700 |
| Message-ID | <lnwpxhl83j.fsf@kst-u.example.com> |
| In reply to | #66572 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> 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:
>>>>> Keith Thompson <kst-u@mib.org> writes:
>>>>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>>
>>>> [...]
>>>>
>>>>>>> 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'm skeptical.
>>>>>
>>>>> The combination of undefined behavior resulting from trap
>>>>> representatons and the Standard allowing an extremely wide
>>>>> range of extensions is enormously powerful. In some sense
>>>>> it's an academic question since such an implementation will
>>>>> in all likelihood never be produced. But I think it's
>>>>> interesting to consider the possibility.
>>>>
>>>> Sure -- but I still don't think it's a possibility.
>>>>
>>>> Extensions can take advantage of undefined behavior, but your proposed
>>>> extension (using padding bits and trap representations in size_t to
>>>> represent fractional values) introduces undefined behavior where it
>>>> doesn't currently exist. I believe it is therefore non-conforming.
>>>>
>>>> I believe that this program:
>>>>
>>>> #include <stdio.h>
>>>> #include <stdint.h>
>>>>
>>>> int main(void) {
>>>> #ifdef UINT8_MAX
>>>> if (sizeof (uint8_t) < (size_t)1) {
>>>> puts("I am confused");
>>>> }
>>>> else {
>>>> puts("ok");
>>>> }
>>>> #else
>>>> puts("ok");
>>>> #endif
>>>> return 0;
>>>> }
>>>>
>>>> is strictly conforming (subject to the usual caveats about the puts call
>>>> failing) and must print "ok".
>>>
>>> Sure, but that doesn't mean there can't an extension that provides
>>> these types, as long as they are provided only to (some subset of)
>>> programs that are not strictly conforming.
>>
>> If you enable the extension only in the presence of a #pragma, for
>> example, then sure, it would be valid. A conforming implementation
>> could have a "#pragma LANGUAGE FORTRAN" that turns it into a Fortran
>> compiler.
>
> Yes, but a program doesn't need #pragma to put it outside the
> realm of being strictly conforming. For example, if a source
> file has '#include <Xstdint.h>' (and assuming of course that it
> isn't skipped by pre-processors conditionals) then the program is
> not strictly conforming.
Sure -- for example <Xstdint.h> could contain a #pragma.
>> Types smaller than CHAR_BIT bits are permitted as an extension
>> only in the sense that just about *anything* is permitted as an
>> extension.
>>
>> Using such a type to define uint8_t on a system where CHAR_BIT > 8
>> would not, I think, be conforming.
>
> I understand the gut reaction. Can you cite a passage in the
> Standard that supports this assertion? I don't know of one.
I don't think there's a single passage I can cite.
In the absence of a #pragma, or a non-standard #include, or something
along those lines, I don't think it's permitted. In the presence of
such a thing, just about *anything* is permitted.
>> In addition, I think it would be a bad idea; it would break some
>> assumptions that C programmers can reasonably depend on, such as
>> that any object's representation can be treated as an array of
>> unsigned char -- or that sizeof yields an integer.
>
> Perhaps, but I think that depends on how the extension is
> presented. If it were presented in a way that such types
> were provided only when there is some explicit indication
> that they should be (eg, like the #include mentioned above),
> why is that bad?
I find it counterintuitive. If an implementation defines uint8_t in a
way that violates the expectations I have for a type with that name
(such as that sizeof (uint8_t) == 1, or at least that it's not between 0
and 1), I think that's a bad thing. Making it depend on a non-standard
#pragma, #include, or whatever can probably make it a conforming
extension, but IMHO it would be far better not to change the existing
meanings of uint8_t, sizeof, and size_t.
Sub-byte types are an interesting idea for an extension, but using a
distinctive syntax would be less confusing. Permitting bit fields
outside structs might be a good starting point.
--
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-08-01 10:53 -0700 |
| Message-ID | <kfn7fpec2un.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66580 |
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:
>>>> 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:
>>>>>
>>>>> [...]
>>>>>
>>>>>>>> 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'm skeptical.
>>>>>>
>>>>>> The combination of undefined behavior resulting from trap
>>>>>> representatons and the Standard allowing an extremely wide
>>>>>> range of extensions is enormously powerful. In some sense
>>>>>> it's an academic question since such an implementation will
>>>>>> in all likelihood never be produced. But I think it's
>>>>>> interesting to consider the possibility.
>>>>>
>>>>> Sure -- but I still don't think it's a possibility.
>>>>>
>>>>> Extensions can take advantage of undefined behavior, but your proposed
>>>>> extension (using padding bits and trap representations in size_t to
>>>>> represent fractional values) introduces undefined behavior where it
>>>>> doesn't currently exist. I believe it is therefore non-conforming.
>>>>>
>>>>> I believe that this program:
>>>>>
>>>>> #include <stdio.h>
>>>>> #include <stdint.h>
>>>>>
>>>>> int main(void) {
>>>>> #ifdef UINT8_MAX
>>>>> if (sizeof (uint8_t) < (size_t)1) {
>>>>> puts("I am confused");
>>>>> }
>>>>> else {
>>>>> puts("ok");
>>>>> }
>>>>> #else
>>>>> puts("ok");
>>>>> #endif
>>>>> return 0;
>>>>> }
>>>>>
>>>>> is strictly conforming (subject to the usual caveats about the puts call
>>>>> failing) and must print "ok".
>>>>
>>>> Sure, but that doesn't mean there can't an extension that provides
>>>> these types, as long as they are provided only to (some subset of)
>>>> programs that are not strictly conforming.
>>>
>>> If you enable the extension only in the presence of a #pragma, for
>>> example, then sure, it would be valid. A conforming implementation
>>> could have a "#pragma LANGUAGE FORTRAN" that turns it into a Fortran
>>> compiler.
>>
>> Yes, but a program doesn't need #pragma to put it outside the
>> realm of being strictly conforming. For example, if a source
>> file has '#include <Xstdint.h>' (and assuming of course that it
>> isn't skipped by pre-processors conditionals) then the program is
>> not strictly conforming.
>
> Sure -- for example <Xstdint.h> could contain a #pragma.
Yes, certainly it could, but my point is it doesn't have to. In
fact the file for <Xstding.h> could be empty and the program
would still be not strictly conforming. Or the source text might
have, eg, 'enum { not_strictly_conforming_eh = 50000 };', and the
program would not be strictly conforming. For that matter, even
these two lines
#include <stdint.h>
typedef uint8_t Octet;
are enough to ensure the program is not strictly conforming. Any
of these methods, or all of them, could be used to allow the
undersized types extension.
>>> Types smaller than CHAR_BIT bits are permitted as an extension
>>> only in the sense that just about *anything* is permitted as an
>>> extension.
>>>
>>> Using such a type to define uint8_t on a system where CHAR_BIT > 8
>>> would not, I think, be conforming.
>>
>> I understand the gut reaction. Can you cite a passage in the
>> Standard that supports this assertion? I don't know of one.
>
> I don't think there's a single passage I can cite.
>
> In the absence of a #pragma, or a non-standard #include, or something
> along those lines, I don't think it's permitted. In the presence of
> such a thing, just about *anything* is permitted.
I agree on the second sentence, but I'm not predicating the
suggestion on #pragma or something like it. Why do you
think, in the case of the first sentence, that an extension
like what I'm describing is not permitted? AFAICT the Standard
allows it.
>>> In addition, I think it would be a bad idea; it would break some
>>> assumptions that C programmers can reasonably depend on, such as
>>> that any object's representation can be treated as an array of
>>> unsigned char -- or that sizeof yields an integer.
>>
>> Perhaps, but I think that depends on how the extension is
>> presented. If it were presented in a way that such types
>> were provided only when there is some explicit indication
>> that they should be (eg, like the #include mentioned above),
>> why is that bad?
>
> I find it counterintuitive. If an implementation defines uint8_t
> in a way that violates the expectations I have for a type with
> that name (such as that sizeof (uint8_t) == 1, or at least that
> it's not between 0 and 1), I think that's a bad thing. Making it
> depend on a non-standard #pragma, #include, or whatever can
> probably make it a conforming extension, but IMHO it would be far
> better not to change the existing meanings of uint8_t, sizeof, and
> size_t.
I think I understand your reaction. I agree that having types
with a size that is greater than zero but less than one is a
little weird. However, given the existence of a type that
satisfies all the requirements of [u]int8_t except the (indirect)
requirement that sizes are a multiple of 1, and since the whole
point of providing undersized types is to provide types whose
sizes are not always multiples of 1, at some level it seems like
the presence of the extension virtually requires [u]int8_t be
provided (this is assuming of course that there is an 8-bit
undersized type, etc).
> Sub-byte types are an interesting idea for an extension, but using
> a distinctive syntax would be less confusing. Permitting bit
> fields outside structs might be a good starting point.
Allowing arbitrary widths is possible but complicated. In most
cases I expect implementations would provide just those widths
that evenly divide CHAR_BIT. Using a syntax that makes it
obvious that something unusual is going on is often a good idea,
although I don't think it needs to be anything high-powered --
just __unsigned_1, __unsigned_2, __unsigned_4, etc, and the
corresponding __signed_NN counterparts, should suffice.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-07 14:46 -0700 |
| Message-ID | <87a8wbry3h.fsf@kst-u.example.com> |
| In reply to | #63048 |
David Brown <david.brown@hesbynett.no> writes:
> On 07/06/15 21:48, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> _Static_assert(sizeof(int32_t) == 4, "Checking char size");
>>
>> The string says "Checking char size", but it's checking the size of
>> int32_t.
>>
>> The only way int32_t can have a size other than 4 bytes is if
>> CHAR_BIT > 8. You can replace the above with:
>>
>> _Static_assert(CHAR_BIT == 8, "Checking CHAR_BIT");
>
> That's pretty much exactly what I wrote - you must have missed that part
> of my mail.
Ah, so you're checking sizeof (int32_t) for the purpose of checking that
CHAR_BIT==8. I did figure out that that's the consequence of that
check, but it wasn't obvious (at least to me) that that was what you
meant; I assumed that there was some sort of typo.
If you want to check that CHAR_BIT==8, why not just check that
CHAR_BIT==8?
> The only reason for using a check with sizeof(int32_t) rather than
> CHAR_BIT is to save yet another include file.
Not worth it IMHO.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-08 09:05 +0200 |
| Message-ID | <ml3eom$v3v$1@dont-email.me> |
| In reply to | #63050 |
On 07/06/15 23:46, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 07/06/15 21:48, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> [...] >>>> _Static_assert(sizeof(int32_t) == 4, "Checking char size"); >>> >>> The string says "Checking char size", but it's checking the size of >>> int32_t. >>> >>> The only way int32_t can have a size other than 4 bytes is if >>> CHAR_BIT > 8. You can replace the above with: >>> >>> _Static_assert(CHAR_BIT == 8, "Checking CHAR_BIT"); >> >> That's pretty much exactly what I wrote - you must have missed that part >> of my mail. > > Ah, so you're checking sizeof (int32_t) for the purpose of checking that > CHAR_BIT==8. I did figure out that that's the consequence of that > check, but it wasn't obvious (at least to me) that that was what you > meant; I assumed that there was some sort of typo. > > If you want to check that CHAR_BIT==8, why not just check that > CHAR_BIT==8? > >> The only reason for using a check with sizeof(int32_t) rather than >> CHAR_BIT is to save yet another include file. > > Not worth it IMHO. > I was merely offering an alternative - and if it was unclear, then I agree it is a bad choice. In hindsight, it was a bad idea - it has distracted the thread from my main point, which is the use of static assertions to check that you've got your sizes and alignments the way you want them.
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruz <chine.bleu@yahoo.com> |
|---|---|
| Date | 2015-06-06 05:06 -0700 |
| Message-ID | <chine.bleu-127385.05060206062015@88-209-239-213.giganet.hu> |
| In reply to | #63008 |
In article <mkun7o$pc2$1@dont-email.me>, bilsch01 <king621@comcast.net> wrote: > The code below writes a file to disk that has 52 bytes. There are 4 > float and 8 int. Isn't that 4x4 + 8x2 = 32 bytes? I don't get it. > > When I change %i to %u the total is 56 bytes. I think it should be the > same whether %i or %u. > fprintf(fp,"%f%f%f%f%i%i%i%i%i%i%i%i",w1,w2,w3,k1,xf,yf,xof,yof,xm,ym,delay,gl Since you're not giving the field width on the formatter, the decimal representation will have as many characters as necessary. Even with a field width, that's only the minimum width. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. 'I desire mercy, not sacrifice.' When is a Kenyan not a Kenyan? When he's a Canadian. That's People's Commissioner Siri Cruz now. Punch!
[toc] | [prev] | [next] | [standalone]
| From | bartekltg <bartekltg@gmail.com> |
|---|---|
| Date | 2015-07-26 00:58 +0200 |
| Message-ID | <mp14au$qq7$1@node2.news.atman.pl> |
| In reply to | #63008 |
On 06.06.2015 13:58, bilsch01 wrote:
> The code below writes a file to disk that has 52 bytes. There are 4
> float and 8 int. Isn't that 4x4 + 8x2 = 32 bytes? I don't get it.
Your int is small ;-)
>
> When I change %i to %u the total is 56 bytes. I think it should be the
> same whether %i or %u.
>
> int main(){
>
> int xf=65535, yf=0, xof=65535, yof=0, xm=65535, ym=0, delay=0,
> glength=65535;
> float w1=0.5, w2=2.0, w3=0.14159, k1=.01;
> FILE *fp;
>
> fp = fopen("gdata", "w");
> fprintf(fp,"%f%f%f%f%i%i%i%i%i%i%i%i",w1,w2,w3,k1,xf,yf,xof,yof,xm,ym,delay,glength);
>
> fclose(fp);
> }
Did you look to the file? It looks like that:
0.5000002.0000000.1415900.010000655350655350655350065535
A binary representation of 4 floats and 8 ints have 32 bytes total.
But you do not write boinary data, fou convert numbers to "strings"
and write it to file. And text format usualy need more bytes than
binary one to contain a number.
This is one of proper ways:
#include <stdio.h>
#include <stdlib.h>
int main(){
int xf=65535, yf=0, xof=65535, yof=0, xm=65535, ym=0, delay=0,
glength=65535;
float w1=0.5, w2=2.0, w3=0.14159, k1=.01;
FILE *fp;
int ti[8] = {xf, yf, xof, yof, xm, ym, delay, glength};
float tf[8]={w1,w2,w3,k1}; // fwrite writes compact chunk of data,
you can call it 12 times or make these arrays.
fp = fopen("gdata2", "wb"); //mode have a 'b'
fwrite(ti,8,sizeof(int), fp);
fwrite(tf,4,sizeof(float), fp);
fclose(fp);
}
And now gdata2 have 48bytes ( 4-byte int in linux) and
looks like binary data, not numbers.
bartekltg
[toc] | [prev] | [next] | [standalone]
| From | bartekltg <bartekltg@gmail.com> |
|---|---|
| Date | 2015-07-26 01:00 +0200 |
| Message-ID | <mp14e5$qq7$2@node2.news.atman.pl> |
| In reply to | #66370 |
On 26.07.2015 00:58, bartekltg wrote: I'm sorry, I didn't see that this thread is tho months old. bartekltg
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.c
csiph-web