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 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-02 06:19 -0700 |
| Message-ID | <kfnpp35akvv.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66600 |
raltbos@xs4all.nl (Richard Bos) writes:
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> Extension should not change the defined behavior of things and
>>> MUST NOT change the behavior of a strictly conforming program.
>>
>> The presence of undersized types is limited (eg, by needing an
>> include line like #include <Xstdint.h>) to programs that are
>> not strictly conforming. So it is guaranteed that the extension
>> will not change the behavior of any strictly conforming program.
>
> Oh, well, in that case...
>
> In a non-conforming program, you're welcome to use Pascal variant
> records, ZMachine Objects, matchboxes with pieces of paper in
> them, and yes, also undersized integers.
>
> But you're outside what can be reasonably argued about with
> reference to the C Standard, then.
It seems like you are under the impression that not being
strictly conforming does by itself give an implementation
complete latitude in how it may interpret the source. That
is not the case.
I did mention including a non-standard header, but that is
just by way of example. An alternate method could be
enum { certainly_not_strictly_conforming = 100000 };
or, taking another tack
#include <stdint.h>
typedef uint8_t Octet;
Either or both of these techniques could be used to enable
the extensions, but they do not grant unbounded latitude
as to how the implementation may interpret the source.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-08-01 09:39 -0400 |
| Message-ID | <g_3vx.30877$uE1.182@fx01.iad> |
| In reply to | #66574 |
On 7/30/15 2:52 PM, Tim Rentsch wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 7/24/15 12:49 PM, Tim Rentsch wrote:
>>
>>> That's true, but the Standard also allows extensions. If types
>>> narrower than CHAR_BIT bits were provided as an extension,
>>> doesn't it seem reasonable to also extend sizeof to give a
>>> non-integral value for those types (not to be confused with
>>> 'extended integer types', which has a specific meaning)? I don't
>>> see any reason why there couldn't be such an extension, provided
>>> of course the usual condition about strictly conforming programs
>>> holds.
>>
>> Extension should not change the defined behavior of things and
>> MUST NOT change the behavior of a strictly conforming program.
>
> The presence of undersized types is limited (eg, by needing an
> include line like #include <Xstdint.h>) to programs that are
> not strictly conforming. So it is guaranteed that the extension
> will not change the behavior of any strictly conforming program.
>
The conversation started with the thought of an implementation, for
example, with CHAR_BIT == 16 but still defining a uint8_t, with some
sort of "fractional" sizeof value.
> As for extensions not changing the defined behavior of things,
> I believe the Standard does not require that. But in any case
> the extension does not change any behavior for things that were
> there without the extension. The behaviors of sizeof, &, and
> pointer arithmetic are all exactly the same as they would be
> when applied to non-extension types.
If extensions are allowed to change the defined behavior of things
defined in the standard, (as long as they do not change the behavior of
strictly conforming programs) then the standard becomes vacuous.
The program:
#include <stdio.h>
int main() {
printf("%zu", sizeof(int));
}
No longer has a guaranteed meaning, since it is not strictly conforming
(being dependent on implantation defined behavior), so thus is subject
to being changed by an "extension". Note also, as far as I can see, the
standard puts no requirements on the implementation actually documenting
its extensions. This effectively renders moot the concept of
implementation defined behavior, as once that occurs (so the program
isn't strictly conforming) the behavior becomes subject to arbitrary
redefinition by an extension.
I firmly believe that what is meant by the language on extensions is
that an implementation is allowed to define meaning to code that by the
standard is a constraint violation or has undefined behavior and define
behavior for that code. In doing so, it might omit a "required"
diagnostic (because the constraint violation has been replaced with the
extension). One limitation on extensions is that they can not use "user
space" symbols (without the need to include a new header) so as to not
change the meaning of a strictly conforming program.
In the case of the "extension" that started this discussion, the issue
is that uint8_t has a number of properties guaranteed by the standard,
and even if this type is tried to be made available under an extension,
it still should meet those requirements.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-01 13:06 -0700 |
| Message-ID | <ln4mkilqo1.fsf@kst-u.example.com> |
| In reply to | #66634 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 7/30/15 2:52 PM, Tim Rentsch wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 7/24/15 12:49 PM, Tim Rentsch wrote:
>>>
>>>> That's true, but the Standard also allows extensions. If types
>>>> narrower than CHAR_BIT bits were provided as an extension,
>>>> doesn't it seem reasonable to also extend sizeof to give a
>>>> non-integral value for those types (not to be confused with
>>>> 'extended integer types', which has a specific meaning)? I don't
>>>> see any reason why there couldn't be such an extension, provided
>>>> of course the usual condition about strictly conforming programs
>>>> holds.
>>>
>>> Extension should not change the defined behavior of things and
>>> MUST NOT change the behavior of a strictly conforming program.
>>
>> The presence of undersized types is limited (eg, by needing an
>> include line like #include <Xstdint.h>) to programs that are
>> not strictly conforming. So it is guaranteed that the extension
>> will not change the behavior of any strictly conforming program.
>>
>
> The conversation started with the thought of an implementation, for
> example, with CHAR_BIT == 16 but still defining a uint8_t, with some
> sort of "fractional" sizeof value.
>
>> As for extensions not changing the defined behavior of things,
>> I believe the Standard does not require that. But in any case
>> the extension does not change any behavior for things that were
>> there without the extension. The behaviors of sizeof, &, and
>> pointer arithmetic are all exactly the same as they would be
>> when applied to non-extension types.
>
> If extensions are allowed to change the defined behavior of things
> defined in the standard, (as long as they do not change the behavior of
> strictly conforming programs) then the standard becomes vacuous.
>
> The program:
>
> #include <stdio.h>
>
> int main() {
> printf("%zu", sizeof(int));
> }
>
> No longer has a guaranteed meaning, since it is not strictly conforming
> (being dependent on implantation defined behavior), so thus is subject
> to being changed by an "extension". Note also, as far as I can see, the
> standard puts no requirements on the implementation actually documenting
> its extensions. This effectively renders moot the concept of
> implementation defined behavior, as once that occurs (so the program
> isn't strictly conforming) the behavior becomes subject to arbitrary
> redefinition by an extension.
N1570 4p8:
An implementation shall be accompanied by a document that defines
all implementation-defined and locale-specific characteristics and
all extensions.
> I firmly believe that what is meant by the language on extensions is
> that an implementation is allowed to define meaning to code that by the
> standard is a constraint violation or has undefined behavior and define
> behavior for that code.
Where the standard specifically refers to strictly conforming
programs, I don't think you can re-interpret that to mean somehting
else.
But perhaps that's just an additional (and possibly redundant)
restriction on what extensions can do. Other restrictions are
imposed by the requirements stated in the entire standard, which
may not be violated by a conforming implementation whether it has
extensions or not.
N1570 4p3:
A program that is correct in all other aspects, operating on
correct data, containing unspecified behavior shall be a correct
program and act in accordance with 5.1.2.3.
"Correct programs" are a much wider category than "strictly
conforming programs", and I see no permission for extensions to
alter their behavior (or rather to extend the range of permissible
behavior).
> In doing so, it might omit a "required"
> diagnostic (because the constraint violation has been replaced with the
> extension).
I don't believe required diagnostics may be omitted. N1570 5.1.1.3p1
requires at least one diagnostic message for any translation unit
that violates a constraint or syntax rule. There's no exception
for extensions.
Of course a non-conforming compiler (which may be an otherwise
conforming compiler with or without some particular command-line
option) is not bound by the standard, and doesn't have to emit
any diagnostics.
[...]
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-08-01 20:43 -0400 |
| Message-ID | <_Idvx.31081$8Y.16822@fx29.iad> |
| In reply to | #66646 |
On 8/1/15 4:06 PM, Keith Thompson wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>> On 7/30/15 2:52 PM, Tim Rentsch wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> On 7/24/15 12:49 PM, Tim Rentsch wrote:
>>>>
>>>>> That's true, but the Standard also allows extensions. If types
>>>>> narrower than CHAR_BIT bits were provided as an extension,
>>>>> doesn't it seem reasonable to also extend sizeof to give a
>>>>> non-integral value for those types (not to be confused with
>>>>> 'extended integer types', which has a specific meaning)? I don't
>>>>> see any reason why there couldn't be such an extension, provided
>>>>> of course the usual condition about strictly conforming programs
>>>>> holds.
>>>>
>>>> Extension should not change the defined behavior of things and
>>>> MUST NOT change the behavior of a strictly conforming program.
>>>
>>> The presence of undersized types is limited (eg, by needing an
>>> include line like #include <Xstdint.h>) to programs that are
>>> not strictly conforming. So it is guaranteed that the extension
>>> will not change the behavior of any strictly conforming program.
>>>
>>
>> The conversation started with the thought of an implementation, for
>> example, with CHAR_BIT == 16 but still defining a uint8_t, with some
>> sort of "fractional" sizeof value.
>>
>>> As for extensions not changing the defined behavior of things,
>>> I believe the Standard does not require that. But in any case
>>> the extension does not change any behavior for things that were
>>> there without the extension. The behaviors of sizeof, &, and
>>> pointer arithmetic are all exactly the same as they would be
>>> when applied to non-extension types.
>>
>> If extensions are allowed to change the defined behavior of things
>> defined in the standard, (as long as they do not change the behavior of
>> strictly conforming programs) then the standard becomes vacuous.
>>
>> The program:
>>
>> #include <stdio.h>
>>
>> int main() {
>> printf("%zu", sizeof(int));
>> }
>>
>> No longer has a guaranteed meaning, since it is not strictly conforming
>> (being dependent on implantation defined behavior), so thus is subject
>> to being changed by an "extension". Note also, as far as I can see, the
>> standard puts no requirements on the implementation actually documenting
>> its extensions. This effectively renders moot the concept of
>> implementation defined behavior, as once that occurs (so the program
>> isn't strictly conforming) the behavior becomes subject to arbitrary
>> redefinition by an extension.
>
> N1570 4p8:
>
> An implementation shall be accompanied by a document that defines
> all implementation-defined and locale-specific characteristics and
> all extensions.
>
Ok, that means that it needs to document it, but (if the initial
assumption was true), it doesn't limit what it could do.
>> I firmly believe that what is meant by the language on extensions is
>> that an implementation is allowed to define meaning to code that by the
>> standard is a constraint violation or has undefined behavior and define
>> behavior for that code.
>
> Where the standard specifically refers to strictly conforming
> programs, I don't think you can re-interpret that to mean somehting
> else.
>
> But perhaps that's just an additional (and possibly redundant)
> restriction on what extensions can do. Other restrictions are
> imposed by the requirements stated in the entire standard, which
> may not be violated by a conforming implementation whether it has
> extensions or not.
>
> N1570 4p3:
>
> A program that is correct in all other aspects, operating on
> correct data, containing unspecified behavior shall be a correct
> program and act in accordance with 5.1.2.3.
>
> "Correct programs" are a much wider category than "strictly
> conforming programs", and I see no permission for extensions to
> alter their behavior (or rather to extend the range of permissible
> behavior).
Yes, that is why I was showing why requiring defined behavior only to
apply to strictly conforming, and allowing an extension to break such
behavior is incorrect, such as having sizeof a standard defined type
result in a "trap" representation (to justify "funny" math).
I agree that a program that has standard defined behavior needs to have
behavior within the bounds the standard defines (including all allowed
implementation and unspecified but allowed behaviors)
>
>> In doing so, it might omit a "required"
>> diagnostic (because the constraint violation has been replaced with the
>> extension).
>
> I don't believe required diagnostics may be omitted. N1570 5.1.1.3p1
> requires at least one diagnostic message for any translation unit
> that violates a constraint or syntax rule. There's no exception
> for extensions.
I am not as sure about it, but then, the compiler announcing, compiling
program with x extension enable could be considered a sufficient message
(the standard allows implementations to generate any "warnings" it
wants, and doesn't require that such "warnings" be distinguishable from
"diagnostics". QoI will dictate that an implementation should generate a
half way decent error (with location) for anything that could need to be
corrected, but it IS just QoI and not standard required.
I can see someone being able to argue that due to the standard
explicitly allowing some extensions, that a standard conforming
extension that, in effect, loosens a constraint, could justify that
there is cause to not be required to issue a diagnostic for a program
that meets the relaxed constraint (otherwise is its an "extension" but a
lessor thing of just defining undefined behavior which wouldn't need the
extension clause).
>
> Of course a non-conforming compiler (which may be an otherwise
> conforming compiler with or without some particular command-line
> option) is not bound by the standard, and doesn't have to emit
> any diagnostics.
>
> [...]
>
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-02 06:52 -0700 |
| Message-ID | <kfnlhdtajcm.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66634 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 7/30/15 2:52 PM, Tim Rentsch wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 7/24/15 12:49 PM, Tim Rentsch wrote:
>>>
>>>> That's true, but the Standard also allows extensions. If types
>>>> narrower than CHAR_BIT bits were provided as an extension,
>>>> doesn't it seem reasonable to also extend sizeof to give a
>>>> non-integral value for those types (not to be confused with
>>>> 'extended integer types', which has a specific meaning)? I don't
>>>> see any reason why there couldn't be such an extension, provided
>>>> of course the usual condition about strictly conforming programs
>>>> holds.
>>>
>>> Extension should not change the defined behavior of things and
>>> MUST NOT change the behavior of a strictly conforming program.
>>
>> The presence of undersized types is limited (eg, by needing an
>> include line like #include <Xstdint.h>) to programs that are
>> not strictly conforming. So it is guaranteed that the extension
>> will not change the behavior of any strictly conforming program.
>
> The conversation started with the thought of an implementation, for
> example, with CHAR_BIT == 16 but still defining a uint8_t, with some
> sort of "fractional" sizeof value.
>
>> As for extensions not changing the defined behavior of things,
>> I believe the Standard does not require that. But in any case
>> the extension does not change any behavior for things that were
>> there without the extension. The behaviors of sizeof, &, and
>> pointer arithmetic are all exactly the same as they would be
>> when applied to non-extension types.
>
> If extensions are allowed to change the defined behavior of things
> defined in the standard, (as long as they do not change the behavior
> of strictly conforming programs) then the standard becomes vacuous.
Perhaps so but I believe the Standard allows it, ie, and that
consequence is intended. I cite as evidence J.5.4, "Scopes of
identifiers":
A function identifier, or the identifier of an object the
declaration of which contains the keyword extern, has file
scope (6.2.1).
Here is an extension which clearly "changes the rules", but it
is listed as a "Common Extension" in section J.5.
> The program:
>
> #include <stdio.h>
>
> int main() {
> printf("%zu", sizeof(int));
> }
>
> No longer has a guaranteed meaning, since it is not strictly
> conforming (being dependent on implantation defined behavior), so
> thus is subject to being changed by an "extension". Note also, as
> far as I can see, the standard puts no requirements on the
> implementation actually documenting its extensions.
As has been pointed out, it does.
> This
> effectively renders moot the concept of implementation defined
> behavior, as once that occurs (so the program isn't strictly
> conforming) the behavior becomes subject to arbitrary redefinition
> by an extension.
>
> I firmly believe that what is meant by the language on extensions
> is that an implementation is allowed to define meaning to code
> that by the standard is a constraint violation or has undefined
> behavior and define behavior for that code. In doing so, it might
> omit a "required" diagnostic (because the constraint violation has
> been replaced with the extension).
This idea is not consistent with J.5.4, which I should mention was
present also in C90 (with slightly different section numbering).
> One limitation on extensions
> is that they can not use "user space" symbols (without the need to
> include a new header) so as to not change the meaning of a
> strictly conforming program.
I believe that idea is not consistent with J.5.9 and J.5.10.
Do you agree?
> In the case of the "extension" that started this discussion, the
> issue is that uint8_t has a number of properties guaranteed by the
> standard, and even if this type is tried to be made available
> under an extension, it still should meet those requirements.
AFAIK there is only one requirement (an indirect one) that is not
met, namely that types have sizes that are integer multiples of
one. But the whole point of the extension is to provide types
that do not satisfy this property. In any case I believe the
Standard allows extensions to change the rules for things, as
evidenced by the citations from section J.5. Considering these
examples, does this change your position at all? Or are there
some other aspects I may have missed that you would like to point
out?
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-08-02 15:14 -0400 |
| Message-ID | <d_tvx.39808$od1.21117@fx15.iad> |
| In reply to | #66696 |
On 8/2/15 9:52 AM, Tim Rentsch wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 7/30/15 2:52 PM, Tim Rentsch wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> On 7/24/15 12:49 PM, Tim Rentsch wrote:
>>>>
>>>>> That's true, but the Standard also allows extensions. If types
>>>>> narrower than CHAR_BIT bits were provided as an extension,
>>>>> doesn't it seem reasonable to also extend sizeof to give a
>>>>> non-integral value for those types (not to be confused with
>>>>> 'extended integer types', which has a specific meaning)? I don't
>>>>> see any reason why there couldn't be such an extension, provided
>>>>> of course the usual condition about strictly conforming programs
>>>>> holds.
>>>>
>>>> Extension should not change the defined behavior of things and
>>>> MUST NOT change the behavior of a strictly conforming program.
>>>
>>> The presence of undersized types is limited (eg, by needing an
>>> include line like #include <Xstdint.h>) to programs that are
>>> not strictly conforming. So it is guaranteed that the extension
>>> will not change the behavior of any strictly conforming program.
>>
>> The conversation started with the thought of an implementation, for
>> example, with CHAR_BIT == 16 but still defining a uint8_t, with some
>> sort of "fractional" sizeof value.
>>
>>> As for extensions not changing the defined behavior of things,
>>> I believe the Standard does not require that. But in any case
>>> the extension does not change any behavior for things that were
>>> there without the extension. The behaviors of sizeof, &, and
>>> pointer arithmetic are all exactly the same as they would be
>>> when applied to non-extension types.
>>
>> If extensions are allowed to change the defined behavior of things
>> defined in the standard, (as long as they do not change the behavior
>> of strictly conforming programs) then the standard becomes vacuous.
>
> Perhaps so but I believe the Standard allows it, ie, and that
> consequence is intended. I cite as evidence J.5.4, "Scopes of
> identifiers":
>
> A function identifier, or the identifier of an object the
> declaration of which contains the keyword extern, has file
> scope (6.2.1).
>
> Here is an extension which clearly "changes the rules", but it
> is listed as a "Common Extension" in section J.5.
>
>> The program:
>>
>> #include <stdio.h>
>>
>> int main() {
>> printf("%zu", sizeof(int));
>> }
>>
>> No longer has a guaranteed meaning, since it is not strictly
>> conforming (being dependent on implantation defined behavior), so
>> thus is subject to being changed by an "extension". Note also, as
>> far as I can see, the standard puts no requirements on the
>> implementation actually documenting its extensions.
>
> As has been pointed out, it does.
Yes, but the requirement to document still doesn't give it the power to
ignore the other requirements. You are proposing that any non-strictly
conforming program could have any arbitrary behavior, as long as the
implementation has documented it, so the above program could sing Dixie
(as long as that is somehow documented).
>
>> This
>> effectively renders moot the concept of implementation defined
>> behavior, as once that occurs (so the program isn't strictly
>> conforming) the behavior becomes subject to arbitrary redefinition
>> by an extension.
>>
>> I firmly believe that what is meant by the language on extensions
>> is that an implementation is allowed to define meaning to code
>> that by the standard is a constraint violation or has undefined
>> behavior and define behavior for that code. In doing so, it might
>> omit a "required" diagnostic (because the constraint violation has
>> been replaced with the extension).
>
> This idea is not consistent with J.5.4, which I should mention was
> present also in C90 (with slightly different section numbering).
This extension makes an extern definition in a position that would
normally be just block scope, now be visible to file scope. This does
NOT break program that is valid by the standard. Such a program could
not have referred to that identifier in another scope without adding a
new definition, which would need to match the first one.
>
>> One limitation on extensions
>> is that they can not use "user space" symbols (without the need to
>> include a new header) so as to not change the meaning of a
>> strictly conforming program.
>
> I believe that idea is not consistent with J.5.9 and J.5.10.
> Do you agree?
>
The 'fortran' function specifier does not exclude the ability to use
fortran as a user symbol, so there is no conflict (the fact that the
other function specifiers are universal keywords does not mean the
fortran needs to be).
Similarly for asm. Yes, this says that if you define a function called
asm that can take a char const* parameter then you would effectively
disable this extension.
As long as an confusion between a user symbol and the extension is
resolved in treating it as the user symbol, the extension is valid.
>> In the case of the "extension" that started this discussion, the
>> issue is that uint8_t has a number of properties guaranteed by the
>> standard, and even if this type is tried to be made available
>> under an extension, it still should meet those requirements.
>
> AFAIK there is only one requirement (an indirect one) that is not
> met, namely that types have sizes that are integer multiples of
> one. But the whole point of the extension is to provide types
> that do not satisfy this property. In any case I believe the
> Standard allows extensions to change the rules for things, as
> evidenced by the citations from section J.5. Considering these
> examples, does this change your position at all? Or are there
> some other aspects I may have missed that you would like to point
> out?
>
Being an integral multiple of 1 is sort of the definition of an integral
type.
You have yet to show a case where the standard give the right to the
implementation to violate the standard required behavior, when the
standard has defined the behavior.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-09 07:54 -0700 |
| Message-ID | <kfna8u07brh.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66728 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 8/2/15 9:52 AM, Tim Rentsch wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 7/30/15 2:52 PM, Tim Rentsch wrote:
>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>
>>>>> On 7/24/15 12:49 PM, Tim Rentsch wrote:
>>>>>
>>>>>> That's true, but the Standard also allows extensions. If types
>>>>>> narrower than CHAR_BIT bits were provided as an extension,
>>>>>> doesn't it seem reasonable to also extend sizeof to give a
>>>>>> non-integral value for those types (not to be confused with
>>>>>> 'extended integer types', which has a specific meaning)? I don't
>>>>>> see any reason why there couldn't be such an extension, provided
>>>>>> of course the usual condition about strictly conforming programs
>>>>>> holds.
>>>>>
>>>>> Extension should not change the defined behavior of things and
>>>>> MUST NOT change the behavior of a strictly conforming program.
>>>>
>>>> The presence of undersized types is limited (eg, by needing an
>>>> include line like #include <Xstdint.h>) to programs that are
>>>> not strictly conforming. So it is guaranteed that the extension
>>>> will not change the behavior of any strictly conforming program.
>>>
>>> The conversation started with the thought of an implementation,
>>> for example, with CHAR_BIT == 16 but still defining a uint8_t,
>>> with some sort of "fractional" sizeof value.
>>>
>>>> As for extensions not changing the defined behavior of things,
>>>> I believe the Standard does not require that. But in any case
>>>> the extension does not change any behavior for things that were
>>>> there without the extension. The behaviors of sizeof, &, and
>>>> pointer arithmetic are all exactly the same as they would be
>>>> when applied to non-extension types.
>>>
>>> If extensions are allowed to change the defined behavior of things
>>> defined in the standard, (as long as they do not change the
>>> behavior of strictly conforming programs) then the standard
>>> becomes vacuous.
>>
>> Perhaps so but I believe the Standard allows it, ie, and that
>> consequence is intended. I cite as evidence J.5.4, "Scopes of
>> identifiers":
>>
>> A function identifier, or the identifier of an object the
>> declaration of which contains the keyword extern, has file
>> scope (6.2.1).
>>
>> Here is an extension which clearly "changes the rules", but it
>> is listed as a "Common Extension" in section J.5.
>>
>>> The program:
>>>
>>> #include <stdio.h>
>>>
>>> int main() {
>>> printf("%zu", sizeof(int));
>>> }
>>>
>>> No longer has a guaranteed meaning, since it is not strictly
>>> conforming (being dependent on implantation defined behavior), so
>>> thus is subject to being changed by an "extension". Note also, as
>>> far as I can see, the standard puts no requirements on the
>>> implementation actually documenting its extensions.
>>
>> As has been pointed out, it does.
>
> Yes, but the requirement to document still doesn't give it the
> power to ignore the other requirements. You are proposing that
> any non-strictly conforming program could have any arbitrary
> behavior, as long as the implementation has documented it, so the
> above program could sing Dixie (as long as that is somehow
> documented).
I am not. Let me repeat my earlier statement, with some extra
emphasis: But in any case the extension /does not change/ any
behavior for things that were there without the extension.
>>> This
>>> effectively renders moot the concept of implementation defined
>>> behavior, as once that occurs (so the program isn't strictly
>>> conforming) the behavior becomes subject to arbitrary redefinition
>>> by an extension.
>>>
>>> I firmly believe that what is meant by the language on extensions
>>> is that an implementation is allowed to define meaning to code
>>> that by the standard is a constraint violation or has undefined
>>> behavior and define behavior for that code. In doing so, it might
>>> omit a "required" diagnostic (because the constraint violation has
>>> been replaced with the extension).
>>
>> This idea is not consistent with J.5.4, which I should mention was
>> present also in C90 (with slightly different section numbering).
>
> This extension makes an extern definition in a position that would
> normally be just block scope, now be visible to file scope. This
> does NOT break program that is valid by the standard. Such a
> program could not have referred to that identifier in another
> scope without adding a new definition, which would need to match
> the first one.
This is wrong. In C90, remember, which has the same mention of
a common extension, functions could be declared implicitly. So
C90 establishes that extensions may change the behavior of
programs that are defined otherwise.
>>> One limitation on extensions
>>> is that they can not use "user space" symbols (without the need to
>>> include a new header) so as to not change the meaning of a
>>> strictly conforming program.
>>
>> I believe that idea is not consistent with J.5.9 and J.5.10.
>> Do you agree?
>
> The 'fortran' function specifier does not exclude the ability to
> use fortran as a user symbol, so there is no conflict (the fact
> that the other function specifiers are universal keywords does not
> mean the fortran needs to be).
The header on J.5.9 says "The fortran keyword". I take the
Standard at its word - it says keyword, it means keyword. If an
identifier is a keyword it can't be used as a normal identifier
(with the obvious exceptions involving macros). Why should it be
taken any differently? Can you cite any other passage in the
Standard, or any other WG14 official document, to support that
position?
> Similarly for asm. Yes, this says that if you define a function
> called asm that can take a char const* parameter then you would
> effectively disable this extension.
The header on J.5.10 also uses the term "keyword", as does the
body. What reason is there to think this use of "keyword" is
meant to be different from how else it is used in the Standard?
Again what I'm asking for is some specific citation.
> As long as an confusion between a user symbol and the extension
> is resolved in treating it as the user symbol, the extension is
> valid.
Even if that is true for strictly conforming programs, J.5.9 and
J.5.10 show that it is not true for non-strictly conforming
programs. But the extension I have described applies only to (some)
non-strictly conforming programs, so there is no conflict.
>>> In the case of the "extension" that started this discussion, the
>>> issue is that uint8_t has a number of properties guaranteed by the
>>> standard, and even if this type is tried to be made available
>>> under an extension, it still should meet those requirements.
>>
>> AFAIK there is only one requirement (an indirect one) that is not
>> met, namely that types have sizes that are integer multiples of
>> one. But the whole point of the extension is to provide types
>> that do not satisfy this property. In any case I believe the
>> Standard allows extensions to change the rules for things, as
>> evidenced by the citations from section J.5. Considering these
>> examples, does this change your position at all? Or are there
>> some other aspects I may have missed that you would like to point
>> out?
>
> Being an integral multiple of 1 is sort of the definition of an
> integral type.
Certainly the Standard requires integral types to be able to
represent (some range of) integers, but nothing in the Standard
precludes the possibility that other values may be denoted.
Indeed the explicit mention of trap representations and undefined
behavior for them shows that such values /can/ be denoted, if an
implementation so chooses.
> You have yet to show a case where the standard give the right to
> the implementation to violate the standard required behavior, when
> the standard has defined the behavior.
There isn't anything in the Standard that says it can't, as long
as no strictly conforming program has its behavior changed. In
any case I will repeat again: the extension I have described
/does not change/ any behavior for things that were there without
the extension, which makes the objection moot.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-08-09 16:43 -0400 |
| Message-ID | <0YOxx.8612$d97.4192@fx26.iad> |
| In reply to | #67036 |
On 8/9/15 10:54 AM, Tim Rentsch wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 8/2/15 9:52 AM, Tim Rentsch wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> On 7/30/15 2:52 PM, Tim Rentsch wrote:
>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>
>>>>>> On 7/24/15 12:49 PM, Tim Rentsch wrote:
>>>>>>
>>>>>>> That's true, but the Standard also allows extensions. If types
>>>>>>> narrower than CHAR_BIT bits were provided as an extension,
>>>>>>> doesn't it seem reasonable to also extend sizeof to give a
>>>>>>> non-integral value for those types (not to be confused with
>>>>>>> 'extended integer types', which has a specific meaning)? I don't
>>>>>>> see any reason why there couldn't be such an extension, provided
>>>>>>> of course the usual condition about strictly conforming programs
>>>>>>> holds.
>>>>>>
>>>>>> Extension should not change the defined behavior of things and
>>>>>> MUST NOT change the behavior of a strictly conforming program.
>>>>>
>>>>> The presence of undersized types is limited (eg, by needing an
>>>>> include line like #include <Xstdint.h>) to programs that are
>>>>> not strictly conforming. So it is guaranteed that the extension
>>>>> will not change the behavior of any strictly conforming program.
>>>>
>>>> The conversation started with the thought of an implementation,
>>>> for example, with CHAR_BIT == 16 but still defining a uint8_t,
>>>> with some sort of "fractional" sizeof value.
>>>>
>>>>> As for extensions not changing the defined behavior of things,
>>>>> I believe the Standard does not require that. But in any case
>>>>> the extension does not change any behavior for things that were
>>>>> there without the extension. The behaviors of sizeof, &, and
>>>>> pointer arithmetic are all exactly the same as they would be
>>>>> when applied to non-extension types.
>>>>
>>>> If extensions are allowed to change the defined behavior of things
>>>> defined in the standard, (as long as they do not change the
>>>> behavior of strictly conforming programs) then the standard
>>>> becomes vacuous.
>>>
>>> Perhaps so but I believe the Standard allows it, ie, and that
>>> consequence is intended. I cite as evidence J.5.4, "Scopes of
>>> identifiers":
>>>
>>> A function identifier, or the identifier of an object the
>>> declaration of which contains the keyword extern, has file
>>> scope (6.2.1).
>>>
>>> Here is an extension which clearly "changes the rules", but it
>>> is listed as a "Common Extension" in section J.5.
>>>
>>>> The program:
>>>>
>>>> #include <stdio.h>
>>>>
>>>> int main() {
>>>> printf("%zu", sizeof(int));
>>>> }
>>>>
>>>> No longer has a guaranteed meaning, since it is not strictly
>>>> conforming (being dependent on implantation defined behavior), so
>>>> thus is subject to being changed by an "extension". Note also, as
>>>> far as I can see, the standard puts no requirements on the
>>>> implementation actually documenting its extensions.
>>>
>>> As has been pointed out, it does.
>>
>> Yes, but the requirement to document still doesn't give it the
>> power to ignore the other requirements. You are proposing that
>> any non-strictly conforming program could have any arbitrary
>> behavior, as long as the implementation has documented it, so the
>> above program could sing Dixie (as long as that is somehow
>> documented).
>
> I am not. Let me repeat my earlier statement, with some extra
> emphasis: But in any case the extension /does not change/ any
> behavior for things that were there without the extension.
>
The original claim was to be able to define uint8_t on a system with
CHAR_BIT > 8 and have sizeof(uint8_t) have a value that acted like a
value of 1/2 (if CHAR_BIT == 16). Unless UNDEFINED behavior has
occurred, sizeof can not produce a trap value, and thus the math MUST
proceed as defined, which doesn't allow for a value acting as 0.5 (i.e.
1 / 2 == 0)
>>>> This
>>>> effectively renders moot the concept of implementation defined
>>>> behavior, as once that occurs (so the program isn't strictly
>>>> conforming) the behavior becomes subject to arbitrary redefinition
>>>> by an extension.
>>>>
>>>> I firmly believe that what is meant by the language on extensions
>>>> is that an implementation is allowed to define meaning to code
>>>> that by the standard is a constraint violation or has undefined
>>>> behavior and define behavior for that code. In doing so, it might
>>>> omit a "required" diagnostic (because the constraint violation has
>>>> been replaced with the extension).
>>>
>>> This idea is not consistent with J.5.4, which I should mention was
>>> present also in C90 (with slightly different section numbering).
>>
>> This extension makes an extern definition in a position that would
>> normally be just block scope, now be visible to file scope. This
>> does NOT break program that is valid by the standard. Such a
>> program could not have referred to that identifier in another
>> scope without adding a new definition, which would need to match
>> the first one.
>
> This is wrong. In C90, remember, which has the same mention of
> a common extension, functions could be declared implicitly. So
> C90 establishes that extensions may change the behavior of
> programs that are defined otherwise.
>
4p3 says:
A program that is correct in all other aspects, operating on correct
data, containing unspecified behavior shall be a correct program and act
in accordance with 5.1.2.3.
Which says, in effect, that unspecified behavior does NOT give the
implementation license to deviate from the defined behavior.
The fact that (in C90) that a function definition is created on the
first call to that function, (with a defined definition base on the
call). If the implied definition disagrees with the actual definition,
the behavior is undefined. Thus the only difference would be in the case
of undefined behavior.
>>>> One limitation on extensions
>>>> is that they can not use "user space" symbols (without the need to
>>>> include a new header) so as to not change the meaning of a
>>>> strictly conforming program.
>>>
>>> I believe that idea is not consistent with J.5.9 and J.5.10.
>>> Do you agree?
>>
>> The 'fortran' function specifier does not exclude the ability to
>> use fortran as a user symbol, so there is no conflict (the fact
>> that the other function specifiers are universal keywords does not
>> mean the fortran needs to be).
>
> The header on J.5.9 says "The fortran keyword". I take the
> Standard at its word - it says keyword, it means keyword. If an
> identifier is a keyword it can't be used as a normal identifier
> (with the obvious exceptions involving macros). Why should it be
> taken any differently? Can you cite any other passage in the
> Standard, or any other WG14 official document, to support that
> position?
Since J.5 says
The inclusion of any extension that may cause a strictly conforming
program to become invalid renders an implementation nonconforming.
Examples of such extensions are new keywords, extra library functions
declared in standard headers, or predefined macros with names that do
not begin with an underscore.
(The list of examples are clearly things that are NOT allowed, as
affecting strictly conforming programs).
This means that a J.5.9 that actually makes fortran a global keyword is
non-conforming by the standard (int fortran; is a valid statement in
strictly conforming code, so you can't make it an error). Making it a
context sensitive keyword (that can be overridden by code) would be a
conforming extensions. Making it a keyword that is only recognized in
the limited scope, and only when the statement would not be valid
otherwise, is acceptable. For example:
typedef long fortran;
fortran foo(int);
must NOT treat fortran as a keyword, but if the second line was:
fortran int foo(int);
then it could be.
>
>> Similarly for asm. Yes, this says that if you define a function
>> called asm that can take a char const* parameter then you would
>> effectively disable this extension.
>
> The header on J.5.10 also uses the term "keyword", as does the
> body. What reason is there to think this use of "keyword" is
> meant to be different from how else it is used in the Standard?
> Again what I'm asking for is some specific citation.
>
Again, refer to J.5
>> As long as an confusion between a user symbol and the extension
>> is resolved in treating it as the user symbol, the extension is
>> valid.
>
> Even if that is true for strictly conforming programs, J.5.9 and
> J.5.10 show that it is not true for non-strictly conforming
> programs. But the extension I have described applies only to (some)
> non-strictly conforming programs, so there is no conflict.
>
If your extenuation changes the meaning of
#include <stdint.h>
#ifndef UINT8_MAX
typedef unsigned char uint8_t;
#endif
and any later use of sizeof(uint8_t), even in the presence of
implementation defined or unspecified behavior, it is NOT a conforming
extension. (unless you can show an explicit permission to change the
defined behavior of sizeof and integral math among the options of
behavior given). (See 4p3)
>>>> In the case of the "extension" that started this discussion, the
>>>> issue is that uint8_t has a number of properties guaranteed by the
>>>> standard, and even if this type is tried to be made available
>>>> under an extension, it still should meet those requirements.
>>>
>>> AFAIK there is only one requirement (an indirect one) that is not
>>> met, namely that types have sizes that are integer multiples of
>>> one. But the whole point of the extension is to provide types
>>> that do not satisfy this property. In any case I believe the
>>> Standard allows extensions to change the rules for things, as
>>> evidenced by the citations from section J.5. Considering these
>>> examples, does this change your position at all? Or are there
>>> some other aspects I may have missed that you would like to point
>>> out?
>>
>> Being an integral multiple of 1 is sort of the definition of an
>> integral type.
>
> Certainly the Standard requires integral types to be able to
> represent (some range of) integers, but nothing in the Standard
> precludes the possibility that other values may be denoted.
> Indeed the explicit mention of trap representations and undefined
> behavior for them shows that such values /can/ be denoted, if an
> implementation so chooses.
Yes, trap representations can do anything as undefined behavior, but you
can only GET a trap representation by performing undefined behavior.
sizeof(type) (assuming type is a valid type) has defined behavior, so
can NOT produce a trap value. The only excuse to not follow such defined
behavior is the presence of undefined behavior.
>
>> You have yet to show a case where the standard give the right to
>> the implementation to violate the standard required behavior, when
>> the standard has defined the behavior.
>
> There isn't anything in the Standard that says it can't, as long
> as no strictly conforming program has its behavior changed. In
> any case I will repeat again: the extension I have described
> /does not change/ any behavior for things that were there without
> the extension, which makes the objection moot.
>
4p3 says that, without undefined behavior, even the presence of
unspecified behavior does not allow the implementation to deviate from
the behavior that has been defined.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-05 10:48 -0700 |
| Message-ID | <kfn4mj8ycyk.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #67043 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 8/9/15 10:54 AM, Tim Rentsch wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 8/2/15 9:52 AM, Tim Rentsch wrote:
>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>
>>>>> On 7/30/15 2:52 PM, Tim Rentsch wrote:
>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>
>>>>>>> On 7/24/15 12:49 PM, Tim Rentsch wrote:
>>>>>>>
>>>>>>>> That's true, but the Standard also allows extensions. If types
>>>>>>>> narrower than CHAR_BIT bits were provided as an extension,
>>>>>>>> doesn't it seem reasonable to also extend sizeof to give a
>>>>>>>> non-integral value for those types (not to be confused with
>>>>>>>> 'extended integer types', which has a specific meaning)? I don't
>>>>>>>> see any reason why there couldn't be such an extension, provided
>>>>>>>> of course the usual condition about strictly conforming programs
>>>>>>>> holds.
>>>>>>>
>>>>>>> Extension should not change the defined behavior of things and
>>>>>>> MUST NOT change the behavior of a strictly conforming program.
>>>>>>
>>>>>> The presence of undersized types is limited (eg, by needing an
>>>>>> include line like #include <Xstdint.h>) to programs that are
>>>>>> not strictly conforming. So it is guaranteed that the extension
>>>>>> will not change the behavior of any strictly conforming program.
>>>>>
>>>>> The conversation started with the thought of an implementation,
>>>>> for example, with CHAR_BIT == 16 but still defining a uint8_t,
>>>>> with some sort of "fractional" sizeof value.
>>>>>
>>>>>> As for extensions not changing the defined behavior of things,
>>>>>> I believe the Standard does not require that. But in any case
>>>>>> the extension does not change any behavior for things that were
>>>>>> there without the extension. The behaviors of sizeof, &, and
>>>>>> pointer arithmetic are all exactly the same as they would be
>>>>>> when applied to non-extension types.
>>>>>
>>>>> If extensions are allowed to change the defined behavior of things
>>>>> defined in the standard, (as long as they do not change the
>>>>> behavior of strictly conforming programs) then the standard
>>>>> becomes vacuous.
>>>>
>>>> Perhaps so but I believe the Standard allows it, ie, and that
>>>> consequence is intended. I cite as evidence J.5.4, "Scopes of
>>>> identifiers":
>>>>
>>>> A function identifier, or the identifier of an object the
>>>> declaration of which contains the keyword extern, has file
>>>> scope (6.2.1).
>>>>
>>>> Here is an extension which clearly "changes the rules", but it
>>>> is listed as a "Common Extension" in section J.5.
>>>>
>>>>> The program:
>>>>>
>>>>> #include <stdio.h>
>>>>>
>>>>> int main() {
>>>>> printf("%zu", sizeof(int));
>>>>> }
>>>>>
>>>>> No longer has a guaranteed meaning, since it is not strictly
>>>>> conforming (being dependent on implantation defined behavior), so
>>>>> thus is subject to being changed by an "extension". Note also, as
>>>>> far as I can see, the standard puts no requirements on the
>>>>> implementation actually documenting its extensions.
>>>>
>>>> As has been pointed out, it does.
>>>
>>> Yes, but the requirement to document still doesn't give it the
>>> power to ignore the other requirements. You are proposing that
>>> any non-strictly conforming program could have any arbitrary
>>> behavior, as long as the implementation has documented it, so the
>>> above program could sing Dixie (as long as that is somehow
>>> documented).
>>
>> I am not. Let me repeat my earlier statement, with some extra
>> emphasis: But in any case the extension /does not change/ any
>> behavior for things that were there without the extension.
>
> The original claim was to be able to define uint8_t on a system with
> CHAR_BIT > 8 and have sizeof(uint8_t) have a value that acted like a
> value of 1/2 (if CHAR_BIT == 16). Unless UNDEFINED behavior has
> occurred, sizeof can not produce a trap value, and thus the math MUST
> proceed as defined, which doesn't allow for a value acting as 0.5
> (i.e. 1 / 2 == 0)
The extension is undersized objects and various types associated
with them. Any use of such types (and thus of the extension) is
automatically undefined behavior (and indeed any use of any
extension is by definition undefined behavior). Because sizeof
is being used on one of these non-standard types, which by their
very presence get things into the realm of undefined behavior,
sizeof may very well give an "unusual" (trap representation)
value.
>>>>> This
>>>>> effectively renders moot the concept of implementation defined
>>>>> behavior, as once that occurs (so the program isn't strictly
>>>>> conforming) the behavior becomes subject to arbitrary redefinition
>>>>> by an extension.
>>>>>
>>>>> I firmly believe that what is meant by the language on extensions
>>>>> is that an implementation is allowed to define meaning to code
>>>>> that by the standard is a constraint violation or has undefined
>>>>> behavior and define behavior for that code. In doing so, it might
>>>>> omit a "required" diagnostic (because the constraint violation has
>>>>> been replaced with the extension).
>>>>
>>>> This idea is not consistent with J.5.4, which I should mention was
>>>> present also in C90 (with slightly different section numbering).
>>>
>>> This extension makes an extern definition in a position that would
>>> normally be just block scope, now be visible to file scope. This
>>> does NOT break program that is valid by the standard. Such a
>>> program could not have referred to that identifier in another
>>> scope without adding a new definition, which would need to match
>>> the first one.
>>
>> This is wrong. In C90, remember, which has the same mention of
>> a common extension, functions could be declared implicitly. So
>> C90 establishes that extensions may change the behavior of
>> programs that are defined otherwise.
>
> 4p3 says:
> A program that is correct in all other aspects, operating on correct
> data, containing unspecified behavior shall be a correct program and
> act in accordance with 5.1.2.3.
>
> Which says, in effect, that unspecified behavior does NOT give the
> implementation license to deviate from the defined behavior.
I explained in my other response why 4p3 is not relevant.
> The fact that (in C90) that a function definition is created on the
> first call to that function, (with a defined definition base on the
> call). If the implied definition disagrees with the actual definition,
> the behavior is undefined. Thus the only difference would be in the
> case of undefined behavior.
For the first sentence, what I think you mean is declaration,
not definition. Is that right?
Assuming I understand what you're trying to say, the conclusion
is wrong. There are programs that have well-defined behavior
without the extension, but not with the extension.
>>>>> One limitation on extensions
>>>>> is that they can not use "user space" symbols (without the need to
>>>>> include a new header) so as to not change the meaning of a
>>>>> strictly conforming program.
>>>>
>>>> I believe that idea is not consistent with J.5.9 and J.5.10.
>>>> Do you agree?
>>>
>>> The 'fortran' function specifier does not exclude the ability to
>>> use fortran as a user symbol, so there is no conflict (the fact
>>> that the other function specifiers are universal keywords does not
>>> mean the fortran needs to be).
>>
>> The header on J.5.9 says "The fortran keyword". I take the
>> Standard at its word - it says keyword, it means keyword. If an
>> identifier is a keyword it can't be used as a normal identifier
>> (with the obvious exceptions involving macros). Why should it be
>> taken any differently? Can you cite any other passage in the
>> Standard, or any other WG14 official document, to support that
>> position?
>
> Since J.5 says
> The inclusion of any extension that may cause a strictly conforming
> program to become invalid renders an implementation
> nonconforming. Examples of such extensions are new keywords, extra
> library functions declared in standard headers, or predefined macros
> with names that do not begin with an underscore.
Note that these are potential conflicts, not guaranteed
conflicts. For example, standard headers may define extra
library functions as extensions.
> (The list of examples are clearly things that are NOT allowed, as
> affecting strictly conforming programs).
They clearly /might/ not be allowed. If they cause problems with
strictly conforming programs, they aren't, but as long as they
don't cause problems with strictly conforming programs, they are.
Do you agree?
> This means that a J.5.9 that actually makes fortran a global keyword
> is non-conforming by the standard (int fortran; is a valid statement
> in strictly conforming code, so you can't make it an error).
> [snip elaboration]
But fortran could be made a keyword just for programs that are
recognizable otherwise as not being strictly conforming. Do you
agree?
>>> Similarly for asm. Yes, this says that if you define a function
>>> called asm that can take a char const* parameter then you would
>>> effectively disable this extension.
>>
>> The header on J.5.10 also uses the term "keyword", as does the
>> body. What reason is there to think this use of "keyword" is
>> meant to be different from how else it is used in the Standard?
>> Again what I'm asking for is some specific citation.
>
> Again, refer to J.5
Same comment as above.
>>> As long as an confusion between a user symbol and the extension
>>> is resolved in treating it as the user symbol, the extension is
>>> valid.
>>
>> Even if that is true for strictly conforming programs, J.5.9 and
>> J.5.10 show that it is not true for non-strictly conforming
>> programs. But the extension I have described applies only to (some)
>> non-strictly conforming programs, so there is no conflict.
>
> If your extenuation changes the meaning of
>
> #include <stdint.h>
> #ifndef UINT8_MAX
> typedef unsigned char uint8_t;
> #endif
>
> and any later use of sizeof(uint8_t), even in the presence of
> implementation defined or unspecified behavior, it is NOT a conforming
> extension.
I believe this code runs afoul of 7.1.3 p1, because (as I
mentioned in my other reply) the name uint8_t is a reserved
name when #include <stdint.h> has been done.
> (unless you can show an explicit permission to change the
> defined behavior of sizeof and integral math among the options of
> behavior given). (See 4p3)
I explained in my other response why 4p3 is not relevant.
>>>>> In the case of the "extension" that started this discussion, the
>>>>> issue is that uint8_t has a number of properties guaranteed by the
>>>>> standard, and even if this type is tried to be made available
>>>>> under an extension, it still should meet those requirements.
>>>>
>>>> AFAIK there is only one requirement (an indirect one) that is not
>>>> met, namely that types have sizes that are integer multiples of
>>>> one. But the whole point of the extension is to provide types
>>>> that do not satisfy this property. In any case I believe the
>>>> Standard allows extensions to change the rules for things, as
>>>> evidenced by the citations from section J.5. Considering these
>>>> examples, does this change your position at all? Or are there
>>>> some other aspects I may have missed that you would like to point
>>>> out?
>>>
>>> Being an integral multiple of 1 is sort of the definition of an
>>> integral type.
>>
>> Certainly the Standard requires integral types to be able to
>> represent (some range of) integers, but nothing in the Standard
>> precludes the possibility that other values may be denoted.
>> Indeed the explicit mention of trap representations and undefined
>> behavior for them shows that such values /can/ be denoted, if an
>> implementation so chooses.
>
> Yes, trap representations can do anything as undefined behavior, but
> you can only GET a trap representation by performing undefined
> behavior. sizeof(type) (assuming type is a valid type) has defined
> behavior, so can NOT produce a trap value. The only excuse to not
> follow such defined behavior is the presence of undefined behavior.
The point of the extension is to provide types that are not
standard types. So the assumption that the type is a "valid
type" (by which I assume you mean regular C type) does not
hold in this case.
>>> You have yet to show a case where the standard give the right to
>>> the implementation to violate the standard required behavior, when
>>> the standard has defined the behavior.
>>
>> There isn't anything in the Standard that says it can't, as long
>> as no strictly conforming program has its behavior changed. In
>> any case I will repeat again: the extension I have described
>> /does not change/ any behavior for things that were there without
>> the extension, which makes the objection moot.
>
> 4p3 says that, without undefined behavior, even the presence of
> unspecified behavior does not allow the implementation to deviate from
> the behavior that has been defined.
I explained in my other response why 4p3 is not relevant.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-07-11 17:50 -0400 |
| Message-ID | <Hcgox.188449$1l7.175131@fx29.iad> |
| In reply to | #65288 |
On 7/11/15 11:21 AM, Tim Rentsch wrote: > 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. > What would sizeof uint8_t be then?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-20 06:36 -0700 |
| Message-ID | <kfnfv4josrq.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65344 |
Richard Damon <Richard@Damon-Family.org> writes: > On 7/11/15 11:21 AM, Tim Rentsch wrote: > >> 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. > > What would sizeof uint8_t be then? If CHAR_BIT were 16, for example, sizeof (uint8_t) would be 0.5. That is, size_t would have padding bits and trap representations, some of which would be used to provided non-integral sizes.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-07-20 15:14 +0000 |
| Message-ID | <55ad0f7b.17668765@news.xs4all.nl> |
| In reply to | #65982 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > Richard Damon <Richard@Damon-Family.org> writes: > > > On 7/11/15 11:21 AM, Tim Rentsch wrote: > > > >> 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. > > > > What would sizeof uint8_t be then? > > If CHAR_BIT were 16, for example, sizeof (uint8_t) would be 0.5. > That is, size_t would have padding bits and trap representations, > some of which would be used to provided non-integral sizes. If CHAR_BIT is 16, uint8_t is not allowed to exist. On a system like that, you just can't deal with 8-bit entities directly, any more than you can deal with 4-bit entities on a "normal" 8-bit system. (uint_least8_t, of course, still can exist, and in fact must.) Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-24 09:38 -0700 |
| Message-ID | <kfnvbd9h5o6.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66000 |
raltbos@xs4all.nl (Richard Bos) writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> Richard Damon <Richard@Damon-Family.org> writes: >> >>> On 7/11/15 11:21 AM, Tim Rentsch wrote: >>> >>>> 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. >>> >>> What would sizeof uint8_t be then? >> >> If CHAR_BIT were 16, for example, sizeof (uint8_t) would be 0.5. >> That is, size_t would have padding bits and trap representations, >> some of which would be used to provided non-integral sizes. > > If CHAR_BIT is 16, uint8_t is not allowed to exist. On a system like > that, you just can't deal with 8-bit entities directly, any more than > you can deal with 4-bit entities on a "normal" 8-bit system. > (uint_least8_t, of course, still can exist, and in fact must.) I believe the Standard does allow types narrower than CHAR_BIT bits to exist, if they are provided as an extension. Do you disagree with that?
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-07-25 19:12 +0000 |
| Message-ID | <55b3def1.7238062@news.xs4all.nl> |
| In reply to | #66286 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > raltbos@xs4all.nl (Richard Bos) writes: > > > Tim Rentsch <txr@alumni.caltech.edu> wrote: > > > >> Richard Damon <Richard@Damon-Family.org> writes: > >> > >>> On 7/11/15 11:21 AM, Tim Rentsch wrote: > >>> > >>>> 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. > >>> > >>> What would sizeof uint8_t be then? > >> > >> If CHAR_BIT were 16, for example, sizeof (uint8_t) would be 0.5. > >> That is, size_t would have padding bits and trap representations, > >> some of which would be used to provided non-integral sizes. > > > > If CHAR_BIT is 16, uint8_t is not allowed to exist. On a system like > > that, you just can't deal with 8-bit entities directly, any more than > > you can deal with 4-bit entities on a "normal" 8-bit system. > > (uint_least8_t, of course, still can exist, and in fact must.) > > I believe the Standard does allow types narrower than > CHAR_BIT bits to exist, if they are provided as an > extension. Do you disagree with that? Yes, for the reasons Richard D explains upthread: it would mess with the behaviour of sizeof. More specifically in this case, sizeof uint8_t would simultaneously have to be 1 and smaller than 1, _or_ uint8_t must have padding bits. The first is impossible, the latter illegal. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-30 12:18 -0700 |
| Message-ID | <kfnmvydcv4f.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66350 |
raltbos@xs4all.nl (Richard Bos) writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> raltbos@xs4all.nl (Richard Bos) writes: >> >>> Tim Rentsch <txr@alumni.caltech.edu> wrote: >>> >>>> Richard Damon <Richard@Damon-Family.org> writes: >>>> >>>>> On 7/11/15 11:21 AM, Tim Rentsch wrote: >>>>> >>>>>> 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. >>>>> >>>>> What would sizeof uint8_t be then? >>>> >>>> If CHAR_BIT were 16, for example, sizeof (uint8_t) would be 0.5. >>>> That is, size_t would have padding bits and trap representations, >>>> some of which would be used to provided non-integral sizes. >>> >>> If CHAR_BIT is 16, uint8_t is not allowed to exist. On a system like >>> that, you just can't deal with 8-bit entities directly, any more than >>> you can deal with 4-bit entities on a "normal" 8-bit system. >>> (uint_least8_t, of course, still can exist, and in fact must.) >> >> I believe the Standard does allow types narrower than >> CHAR_BIT bits to exist, if they are provided as an >> extension. Do you disagree with that? > > Yes, for the reasons Richard D explains upthread: it would mess > with the behaviour of sizeof. > > More specifically in this case, sizeof uint8_t would > simultaneously have to be 1 and smaller than 1, _or_ uint8_t must > have padding bits. The first is impossible, the latter illegal. I have responded now to two of his postings explaining how this would work. I'm interested to hear any further comments you might have.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-11 17:03 -0700 |
| Message-ID | <lnwpy6nsxq.fsf@kst-u.example.com> |
| In reply to | #65288 |
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.
> 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.
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-12 00:15 +0000 |
| Message-ID | <mnsbi7$ckb$1@speranza.aioe.org> |
| In reply to | #65370 |
Keith Thompson <kst-u@mib.org> wrote: > Tim Rentsch <txr@alumni.caltech.edu> writes: (snip) > 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. >> 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. Hmm. Consider CHAR_BIT > 8, and unsigned char such that values greater than 255 are allowed. Now consider uint8_t that doesn't allow such, but treats all operations modulo 256. The two are otherwise the same, but the latter forces the result to be modulo 256, and so is slower. The only machine I have an account on with CHAR_BIT > 8 is a PDP-10, but I haven't tried much of this. I suspect it doesn't have uint8_t. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-11 17:42 -0700 |
| Message-ID | <ln7fq6nr3q.fsf@kst-u.example.com> |
| In reply to | #65373 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
> (snip)
>> 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.
>
>>> 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.
>
> Hmm. Consider CHAR_BIT > 8, and unsigned char such that values
> greater than 255 are allowed. Now consider uint8_t that doesn't
> allow such, but treats all operations modulo 256. The two are
> otherwise the same, but the latter forces the result to be
> modulo 256, and so is slower.
>
> The only machine I have an account on with CHAR_BIT > 8 is
> a PDP-10, but I haven't tried much of this. I suspect it
> doesn't have uint8_t.
I'd be surprised if it had a C compiler that supports C99 or later.
The uintN_t types are not allowed to have padding bits.
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-12 02:46 +0000 |
| Message-ID | <mnskdn$qnv$2@speranza.aioe.org> |
| In reply to | #65381 |
Keith Thompson <kst-u@mib.org> wrote: (snip, I wrote) >> The only machine I have an account on with CHAR_BIT > 8 is >> a PDP-10, but I haven't tried much of this. I suspect it >> doesn't have uint8_t. > I'd be surprised if it had a C compiler that supports C99 or later. > The uintN_t types are not allowed to have padding bits. I thought it was doing pretty well to have a C compiler at all. That one is TOPS-20, there might not be a C compiler for TOPS-10. -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-12 12:33 -0400 |
| Message-ID | <55A296F7.3040804@verizon.net> |
| In reply to | #65373 |
On 07/11/2015 08:15 PM, glen herrmannsfeldt wrote: > Keith Thompson <kst-u@mib.org> wrote: >> 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. > > Hmm. Consider CHAR_BIT > 8, and unsigned char such that values > greater than 255 are allowed. Now consider uint8_t that doesn't > allow such, but treats all operations modulo 256. The two are > otherwise the same, but the latter forces the result to be > modulo 256, and so is slower. You've just described a uint8_t with 8 value bits and CHAR_BIT-8 padding bits. Padding bits are not allowed in the exact-width types.
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web