Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #65047 > unrolled thread

Unspecified Behaviors in C90 - part 3

Back to article view | Back to comp.lang.c

Contents

  Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-09 11:21 -0700
    Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-09 14:54 -0400
      Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 21:38 +0100
    Re: Unspecified Behaviors in C90 - part 3 raltbos@xs4all.nl (Richard Bos) - 2015-07-13 21:22 +0000
      Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 08:21 -0700
        Re: Unspecified Behaviors in C90 - part 3 Keith Thompson <kst-u@mib.org> - 2015-07-14 08:48 -0700
          Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 09:33 -0700
            Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-14 18:08 +0100
              Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 19:38 -0700
                Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 00:47 -0400
                  Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:10 -0700
                    Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 21:17 -0400
                    Re: Unspecified Behaviors in C90 - part 3 maddoxr@acm.org - 2015-07-17 07:43 -0700
                Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-16 09:35 +0100
                  Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:18 -0700
                    Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:45 +0100
                    Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 21:19 -0400
                      Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-17 12:14 -0400
                        Re: Unspecified Behaviors in C90 - part 3 Keith Thompson <kst-u@mib.org> - 2015-07-17 11:00 -0700
                    Re: Unspecified Behaviors in C90 - part 3 raltbos@xs4all.nl (Richard Bos) - 2015-07-19 21:24 +0000
                Re: Unspecified Behaviors in C90 - part 3 Keith Thompson <kst-u@mib.org> - 2015-07-16 07:40 -0700
                  Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:20 -0700
                    Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:49 +0100
            Re: Unspecified Behaviors in C90 - part 3 Keith Thompson <kst-u@mib.org> - 2015-07-14 11:23 -0700
            Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-14 15:11 -0400
              Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 19:46 -0700
                Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 01:50 -0400
                  Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:15 -0700
                    Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:39 +0100
                    Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 22:26 -0400
        Re: Unspecified Behaviors in C90 - part 3 raltbos@xs4all.nl (Richard Bos) - 2015-07-19 21:22 +0000
        Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-19 17:57 -0400

Page 1 of 2  [1] 2  Next page →

#65047 — Unspecified Behaviors in C90 - part 3

Appendix G.1 to the 1990 ISO Standard lists 22 unspecified behaviors
recognized by the standard.  These behaviors are of interest because 
an implementation of C is not required to document them.

I have concluded that section 5.2.2 in the standard should be discarded. 
But 5.2.2 contains material we may not want to loose - like the 
significance of \a. K&R78 say "Input and output facilities are not part 
of the C language". But they have functions in the standard library 
(which is no more than stdio.h in their case) to provide those 
facilities. 

The standard defines two character sets - source and execution. The 
source characters are eaten up by the preprocessor and do no concern 
me here. The difficulty is that the execution character set can be 
manipulated by the program and must be recognized as data. In fact 
the program may wish to manipulate more than one character set. 
Multiple charactor sets can be accomodated by assuming there is one 
big universal character set - Unicode. A C standard might say that 
the way the Unicode code points are represented is implementation-
defined and leave it at that. But that implies that the  quotes 
around character constants and string literals are part of an 
implementation-defined system. I am not ready to provide even a 
tentative solution.

The system presented in 5.2.2 is very familiar and not something I 
would want to edict out of existence. But it seems perverse to spend 
much time or effort trying to fit any of '\a', '\b', '\f', '\r' or 
'\v' into a modern version of C. I think that all the material in 
5.2.2 could be transferred to <stdio.h> and all the desired behavior 
obtined that way.

The situation in respect to 5.2.1 is altogther different. The source 
characters are those the compiler will accept. By limiting ourselves 
to what is in 5.2.1 we have made all C programs look alike regardless 
of what script the programmer is most comfortable with. But not only 
is it possible to use a pre-preprocessor to convert almost any 
logically equivalent text into a C source but the standard allows for
additional characters. However these characters cannot used in 
identifiers (6.1.2) which is the only place they might impact on the 
C code. That, I believe, means their use is limited to comments.

The translation phase of the compiler can be viewed as receiving a 
stream of tokens. There are three types of tokens in this stream. 
One type is a set of 78 built-in tokens (operators, punctuation and 
keywords). Another set are identifiers and the third are values. In 
the input stream identifiers have no intrinisic characteristics 
other than that they can be told apart. Values are essentially 
self-describing. I prefer to look at the value tokens as a set of 
pointers to explicit values. Thus not only is the compiler supplied 
with a stream of tokens it also is supplied with a database of values. 

The point is that any set of 78 built-in tokens might be used - not 
just those listed passim in part 6. The external source form of an
identifier might be a word (or words) in any alphabet. Even integer 
numbers might be in decimal, hex or bit (I consider octal numbers 
obsolete in 2015). The execution character set remains a problem.  

