Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.std.c > #6321 > unrolled thread
| Started by | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| First post | 2021-09-30 01:47 +0000 |
| Last post | 2021-09-30 03:20 +0100 |
| Articles | 20 on this page of 80 — 10 participants |
Back to article view | Back to comp.std.c
contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-09-30 01:47 +0000
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-29 19:05 -0700
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-09-30 11:24 +0000
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-30 08:38 -0700
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-01 09:05 +0000
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-01 12:20 -0700
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-04 09:26 +0000
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-04 10:34 -0700
Re: contradiction about the INFINITY macro Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2021-10-05 13:53 +0100
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-06 00:12 +0000
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-07 07:05 -0700
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-07 07:51 -0700
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-08 11:41 -0700
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-09 19:49 +0000
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-09 14:28 -0700
Re: contradiction about the INFINITY macro Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2021-10-01 22:55 +0200
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-01 14:26 -0700
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-08 08:30 -0700
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-08 11:40 -0700
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-17 21:00 -0800
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-09 20:05 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-11 12:40 -0400
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-17 21:02 -0800
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-08 00:02 -0700
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-09 20:17 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-11 12:40 -0400
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-11 12:39 -0700
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-11 21:04 -0400
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-11 18:33 -0700
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-03 12:03 -0800
Re: contradiction about the INFINITY macro Richard Damon <Richard@Damon-Family.org> - 2022-01-03 16:45 -0500
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-03 14:36 -0800
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-04 02:10 -0500
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 10:09 -0800
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-03 11:55 -0800
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-26 10:01 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 12:53 -0400
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-28 09:38 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-28 11:23 -0400
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-10-29 12:12 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-30 02:08 -0400
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-08 02:44 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-08 01:46 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-08 10:56 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-08 13:50 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-09 02:48 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-09 00:50 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-09 10:12 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-09 12:51 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-10 12:48 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-10 12:03 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-12 23:17 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-12 21:03 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-15 09:18 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-15 14:25 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-16 01:17 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-16 10:29 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-12-08 10:09 +0000
Re: contradiction about the INFINITY macro Derek Jones <derek@NOSPAM-knosof.co.uk> - 2021-11-16 11:32 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-16 10:35 -0500
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-11-09 07:13 -0800
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-10 13:16 +0000
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-11-10 08:02 -0800
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-10 15:01 -0800
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-13 00:30 +0000
Re: contradiction about the INFINITY macro Thomas Koenig <tkoenig@netcologne.de> - 2021-12-02 22:14 +0000
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-03 12:48 -0800
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-12 23:55 +0000
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-11-15 07:59 -0800
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-15 23:39 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-15 20:00 -0500
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-16 01:28 +0000
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-11-16 01:57 +0000
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-16 09:52 -0500
Re: contradiction about the INFINITY macro Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-16 19:00 -0800
Re: contradiction about the INFINITY macro Vincent Lefevre <vincent-news@vinc17.net> - 2021-12-08 10:56 +0000
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-03 12:56 -0800
Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-03 22:45 -0800
Re: contradiction about the INFINITY macro Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 05:35 -0800
Re: contradiction about the INFINITY macro Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-30 03:20 +0100
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-11-09 07:13 -0800 |
| Message-ID | <861r3pbbwh.fsf@linuxsc.com> |
| In reply to | #6346 |
Vincent Lefevre <vincent-news@vinc17.net> writes: > In article <86wnmoov7c.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> What occurs is defined behavior and (for implementations that do >> not have the needed value for infinity) violates a constraint. >> A diagnostic must be produced. > > If this is defined behavior, where is the result of an overflow > defined by the standard? (I can see only 7.12.1p5, but this is > for math functions; here, this is a constant that overflows.) I'm wondering if you have resolved your original uncertainty about the behavior of INFINITY in an implementation that does not support infinities?
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-11-10 13:16 +0000 |
| Message-ID | <20211110124948$eea4@zira.vinc17.org> |
| In reply to | #6371 |
In article <861r3pbbwh.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Vincent Lefevre <vincent-news@vinc17.net> writes:
> > In article <86wnmoov7c.fsf@linuxsc.com>,
> > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> >
> >> What occurs is defined behavior and (for implementations that do
> >> not have the needed value for infinity) violates a constraint.
> >> A diagnostic must be produced.
> >
> > If this is defined behavior, where is the result of an overflow
> > defined by the standard? (I can see only 7.12.1p5, but this is
> > for math functions; here, this is a constant that overflows.)
> I'm wondering if you have resolved your original uncertainty
> about the behavior of INFINITY in an implementation that does
> not support infinities?
I suspect that by saying "overflow", the standard actually meant that
the result is not in the range of representable values. This is the
only way the footnote "In this case, using INFINITY will violate the
constraint in 6.4.4 and thus require a diagnostic." can make sense
(the constraint in 6.4.4 is about the range, not overflow). But IMHO,
the failing constraint makes the behavior undefined, actually makes
the program erroneous.
Similarly, on
static int i = 1 / 0;
int main (void)
{
return 0;
}
GCC fails to translate the program due to the failing constraint:
tst.c:1:16: error: initializer element is not constant
1 | static int i = 1 / 0;
| ^
(this is not just a diagnostic, GCC does not generate an executable).
Ditto with Clang:
tst.c:1:18: error: initializer element is not a compile-time constant
static int i = 1 / 0;
~~^~~
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-11-10 08:02 -0800 |
| Message-ID | <86wnlg9ey7.fsf@linuxsc.com> |
| In reply to | #6374 |
Vincent Lefevre <vincent-news@vinc17.net> writes:
> In article <861r3pbbwh.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>>
>>> In article <86wnmoov7c.fsf@linuxsc.com>,
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> What occurs is defined behavior and (for implementations that do
>>>> not have the needed value for infinity) violates a constraint.
>>>> A diagnostic must be produced.
>>>
>>> If this is defined behavior, where is the result of an overflow
>>> defined by the standard? (I can see only 7.12.1p5, but this is
>>> for math functions; here, this is a constant that overflows.)
>>
>> I'm wondering if you have resolved your original uncertainty
>> about the behavior of INFINITY in an implementation that does
>> not support infinities?
>
> I suspect that by saying "overflow", the standard actually meant that
> the result is not in the range of representable values. This is the
> only way the footnote "In this case, using INFINITY will violate the
> constraint in 6.4.4 and thus require a diagnostic." can make sense
> (the constraint in 6.4.4 is about the range, not overflow). But IMHO,
> the failing constraint makes the behavior undefined, actually makes
> the program erroneous.
Suppose we have an implementation that does not support
infinities, a range of double and long double up to about ten to
the 99999, and ask it to translate the following .c file
double way_too_big = 1.e1000000;
This constant value violates the constraint in 6.4.4. Do you
think this .c file (and any program it is part of) has undefined
behavior? If so, do you think any constraint violation implies
undefined behavior, or just some of them?
> Similarly, on
>
> static int i = 1 / 0;
> int main (void)
> {
> return 0;
> }
>
> GCC fails to translate the program due to the failing constraint:
>
> tst.c:1:16: error: initializer element is not constant
> 1 | static int i = 1 / 0;
> | ^
>
> (this is not just a diagnostic, GCC does not generate an
> executable).
Note that the C standard does not distinguish between "errors"
and "warnings" in diagnostic messages. Either is allowed
regardless of whether undefined behavior is present.
> Ditto with Clang:
>
> tst.c:1:18: error: initializer element is not a compile-time constant
> static int i = 1 / 0;
> ~~^~~
The messages indicate that the failure is not about exceeding the
range of a type, but rather about satisfying the constraints for
constant expressions, in particular 6.6 p4, which says in part
Each constant expression shall evaluate to a constant [...]
The problem here is that 1/0 doesn't evaluate to anything,
because division by 0 is not defined. Any question of range of
representable values doesn't enter into it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-11-10 15:01 -0800 |
| Message-ID | <87fss3wr6t.fsf@nosuchdomain.example.com> |
| In reply to | #6375 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Vincent Lefevre <vincent-news@vinc17.net> writes:
>> In article <861r3pbbwh.fsf@linuxsc.com>,
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>>>> In article <86wnmoov7c.fsf@linuxsc.com>,
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>>> What occurs is defined behavior and (for implementations that do
>>>>> not have the needed value for infinity) violates a constraint.
>>>>> A diagnostic must be produced.
>>>>
>>>> If this is defined behavior, where is the result of an overflow
>>>> defined by the standard? (I can see only 7.12.1p5, but this is
>>>> for math functions; here, this is a constant that overflows.)
>>>
>>> I'm wondering if you have resolved your original uncertainty
>>> about the behavior of INFINITY in an implementation that does
>>> not support infinities?
>>
>> I suspect that by saying "overflow", the standard actually meant that
>> the result is not in the range of representable values. This is the
>> only way the footnote "In this case, using INFINITY will violate the
>> constraint in 6.4.4 and thus require a diagnostic." can make sense
>> (the constraint in 6.4.4 is about the range, not overflow). But IMHO,
>> the failing constraint makes the behavior undefined, actually makes
>> the program erroneous.
>
> Suppose we have an implementation that does not support
> infinities, a range of double and long double up to about ten to
> the 99999, and ask it to translate the following .c file
>
> double way_too_big = 1.e1000000;
>
> This constant value violates the constraint in 6.4.4. Do you
> think this .c file (and any program it is part of) has undefined
> behavior? If so, do you think any constraint violation implies
> undefined behavior, or just some of them?
(Jumping in though the question was addressed to someone else.)
I think it's a tricky question. I think the language would be cleaner
if the standard explicitly stated that violating a constraint always
results in undefined behavior -- or if it explicitly stated that it
doesn't. (The former is my personal preference.)
Clearly a compiler is allowed (but not required) to reject a program
that violates a constraint. If it does so, there is no behavior. So
the question is whether the behavior is undefined if the implementation
chooses not to reject it. (I personally don't see a whole lot of value
in defining the behavior of code that could have been rejected outright.
I'm also not a big fan of the fact that required diagnostics don't have
to be fatal, but that's not likely to change.)
The semantics of floating constants specify that the value is "either
the nearest representable value, or the larger or smaller representable
value immediately adjacent to the nearest representable value, chosen in
an implementation-defined manner". Given that infinities are not
supported, that would be DBL_MAX or its predecessor. Based on that, I'd
say that:
- A diagnostic is required.
- A compiler may reject the program.
- If the compiler doesn't reject the program, the value of way_too_big
must be DBL_MAX or its predecessor. (Making it the predecessor of
DBL_MAX would be weird but conforming.)
*Except* that the definition of "constraint" is "restriction, either
syntactic or semantic, by which the exposition of language elements is
to be interpreted". I find that rather vague, but it could be
interpreted to mean that if a constraint is violated, there is no valid
interpretation of language elements.
Rejecting 1.e1000000 with a fatal diagnostic is clearly conforming.
Issuing a non-fatal warning for 1.e1000000 and setting way_too_big to
DBL_MAX is conforming (even if the behavior is/were undefined, that's
perfectly valid).
An implementation that issues a non-fatal warning for 1.e1000000 and
sets way_too_big to 42.0 is arguably non-conforming, but if its
implementers argue that the behavior is undefined because of their
interpretation of the standard's definition of "constraint", I'd have a
hard time claiming they're wrong.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-11-13 00:30 +0000 |
| Message-ID | <20211112235943$2d67@zira.vinc17.org> |
| In reply to | #6377 |
In article <87fss3wr6t.fsf@nosuchdomain.example.com>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > I think it's a tricky question. I think the language would be cleaner > if the standard explicitly stated that violating a constraint always > results in undefined behavior -- or if it explicitly stated that it > doesn't. (The former is my personal preference.) I agree. But note that there's this definition: 3.8 constraint restriction, either syntactic or semantic, by which the exposition of language elements is to be interpreted As I understand, if such a restriction is not fulfilled, then there is no interpretation; hence undefined behavior (or program rejection). But DR 261 says that if one can do without having to use an unsatisfied constraint, then this is fine. For instance, 1 / 0 is not regarded as a constant expression, just as a "normal" expression, because it fails to satisfy constraint 6.6p4 on constant expressions. (In a context of a required constant expression, there will be undefined behavior or the program will be rejected, whether the expression is not regarded as a constant expression or one just considers the failed constraint.) > The semantics of floating constants specify that the value is "either > the nearest representable value, or the larger or smaller representable > value immediately adjacent to the nearest representable value, chosen in > an implementation-defined manner". Given that infinities are not > supported, that would be DBL_MAX or its predecessor. Based on that, I'd > say that: > - A diagnostic is required. > - A compiler may reject the program. > - If the compiler doesn't reject the program, the value of way_too_big > must be DBL_MAX or its predecessor. (Making it the predecessor of > DBL_MAX would be weird but conforming.) > *Except* that the definition of "constraint" is "restriction, either > syntactic or semantic, by which the exposition of language elements is > to be interpreted". I find that rather vague, but it could be > interpreted to mean that if a constraint is violated, there is no valid > interpretation of language elements. Yes, this is rather vague, but I think that this should be regarded as undefined behavior (but nothing prevents the implementation from defining the behavior). Note that this would allow an implementation to leave the variable as uninitialized[*], assuming that if the user wants to use the program despite the diagnostic, the program will work perfectly as long as the variable is not used. [*] A possible justification is that if the user defined a variable whose initializer doesn't make sense on some plarform, this can mean that this variable will never be used on such a plarform, e.g. as being used in dead code only. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2021-12-02 22:14 +0000 |
| Message-ID | <sobggj$npq$1@newsreader4.netcologne.de> |
| In reply to | #6377 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> schrieb: > I think it's a tricky question. I think the language would be cleaner > if the standard explicitly stated that violating a constraint always > results in undefined behavior -- or if it explicitly stated that it > doesn't. (The former is my personal preference.) Other language standards use different concepts, and maybe the C standard could be improved by adopting them. The Fortran standard, for example, has numbered constraints and general prohibitions or requirements, denoted by "shall not" and "shall", respectively. If a numbered constraint is violated, the compiler has to detect and report this. If it fails to do so, it's a compiler bug. This is usually done for things that can easily be checked at compile time. If a "shall" or "shall not" directive is violated, then this is a bug in the program, and quite specifically the programmer's fault. A compiler may or may not report an error, this is then mostly a quality of implementation issue, and often a tradeoff with execution speed. It's cleaner than what C has, IMHO.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-03 12:48 -0800 |
| Message-ID | <86k0fgy287.fsf@linuxsc.com> |
| In reply to | #6377 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Vincent Lefevre <vincent-news@vinc17.net> writes: >> >>> In article <861r3pbbwh.fsf@linuxsc.com>, >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> Vincent Lefevre <vincent-news@vinc17.net> writes: >>>> >>>>> In article <86wnmoov7c.fsf@linuxsc.com>, >>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>>> >>>>>> What occurs is defined behavior and (for implementations that do >>>>>> not have the needed value for infinity) violates a constraint. >>>>>> A diagnostic must be produced. >>>>> >>>>> If this is defined behavior, where is the result of an overflow >>>>> defined by the standard? (I can see only 7.12.1p5, but this is >>>>> for math functions; here, this is a constant that overflows.) >>>> >>>> I'm wondering if you have resolved your original uncertainty >>>> about the behavior of INFINITY in an implementation that does >>>> not support infinities? >>> >>> I suspect that by saying "overflow", the standard actually meant that >>> the result is not in the range of representable values. This is the >>> only way the footnote "In this case, using INFINITY will violate the >>> constraint in 6.4.4 and thus require a diagnostic." can make sense >>> (the constraint in 6.4.4 is about the range, not overflow). But IMHO, >>> the failing constraint makes the behavior undefined, actually makes >>> the program erroneous. >> >> Suppose we have an implementation that does not support >> infinities, a range of double and long double up to about ten to >> the 99999, and ask it to translate the following .c file >> >> double way_too_big = 1.e1000000; >> >> This constant value violates the constraint in 6.4.4. Do you >> think this .c file (and any program it is part of) has undefined >> behavior? If so, do you think any constraint violation implies >> undefined behavior, or just some of them? > > (Jumping in though the question was addressed to someone else.) > > I think it's a tricky question. I think the language would be > cleaner if the standard explicitly stated that violating a > constraint always results in undefined behavior -- or if it > explicitly stated that it doesn't. (The former is my personal > preference.) Here are some statements that I believe are true: 1. The C standard has no statement that says directly that constraint violations result in undefined behavior. 2. The definition of "constraint" in the C standard is ambiguous and does not have a single objective meaning. 3. There are no indications (at least none that I am aware of) in the C standard, or any other official writing of the WG14 group, of what meaning is intended by the ISO C group for the question in question. > Clearly a compiler is allowed (but not required) to reject a program > that violates a constraint. If it does so, there is no behavior. Same comment as I gave in my other recent posting - programs have behavior, in the sense used in the C standard, regardless of whether any implementation accepts or rejects them. (The behavior may be "undefined behavior".) > So the question is whether the behavior is undefined if the > implementation chooses not to reject it. (I personally don't see a > whole lot of value in defining the behavior of code that could have > been rejected outright. Again, there are lots of constructs that clearly have defined behavior, and yet implementations can choose to reject them. > I'm also not a big fan of the fact that > required diagnostics don't have to be fatal, but that's not likely > to change.) IMO this view is short sighted. Implementations are allowed to define extensions as long as they are documented and don't change the meaning of any strictly conforming program. If any required diagnostic has to be fatal, that would disallow all kinds of useful extensions. Speaking just for myself, I would like implementations to provide an option under which any required diagnostic would result in the program being rejected. But only an option, and in any case that is in the area of QOI issues, which the C standard has explicitly chosen not to address. > [analysis of possible interpretations of the above code fragment] My question was only about whether there is undefined behavior.
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-11-12 23:55 +0000 |
| Message-ID | <20211112231854$195e@zira.vinc17.org> |
| In reply to | #6375 |
In article <86wnlg9ey7.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Suppose we have an implementation that does not support
> infinities, a range of double and long double up to about ten to
> the 99999, and ask it to translate the following .c file
> double way_too_big = 1.e1000000;
> This constant value violates the constraint in 6.4.4. Do you
> think this .c file (and any program it is part of) has undefined
> behavior? If so, do you think any constraint violation implies
> undefined behavior, or just some of them?
I think that constraints are there to define conditions under which
specifications make sense. Thus, if a constraint is not satisfied,
behavior is undefined (unless the standard *specifically* defines
cases for which the constraint would not be satisfied; this is true
for other kinds of undefined behavior, such as with Annex F, which
defines the result of 1.0 / 0.0).
That's also why there are diagnostics, which would otherwise be
useless in the standard.
In case this is not clear, the intent of the diagnostic in the above
case is not about an inaccuracy, because the inaccuracy also exists
when infinities are supported (and in this case, the constraint is
satisfied, i.e. no required diagnostics).
> > Similarly, on
> >
> > static int i = 1 / 0;
> > int main (void)
> > {
> > return 0;
> > }
> >
> > GCC fails to translate the program due to the failing constraint:
> >
> > tst.c:1:16: error: initializer element is not constant
> > 1 | static int i = 1 / 0;
> > | ^
> >
> > (this is not just a diagnostic, GCC does not generate an
> > executable).
> Note that the C standard does not distinguish between "errors"
> and "warnings" in diagnostic messages. Either is allowed
> regardless of whether undefined behavior is present.
Agreed (but I think that GCC will generally generate an error
when this is undefined behavior, though one needs -pedantic-errors
to make sure that no extensions are used to define things that
are normally undefined).
> > Ditto with Clang:
> >
> > tst.c:1:18: error: initializer element is not a compile-time constant
> > static int i = 1 / 0;
> > ~~^~~
> The messages indicate that the failure is not about exceeding the
> range of a type, but rather about satisfying the constraints for
> constant expressions, in particular 6.6 p4, which says in part
> Each constant expression shall evaluate to a constant [...]
Yes, this was my point.
> The problem here is that 1/0 doesn't evaluate to anything,
> because division by 0 is not defined. Any question of range of
> representable values doesn't enter into it.
My point is that 1 / 0 is not regarded as a constant expression
(here because 1 / 0 isn't mathematically defined, but the cause
could also be that the result is out of range, as seen below).
Ditto with
static int i = 2147483647 + 2147483647;
but -pedantic-errors is needed as I've said above. On
int main (void)
{
static int i = 2147483647 + 2147483647;
return 0;
}
"gcc -pedantic-errors" gives
tst.c:3:3: error: overflow in constant expression [-Woverflow]
3 | static int i = 2147483647 + 2147483647;
| ^~~~~~
but no errors (= no diagnostics due to a failing constraint) for
int main (void)
{
int i = 2147483647 + 2147483647;
return 0;
}
because 2147483647 + 2147483647 is not regarded as a constant
expression (as explained in DR 261).
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-11-15 07:59 -0800 |
| Message-ID | <86v90t8l6j.fsf@linuxsc.com> |
| In reply to | #6379 |
Vincent Lefevre <vincent-news@vinc17.net> writes:
> In article <86wnlg9ey7.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Suppose we have an implementation that does not support
>> infinities, a range of double and long double up to about ten to
>> the 99999, and ask it to translate the following .c file
>>
>> double way_too_big = 1.e1000000;
>>
>> This constant value violates the constraint in 6.4.4. Do you
>> think this .c file (and any program it is part of) has undefined
>> behavior? If so, do you think any constraint violation implies
>> undefined behavior, or just some of them?
>
> I think that constraints are there to define conditions under which
> specifications make sense. Thus, if a constraint is not satisfied,
> behavior is undefined [...]
Suppose again we have an implementation that does not support
infinities and has a range of double and long double up to about
ten to the 99999. Question one: as far as the C standard is
concerned, is the treatment of this .c file
double way_too_big = 1.e1000000;
and of this .c file
#include <math.h>
double way_too_big = INFINITY;
the same in the two cases? (The question is meant to disregard
differences that are purely implementation choices, as for
example possibly labelling one case a "warning" and the other
case an "error".)
Question two: does the C standard require that at least one
diagnostic be issued for each of the above .c files?
Note that both of these are yes/no questions.
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-11-15 23:39 +0000 |
| Message-ID | <20211115233426$5e8a@zira.vinc17.org> |
| In reply to | #6383 |
In article <86v90t8l6j.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Suppose again we have an implementation that does not support > infinities and has a range of double and long double up to about > ten to the 99999. Question one: as far as the C standard is > concerned, is the treatment of this .c file > double way_too_big = 1.e1000000; > and of this .c file > #include <math.h> > double way_too_big = INFINITY; > the same in the two cases? IMHO, this is undefined behavior in both cases, due to the unsatisfied constraint. So, yes. > Question two: does the C standard require that at least one > diagnostic be issued for each of the above .c files? Yes: The constraint is unsatisfied in both cases, so at least one diagnostic is required in both cases. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-11-15 20:00 -0500 |
| Message-ID | <smuvs5$6qh$1@dont-email.me> |
| In reply to | #6385 |
On 11/15/21 6:39 PM, Vincent Lefevre wrote: > In article <86v90t8l6j.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Suppose again we have an implementation that does not support >> infinities and has a range of double and long double up to about >> ten to the 99999. Question one: as far as the C standard is >> concerned, is the treatment of this .c file > >> double way_too_big = 1.e1000000; > >> and of this .c file > >> #include <math.h> > >> double way_too_big = INFINITY; > >> the same in the two cases? > > IMHO, this is undefined behavior in both cases, due to the > unsatisfied constraint. So, yes. So, of the three ways used by the standard to indicate that the behavior is undefined, which one was used in this case? "If a "shall" or "shall not" requirement that appears outside of a constraint or runtime-constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this document by the words "undefined behavior" or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe "behavior that is undefined"." (4p2). If it's a "shall" or an explicit "undefined behavior", please identify the clause containing those words.
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-11-16 01:28 +0000 |
| Message-ID | <20211116011941$1337@zira.vinc17.org> |
| In reply to | #6386 |
In article <smuvs5$6qh$1@dont-email.me>, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > On 11/15/21 6:39 PM, Vincent Lefevre wrote: > > In article <86v90t8l6j.fsf@linuxsc.com>, > > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > > > >> Suppose again we have an implementation that does not support > >> infinities and has a range of double and long double up to about > >> ten to the 99999. Question one: as far as the C standard is > >> concerned, is the treatment of this .c file > > > >> double way_too_big = 1.e1000000; > > > >> and of this .c file > > > >> #include <math.h> > > > >> double way_too_big = INFINITY; > > > >> the same in the two cases? > > > > IMHO, this is undefined behavior in both cases, due to the > > unsatisfied constraint. So, yes. > So, of the three ways used by the standard to indicate that the behavior > is undefined, which one was used in this case? > "If a "shall" or "shall not" requirement that appears outside of a > constraint or runtime-constraint is violated, the behavior is undefined. > Undefined behavior is otherwise indicated in this document by the words > "undefined behavior" or by the omission of any explicit definition of > behavior. There is no difference in emphasis among these three; they all > describe "behavior that is undefined"." (4p2). Omission of any explicit definition of behavior. There is a constraint (restriction) that is not satisfied. Thus the code becomes invalid and nothing gets defined as a consequence. This is like, in math, applying a theorem where the hypotheses are not satisfied. I would expect the implementation to reject the code, or accept it in a way unspecified by the standard (but the implementation could document what happens, as an extension). -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-11-16 01:57 +0000 |
| Message-ID | <20211116015308$51d0@zira.vinc17.org> |
| In reply to | #6388 |
In article <20211116011941$1337@zira.vinc17.org>, Vincent Lefevre <vincent-news@vinc17.net> wrote: > I would expect the implementation to reject the code, or accept it > in a way unspecified by the standard (but the implementation could > document what happens, as an extension). As a useful example, I would say that an implementation that doesn't support infinities but has NaNs would be allow to track out-of-range values to try to emulate infinities (e.g. for safety reasons). For instance, INFINITY - INFINITY could yield NaN instead of 0. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-11-16 09:52 -0500 |
| Message-ID | <sn0gjr$vpv$1@dont-email.me> |
| In reply to | #6388 |
On 11/15/21 8:28 PM, Vincent Lefevre wrote: > In article <smuvs5$6qh$1@dont-email.me>, > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > >> On 11/15/21 6:39 PM, Vincent Lefevre wrote: >>> In article <86v90t8l6j.fsf@linuxsc.com>, >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> Suppose again we have an implementation that does not support >>>> infinities and has a range of double and long double up to about >>>> ten to the 99999. Question one: as far as the C standard is >>>> concerned, is the treatment of this .c file >>> >>>> double way_too_big = 1.e1000000; >>> >>>> and of this .c file >>> >>>> #include <math.h> >>> >>>> double way_too_big = INFINITY; >>> >>>> the same in the two cases? >>> >>> IMHO, this is undefined behavior in both cases, due to the >>> unsatisfied constraint. So, yes. > >> So, of the three ways used by the standard to indicate that the behavior >> is undefined, which one was used in this case? > >> "If a "shall" or "shall not" requirement that appears outside of a >> constraint or runtime-constraint is violated, the behavior is undefined. >> Undefined behavior is otherwise indicated in this document by the words >> "undefined behavior" or by the omission of any explicit definition of >> behavior. There is no difference in emphasis among these three; they all >> describe "behavior that is undefined"." (4p2). > > Omission of any explicit definition of behavior. The fact that a constraint is violated does not erase the definition provided by 6.4.4.2p4, or render it any less applicable. > ... There is a constraint > (restriction) that is not satisfied. Agreed. > ... Thus the code becomes invalid and > nothing gets defined as a consequence. This is, I presume, what makes you think that 6.4.4.2p4 is effectively erased? The standard says nothing to that effect. The only meaningful thing it says is that a diagnostic is required (5.1.1.3p1). I do not consider the standard's definition of "constraint" to be meaningful: "restriction, either syntactic or semantic, by which the exposition of language elements is to be interpreted" (3.8). What that sentence means,if anything, is not at all clear, but one thing is clear - it says nothing about what should happen if the restriction is violated. 5.1.1.3p1 is the only clause that says anything about that issue. Note: the requirement specified in 5.1.1.3p1 would also be erased, if a constraint violation is considered to effectively erase unspecified parts of the rest of the standard. Surely you don't claim that 3.8 specifies which parts get erased? > I would expect the implementation to reject the code, or accept it > in a way unspecified by the standard (but the implementation could > document what happens, as an extension). While an implementation is not required to accept and translate such code (that's only required for the "one program"), if it does translate such code, then (in the absence of any other problems) the resulting executable must produce the same observable behavior as if such a constant was given a value of either DBL_MAX or nextdown(DBL_MAX) - any other result fails to meet the requirements of 6.4.4.2p4.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-11-16 19:00 -0800 |
| Message-ID | <87pmqzv64t.fsf@nosuchdomain.example.com> |
| In reply to | #6391 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 11/15/21 8:28 PM, Vincent Lefevre wrote:
>> In article <smuvs5$6qh$1@dont-email.me>,
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
[...]
>>> "If a "shall" or "shall not" requirement that appears outside of a
>>> constraint or runtime-constraint is violated, the behavior is undefined.
>>> Undefined behavior is otherwise indicated in this document by the words
>>> "undefined behavior" or by the omission of any explicit definition of
>>> behavior. There is no difference in emphasis among these three; they all
>>> describe "behavior that is undefined"." (4p2).
>>
>> Omission of any explicit definition of behavior.
>
> The fact that a constraint is violated does not erase the definition
> provided by 6.4.4.2p4, or render it any less applicable.
I suggest that that may be an open question.
>> ... There is a constraint
>> (restriction) that is not satisfied.
>
> Agreed.
>
>> ... Thus the code becomes invalid and
>> nothing gets defined as a consequence.
>
> This is, I presume, what makes you think that 6.4.4.2p4 is effectively
> erased?
>
> The standard says nothing to that effect. The only meaningful thing it
> says is that a diagnostic is required (5.1.1.3p1). I do not consider the
> standard's definition of "constraint" to be meaningful: "restriction,
> either syntactic or semantic, by which the exposition of language
> elements is to be interpreted" (3.8). What that sentence means,if
> anything, is not at all clear, but one thing is clear - it says nothing
> about what should happen if the restriction is violated. 5.1.1.3p1 is
> the only clause that says anything about that issue.
> Note: the requirement specified in 5.1.1.3p1 would also be erased, if a
> constraint violation is considered to effectively erase unspecified
> parts of the rest of the standard. Surely you don't claim that 3.8
> specifies which parts get erased?
The standard's definition of "constraint" is uncomfortably vague -- but
that doesn't mean I'm comfortable ignoring it.
Given the definition of a "constraint" as a "restriction, either
syntactic or semantic, by which the exposition of language elements is
to be interpreted", it seems to me to be at least plausible that when a
constraint is violated, the "exposition of language elements" cannot be
interpreted.
The implication would be that any program that violates a constraint has
undefined behavior (assuming it survives translation). And yes, I'm
proposing that violating any single constraint makes most of the rest of
the standard moot.
I'm not saying that this is the only way to interpret that wording.
It's vague enough to permit a number of reasonable readings. But I
don't think we can just ignore it.
I'd like to see a future standard settle this one way or the other.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent-news@vinc17.net> |
|---|---|
| Date | 2021-12-08 10:56 +0000 |
| Message-ID | <20211208103559$62c9@zira.vinc17.org> |
| In reply to | #6394 |
In article <87pmqzv64t.fsf@nosuchdomain.example.com>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > The standard's definition of "constraint" is uncomfortably vague -- but > that doesn't mean I'm comfortable ignoring it. > Given the definition of a "constraint" as a "restriction, either > syntactic or semantic, by which the exposition of language elements is > to be interpreted", it seems to me to be at least plausible that when a > constraint is violated, the "exposition of language elements" cannot be > interpreted. DR 261[*] goes in this way, IMHO. Here, the constraint on constant expressions is used to determine whether an expression may be regarded as a constant expression or not. Thus, if the constraint is not matched, then the expression is not a constant expression, and what falls under this constraint does not apply. Note that the Committee Response says "valid interpretation of the code", i.e. if the requirements of a constraint are not met, then there is no "valid interpretation of the code". [*] http://www.open-std.org/JTC1/SC22/WG14/www/docs/dr_261.htm -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-03 12:56 -0800 |
| Message-ID | <86fsq4y1vw.fsf@linuxsc.com> |
| In reply to | #6394 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > >> On 11/15/21 8:28 PM, Vincent Lefevre wrote: >> >>> In article <smuvs5$6qh$1@dont-email.me>, >>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > > [...] > >>>> "If a "shall" or "shall not" requirement that appears outside of >>>> a constraint or runtime-constraint is violated, the behavior is >>>> undefined. Undefined behavior is otherwise indicated in this >>>> document by the words "undefined behavior" or by the omission of >>>> any explicit definition of behavior. There is no difference in >>>> emphasis among these three; they all describe "behavior that is >>>> undefined"." (4p2). >>> >>> Omission of any explicit definition of behavior. >> >> The fact that a constraint is violated does not erase the >> definition provided by 6.4.4.2p4, or render it any less applicable. > > I suggest that that may be an open question. > >>> ... There is a constraint >>> (restriction) that is not satisfied. >> >> Agreed. >> >>> ... Thus the code becomes invalid and >>> nothing gets defined as a consequence. >> >> This is, I presume, what makes you think that 6.4.4.2p4 is >> effectively erased? >> >> The standard says nothing to that effect. The only meaningful >> thing it says is that a diagnostic is required (5.1.1.3p1). I do >> not consider the standard's definition of "constraint" to be >> meaningful: "restriction, either syntactic or semantic, by which >> the exposition of language elements is to be interpreted" (3.8). (Incidental remark: the problem is not that the definition of constraint is meaningless; the problem is that the meaning of the definition is ambiguous and subjective (but that's not the same as meaningless (or "not meaningful")).) >> What that sentence means,if anything, is not at all clear, but one >> thing is clear - it says nothing about what should happen if the >> restriction is violated. 5.1.1.3p1 is the only clause that says >> anything about that issue. Note: the requirement specified in >> 5.1.1.3p1 would also be erased, if a constraint violation is >> considered to effectively erase unspecified parts of the rest of >> the standard. Surely you don't claim that 3.8 specifies which >> parts get erased? > > The standard's definition of "constraint" is uncomfortably vague > -- but that doesn't mean I'm comfortable ignoring it. > > Given the definition of a "constraint" as a "restriction, either > syntactic or semantic, by which the exposition of language > elements is to be interpreted", it seems to me to be at least > plausible that when a constraint is violated, the "exposition of > language elements" cannot be interpreted. > > The implication would be that any program that violates a constraint > has undefined behavior (assuming it survives translation). And yes, > I'm proposing that violating any single constraint makes most of the > rest of the standard moot. > > I'm not saying that this is the only way to interpret that wording. > It's vague enough to permit a number of reasonable readings. [...] So you're saying that the meaning of the definition of constraint is to some extent subjective, ie, reader dependent?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-01-03 22:45 -0800 |
| Message-ID | <6d480235-16d5-4de4-8a15-4c55df49250dn@googlegroups.com> |
| In reply to | #6409 |
On Monday, January 3, 2022 at 3:56:22 PM UTC-5, Tim Rentsch wrote: > Keith Thompson <Keith.S.T...@gmail.com> writes: > > > James Kuyper <james...@alumni.caltech.edu> writes: ... > >> The standard says nothing to that effect. The only meaningful > >> thing it says is that a diagnostic is required (5.1.1.3p1). I do > >> not consider the standard's definition of "constraint" to be > >> meaningful: "restriction, either syntactic or semantic, by which > >> the exposition of language elements is to be interpreted" (3.8). ... > > The standard's definition of "constraint" is uncomfortably vague > > -- but that doesn't mean I'm comfortable ignoring it. > > > > Given the definition of a "constraint" as a "restriction, either > > syntactic or semantic, by which the exposition of language > > elements is to be interpreted", it seems to me to be at least > > plausible that when a constraint is violated, the "exposition of > > language elements" cannot be interpreted. ... > > I'm not saying that this is the only way to interpret that wording. > > It's vague enough to permit a number of reasonable readings. [...] > > So you're saying that the meaning of the definition of constraint > is to some extent subjective, ie, reader dependent? As I said above, it seems to me to be so poorly worded that it's not clear to me that it has any meaning, much less one that is subjective. Since other people disagree with me on that point, there would appear to be some subjectivity at play in that judgment, but after reading their arguments, I remain at a loss as to how they can interpret that phrase as being meaningful.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-17 05:35 -0800 |
| Message-ID | <868rvetrhd.fsf@linuxsc.com> |
| In reply to | #6412 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On Monday, January 3, 2022 at 3:56:22 PM UTC-5, Tim Rentsch wrote: > >> Keith Thompson <Keith.S.T...@gmail.com> writes: >> >>> James Kuyper <james...@alumni.caltech.edu> writes: > > ... > >>>> The standard says nothing to that effect. The only meaningful >>>> thing it says is that a diagnostic is required (5.1.1.3p1). I do >>>> not consider the standard's definition of "constraint" to be >>>> meaningful: "restriction, either syntactic or semantic, by which >>>> the exposition of language elements is to be interpreted" (3.8). > > ... > >>> The standard's definition of "constraint" is uncomfortably vague >>> -- but that doesn't mean I'm comfortable ignoring it. >>> >>> Given the definition of a "constraint" as a "restriction, either >>> syntactic or semantic, by which the exposition of language >>> elements is to be interpreted", it seems to me to be at least >>> plausible that when a constraint is violated, the "exposition of >>> language elements" cannot be interpreted. > > ... > >>> I'm not saying that this is the only way to interpret that wording. >>> It's vague enough to permit a number of reasonable readings. [...] >> >> So you're saying that the meaning of the definition of constraint >> is to some extent subjective, ie, reader dependent? > > As I said above, it seems to me to be so poorly worded that it's not > clear to me that it has any meaning, much less one that is subjective. > Since other people disagree with me on that point, there would > appear to be some subjectivity at play in that judgment, but after > reading their arguments, I remain at a loss as to how they can > interpret that phrase as being meaningful. So is what you're saying that whether the meaning is subjective is itself a subjective question?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-09-30 03:20 +0100 |
| Message-ID | <87a6jun6s8.fsf@bsb.me.uk> |
| In reply to | #6321 |
Vincent Lefevre <vincent-news@vinc17.net> writes: > In ISO C99:TC3 to C17, 7.12p4: > > The macro INFINITY expands to a constant expression of type float > representing positive or unsigned infinity, if available; else to a > positive constant of type float that overflows at translation time. > > Consider the "else" case. It is said that INFINITY expands to a > constant and that it overflows, so that it is not in the range of > representable values of float. > > But in 6.4.4p2: > > Each constant shall have a type and the value of a constant shall > be in the range of representable values for its type. > > which would imply that INFINITY expands to a value in the range of > representable values of float, contradicted by 7.12p4. Right. But there is footnote that clarifies matters: "In this case, using INFINITY will violate the constraint in 6.4.4 and thus require a diagnostic." so any program using INFINITY has undefined behaviour because the intent is to violate 6.4.4. I agree that there should be a better way to specify it, but expanding to a constant that violates the constraints on such constants is clumsy but reasonably clear. -- Ben.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.std.c
csiph-web