Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #110548 > unrolled thread
| Started by | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| First post | 2017-05-24 08:16 -0700 |
| Last post | 2017-06-03 11:29 +0000 |
| Articles | 20 on this page of 82 — 20 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-24 08:16 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-24 10:43 -0700
Re: C Macros Badly Defined? Ike Naar <ike@iceland.freeshell.org> - 2017-05-24 19:06 +0000
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-27 06:10 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-27 12:02 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-27 13:42 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-27 15:48 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-28 14:40 -0700
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-29 08:33 -0700
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-29 08:17 -0700
Re: C Macros Badly Defined? bartc <bc@freeuk.com> - 2017-05-29 16:26 +0100
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-30 06:13 -0700
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-30 09:57 -0700
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-30 19:12 +0200
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-30 14:55 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-30 15:39 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-30 16:03 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-30 16:50 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-30 17:12 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-31 06:30 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-31 09:36 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 12:08 -0700
Re: C Macros Badly Defined? scott@slp53.sl.home (Scott Lurndal) - 2017-05-31 19:16 +0000
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 12:35 -0700
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-01 04:06 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-06-01 10:33 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-06-01 12:00 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-06-01 15:35 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-06-01 17:26 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-06-01 20:48 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-31 12:43 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 21:50 -0700
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:36 +0000
Re: C Macros Badly Defined? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-03 11:44 +0000
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-06-03 09:19 -0700
Re: C Macros Badly Defined? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-03 16:22 +0000
Re: Standards in various formats Noob <root@127.0.0.1> - 2017-06-01 13:24 +0200
Re: C Macros Badly Defined? jadill33@gmail.com - 2017-05-31 13:02 -0700
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-30 22:06 -0700
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-05-31 12:51 +0200
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-31 06:21 -0700
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-05-31 17:16 +0200
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 17:24 +0200
Re: C Macros Badly Defined? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-31 22:18 +0200
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 23:09 +0200
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-31 17:32 -0400
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 23:50 +0200
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-31 18:01 -0400
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 00:33 +0200
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-31 22:36 -0400
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 06:08 +0200
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-01 11:08 -0400
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-01 01:30 -0700
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 11:38 +0200
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-01 03:13 -0700
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 12:25 +0200
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-01 04:48 -0700
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 14:27 +0200
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-01 05:55 -0700
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-01 11:11 -0400
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 17:40 +0200
Re: C Macros Badly Defined? Ian Collins <ian-news@hotmail.com> - 2017-06-02 08:32 +1200
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 23:14 +0200
Re: C Macros Badly Defined? jameskuyper@verizon.net - 2017-06-01 14:41 -0700
Re: C Macros Badly Defined? Ian Collins <ian-news@hotmail.com> - 2017-06-02 09:48 +1200
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-06-02 00:56 +0200
Re: C Macros Badly Defined? Ian Collins <ian-news@hotmail.com> - 2017-06-02 11:12 +1200
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:54 +0000
Re: C Macros Badly Defined? Leon Taylor <leontaylor476@gmail.com> - 2017-06-03 05:10 -0700
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-06-04 14:32 +0200
Re: C Macros Badly Defined? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-01 21:44 +0000
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:51 +0000
Re: C Macros Badly Defined? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-01 21:38 +0000
Re: C Macros Badly Defined? Ian Collins <ian-news@hotmail.com> - 2017-06-02 11:10 +1200
Re: C Macros Badly Defined? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-01 23:34 +0000
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:48 +0000
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-06-01 08:56 -0700
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-06-02 14:11 +0200
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-06-02 10:02 -0700
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:45 +0000
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-31 09:11 -0700
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:29 +0000
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-31 09:36 -0700 |
| Message-ID | <lnwp8xoudz.fsf@kst-u.example.com> |
| In reply to | #110993 |
supercat@casperkitty.com writes:
> On Tuesday, May 30, 2017 at 7:12:08 PM UTC-5, Keith Thompson wrote:
>> supercat writes:
>> > Most standards specify what conforming entities have to "do", and
>> > are quite specific about what entities are responsible for ensuring
>> > what. The Standard sometimes talks about obligations of programs
>> > or implementations, but sometimes uses "shall be" to impose
>> > obligations upon grammatical constructs.
>>
>> For example?
>
> Compare 6.2.5p3:
>
> If any other character is stored in a char object, the resulting value
> is implementation-defined but shall be within the range of values that
> can be represented in that type.
(which is outside a constraint)
> with 6.8.4.2p2:
>
> If a switch statement has an associated case or default label within
> the scope of an identifier with a variably modified type, the entire
> switch statement shall be within the scope of that identifier.
(which is within a constraint)
> The former could be interpreted to suggest that if an implementation
> defined CHAR_MIN as -127 but specified that values get two's-complement
> reduced, a program which stored 128 to a "char" and read it back would
> violate a "shall" constraint and thus have Undefined Behavior.
I think it's a misuse of the word "shall". Replacing "shall" by "is
guaranteed to" would be an improvement. (BTW, your use of the word
"constraint" here is inconsistent with the way the standard uses it.)
> The
> latter could be read as suggesting that an implementation shall treat
> the scopes of identifiers in such fashion as to abide by the second.
Except that that interpretation would contradict other requirements
about scopes of identifiers. I think it's clear enough that a
constraint is being imposed on programs. This program:
int main(void) {
int n = 1;
switch (n) {
case 1: ;
int vla[n];
default: ;
}
}
violates that constraint, requiring a diagnostic.
> Both constructs can be worked out, of course, but especially with the
> second I think it would be clearer to say that no "case" label shall
> be placed within the scope of a variably-modified type *unless* the
> entire switch statement is likewise within that scope.
Sure, that's another way to express the same requirement.
(And yet again, please use shorter lines so I don't have to reformat
quoted text.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-31 12:08 -0700 |
| Message-ID | <267ed825-c65c-4e0f-ad39-29ccbd348e8c@googlegroups.com> |
| In reply to | #111023 |
On Wednesday, May 31, 2017 at 9:37:04 AM UTC-7, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> > On Tuesday, May 30, 2017 at 7:12:08 PM UTC-5, Keith Thompson wrote:
> >> supercat writes:
> >> > Most standards specify what conforming entities have to "do", and
> >> > are quite specific about what entities are responsible for ensuring
> >> > what. The Standard sometimes talks about obligations of programs
> >> > or implementations, but sometimes uses "shall be" to impose
> >> > obligations upon grammatical constructs.
> >>
> >> For example?
> >
> > Compare 6.2.5p3:
> >
> > If any other character is stored in a char object, the resulting value
> > is implementation-defined but shall be within the range of values that
> > can be represented in that type.
>
> (which is outside a constraint)
>
> > with 6.8.4.2p2:
> >
> > If a switch statement has an associated case or default label within
> > the scope of an identifier with a variably modified type, the entire
> > switch statement shall be within the scope of that identifier.
>
> (which is within a constraint)
>
> > The former could be interpreted to suggest that if an implementation
> > defined CHAR_MIN as -127 but specified that values get two's-complement
> > reduced, a program which stored 128 to a "char" and read it back would
> > violate a "shall" constraint and thus have Undefined Behavior.
>
> I think it's a misuse of the word "shall". Replacing "shall" by "is
> guaranteed to" would be an improvement. (BTW, your use of the word
> "constraint" here is inconsistent with the way the standard uses it.)
>
> > The
> > latter could be read as suggesting that an implementation shall treat
> > the scopes of identifiers in such fashion as to abide by the second.
>
> Except that that interpretation would contradict other requirements
> about scopes of identifiers. I think it's clear enough that a
> constraint is being imposed on programs. This program:
>
> int main(void) {
> int n = 1;
> switch (n) {
> case 1: ;
> int vla[n];
> default: ;
> }
> }
>
> violates that constraint, requiring a diagnostic.
>
> > Both constructs can be worked out, of course, but especially with the
> > second I think it would be clearer to say that no "case" label shall
> > be placed within the scope of a variably-modified type *unless* the
> > entire switch statement is likewise within that scope.
>
> Sure, that's another way to express the same requirement.
>
> (And yet again, please use shorter lines so I don't have to reformat
> quoted text.)
Lots of action on a minor point. Oh Well.
My objection to the Standard's use of "shall" was an
esthetic objection to the writing in the Standard - not
a comment on undefined behavior.
As nearly as I can tell this use of "shall" in a technical
sense is confined to constraints (the definition of which I
don't think is clear - but everybody knows what they mean).
Is there a use of "shall" anywhere outside a constraint?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-05-31 19:16 +0000 |
| Message-ID | <%DEXA.54278$fR7.17881@fx42.iad> |
| In reply to | #111040 |
David Kleinecke <dkleinecke@gmail.com> writes:
>On Wednesday, May 31, 2017 at 9:37:04 AM UTC-7, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>> > On Tuesday, May 30, 2017 at 7:12:08 PM UTC-5, Keith Thompson wrote:
>> >> supercat writes:
>> >> > Most standards specify what conforming entities have to "do", and
>> >> > are quite specific about what entities are responsible for ensuring
>> >> > what. The Standard sometimes talks about obligations of programs
>> >> > or implementations, but sometimes uses "shall be" to impose
>> >> > obligations upon grammatical constructs.
>> >>
>> >> For example?
>> >
>> > Compare 6.2.5p3:
>> >
>> > If any other character is stored in a char object, the resulting value
>> > is implementation-defined but shall be within the range of values that
>> > can be represented in that type.
>>
>> (which is outside a constraint)
>>
>> > with 6.8.4.2p2:
>> >
>> > If a switch statement has an associated case or default label within
>> > the scope of an identifier with a variably modified type, the entire
>> > switch statement shall be within the scope of that identifier.
>>
>> (which is within a constraint)
>>
>> > The former could be interpreted to suggest that if an implementation
>> > defined CHAR_MIN as -127 but specified that values get two's-complement
>> > reduced, a program which stored 128 to a "char" and read it back would
>> > violate a "shall" constraint and thus have Undefined Behavior.
>>
>> I think it's a misuse of the word "shall". Replacing "shall" by "is
>> guaranteed to" would be an improvement. (BTW, your use of the word
>> "constraint" here is inconsistent with the way the standard uses it.)
>>
>> > The
>> > latter could be read as suggesting that an implementation shall treat
>> > the scopes of identifiers in such fashion as to abide by the second.
>>
>> Except that that interpretation would contradict other requirements
>> about scopes of identifiers. I think it's clear enough that a
>> constraint is being imposed on programs. This program:
>>
>> int main(void) {
>> int n = 1;
>> switch (n) {
>> case 1: ;
>> int vla[n];
>> default: ;
>> }
>> }
>>
>> violates that constraint, requiring a diagnostic.
>>
>> > Both constructs can be worked out, of course, but especially with the
>> > second I think it would be clearer to say that no "case" label shall
>> > be placed within the scope of a variably-modified type *unless* the
>> > entire switch statement is likewise within that scope.
>>
>> Sure, that's another way to express the same requirement.
>>
>> (And yet again, please use shorter lines so I don't have to reformat
>> quoted text.)
>
>Lots of action on a minor point. Oh Well.
>
>My objection to the Standard's use of "shall" was an
>esthetic objection to the writing in the Standard - not
>a comment on undefined behavior.
>
>As nearly as I can tell this use of "shall" in a technical
>sense is confined to constraints (the definition of which I
>don't think is clear - but everybody knows what they mean).
>Is there a use of "shall" anywhere outside a constraint?
While don't have the C spec handy, Posix defines 'shall' as follows:
shall
For an implementation that conforms to POSIX.1-2008, describes a
feature or behavior that is mandatory. An application can rely
on the existence of the feature or behavior.
For an application or user, describes a behavior that is mandatory.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap01.html
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-31 12:35 -0700 |
| Message-ID | <f4bbbd30-c58c-46f7-804a-e9938dea58bb@googlegroups.com> |
| In reply to | #111042 |
On Wednesday, May 31, 2017 at 12:16:19 PM UTC-7, Scott Lurndal wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> >On Wednesday, May 31, 2017 at 9:37:04 AM UTC-7, Keith Thompson wrote:
> >> supercat@casperkitty.com writes:
> >> > On Tuesday, May 30, 2017 at 7:12:08 PM UTC-5, Keith Thompson wrote:
> >> >> supercat writes:
> >> >> > Most standards specify what conforming entities have to "do", and
> >> >> > are quite specific about what entities are responsible for ensuring
> >> >> > what. The Standard sometimes talks about obligations of programs
> >> >> > or implementations, but sometimes uses "shall be" to impose
> >> >> > obligations upon grammatical constructs.
> >> >>
> >> >> For example?
> >> >
> >> > Compare 6.2.5p3:
> >> >
> >> > If any other character is stored in a char object, the resulting value
> >> > is implementation-defined but shall be within the range of values that
> >> > can be represented in that type.
> >>
> >> (which is outside a constraint)
> >>
> >> > with 6.8.4.2p2:
> >> >
> >> > If a switch statement has an associated case or default label within
> >> > the scope of an identifier with a variably modified type, the entire
> >> > switch statement shall be within the scope of that identifier.
> >>
> >> (which is within a constraint)
> >>
> >> > The former could be interpreted to suggest that if an implementation
> >> > defined CHAR_MIN as -127 but specified that values get two's-complement
> >> > reduced, a program which stored 128 to a "char" and read it back would
> >> > violate a "shall" constraint and thus have Undefined Behavior.
> >>
> >> I think it's a misuse of the word "shall". Replacing "shall" by "is
> >> guaranteed to" would be an improvement. (BTW, your use of the word
> >> "constraint" here is inconsistent with the way the standard uses it.)
> >>
> >> > The
> >> > latter could be read as suggesting that an implementation shall treat
> >> > the scopes of identifiers in such fashion as to abide by the second.
> >>
> >> Except that that interpretation would contradict other requirements
> >> about scopes of identifiers. I think it's clear enough that a
> >> constraint is being imposed on programs. This program:
> >>
> >> int main(void) {
> >> int n = 1;
> >> switch (n) {
> >> case 1: ;
> >> int vla[n];
> >> default: ;
> >> }
> >> }
> >>
> >> violates that constraint, requiring a diagnostic.
> >>
> >> > Both constructs can be worked out, of course, but especially with the
> >> > second I think it would be clearer to say that no "case" label shall
> >> > be placed within the scope of a variably-modified type *unless* the
> >> > entire switch statement is likewise within that scope.
> >>
> >> Sure, that's another way to express the same requirement.
> >>
> >> (And yet again, please use shorter lines so I don't have to reformat
> >> quoted text.)
> >
> >Lots of action on a minor point. Oh Well.
> >
> >My objection to the Standard's use of "shall" was an
> >esthetic objection to the writing in the Standard - not
> >a comment on undefined behavior.
> >
> >As nearly as I can tell this use of "shall" in a technical
> >sense is confined to constraints (the definition of which I
> >don't think is clear - but everybody knows what they mean).
> >Is there a use of "shall" anywhere outside a constraint?
>
> While don't have the C spec handy, Posix defines 'shall' as follows:
>
> shall
>
> For an implementation that conforms to POSIX.1-2008, describes a
> feature or behavior that is mandatory. An application can rely
> on the existence of the feature or behavior.
>
> For an application or user, describes a behavior that is mandatory.
>
>
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap01.html
There isn't any problem connected with what "shall" is being
used to say. But it isn't being used in its ordinary English
way. So I called it a technical term. I consider it unfortunate
and wonder why "must" was not used instead.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-06-01 04:06 -0700 |
| Message-ID | <kfno9u8c6gj.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #111045 |
David Kleinecke <dkleinecke@gmail.com> writes: > [..use of "shall" in the Standard..] > > There isn't any problem connected with what "shall" is being > used to say. But it isn't being used in its ordinary English > way. [...] This assertion is in conflict with all of the ordinary English dictionaries I consulted.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-06-01 10:33 -0700 |
| Message-ID | <94e7a42a-8f7a-4823-9883-4b8ae5988572@googlegroups.com> |
| In reply to | #111090 |
On Thursday, June 1, 2017 at 4:07:00 AM UTC-7, Tim Rentsch wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > > [..use of "shall" in the Standard..] > > > > There isn't any problem connected with what "shall" is being > > used to say. But it isn't being used in its ordinary English > > way. [...] > > This assertion is in conflict with all of the ordinary English > dictionaries I consulted. Dictionaries are not a good guide to current usage. "Shall" is essentially obsolete in modern English. The modern English modal to use would have been "must".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-06-01 12:00 -0700 |
| Message-ID | <lnbmq7pm7e.fsf@kst-u.example.com> |
| In reply to | #111129 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Thursday, June 1, 2017 at 4:07:00 AM UTC-7, Tim Rentsch wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>>
>> > [..use of "shall" in the Standard..]
>> >
>> > There isn't any problem connected with what "shall" is being
>> > used to say. But it isn't being used in its ordinary English
>> > way. [...]
>>
>> This assertion is in conflict with all of the ordinary English
>> dictionaries I consulted.
>
> Dictionaries are not a good guide to current usage. "Shall" is
> essentially obsolete in modern English. The modern English
> modal to use would have been "must".
I disagree that "shall" is obsolete. Shall I provide examples?
In any case, the use of "shall" in this sense is quite common in
standards, particularly ISO standards.
And if it were obsolete, that would be an argument in favor of using it,
since the standard can define what it means in that context with less
risk of conflicting with common usage.
You just need to understand how the standard uses the word, and that's
something you only have to do once. After that, it shoulnd't be a
problem.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-06-01 15:35 -0700 |
| Message-ID | <6a009fc9-0017-496c-87a4-6e8721417c10@googlegroups.com> |
| In reply to | #111135 |
On Thursday, June 1, 2017 at 12:00:46 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Thursday, June 1, 2017 at 4:07:00 AM UTC-7, Tim Rentsch wrote: > >> David Kleinecke <dkleinecke@gmail.com> writes: > >> > >> > [..use of "shall" in the Standard..] > >> > > >> > There isn't any problem connected with what "shall" is being > >> > used to say. But it isn't being used in its ordinary English > >> > way. [...] > >> > >> This assertion is in conflict with all of the ordinary English > >> dictionaries I consulted. > > > > Dictionaries are not a good guide to current usage. "Shall" is > > essentially obsolete in modern English. The modern English > > modal to use would have been "must". > > I disagree that "shall" is obsolete. Shall I provide examples? > > In any case, the use of "shall" in this sense is quite common in > standards, particularly ISO standards. > > And if it were obsolete, that would be an argument in favor of using it, > since the standard can define what it means in that context with less > risk of conflicting with common usage. > > You just need to understand how the standard uses the word, and that's > something you only have to do once. After that, it shoulnd't be a > problem. I suspect you didn't read the full context. The subject was the writing style in the standard. I was commenting that I thought it was quite good and that my biggest bitch was with the un-English use of "shall". If that's my biggest bitch I am quite happy with what I see. I imagined people would see my bitch as a trivial complaint. As to the current status of "shall" in English see any modern LINGUISTIC book on English Grammar.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-06-01 17:26 -0700 |
| Message-ID | <lnvaofnskl.fsf@kst-u.example.com> |
| In reply to | #111163 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Thursday, June 1, 2017 at 12:00:46 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > On Thursday, June 1, 2017 at 4:07:00 AM UTC-7, Tim Rentsch wrote:
>> >> David Kleinecke <dkleinecke@gmail.com> writes:
>> >>
>> >> > [..use of "shall" in the Standard..]
>> >> >
>> >> > There isn't any problem connected with what "shall" is being
>> >> > used to say. But it isn't being used in its ordinary English
>> >> > way. [...]
>> >>
>> >> This assertion is in conflict with all of the ordinary English
>> >> dictionaries I consulted.
>> >
>> > Dictionaries are not a good guide to current usage. "Shall" is
>> > essentially obsolete in modern English. The modern English
>> > modal to use would have been "must".
>>
>> I disagree that "shall" is obsolete. Shall I provide examples?
>>
>> In any case, the use of "shall" in this sense is quite common in
>> standards, particularly ISO standards.
>>
>> And if it were obsolete, that would be an argument in favor of using it,
>> since the standard can define what it means in that context with less
>> risk of conflicting with common usage.
>>
>> You just need to understand how the standard uses the word, and that's
>> something you only have to do once. After that, it shoulnd't be a
>> problem.
>
> I suspect you didn't read the full context.
In fact I did.
> The subject was the
> writing style in the standard. I was commenting that I thought it
> was quite good and that my biggest bitch was with the un-English
> use of "shall".
I understood your point, and I disagree with it. It's a perfectly
ordinary English word, not obsolete at all, and the standard uses it in
a semi-formal sense that it clearly defines for itself.
> If that's my biggest bitch I am quite happy with
> what I see. I imagined people would see my bitch as a trivial
> complaint.
Yes.
> As to the current status of "shall" in English see any modern
> LINGUISTIC book on English Grammar.
Did you notice my question, above, "Shall I provide examples?" Did you
find my use of the word "Shall" in that sentence odd? I didn't.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-06-01 20:48 -0700 |
| Message-ID | <cfd54b44-6515-40ec-b25b-957c9fdd3ae5@googlegroups.com> |
| In reply to | #111177 |
On Thursday, June 1, 2017 at 5:26:10 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Thursday, June 1, 2017 at 12:00:46 PM UTC-7, Keith Thompson wrote: > >> David Kleinecke <dkleinecke@gmail.com> writes: > >> > On Thursday, June 1, 2017 at 4:07:00 AM UTC-7, Tim Rentsch wrote: > >> >> David Kleinecke <dkleinecke@gmail.com> writes: > >> >> > >> >> > [..use of "shall" in the Standard..] > >> >> > > >> >> > There isn't any problem connected with what "shall" is being > >> >> > used to say. But it isn't being used in its ordinary English > >> >> > way. [...] > >> >> > >> >> This assertion is in conflict with all of the ordinary English > >> >> dictionaries I consulted. > >> > > >> > Dictionaries are not a good guide to current usage. "Shall" is > >> > essentially obsolete in modern English. The modern English > >> > modal to use would have been "must". > >> > >> I disagree that "shall" is obsolete. Shall I provide examples? > >> > >> In any case, the use of "shall" in this sense is quite common in > >> standards, particularly ISO standards. > >> > >> And if it were obsolete, that would be an argument in favor of using it, > >> since the standard can define what it means in that context with less > >> risk of conflicting with common usage. > >> > >> You just need to understand how the standard uses the word, and that's > >> something you only have to do once. After that, it shoulnd't be a > >> problem. > > > > I suspect you didn't read the full context. > > In fact I did. > > > The subject was the > > writing style in the standard. I was commenting that I thought it > > was quite good and that my biggest bitch was with the un-English > > use of "shall". > > I understood your point, and I disagree with it. It's a perfectly > ordinary English word, not obsolete at all, and the standard uses it in > a semi-formal sense that it clearly defines for itself. > > > If that's my biggest bitch I am quite happy with > > what I see. I imagined people would see my bitch as a trivial > > complaint. > > Yes. > > > As to the current status of "shall" in English see any modern > > LINGUISTIC book on English Grammar. > > Did you notice my question, above, "Shall I provide examples?" Did you > find my use of the word "Shall" in that sentence odd? I didn't. I didn't notice it. I would have said "Need". But usage differs and many people write a much more old-fashioned dialect than they speak. But re-reading what you wrote I see I assumed word play - "shall" .. "shall".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-31 12:43 -0700 |
| Message-ID | <lnshjkq0c2.fsf@kst-u.example.com> |
| In reply to | #111042 |
scott@slp53.sl.home (Scott Lurndal) writes:
> David Kleinecke <dkleinecke@gmail.com> writes:
[...]
>>As nearly as I can tell this use of "shall" in a technical
>>sense is confined to constraints (the definition of which I
>>don't think is clear - but everybody knows what they mean).
>>Is there a use of "shall" anywhere outside a constraint?
(Perhaps David has forgotten that I killfiled him.)
> While don't have the C spec handy, Posix defines 'shall' as follows:
>
> shall
>
> For an implementation that conforms to POSIX.1-2008, describes a
> feature or behavior that is mandatory. An application can rely
> on the existence of the feature or behavior.
>
> For an application or user, describes a behavior that is mandatory.
>
>
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap01.html
The C standard defines its use of "shall" in section 4, paragraphs
1 and 2:
In this International Standard, "shall" is to be interpreted as
a requirement on an implementation or on a program; conversely,
"shall not" is to be interpreted as a prohibition.
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
International Standard 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".
5.1.1.3p1 says that violations of constraints (and of syntax rules) must
be diagnosed.
There are numerous occurrences of "shall" both inside and outside
constraints.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-31 21:50 -0700 |
| Message-ID | <afd98822-14b6-4eff-9f65-46bd28e6c412@googlegroups.com> |
| In reply to | #111046 |
On Wednesday, May 31, 2017 at 12:43:17 PM UTC-7, Keith Thompson wrote: > scott@slp53.sl.home (Scott Lurndal) writes: > > David Kleinecke <dkleinecke@gmail.com> writes: > [...] > >>As nearly as I can tell this use of "shall" in a technical > >>sense is confined to constraints (the definition of which I > >>don't think is clear - but everybody knows what they mean). > >>Is there a use of "shall" anywhere outside a constraint? > > (Perhaps David has forgotten that I killfiled him.) > > > While don't have the C spec handy, Posix defines 'shall' as follows: > > > > shall > > > > For an implementation that conforms to POSIX.1-2008, describes a > > feature or behavior that is mandatory. An application can rely > > on the existence of the feature or behavior. > > > > For an application or user, describes a behavior that is mandatory. > > > > > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap01.html > > The C standard defines its use of "shall" in section 4, paragraphs > 1 and 2: > > In this International Standard, "shall" is to be interpreted as > a requirement on an implementation or on a program; conversely, > "shall not" is to be interpreted as a prohibition. > > 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 > International Standard 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". > > 5.1.1.3p1 says that violations of constraints (and of syntax rules) must > be diagnosed. > > There are numerous occurrences of "shall" both inside and outside > constraints. I'm not going to check that against anything except the C89 standard. The paragraph about constraints is part of 3.16. The other paragraph is missing. But this changes nothing. My problem is that the standard is using "shall" technically in places where "must" would be real English. Perhaps the later standards use "shall" outside of constraints more freely than the C89 standard. Perhaps you can give be a reference to where "shall" occurs outside a constraints in a passage that is unchanged from C89. And, of course, you killfiled me because I don't have enough respect for the standards. To the tiger in the zoo Madeline said pooh, pooh
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-06-03 11:36 +0000 |
| Message-ID | <59329f2e.4797046@news.xs4all.nl> |
| In reply to | #111046 |
Keith Thompson <kst-u@mib.org> wrote: > scott@slp53.sl.home (Scott Lurndal) writes: > > David Kleinecke <dkleinecke@gmail.com> writes: > [...] > >>As nearly as I can tell this use of "shall" in a technical > >>sense is confined to constraints (the definition of which I > >>don't think is clear - but everybody knows what they mean). > >>Is there a use of "shall" anywhere outside a constraint? > > (Perhaps David has forgotten that I killfiled him.) It's bad form to reply directly to people you have killfiled. Richard
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2017-06-03 11:44 +0000 |
| Message-ID | <ogu7f7$fco$1@news.xmission.com> |
| In reply to | #111353 |
In article <59329f2e.4797046@news.xs4all.nl>, Richard Bos <rlbos@xs4all.nl> wrote: >Keith Thompson <kst-u@mib.org> wrote: > >> scott@slp53.sl.home (Scott Lurndal) writes: >> > David Kleinecke <dkleinecke@gmail.com> writes: >> [...] >> >>As nearly as I can tell this use of "shall" in a technical >> >>sense is confined to constraints (the definition of which I >> >>don't think is clear - but everybody knows what they mean). >> >>Is there a use of "shall" anywhere outside a constraint? >> >> (Perhaps David has forgotten that I killfiled him.) > >It's bad form to reply directly to people you have killfiled. > >Richard Indeed. Perhaps Keith should have written: >> (Perhaps David has forgotten that I have claimed to have killfiled him.) Also, it is bad form to discuss one's killfile in public at all. -- A Catholic woman tells her husband to buy Viagra. A Jewish woman tells her husband to buy Pfizer.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-06-03 09:19 -0700 |
| Message-ID | <ln60gdm4bv.fsf@kst-u.example.com> |
| In reply to | #111353 |
raltbos@xs4all.nl (Richard Bos) writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>> > David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>> >>As nearly as I can tell this use of "shall" in a technical
>> >>sense is confined to constraints (the definition of which I
>> >>don't think is clear - but everybody knows what they mean).
>> >>Is there a use of "shall" anywhere outside a constraint?
>>
>> (Perhaps David has forgotten that I killfiled him.)
>
> It's bad form to reply directly to people you have killfiled.
Which is why, in this case, I didn't.
As it happens, I've recently removed David from my killfile.
(I didn't see any point in announcing that.)
--
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 | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2017-06-03 16:22 +0000 |
| Message-ID | <ogunof$phi$2@news.xmission.com> |
| In reply to | #111379 |
In article <ln60gdm4bv.fsf@kst-u.example.com>, Keith Thompson <kst-u@mib.org> wrote: >raltbos@xs4all.nl (Richard Bos) writes: >> Keith Thompson <kst-u@mib.org> wrote: >>> scott@slp53.sl.home (Scott Lurndal) writes: >>> > David Kleinecke <dkleinecke@gmail.com> writes: >>> [...] >>> >>As nearly as I can tell this use of "shall" in a technical >>> >>sense is confined to constraints (the definition of which I >>> >>don't think is clear - but everybody knows what they mean). >>> >>Is there a use of "shall" anywhere outside a constraint? >>> >>> (Perhaps David has forgotten that I killfiled him.) >> >> It's bad form to reply directly to people you have killfiled. > >Which is why, in this case, I didn't. Except that you did. >As it happens, I've recently removed David from my killfile. >(I didn't see any point in announcing that.) Except that you just did. -- 1/20/17: A great day for all those people who are sick of being told they don't know how to spell "you're" (or "there").
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-06-01 13:24 +0200 |
| Subject | Re: Standards in various formats |
| Message-ID | <ogotb5$df5$1@dont-email.me> |
| In reply to | #111042 |
On 31/05/2017 21:16, Scott Lurndal wrote: > While I don't have the C spec handy [...] Great resource: http://port70.net/~nsz/c/
[toc] | [prev] | [next] | [standalone]
| From | jadill33@gmail.com |
|---|---|
| Date | 2017-05-31 13:02 -0700 |
| Message-ID | <7a135ff3-d6a6-41d0-b781-b84482549ec6@googlegroups.com> |
| In reply to | #111040 |
On Wednesday, May 31, 2017 at 3:08:35 PM UTC-4, David Kleinecke wrote:
> On Wednesday, May 31, 2017 at 9:37:04 AM UTC-7, Keith Thompson wrote:
> > s...@casperkitty.com writes:
> > > On Tuesday, May 30, 2017 at 7:12:08 PM UTC-5, Keith Thompson wrote:
> > >> supercat writes:
> > >> > Most standards specify what conforming entities have to "do", and
> > >> > are quite specific about what entities are responsible for ensuring
> > >> > what. The Standard sometimes talks about obligations of programs
> > >> > or implementations, but sometimes uses "shall be" to impose
> > >> > obligations upon grammatical constructs.
> > >>
> > >> For example?
> > >
> > > Compare 6.2.5p3:
> > >
> > > If any other character is stored in a char object, the resulting value
> > > is implementation-defined but shall be within the range of values that
> > > can be represented in that type.
> >
> > (which is outside a constraint)
> >
> > > with 6.8.4.2p2:
> > >
> > > If a switch statement has an associated case or default label within
> > > the scope of an identifier with a variably modified type, the entire
> > > switch statement shall be within the scope of that identifier.
> >
> > (which is within a constraint)
> >
> > > The former could be interpreted to suggest that if an implementation
> > > defined CHAR_MIN as -127 but specified that values get two's-complement
> > > reduced, a program which stored 128 to a "char" and read it back would
> > > violate a "shall" constraint and thus have Undefined Behavior.
> >
> > I think it's a misuse of the word "shall". Replacing "shall" by "is
> > guaranteed to" would be an improvement. (BTW, your use of the word
> > "constraint" here is inconsistent with the way the standard uses it.)
> >
> > > The
> > > latter could be read as suggesting that an implementation shall treat
> > > the scopes of identifiers in such fashion as to abide by the second.
> >
> > Except that that interpretation would contradict other requirements
> > about scopes of identifiers. I think it's clear enough that a
> > constraint is being imposed on programs. This program:
> >
> > int main(void) {
> > int n = 1;
> > switch (n) {
> > case 1: ;
> > int vla[n];
> > default: ;
> > }
> > }
> >
> > violates that constraint, requiring a diagnostic.
> >
> > > Both constructs can be worked out, of course, but especially with the
> > > second I think it would be clearer to say that no "case" label shall
> > > be placed within the scope of a variably-modified type *unless* the
> > > entire switch statement is likewise within that scope.
> >
> > Sure, that's another way to express the same requirement.
> >
> > (And yet again, please use shorter lines so I don't have to reformat
> > quoted text.)
>
> Lots of action on a minor point. Oh Well.
>
> My objection to the Standard's use of "shall" was an
> esthetic objection to the writing in the Standard - not
> a comment on undefined behavior.
>
> As nearly as I can tell this use of "shall" in a technical
> sense is confined to constraints (the definition of which I
> don't think is clear - but everybody knows what they mean).
> Is there a use of "shall" anywhere outside a constraint?
The use of "shall" as a keyword is often indicative of a structured
requirements document generated according to some process defined standard,
like CMMI. "shall" has a very particular meaning in requirement statements
in contrast with "will" in terms of traceability between requirements,
design, code, and test.
Often times these documents are defined a program like Rational DOORS, which
has support for this kind of traceability. Based on appearance, the C
standard looks similar in format to the requirement documents I see exported
from DOORS.
Best regards,
John D.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-05-30 22:06 -0700 |
| Message-ID | <dfb91375-6714-4877-a4cc-635b9095de01@googlegroups.com> |
| In reply to | #110977 |
On Wednesday, May 31, 2017 at 12:50:27 AM UTC+1, supe...@casperkitty.com wrote: > > Indeed, but some programmers seem to think that permission to behave > nonsensically should be viewed, in and of itself, as a compelling reason > to behave nonsensically. Additionally, some people seem to think that > the failure of the Standard to define a behavior represents a judgment by > the Committee that any programs that would rely upon that behavior should > be considered "defective". > You've posted about this at length. The idea is that a construct which creates something like arithmetical overflow, which is technically UB, is "impossible" and can be optimised to nothing. I've got to say that these just aren't the problems I have with C code. Programs fail for other reasons.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-31 12:51 +0200 |
| Message-ID | <ogm713$1jb$1@dont-email.me> |
| In reply to | #110977 |
On 31/05/17 01:50, supercat@casperkitty.com wrote: > On Tuesday, May 30, 2017 at 6:03:48 PM UTC-5, Keith Thompson wrote: >> The term, as you know, is "undefined behavior". Hiding it behind extra >> wording is not helpful. > > Many useful tasks cannot be performed efficiently, or at all, without using > behaviors which are defined by some implementations but are not mandated by > the Standard. What terminology would you use to distinguish those behaviors > from behaviors which are not defined by anything whatsoever? Implementation-defined behaviour, or target-specific behaviour. The C standards specifically refer to some behaviours as "implementation defined", which means the implementation must define (and document) the behaviour. Implementations can freely add other defined behaviour (as long as it does not contradict standards-defined behaviour). > > The fact that programs which invoke upon not-defined-by-anything behaviors > are broken does not imply that programs which invoke not-defined-by-the- > Standard-but-instead-defined-by-other-things behaviors are broken. Some > compiler writers seem unable to distinguish those categories, however. A compiler will follow "defined by the standards" /and/ "defined by the implementation" behaviours. This second part includes extensions, implementation-defined behaviour, and any cases where the implementation specifically provides definitions for things that the standards leave undefined. A compiler has /no/ obligation to follow behaviour that is defined elsewhere. That includes behaviour that may seem "natural" for the target platform, behaviour that other compilers support, behaviour that existed in older C versions or standards, or behaviour that is in the imagination of the user. You can imagine that every compiler is written using only the C standards (whichever versions they support) and their own reference manual as the requirements. /Nothing/ else matters - no other behaviour is defined. So where are the definitions for your "not-defined-by-the-Standard-but-instead-defined-by-other-things" behaviours? And why do you think that compiler writers need to obey definitions from unrelated places? > >> The C standard defines clearly and unambiguously what it means by >> "shall". The meaning depends on the context; it means one thing in a >> constraint, and something else outside a constraint. > > Most standards specify what conforming entities have to "do", and are quite > specific about what entities are responsible for ensuring what. The Standard > sometimes talks about obligations of programs or implementations, but > sometimes uses "shall be" to impose obligations upon grammatical constructs. Read chapter 4 of the standards. It tells you what "shall" and "shall not" mean. Incidentally, you might want to pay particular attention to paragraph 2: > 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 International Standard 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’’. Note the final sentence here. This should, I hope, put an end to your endless claims about what you think the standards authors actually meant. > >>> Note that if it would make sense for most implementations to process some >>> action the same way (e.g. the way it was defined in C89) but there might >>> possibly be some platforms where defining a consistent behavior would be >>> expensive (e.g. ones'-complement machines), leaving the behavior Undefined >>> should allow implementations to process such actions sensibly. >> >> Leaving the behavior undefined quite literally allows implementations to >> behave in any way they like, including whatever you think is sensible. > > Indeed, but some programmers seem to think that permission to behave > nonsensically should be viewed, in and of itself, as a compelling reason > to behave nonsensically. Name /one/ such programmer. Give even /one/ example where you can clearly demonstrate that the reason a compiler behaves in a "nonsensical" manner is purely because it is allowed to behave "nonsensically". Of course, you can't demonstrate this from a single program - you have to show that there are /no/ correct programs that don't benefit in some way from the compiler feature. Remember, of course, that when there is no definition of the correct behaviour, it does not make sense to say that something is "nonsensically", no matter what it does. Now, if you were claiming that some compilers are less helpful than they might be in how they take advantage of undefined behaviour, I would agree. When a compiler sees a chance to skip some code because it could never be activated in a correct run of the program, that is a /good/ thing - but it would often be even better if compiler messages informed you of that fact. But when you claim compiler writers do that sort of thing out of an evil sense of humour to annoy programmers and "create" bugs in code that used to work, you are talking about something else entirely. > Additionally, some people seem to think that > the failure of the Standard to define a behavior represents a judgment by > the Committee that any programs that would rely upon that behavior should > be considered "defective". I think everyone who understands the way C works would think that programs which rely on undefined behaviour are defective - both compiler writers and programmers. They would all agree that this refers to behaviour that is undefined by the implementation, rather than just undefined by the Standard - C is intended to be usable in a non-portable, implementation-specific manner as well as for portable code. > > >>> All that's >>> necessary is that implementers recognize that (1) there is significant >>> value in following precedent absent a compelling reason to do otherwise, >>> and (2) permission to do otherwise does not, in and of itself, constitute >>> a compelling reason. >> >> Do you really have a problem with the way the standard uses the word "shall"? > > I believe it has contributed toward some implementers' belief that programs > relying upon certain behaviors should be viewed as "defective", rather than > merely being unsuitable for implementations which are designed for other > kinds of applications. > Read chapter 4 of the standards again. The word "shall" apparently confuses /you/, not other people.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web