[toc] | [next] | [standalone]

#65051

On 07/09/2015 02:21 PM, David Kleinecke wrote:
...
> The situation in respect to 5.2.1 is altogther different. The source 
> characters are those the compiler will accept. By limiting ourselves 
> to what is in 5.2.1 we have made all C programs look alike regardless 
> of what script the programmer is most comfortable with. But not only 
> is it possible to use a pre-preprocessor to convert almost any 
> logically equivalent text into a C source but the standard allows for
> additional characters. However these characters cannot used in 
> identifiers (6.1.2) which is the only place they might impact on the 
> C code. That, I believe, means their use is limited to comments.

The C standard has gone a long way in a quite different direction from
what you're talking about. By restricting yourself to C90, you've
rendered this discussion of negligible interest to anyone but yourself.
You can use C90 as a basis for starting your own new language, but if
you have any desire to influence the development of the C language,
you'll need to understand what was changed with regard to those issues
in C99 and C2011. Realistically, you're not going to see any of those
changes reversed unless you fully understood the reason why they were
made, and cam convince the committee that you have a superior solution
to the same problems. Discussions which ignore the existence of those
changes are guaranteed to go nowhere, fast.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#65063

On 09/07/15 19:54, James Kuyper wrote:
> [...]  if
> you have any desire to influence the development of the C language,
> you'll need to understand what was changed with regard to those issues
> in C99 and C2011. Realistically, you're not going to see any of those
> changes reversed unless you fully understood the reason why they were
> made, and cam convince the committee that you have a superior solution
> to the same problems. Discussions which ignore the existence of those
> changes are guaranteed to go nowhere, fast.

By way of contrast, discussions which recognise the existence of those 
changes are guaranteed to go nowhere, rather more slowly.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#65525

David Kleinecke <dkleinecke@gmail.com> wrote:

> Appendix G.1 to the 1990 ISO Standard lists 22 unspecified behaviors
> recognized by the standard.  These behaviors are of interest because 
> an implementation of C is not required to document them.

No, you keep getting this wrong.

These behaviours are unspecified precisely because they are _not_ of
interest to the programmer. Note that this is stronger than "you need
not care about this": it's closer to "you _should_ not care about this".
If you start delving into the details of unspecified behaviour, you are
on a hiding to nothing; worse, you are setting yourself up to be trapped
by over-optimisations that break.

Richard

[toc] | [prev] | [next] | [standalone]

#65551

On Monday, July 13, 2015 at 2:22:53 PM UTC-7, Richard Bos wrote:
> David Kleinecke <dkleinecke@gmail.com> wrote:
> 
> > Appendix G.1 to the 1990 ISO Standard lists 22 unspecified behaviors
> > recognized by the standard.  These behaviors are of interest because 
> > an implementation of C is not required to document them.
> 
> No, you keep getting this wrong.
> 
> These behaviours are unspecified precisely because they are _not_ of
> interest to the programmer. Note that this is stronger than "you need
> not care about this": it's closer to "you _should_ not care about this".
> If you start delving into the details of unspecified behaviour, you are
> on a hiding to nothing; worse, you are setting yourself up to be trapped
> by over-optimisations that break.
 
I agree. The confusing part seems to be that people jump to the
conclusion that documentation means a full description. All the
documentation needs to say is that "this cannot be depended on"
or words to that effect. 

[toc] | [prev] | [next] | [standalone]

#65554

David Kleinecke <dkleinecke@gmail.com> writes:
> On Monday, July 13, 2015 at 2:22:53 PM UTC-7, Richard Bos wrote:
>> David Kleinecke <dkleinecke@gmail.com> wrote:
>> 
>> > Appendix G.1 to the 1990 ISO Standard lists 22 unspecified behaviors
>> > recognized by the standard.  These behaviors are of interest because 
>> > an implementation of C is not required to document them.
>> 
>> No, you keep getting this wrong.
>> 
>> These behaviours are unspecified precisely because they are _not_ of
>> interest to the programmer. Note that this is stronger than "you need
>> not care about this": it's closer to "you _should_ not care about this".
>> If you start delving into the details of unspecified behaviour, you are
>> on a hiding to nothing; worse, you are setting yourself up to be trapped
>> by over-optimisations that break.
>  
> I agree. The confusing part seems to be that people jump to the
> conclusion that documentation means a full description. All the
> documentation needs to say is that "this cannot be depended on"
> or words to that effect. 

You agree??  Why didn't you say so in the first place??

