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 1 of 5 [1] 2 3 4 5 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-24 08:16 -0700 |
| Subject | Re: C Macros Badly Defined? |
| Message-ID | <kfnefvei8tz.fsf@x-alumni2.alumni.caltech.edu> |
supercat@casperkitty.com writes: > On Monday, May 15, 2017 at 10:41:36 AM UTC-5, Ben Bacarisse wrote: >> Ah, that's not what I meant. I was not asking you to invent a macro >> language you'd prefer, I was asking if you can suggest a way in which >> the wording of (or, for that matter, any other changes to) the standard >> would make the current intended semantics clearer. > > IMHO, many things could be made much clearer if the authors of the > Standard [...] Someone with your track record of horrifically obfuscated writing is in no position to give advice on how to make things clearer.
[toc] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-24 10:43 -0700 |
| Message-ID | <bbc3c720-701e-4e62-913c-c1c6534b849a@googlegroups.com> |
| In reply to | #110548 |
On Wednesday, May 24, 2017 at 10:16:32 AM UTC-5, Tim Rentsch wrote:
> supercat writes:
> > IMHO, many things could be made much clearer if the authors of the
> > Standard [...]
>
> Someone with your track record of horrifically obfuscated writing
> is in no position to give advice on how to make things clearer.
Sometimes sentences to get away from me, especially when I'm in a rush. A
formal language standard, however, should be held to a higher-standard than
a 5-minute Usenet post.
It is hard to write a standard which classifies every program as violating
constraints or not violating constraints. It is impossible to do so while
simultaneously guaranteeing that:
1. Any program which any existing implementations would reject is regarded
as violating constraints.
2. No program which is in production use will be regarded as violating
constraints.
It would be much easier, *and* more useful, to recognize three categories
of programs:
1. Those which should be unambiguously regarded as violating constraints.
2. Those which should be unambiguously regarded as not violating
constraints.
3. Those which may or may not be regarded as violating constraints.
A good Standard should endeavor to minimize the fraction of programs in
the third class when practical. If a construct is simultaneously rejected
by some compilers but usefully employed in production code, however, that
would suggest that it cannot "practically" be classified as #1 or #2.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2017-05-24 19:06 +0000 |
| Message-ID | <slrn3vfsoibmkh.5n1.ike@iceland.freeshell.org> |
| In reply to | #110570 |
On 2017-05-24, supercat@casperkitty.com <supercat@casperkitty.com> wrote: > Sometimes sentences to get away from me, especially when I'm in a rush. Rushing again?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-27 06:10 -0700 |
| Message-ID | <kfnh906fnt4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110570 |
supercat@casperkitty.com writes: > On Wednesday, May 24, 2017 at 10:16:32 AM UTC-5, Tim Rentsch wrote: >> supercat writes: >> >>> IMHO, many things could be made much clearer if the authors of the >>> Standard [...] >> >> Someone with your track record of horrifically obfuscated writing >> is in no position to give advice on how to make things clearer. > > Sometimes sentences to get away from me, especially when I'm in a > rush. [...] What, you're saying you can do better? Prove it. After you have demonstrated an ability to produce reasonable quality prose, not just in isolated sentences but over scores of entire postings, then we can talk about comparing your ideas to writing in the Standard.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-27 12:02 -0700 |
| Message-ID | <32478449-75f4-44d0-bcb0-b159bc1b8473@googlegroups.com> |
| In reply to | #110791 |
On Saturday, May 27, 2017 at 6:10:22 AM UTC-7, Tim Rentsch wrote: > supercat@casperkitty.com writes: > > > On Wednesday, May 24, 2017 at 10:16:32 AM UTC-5, Tim Rentsch wrote: > >> supercat writes: > >> > >>> IMHO, many things could be made much clearer if the authors of the > >>> Standard [...] > >> > >> Someone with your track record of horrifically obfuscated writing > >> is in no position to give advice on how to make things clearer. > > > > Sometimes sentences to get away from me, especially when I'm in a > > rush. [...] > > What, you're saying you can do better? Prove it. After you have > demonstrated an ability to produce reasonable quality prose, not > just in isolated sentences but over scores of entire postings, > then we can talk about comparing your ideas to writing in the > Standard. The Standard is not written in what would ordinarily be called quality prose. Its style is a legalistic style. Legal writing has a long long history and is not always admired. But it is a serious attempt to be precise and thorough. I once suggested describing the distribution of assets in a trust agreement with COBOL code. The lawyers were appalled. "Why not", they said, "describe it in general in the agreement and work out the details later." The agreement was never finalized. I am of the opinion that the standard could be clearer but is generally a good piece of work. All the versions.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-27 13:42 -0700 |
| Message-ID | <3047ee42-73bf-48e1-ad5f-aed5e0d12cec@googlegroups.com> |
| In reply to | #110798 |
On Saturday, May 27, 2017 at 2:02:41 PM UTC-5, David Kleinecke wrote: > I am of the opinion that the standard could be clearer but is > generally a good piece of work. All the versions. They're mostly pretty good, except for one major failing: it fails to make clear that a decision to characterize an action as invoking Undefined Behavior merely indicates a finding that some implementations *might* benefit from being allowed to behave in arbitrary fashion. It does not in any way imply that compilers should not attempt to define a useful behavior, or at least offer useful behavioral guarantees, when targeting platforms and application fields where doing so would make sense.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-27 15:48 -0700 |
| Message-ID | <47f24ba3-2811-4dd1-8e85-1006ecb39541@googlegroups.com> |
| In reply to | #110803 |
On Saturday, May 27, 2017 at 1:42:28 PM UTC-7, supe...@casperkitty.com wrote: > On Saturday, May 27, 2017 at 2:02:41 PM UTC-5, David Kleinecke wrote: > > I am of the opinion that the standard could be clearer but is > > generally a good piece of work. All the versions. > > They're mostly pretty good, except for one major failing: it fails to > make clear that a decision to characterize an action as invoking Undefined > Behavior merely indicates a finding that some implementations *might* > benefit from being allowed to behave in arbitrary fashion. It does not in > any way imply that compilers should not attempt to define a useful behavior, > or at least offer useful behavioral guarantees, when targeting platforms > and application fields where doing so would make sense. I think the standard intended situations where a compiler could react positively to be "implementation-defined". But it says "Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results to behaving behaving during translation or program execution in a documented matter characteristic of the environment (with or without the issuance of a diagnostic message) to terminating a translation or execution (with the issuance of a diagnostic message)" As nearly as I can grasp that it means the compiler can do anything it pleases provided: (1) what it does is documented (2) if it terminates it must issue a diagnostic. As noted it could be clearer.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-28 14:40 -0700 |
| Message-ID | <efe046cf-4d9a-423a-8c4a-949447131e84@googlegroups.com> |
| In reply to | #110809 |
On Saturday, May 27, 2017 at 5:48:56 PM UTC-5, David Kleinecke wrote: > On Saturday, May 27, 2017 at 1:42:28 PM UTC-7, supe...@casperkitty.com wrote: > > On Saturday, May 27, 2017 at 2:02:41 PM UTC-5, David Kleinecke wrote: > > > I am of the opinion that the standard could be clearer but is > > > generally a good piece of work. All the versions. > > > > They're mostly pretty good, except for one major failing: it fails to > > make clear that a decision to characterize an action as invoking Undefined > > Behavior merely indicates a finding that some implementations *might* > > benefit from being allowed to behave in arbitrary fashion. It does not in > > any way imply that compilers should not attempt to define a useful behavior, > > or at least offer useful behavioral guarantees, when targeting platforms > > and application fields where doing so would make sense. > > I think the standard intended situations where a compiler > could react positively to be "implementation-defined". The term "Implementation-Defined" is mostly applied only to cases where a compiler is required to choose from among a some specific possibilities (e.g. the storage format for an "int"). In cases where an action is said to invoke Implementation-Defined behavior, implementations are required to specify a behavior whether or not *any* behavior would be useful given the target platform and application field. It's unclear what degree of precision the authors of the Standard sought to require with the phrase "Implementation- Defined Behavior", but the Standard seems to have avoided applying it to actions which might sometimes trap and sometimes not, based upon unpredictable criteria. If an action should behave in consistent usable fashion on 99% of implementations, but there might plausibly be some implementations that would benefit from being allowed to behave in not-necessarily-consistent fashion, the Standard will describe such action as invoking Undefined Behavior. A prime example of that would be left-shifting a negative number. Consider... 1. On two's-complement machines there is only one sensible way to define the behavior of a signed left shift, and C89 defined left-shift in that fashion. 2. On machines other than two's-complement machines, it may be more helpful to have a signed left-shift work in other ways (e.g. on a ones'-comp machine, multiply-by-two would probably be more useful than zero fill, or performance may be enhanced by letting a compiler use whichever approach would be faster in any given situation. 3. It may be helpful to have an option to trap cases where the choice between zero fill and multiplication by two might affect a program's output. That need not imply trapping all such shifts, however. If a compiler in-lines a function and observes that code ignores the result of a left-shift operation, code to check whether the value being shifted was negative may not serve much purpose. Because of the three points above, it would make sense for C99 to make left-shifting of a negative number Undefined Behavior if there were any likelihood of anyone every writing a C99 implementation for something other than two's-complement machines. That should not be taken to imply, however, that any general-purpose implementation for a two's-complement machine should do anything other than behave in the fashion that had been mandated by C89. > But > it says "Permissible undefined behavior ranges from ignoring > the situation completely with unpredictable results to > behaving behaving during translation or program execution > in a documented matter characteristic of the environment > (with or without the issuance of a diagnostic message) to > terminating a translation or execution (with the issuance > of a diagnostic message)" > > As nearly as I can grasp that it means the compiler can do > anything it pleases provided: > (1) what it does is documented > (2) if it terminates it must issue a diagnostic. > As noted it could be clearer. An implementation can be conforming without documenting anything about what happens in cases where the Standard imposes no requirements. That does not imply, however, that an implementation which documents useful behavior would not be more suitable for some purposes than one which does not. If one were to interpret UB as an invitation for an implementation to do anything that would be even remotely sensible given its target platform and application field, but also as an invitation for programmers to exploit cases where every remotely-sensible behavior by an implementation would meet the programmer's needs, that would seem like a far more useful balancing of implementation and programmer needs than saying that implementations must be presumed to act in arbitrarily nonsensical fashion.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-29 08:33 -0700 |
| Message-ID | <kfnmv9vekyy.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110809 |
David Kleinecke <dkleinecke@gmail.com> writes: > On Saturday, May 27, 2017 at 1:42:28 PM UTC-7, supe...@casperkitty.com wrote: >> On Saturday, May 27, 2017 at 2:02:41 PM UTC-5, David Kleinecke wrote: >>> I am of the opinion that the standard could be clearer but is >>> generally a good piece of work. All the versions. >> >> They're mostly pretty good, except for one major failing: it fails to >> make clear that a decision to characterize an action as invoking Undefined >> Behavior merely indicates a finding that some implementations *might* >> benefit from being allowed to behave in arbitrary fashion. It does not in >> any way imply that compilers should not attempt to define a useful behavior, >> or at least offer useful behavioral guarantees, when targeting platforms >> and application fields where doing so would make sense. > > I think the standard intended situations where a compiler > could react positively to be "implementation-defined". But > it says "Permissible undefined behavior ranges from ignoring > the situation completely with unpredictable results to > behaving behaving during translation or program execution > in a documented matter characteristic of the environment > (with or without the issuance of a diagnostic message) to > terminating a translation or execution (with the issuance > of a diagnostic message)" > > As nearly as I can grasp that it means the compiler can do > anything it pleases provided: > (1) what it does is documented > (2) if it terminates it must issue a diagnostic. > As noted it could be clearer. If you're talking about undefined behavior, neither of those conditions has to hold. Any circumstances that fall into the category of undefined behavior place no restrictions on what an implementation must do, except that if there is a syntax error or a constraint violation then a diagnostic must be given. (Incidentally, the passage you have quoted is a "NOTE", which means the text is informative, not normative. That is, it might be helpful to know, but it is not part of what formally defines the language.) The attribute of "implemenation-defined" applies only to those behaviors explicitly identified as such in the Standard. An implementation can document anything it wants (ie, as long as those items that are required to be documented have been), but doing that has no effect on what is implementation-defined.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-29 08:17 -0700 |
| Message-ID | <kfnr2z7elpa.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110798 |
David Kleinecke <dkleinecke@gmail.com> writes: > On Saturday, May 27, 2017 at 6:10:22 AM UTC-7, Tim Rentsch wrote: >> supercat@casperkitty.com writes: >> >>> On Wednesday, May 24, 2017 at 10:16:32 AM UTC-5, Tim Rentsch wrote: >>>> supercat writes: >>>> >>>>> IMHO, many things could be made much clearer if the authors of the >>>>> Standard [...] >>>> >>>> Someone with your track record of horrifically obfuscated writing >>>> is in no position to give advice on how to make things clearer. >>> >>> Sometimes sentences to get away from me, especially when I'm in a >>> rush. [...] >> >> What, you're saying you can do better? Prove it. After you have >> demonstrated an ability to produce reasonable quality prose, not >> just in isolated sentences but over scores of entire postings, >> then we can talk about comparing your ideas to writing in the >> Standard. > > The Standard is not written in what would ordinarily be called > quality prose. Its style is a legalistic style. Legal writing > has a long long history and is not always admired. But it is a > serious attempt to be precise and thorough. Text in the Standard is prose, as opposed to poetry, and is written in formal English. The style resembles the style of legal documents, which isn't too surprising since both use formal English, and as you point out precise language, but in my very much non-expert opinion the Standard doesn't really cut it as a legal document. All that is sort of by-the-way, because the prose I was referring to above relates to writing from supercat. Whatever else might be said of it, the quality of the writing in the Standard is pretty high. The quality of supercat's writing is pretty low. If he wants to make suggestions about how the Standard could be more clear, he first should demonstrate some ability to produce clear writing himself.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-29 16:26 +0100 |
| Message-ID | <q4XWA.91598$B6.744@fx02.am4> |
| In reply to | #110878 |
On 29/05/2017 16:17, Tim Rentsch wrote: > All that is sort of by-the-way, because the prose I was referring > to above relates to writing from supercat. Whatever else might be > said of it, the quality of the writing in the Standard is pretty > high. The quality of supercat's writing is pretty low. The C Standard is a document that has been refined over decades. And versions of it presumably have a team to read, check and hone the writing to perfection. And you want to compare that with a few comments on a usenet post? (A medium that doesn't even let you fix a typo once something is posted.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-30 06:13 -0700 |
| Message-ID | <kfna85uebdg.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110881 |
bartc <bc@freeuk.com> writes: > On 29/05/2017 16:17, Tim Rentsch wrote: > >> All that is sort of by-the-way, because the prose I was referring >> to above relates to writing from supercat. Whatever else might be >> said of it, the quality of the writing in the Standard is pretty >> high. The quality of supercat's writing is pretty low. > > The C Standard is a document that has been refined over decades. And > versions of it presumably have a team to read, check and hone the > writing to perfection. > > And you want to compare that with a few comments on a usenet post? If that post calls out the C standard for not being clear enough, and purports to give advice on how to improve it, Yes I do. As would I hope any sensible person.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-05-30 09:57 -0700 |
| Message-ID | <dd7db285-dbdc-4045-9b78-d742c677b123@googlegroups.com> |
| In reply to | #110938 |
On Tuesday, May 30, 2017 at 2:13:29 PM UTC+1, Tim Rentsch wrote: > > If that post calls out the C standard for not being clear enough, > and purports to give advice on how to improve it, Yes I do. As > would I hope any sensible person. [expect SuperCat to write > with more clarity] > It's very common to find programmers who are technically proficient but poor at communicating. It's said that English Literature graduates in fact make some of the best programmers.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-30 19:12 +0200 |
| Message-ID | <20170530191233.84e5575b78503611c757e526@gmail.com> |
| In reply to | #110955 |
On Tue, 30 May 2017 09:57:23 -0700 (PDT) Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > It's very common to find programmers who are technically proficient > but poor at communicating. It's said that English Literature graduates > in fact make some of the best programmers. Actually there's no "best programmer" but only good and bad code. Even the so-called best programmers wrote some utter sh!t but legends tend to mask this part of their humanity. The humanity is buggy and the more wonderful bug is its creativity. Retards with trisomy are creatives but socially excluded for being out of the common standard of humanity. In some way we need both side of the humanity, scientists and artists, to build a new world.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-30 14:55 -0700 |
| Message-ID | <24fcaf3b-5a4a-46ad-ad65-ad7ab3e23c66@googlegroups.com> |
| In reply to | #110956 |
On Tuesday, May 30, 2017 at 10:15:50 AM UTC-7, GOTHIER Nathan wrote: > On Tue, 30 May 2017 09:57:23 -0700 (PDT) > Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > > > It's very common to find programmers who are technically proficient > > but poor at communicating. It's said that English Literature graduates > > in fact make some of the best programmers. > > Actually there's no "best programmer" but only good and bad code. Even the > so-called best programmers wrote some utter sh!t but legends tend to mask > this part of their humanity. The humanity is buggy and the more wonderful bug > is its creativity. Retards with trisomy are creatives but socially excluded for > being out of the common standard of humanity. In some way we need both side of > the humanity, scientists and artists, to build a new world. My biggest bitch with the Standards is that they use the modal verb "shall" is an un-English way (which might be a legalism). In fact, the modal "shall" has, these days, disappeared from all but the most old-fashioned pedantic English.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-30 15:39 -0700 |
| Message-ID | <dac46230-cfd9-4370-9f02-e4bb3e640a3d@googlegroups.com> |
| In reply to | #110969 |
On Tuesday, May 30, 2017 at 4:56:03 PM UTC-5, David Kleinecke wrote:
> My biggest bitch with the Standards is that they use the
> modal verb "shall" is an un-English way (which might be a
> legalism). In fact, the modal "shall" has, these days,
> disappeared from all but the most old-fashioned pedantic
> English.
That is a pretty severe problem. In most cases where a standard says that
a conforming widget MUST do X, that implies that anything which does not do
X is, *by definition*, not a conforming widget. The C Standard, however,
uses the term "shall" in some cases where it means nothing beyond the fact
that:
1. A program that fails to do what is specified is not strictly conforming.
2. The Standard does not require that conforming implementations behave
in any particular fashion if programs fail to do what is specified.
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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-30 16:03 -0700 |
| Message-ID | <lnfufmq75f.fsf@kst-u.example.com> |
| In reply to | #110973 |
supercat@casperkitty.com writes:
> On Tuesday, May 30, 2017 at 4:56:03 PM UTC-5, David Kleinecke wrote:
>> My biggest bitch with the Standards is that they use the
>> modal verb "shall" is an un-English way (which might be a
>> legalism). In fact, the modal "shall" has, these days,
>> disappeared from all but the most old-fashioned pedantic
>> English.
>
> That is a pretty severe problem.
No, it isn't.
> In most cases where a standard says that
> a conforming widget MUST do X, that implies that anything which does not do
> X is, *by definition*, not a conforming widget. The C Standard, however,
> uses the term "shall" in some cases where it means nothing beyond the fact
> that:
>
> 1. A program that fails to do what is specified is not strictly conforming.
>
> 2. The Standard does not require that conforming implementations behave
> in any particular fashion if programs fail to do what is specified.
The term, as you know, is "undefined behavior". Hiding it behind extra
wording is not helpful.
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.
> 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.
> 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"?
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-30 16:50 -0700 |
| Message-ID | <ce4d2265-c85d-4944-855e-19a2d9b55fa5@googlegroups.com> |
| In reply to | #110976 |
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? 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. > 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. > > 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. 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". > > 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-30 17:12 -0700 |
| Message-ID | <lnbmq9rijy.fsf@kst-u.example.com> |
| In reply to | #110977 |
supercat@casperkitty.com writes:
> 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?
"Non-portable", I suppose.
> 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.
Feel free to complain to them.
>> 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.
For example?
[...]
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-31 06:30 -0700 |
| Message-ID | <5a862af8-50eb-443c-8562-a3ae8e9cd9da@googlegroups.com> |
| In reply to | #110978 |
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. 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. 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. 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. 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.
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web