From what you've been saying so far, I and others have reached
the conclusion that you want specific explicit documentation of
each choice for each case of unspecified behavior.  Your stubborn
refusal to answer direct questions or to give any rationale for
your requirements has left us with no reasonable alternative to
that conclusion.

So are you now saying that if an implementation's documentation
included the following statement:

    Unspecified behavior as described in the ISO C standard is
    unspecified.

that would satisfy your requirements?  (In my opinion such a
statement would be a waste of space; the standard already defines
the meaning of "unspecified behavior", and there's no need for an
implementation's documentation to repeat it.)

To be clear, that is not a rhetorical question.  To be equally clear,
based on your recent posts here I do not expect you to answer it,
though I'm prepared to be pleasantly surprised.

-- 
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]

#65565

On Tuesday, July 14, 2015 at 8:49:01 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Monday, July 13, 2015 at 2:22:53 PM UTC-7, Richard Bos wrote:
> >> David Kleinecke <dkleinecke@gmail.com> wrote:
> >> 
> >> > Appendix G.1 to the 1990 ISO Standard lists 22 unspecified behaviors
> >> > recognized by the standard.  These behaviors are of interest because 
> >> > an implementation of C is not required to document them.
> >> 
> >> No, you keep getting this wrong.
> >> 
> >> These behaviours are unspecified precisely because they are _not_ of
> >> interest to the programmer. Note that this is stronger than "you need
> >> not care about this": it's closer to "you _should_ not care about this".
> >> If you start delving into the details of unspecified behaviour, you are
> >> on a hiding to nothing; worse, you are setting yourself up to be trapped
> >> by over-optimisations that break.
> >  
> > I agree. The confusing part seems to be that people jump to the
> > conclusion that documentation means a full description. All the
> > documentation needs to say is that "this cannot be depended on"
> > or words to that effect. 
> 
> You agree??  Why didn't you say so in the first place??
> 
> From what you've been saying so far, I and others have reached
> the conclusion that you want specific explicit documentation of
> each choice for each case of unspecified behavior.  Your stubborn
> refusal to answer direct questions or to give any rationale for
> your requirements has left us with no reasonable alternative to
> that conclusion.
> 
> So are you now saying that if an implementation's documentation
> included the following statement:
> 
>     Unspecified behavior as described in the ISO C standard is
>     unspecified.
> 
> that would satisfy your requirements?  (In my opinion such a
> statement would be a waste of space; the standard already defines
> the meaning of "unspecified behavior", and there's no need for an
> implementation's documentation to repeat it.)
> 
> To be clear, that is not a rhetorical question.  To be equally clear,
> based on your recent posts here I do not expect you to answer it,
> though I'm prepared to be pleasantly surprised.
 
Not quite - but close. The things listed as unspecified are unspecified
in different ways and I would like those ways separated. For example, 
the behavior if a printable character is written when the active
position is at the final position of a line is unspecified because the
standard is declining to specify the display device but could (and
should) be documented for any real device. 

On the other hand the order of evaluation of arguments needs to be
documented because perhaps the order is predictable. 

A blanket statement is too simple but brief statements will usually
suffice. 

  

[toc] | [prev] | [next] | [standalone]

#65568

On 14/07/15 17:33, David Kleinecke wrote:

<snip>

> Not quite - but close. The things listed as unspecified are unspecified
> in different ways and I would like those ways separated. For example,
> the behavior if a printable character is written when the active
> position is at the final position of a line is unspecified because the
> standard is declining to specify the display device but could (and
> should) be documented for any real device.

So we have two choices that I can see - document the behaviour of the 
display device in the display device documentation, or document the 
behaviour of all existing display devices in the Standard (or in the 
implementation's documentation), and update the Standard (or the 
implementation docs) every time a new display device is brought to 
market. If we take the latter course, the Standard (or *every* 
implementation document) immediately increases in length by a 
significant amount, and is almost always out of date. If we adopt the 
former course, people who actually need to know about the 
characteristics of a specific display device can look up those 
characteristics easily, without burdening the rest of the world with 
redundant data. So you are making a good argument for leaving some 
things unspecified. What advantage do you see in forcing implementers to 
document the behaviour of display devices?

> On the other hand the order of evaluation of arguments needs to be
> documented because perhaps the order is predictable.

If the order is predictable, you don't need to document it because you 
can just predict it instead. In fact, the order is not predictable (in 
the sense that more than one reasonable choice can be made and 
implementers do in fact make different choices on occasion), but it 
turns out not to matter because well-written C code doesn't depend on 
order of evaluation (between sequence points).

> A blanket statement is too simple but brief statements will usually
> suffice.

Why is a blanket statement too simple? It seems to me to be perfectly 
reasonable for the Standard to identify a number of areas in which there 
is no need to specify a precise behaviour (e.g. order of evaluation), 
and simply label these areas "unspecified behaviour". That's what the 
Standard does right now. It works. If you want either ISO or 
implementers to change the way they do things, you will need more 
powerful arguments than you have so far supplied.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#65672

On Tuesday, July 14, 2015 at 10:09:00 AM UTC-7, Richard Heathfield wrote:
> On 14/07/15 17:33, David Kleinecke wrote:
> 
> > Not quite - but close. The things listed as unspecified are unspecified
> > in different ways and I would like those ways separated. For example,
> > the behavior if a printable character is written when the active
> > position is at the final position of a line is unspecified because the
> > standard is declining to specify the display device but could (and
> > should) be documented for any real device.
> 
> So we have two choices that I can see - document the behaviour of the 
> display device in the display device documentation, or document the 
> behaviour of all existing display devices in the Standard (or in the 
> implementation's documentation), and update the Standard (or the 
> implementation docs) every time a new display device is brought to 
> market. If we take the latter course, the Standard (or *every* 
> implementation document) immediately increases in length by a 
> significant amount, and is almost always out of date. If we adopt the 
> former course, people who actually need to know about the 
> characteristics of a specific display device can look up those 
> characteristics easily, without burdening the rest of the world with 
> redundant data. So you are making a good argument for leaving some 
> things unspecified. What advantage do you see in forcing implementers to 
> document the behaviour of display devices?

I believe that what you say does not follow. As I see it, the whole
current display device philosophy (5.2.2 and elsewhere) should be 
replaced. I have not thought through by exactly what. But, in any
case the Standard should be LESS specific than it is today 
 
> > On the other hand the order of evaluation of arguments needs to be
> > documented because perhaps the order is predictable.
> 
> If the order is predictable, you don't need to document it because you 
> can just predict it instead. In fact, the order is not predictable (in 
> the sense that more than one reasonable choice can be made and 
> implementers do in fact make different choices on occasion), but it 
> turns out not to matter because well-written C code doesn't depend on 
> order of evaluation (between sequence points).

What about
    y = f(g(x),h(x));
where g and h have different non-commutive side-effects on something 
else? Say g(x) = {y=y+2} and h(x) = {y=3*y}
 
> > A blanket statement is too simple but brief statements will usually
> > suffice.
> 
> Why is a blanket statement too simple? It seems to me to be perfectly 
> reasonable for the Standard to identify a number of areas in which there 
> is no need to specify a precise behaviour (e.g. order of evaluation), 
> and simply label these areas "unspecified behaviour". That's what the 
> Standard does right now. It works. If you want either ISO or 
> implementers to change the way they do things, you will need more 
> powerful arguments than you have so far supplied.
 
I can always hope. Perhaps the Standard committe members would agree if
they thought to consider the matter. I want to remind them.

[toc] | [prev] | [next] | [standalone]

#65682

On 07/15/2015 10:38 PM, David Kleinecke wrote:
> On Tuesday, July 14, 2015 at 10:09:00 AM UTC-7, Richard Heathfield wrote:
...
> ... As I see it, the whole
> current display device philosophy (5.2.2 and elsewhere) should be 
> replaced. I have not thought through by exactly what. But, in any
> case the Standard should be LESS specific than it is today

Well, I'm glad to see that you're starting to understand how leaving
something unspecified could be a good idea. However, the standard
specifies so little about the display device that I find it hard to
imagine how it could be significantly beneficial for the standard to
specify even less.

...
>> ... In fact, the order is not predictable (in 
>> the sense that more than one reasonable choice can be made and 
>> implementers do in fact make different choices on occasion), but it 
>> turns out not to matter because well-written C code doesn't depend on 
>> order of evaluation (between sequence points).
> 
> What about
>     y = f(g(x),h(x));
> where g and h have different non-commutive side-effects on something 
> else? Say g(x) = {y=y+2} and h(x) = {y=3*y}

If the order matters, then write your code in such a way that it has the
sequence points needed to make the order you want mandatory:

	temp1 = g(x);
	y = f(temp1, h(x));

When you don't care about the order, use constructs with unspecified
order of evaluation, leaving the compiler is free to optimize the order.
When you do care about the order, use constructs that only allow the
order you need to have happen. It's not rocket science.

...
>> Why is a blanket statement too simple? It seems to me to be perfectly 
>> reasonable for the Standard to identify a number of areas in which there 
>> is no need to specify a precise behaviour (e.g. order of evaluation), 
>> and simply label these areas "unspecified behaviour". That's what the 
>> Standard does right now. It works. If you want either ISO or 
>> implementers to change the way they do things, you will need more 
>> powerful arguments than you have so far supplied.
>  
> I can always hope. Perhaps the Standard committe members would agree if
> they thought to consider the matter. I want to remind them.

I think you underestimate the amount of consideration they've given the
matter; which would be a natural consequence of overestimating the
strength of your arguments for changing things.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#65731

On Wednesday, July 15, 2015 at 9:53:28 PM UTC-7, James Kuyper wrote:
> On 07/15/2015 10:38 PM, David Kleinecke wrote:
> > On Tuesday, July 14, 2015 at 10:09:00 AM UTC-7, Richard Heathfield wrote:
> ...
> > ... As I see it, the whole
> > current display device philosophy (5.2.2 and elsewhere) should be 
> > replaced. I have not thought through by exactly what. But, in any
> > case the Standard should be LESS specific than it is today
> 
> Well, I'm glad to see that you're starting to understand how leaving
> something unspecified could be a good idea. However, the standard
> specifies so little about the display device that I find it hard to
> imagine how it could be significantly beneficial for the standard to
> specify even less.
 
Unspecified yes - undocumented no. I started to think through what I
might use instead of 5.2.2 but got distracted. I'll try to find some
time for a suggection. I am not too eager about this because changing
5.2.2 is major change not just a piddly litle detail like documentation.  

> ...
> >> ... In fact, the order is not predictable (in 
> >> the sense that more than one reasonable choice can be made and 
> >> implementers do in fact make different choices on occasion), but it 
> >> turns out not to matter because well-written C code doesn't depend on 
> >> order of evaluation (between sequence points).
> > 
> > What about
> >     y = f(g(x),h(x));
> > where g and h have different non-commutive side-effects on something 
> > else? Say g(x) = {y=y+2} and h(x) = {y=3*y}
> 
> If the order matters, then write your code in such a way that it has the
> sequence points needed to make the order you want mandatory:
> 
> 	temp1 = g(x);
> 	y = f(temp1, h(x));
> 
> When you don't care about the order, use constructs with unspecified
> order of evaluation, leaving the compiler is free to optimize the order.
> When you do care about the order, use constructs that only allow the
> order you need to have happen. It's not rocket science.
 
But it might be very helpful if to know if the orde could be
assumed.

> ...
> >> Why is a blanket statement too simple? It seems to me to be perfectly 
> >> reasonable for the Standard to identify a number of areas in which there 
> >> is no need to specify a precise behaviour (e.g. order of evaluation), 
> >> and simply label these areas "unspecified behaviour". That's what the 
> >> Standard does right now. It works. If you want either ISO or 
> >> implementers to change the way they do things, you will need more 
> >> powerful arguments than you have so far supplied.
> >  
> > I can always hope. Perhaps the Standard committe members would agree if
> > they thought to consider the matter. I want to remind them.
> 
> I think you underestimate the amount of consideration they've given the
> matter; which would be a natural consequence of overestimating the
> strength of your arguments for changing things.
> -- 

[toc] | [prev] | [next] | [standalone]

#65746

On 07/16/2015 08:10 PM, David Kleinecke wrote:
> On Wednesday, July 15, 2015 at 9:53:28 PM UTC-7, James Kuyper wrote:
>> On 07/15/2015 10:38 PM, David Kleinecke wrote:
...
>>> What about
>>>     y = f(g(x),h(x));
>>> where g and h have different non-commutive side-effects on something 
>>> else? Say g(x) = {y=y+2} and h(x) = {y=3*y}
>>
>> If the order matters, then write your code in such a way that it has the
>> sequence points needed to make the order you want mandatory:
>>
>> 	temp1 = g(x);
>> 	y = f(temp1, h(x));
>>
>> When you don't care about the order, use constructs with unspecified
>> order of evaluation, leaving the compiler is free to optimize the order.
>> When you do care about the order, use constructs that only allow the
>> order you need to have happen. It's not rocket science.
>  
> But it might be very helpful if to know if the orde could be
> assumed.

I suppose it might be. For that matter, he moon might be made of green
cheese. It would be helpful if you could articulate a plausible reason
why it would be helpful.

It seems to me that the only plausible consequence of requiring
implementations to document rules that could be used to determine the
order of evaluation, is that some people will check those rules, and if
the order selected by a given implementation happens to be the one that
they need, they'll write y = f(g(), h()). That's bad - if the order
matters, they should write code that explicitly forces the functions to
be called in the desired order.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#65783

On Thursday, July 16, 2015 at 8:10:39 PM UTC-4, David Kleinecke wrote:
> On Wednesday, July 15, 2015 at 9:53:28 PM UTC-7, James Kuyper wrote:
> > On 07/15/2015 10:38 PM, David Kleinecke wrote:
> > > On Tuesday, July 14, 2015 at 10:09:00 AM UTC-7, Richard Heathfield wrote:
> > ...
> > > ... As I see it, the whole
> > > current display device philosophy (5.2.2 and elsewhere) should be 
> > > replaced. I have not thought through by exactly what. But, in any
> > > case the Standard should be LESS specific than it is today
> > 
> > Well, I'm glad to see that you're starting to understand how leaving
> > something unspecified could be a good idea. However, the standard
> > specifies so little about the display device that I find it hard to
> > imagine how it could be significantly beneficial for the standard to
> > specify even less.
>  
> Unspecified yes - undocumented no. I started to think through what I
> might use instead of 5.2.2 but got distracted. I'll try to find some
> time for a suggection. I am not too eager about this because changing
> 5.2.2 is major change not just a piddly litle detail like documentation.  
> 
> > ...
> > >> ... In fact, the order is not predictable (in 
> > >> the sense that more than one reasonable choice can be made and 
> > >> implementers do in fact make different choices on occasion), but it 
> > >> turns out not to matter because well-written C code doesn't depend on 
> > >> order of evaluation (between sequence points).
> > > 
> > > What about
> > >     y = f(g(x),h(x));
> > > where g and h have different non-commutive side-effects on something 
> > > else? Say g(x) = {y=y+2} and h(x) = {y=3*y}
> > 
> > If the order matters, then write your code in such a way that it has the
> > sequence points needed to make the order you want mandatory:
> > 
> > 	temp1 = g(x);
> > 	y = f(temp1, h(x));
> > 
> > When you don't care about the order, use constructs with unspecified
> > order of evaluation, leaving the compiler is free to optimize the order.
> > When you do care about the order, use constructs that only allow the
> > order you need to have happen. It's not rocket science.
>  
> But it might be very helpful if to know if the orde could be
> assumed.
> 

And we do know the answer to that one:  The order cannot be assumed.  Done.  :-)

Randy.

[toc] | [prev] | [next] | [standalone]

#65686

On 16/07/15 03:38, David Kleinecke wrote:
> On Tuesday, July 14, 2015 at 10:09:00 AM UTC-7, Richard Heathfield wrote:
>> On 14/07/15 17:33, David Kleinecke wrote:
>>
>> > Not quite - but close. The things listed as unspecified are unspecified
>> > in different ways and I would like those ways separated. For example,
>> > the behavior if a printable character is written when the active
>> > position is at the final position of a line is unspecified because the
>> > standard is declining to specify the display device but could (and
>> > should) be documented for any real device.
>>
>> So we have two choices that I can see - document the behaviour of the
>> display device in the display device documentation, or document the
>> behaviour of all existing display devices in the Standard (or in the
>> implementation's documentation), and update the Standard (or the
>> implementation docs) every time a new display device is brought to
>> market. If we take the latter course, the Standard (or *every*
>> implementation document) immediately increases in length by a
>> significant amount, and is almost always out of date. If we adopt the
>> former course, people who actually need to know about the
>> characteristics of a specific display device can look up those
>> characteristics easily, without burdening the rest of the world with
>> redundant data. So you are making a good argument for leaving some
>> things unspecified. What advantage do you see in forcing implementers to
>> document the behaviour of display devices?
>
> I believe that what you say does not follow. As I see it, the whole
> current display device philosophy (5.2.2 and elsewhere) should be
> replaced. I have not thought through by exactly what. But, in any
> case the Standard should be LESS specific than it is today

Oh, I'm sorry. I thought you were arguing for more documentation. Now it 
turns out you want less. Which bits do you think it should leave out?

>
>> > On the other hand the order of evaluation of arguments needs to be
>> > documented because perhaps the order is predictable.
>>
>> If the order is predictable, you don't need to document it because you
>> can just predict it instead. In fact, the order is not predictable (in
>> the sense that more than one reasonable choice can be made and
>> implementers do in fact make different choices on occasion), but it
>> turns out not to matter because well-written C code doesn't depend on
>> order of evaluation (between sequence points).
>
> What about
>      y = f(g(x),h(x));
> where g and h have different non-commutive side-effects on something
> else? Say g(x) = {y=y+2} and h(x) = {y=3*y}

As I said, well-written C code does not rely on order of evaluation. 
What you have there is not well-written C code. Decide on the order of 
evaluation you want, and then write the C in such a way that that is 
what you get, regardless of how the compiler generates the code.

>> > A blanket statement is too simple but brief statements will usually
>> > suffice.
>>
>> Why is a blanket statement too simple? It seems to me to be perfectly
>> reasonable for the Standard to identify a number of areas in which there
>> is no need to specify a precise behaviour (e.g. order of evaluation),
>> and simply label these areas "unspecified behaviour". That's what the
>> Standard does right now. It works. If you want either ISO or
>> implementers to change the way they do things, you will need more
>> powerful arguments than you have so far supplied.
>
> I can always hope. Perhaps the Standard committe members would agree if
> they thought to consider the matter. I want to remind them.

You can always hope... that they'll listen to you even though you 
haven't advanced any reason why they should? Good luck with that.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#65733

On Thursday, July 16, 2015 at 1:36:11 AM UTC-7, Richard Heathfield wrote:
> On 16/07/15 03:38, David Kleinecke wrote:
> >
> > What about
> >      y = f(g(x),h(x));
> > where g and h have different non-commutive side-effects on something
> > else? Say g(x) = {y=y+2} and h(x) = {y=3*y}
> 
> As I said, well-written C code does not rely on order of evaluation. 
> What you have there is not well-written C code. Decide on the order of 
> evaluation you want, and then write the C in such a way that that is 
> what you get, regardless of how the compiler generates the code.

Of course, as it appears today. But as I keep saying -suppose the
compiler did respect the order. Would't you want to know? 

[toc] | [prev] | [next] | [standalone]

#65741

On 17/07/15 01:18, David Kleinecke wrote:
> On Thursday, July 16, 2015 at 1:36:11 AM UTC-7, Richard Heathfield wrote:
>> On 16/07/15 03:38, David Kleinecke wrote:
>> >
>> > What about
>> >      y = f(g(x),h(x));
>> > where g and h have different non-commutive side-effects on something
>> > else? Say g(x) = {y=y+2} and h(x) = {y=3*y}
>>
>> As I said, well-written C code does not rely on order of evaluation.
>> What you have there is not well-written C code. Decide on the order of
>> evaluation you want, and then write the C in such a way that that is
>> what you get, regardless of how the compiler generates the code.
>
> Of course, as it appears today. But as I keep saying -suppose the
> compiler did respect the order. Would't you want to know?

Which compiler are we talking about here? The one I used yesterday when 
I first cut the code? The one I used today when I debugged the code? The 
one I will use tomorrow when I add a new feature to that part of the 
program? (These three will sometimes be the same compiler, but they will 
sometimes be two or even three different ones, drawn from a stable of 
about half a dozen that I currently have installed.) Or are we talking 
about one of the compilers that my users use to compile the code on 
their machines? If so, which one, and why that one, and what happens to 
the poor so-and-sos who don't happen to use that compiler?

You see, for that information to be useful to me, the order of 
evaluation would have to be the same on *all* implementations, and that 
simply isn't going to happen. Different implementers have different 
priorities, different hardware, different ways of doing things, and 
they're not going to take too kindly to a change in the Standard that 
requires them to make a poor choice for their hardware.

No, it's better all round if I just write the code properly in the first 
place.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#65747

On 07/16/2015 08:18 PM, David Kleinecke wrote:
> On Thursday, July 16, 2015 at 1:36:11 AM UTC-7, Richard Heathfield wrote:
>> On 16/07/15 03:38, David Kleinecke wrote:
>>>
>>> What about
>>>      y = f(g(x),h(x));
>>> where g and h have different non-commutive side-effects on something
>>> else? Say g(x) = {y=y+2} and h(x) = {y=3*y}
>>
>> As I said, well-written C code does not rely on order of evaluation. 
>> What you have there is not well-written C code. Decide on the order of 
>> evaluation you want, and then write the C in such a way that that is 
>> what you get, regardless of how the compiler generates the code.
> 
> Of course, as it appears today. But as I keep saying -suppose the
> compiler did respect the order. Would't you want to know? 

What do you mean by the phrase "respect the order". This appears to be
based on the incorrect assumption that there is a particular order to be
respected. If not, what are you talking about?
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#65789

On 07/16/2015 09:19 PM, James Kuyper wrote:
> On 07/16/2015 08:18 PM, David Kleinecke wrote:
>> On Thursday, July 16, 2015 at 1:36:11 AM UTC-7, Richard Heathfield wrote:
>>> On 16/07/15 03:38, David Kleinecke wrote:
>>>>
>>>> What about
>>>>      y = f(g(x),h(x));
>>>> where g and h have different non-commutive side-effects on something
>>>> else? Say g(x) = {y=y+2} and h(x) = {y=3*y}
>>>
>>> As I said, well-written C code does not rely on order of evaluation. 
>>> What you have there is not well-written C code. Decide on the order of 
>>> evaluation you want, and then write the C in such a way that that is 
>>> what you get, regardless of how the compiler generates the code.
>>
>> Of course, as it appears today. But as I keep saying -suppose the
>> compiler did respect the order. Would't you want to know? 
> 
> What do you mean by the phrase "respect the order". This appears to be
> based on the incorrect assumption that there is a particular order to be
> respected. If not, what are you talking about?

I've thought about it a bit, and I've thought of a possible explanation.
Is is possible that you believe the the standard always specifies the
order in which things occur, but gives implementations permission to
optimize by choosing a different order - but only if it doesn't matter
which order they occur in? That incorrect belief would explain most of
the comments you've made recently that talk about respecting the order.

There's an element of truth there. There is an "as-if" rule, though it's
not explicitly labeled as such. The basic concept is that an
implementation can use any method it desires to implement the specified
behavior - it doesn't have to implement it the same way that the
standard describes, but it must always produce the same results as-if it
had been done that way. Rick C Hodgin, among other people, find this
extremely objectionable - he wants C to be nothing more than a
high-level assembler, with a direct one-to-one correspondence between C
language constructs and the generated assembly language. If that's what
he wants, he should be using assembler - C is not, and never was,
intended to be that kind of language.

It is true that the as-if rule permits an implementation to rearrange
the order in which events occur, even if that order is explicitly
specified by the standard, so long as it doesn't matter in terms of the
observable behavior of your program.

When the C standard says that the behavior is unspecified, that's a very
different concept. It is permitted for the behavior of the program to be
detectably different, depending upon which choice the implementation
made. If one of the permitted options would produce behavior that you
don't want to happen, then you're supposed to re-write the code so that
it's no longer a permitted option. Such a re-write is always possible.

[toc] | [prev] | [next] | [standalone]

#65794

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> When the C standard says that the behavior is unspecified, that's a very
> different concept. It is permitted for the behavior of the program to be
> detectably different, depending upon which choice the implementation
> made. If one of the permitted options would produce behavior that you
> don't want to happen, then you're supposed to re-write the code so that
> it's no longer a permitted option. Such a re-write is always possible.

A concrete example might help:

#include <stdio.h>

int g(void) { putchar('g'); return 0; }

int h(void) { putchar('h'); return 0; }

void f(int x, int y) { /* nothing */ } 

int main(void) {
    f(g(), h());
    putchar('\n');
    return 0;
}

This program may print either "gh" or "hg", followed by a newline.
It may not (assuming the putchar() calls succeed) do anything else.

Which output is produced is *unspecified*.  There is no implication
in the standard that either order is the default or preferred
order; either may occur, and implementations are not required to
document whcih choice they make, or to make the same choice in all
circumstances.  The program could legally print "gh" one time and
"hg" the next time (though that would be mildly surprising).

This is entirely deliberate.

There might be legitimate performance reasons a compiler might
prefer one order over the other -- not in this particular case,
since g() and h() are so similar, but in other cases where, for
example, register allocation might be easier with one order than
with the other.

The current language rules give substantial flexibility both to
compiler authors and to programmers.

As a programmer, if I need a particular order, I can modify the
program to guarantee it (this has been demonstrated already).
If I don't care about the order, I can let the compiler choose
based on performance, or code size, or other criteria.

If the order were not unspecified, I could still write code that
enforces a particular order, but I would no longer be able to write
code that says "I don't care about the evaluation order, generate
the best code you can".  And if it were implementation-defined,
code that depends on a particular implementation's documented
behavior would still not be portable to other implementations with
different documented behavior.

-- 
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]

#65927

David Kleinecke <dkleinecke@gmail.com> wrote:

> On Thursday, July 16, 2015 at 1:36:11 AM UTC-7, Richard Heathfield wrote:
> > On 16/07/15 03:38, David Kleinecke wrote:
> > >
> > > What about
> > >      y = f(g(x),h(x));
> > > where g and h have different non-commutive side-effects on something
> > > else? Say g(x) = {y=y+2} and h(x) = {y=3*y}
> > 
> > As I said, well-written C code does not rely on order of evaluation. 
> > What you have there is not well-written C code. Decide on the order of 
> > evaluation you want, and then write the C in such a way that that is 
> > what you get, regardless of how the compiler generates the code.
> 
> Of course, as it appears today. But as I keep saying -suppose the
> compiler did respect the order. Would't you want to know? 

No.

I would prefer not to be led astray into unnecessary non-portability.

Richard

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web