undefined behaviour
fax
I am a beginner of the language. What are the meaning of undefined
behaviour? Is it simply an error so difficult to diagnostic at
compile-time/run-time?
Thanks.
those who know me have no need of my name
>I am a beginner of the language. What are the meaning of undefined
>behaviour?
it means that the standard imposes no specific behavior, an implementation
is free to do anything.
>Is it simply an error so difficult to diagnostic at
>compile-time/run-time?
no, although those are possibilities.
--
bringing you boring signatures for 17 years
James Kuyper
Undefined behavior is nothing more or less than behavior that the C
standard doesn't define. In general, it should be avoided, because if
the C standard doesn't define the behavior, it can be arbitrarily bad.
In principle, it would be perfectly legal for code with undefined
behavior to have the result of launching a nuclear war when executed. As
a more practical matter, undefined behavior frequently includes aborting
your program, or messing up your data, or sending bad instructions to
your hardware.
However, undefined behavior can also include executing exactly as you
would expect the code to execute. An implementation is free to provide a
definition of the behavior, even when the standard does not. Code that
isn't meant to be portable can rely on such implemention-specific
guarantees. Portable code cannot.
There's also a lot of "nearly portable" code; code who's behavior is
undefined by the C standard, but is in fact well-defined by de-facto
standards on almost every platform you're likely to use.
Douglas A. Gwyn
> ... What are the meaning of undefined behaviour?
It's a technical term of standardese; essentially it means
that the C standard makes no guarantees about what happens.
The program might crash, it might continue but do something
strange, or it might continue and do something sensible.
When programming for portability, which should usually be
the case, you want to avoid writing code that results in
undefined behavior.
fax
> When programming for portability, which should usually be
> the case, you want to avoid writing code that results in
> undefined behavior.
Then, for example, a situation like:
float func1(void);
void func2(int a);
/* caller */
func2(func1());
is to avoid because it isn't portable, or not?
Thanks.
Douglas A. Gwyn
> > the case, you want to avoid writing code that results in
> > undefined behavior.
> Then, for example, a situation like:
> float func1(void);
> void func2(int a);
> /* caller */
> func2(func1());
> is to avoid because it isn't portable, or not?
The C standard specifies that while a prototype for a function
is visible, arguments are automatically converted to the types
specified in the prototype. Therefore your example has well-
defined behavior. There are some infelicities; for example
floating-point conversion to integer type involves discarding
the fractional part. Also, practically all floating-point
computation is inexact and thus care must be taken to not rely
on exact results; floating-point only approximates real numbers
and therefore properties of the latter than you learned in
school don't necessarily apply to the former.
aBort
> fax wrote:
> > Then, for example, a situation like:
> > float func1(void);
> > void func2(int a);
> > /* caller */
> > func2(func1());
> > is to avoid because it isn't portable, or not?
>
> The C standard specifies that while a prototype for a function
> is visible, arguments are automatically converted to the types
> specified in the prototype. Therefore your example has well-
> defined behavior.
If the integral part can't be represented by an integer type, the behavior is
undefined.
t...@cs.ucr.edu
+ Hello,
+
+ I am a beginner of the language. What are the meaning of undefined
+ behaviour?
Behavior that follows occurrence of a situation for which there is no
Standard-defined behavior. Think of that situation as voiding the
Standard contract between the program and Standard-conforming
implementations.
+ Is it simply an error so difficult to diagnostic at
+ compile-time/run-time?
No, there's much more to it than that. There are a number of reasons
that the authors leave behavior undefined, e.g.:
- The situation is an error that cannot generally be diagnosed
at compile time (e.g., dereferencing the null pointer).
- To allow better optimization (e.g., optimum code for "x = ++*p"
might misbehave for the case where p == &x) by making it the
programmer's fault if optimize code misbehaves.
- To allow for extensions of C (e.g, Pthreads) to add new features
by giving the program an extended contract.
Tom Payne
Francis Glassborow
<kuy...@saicmodis.com> writes
>However, undefined behavior can also include executing exactly as you
>would expect the code to execute. An implementation is free to provide a
>definition of the behavior, even when the standard does not. Code that
>isn't meant to be portable can rely on such implemention-specific
>guarantees. Portable code cannot.
>There's also a lot of "nearly portable" code; code who's behavior is
>undefined by the C standard, but is in fact well-defined by de-facto
>standards on almost every platform you're likely to use.
There is another aspect of undefined behaviour and that is that it
allows compilers to provide platform specific behaviour where that is
possible/desirable without placing any burden on compilers for platforms
where nothing reasonable can be done.
programmers should be sensitive to where they make use of undefined
behaviour that has been made safe for a specific platform.
--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
fax
> by giving the program an extended contract.
But when a compiler choose a solution for an unspecified behavior or an
implementation-defined behavior it already does an extension extern to
standard rules. Then, wnat are differences between theese three models?
Thanks.
James Kuyper Jr.
In general, extensions cause desirable behavior, from someone's point of
view. Implementors usually boast proudly about the fact that their
implementation supports a given extension.
The other two models he listed were:
>> - The situation is an error that cannot generally be diagnosed
>> at compile time (e.g., dereferencing the null pointer).
>>
>> - To allow better optimization (e.g., optimum code for "x = ++*p"
>> might misbehave for the case where p == &x) by making it the
>> programmer's fault if optimize code misbehaves.
In both of those cases, the associated undefined behavior is generally
undesirable. If an implementor even mentions such behavior, it's usually
in the form of a warning, rather than a boast.
Dan Pop
Unspecified behaviour: the implementor must (or, at least, is supposed to)
do something sensible, but is not required to document what he does.
Implementation-defined behaviour: the implementor must do something
sensible and has to document what he does.
Undefined behaviour: the implementor need not do something sensible and
is not required to document it, either.
Consider, for example,
#include <unistd.h>
which is undefined behaviour in a C program.
If the implementor claims POSIX conformance, in addition to ISO C
conformance, this has a well defined and documented behaviour. Otherwise,
this header may be completely missing from the implementation, and you'll
get a diagnostic, or it might be present and contain pure garbage or,
even worse, obnoxious stuff like
#define long short
#define double float
that could compromise the semantics of any program including it. All
these possibilities are allowed by the C standand.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Niklas Matthies
> In <XqPH9.61071$3l.16...@twister1.libero.it> "fax" <fas...@libero.it> writes:
>
>>> - To allow for extensions of C (e.g, Pthreads) to add new features
>>> by giving the program an extended contract.
>>
>>But when a compiler choose a solution for an unspecified behavior or an
>>implementation-defined behavior it already does an extension extern to
>>standard rules. Then, wnat are differences between theese three models?
>
> Unspecified behaviour: the implementor must (or, at least, is supposed to)
> do something sensible, but is not required to document what he does.
>
> Implementation-defined behaviour: the implementor must do something
> sensible and has to document what he does.
>
> Undefined behaviour: the implementor need not do something sensible and
> is not required to document it, either.
That's not quite accurate. In none of these cases does the standard
mandate that the behavior the implementation chooses must be "sensible".
The following is correct:
Undefined behavior: Anything can happen.
Unspecified behavior: Only certain things specified by the standard
can happen, but the implementation is not required to document which
one will happen.
Implementation-defined behavior: Only certain things specified by the
standard can happen, and the implementation is required to document
which one will happen.
-- Niklas Matthies
fax
>
> #include <unistd.h>
>
> which is undefined behaviour in a C program.
>
> If the implementor claims POSIX conformance, in addition to ISO C
> conformance, this has a well defined and documented behaviour.
Then, if I have understood well theese concept, a program like this:
#include <stdio.h>
/* it has a defined behavior*/
/* an header of POSIX */
#include <conio.h>
/* it has an implementation-definen behavior */
/* my header */
#include <my-header.h>
#include "c:\include\my-header.h"
/* it has an undefined behavior */
Thanks.
Francis Glassborow
writes
>If the implementor claims POSIX conformance, in addition to ISO C
>conformance, this has a well defined and documented behaviour. Otherwise,
>this header may be completely missing from the implementation, and you'll
>get a diagnostic, or it might be present and contain pure garbage or,
>even worse, obnoxious stuff like
Is it actually possible to simultaneously conform to both those
standards?
Francis Glassborow
Matthies <comp.std.c...@nmhq.net> writes
>Implementation-defined behavior: Only certain things specified by the
>standard can happen, and the implementation is required to document
>which one will happen.
Chapter and verse please.
Dan Pop
>On 2002-12-06 11:54, Dan Pop <Dan...@cern.ch> wrote:
>> In <XqPH9.61071$3l.16...@twister1.libero.it> "fax" <fas...@libero.it> writes:
>>
>>>> - To allow for extensions of C (e.g, Pthreads) to add new features
>>>> by giving the program an extended contract.
>>>
>>>But when a compiler choose a solution for an unspecified behavior or an
>>>implementation-defined behavior it already does an extension extern to
>>>standard rules. Then, wnat are differences between theese three models?
>>
>> Unspecified behaviour: the implementor must (or, at least, is supposed to)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> do something sensible, but is not required to document what he does.
>>
>> Implementation-defined behaviour: the implementor must do something
>> sensible and has to document what he does.
>>
>> Undefined behaviour: the implementor need not do something sensible and
>> is not required to document it, either.
>
>That's not quite accurate. In none of these cases does the standard
>mandate that the behavior the implementation chooses must be "sensible".
That's why I added the parenthetic remark underlined above.
James Kuyper Jr.
> In message <slrnav168i.sj.com...@nmhq.net>, Niklas
> Matthies <comp.std.c...@nmhq.net> writes
>
>> Implementation-defined behavior: Only certain things specified by the
>> standard can happen, and the implementation is required to document
>> which one will happen.
>
>
> Chapter and verse please.
3.4.1:
"implementation-defined behavior
Unspecified behavior where each implementation documents how the choice
is made."
3.4.4:
"unspecified behavior
Behavior where this International Standard provides two or more
possibilities and imposes no further requirements on which is chosen in
any instance."
Niklas Matthies
> In message <slrnav168i.sj.com...@nmhq.net>, Niklas
> Matthies <comp.std.c...@nmhq.net> writes
>>Implementation-defined behavior: Only certain things specified by the
>>standard can happen, and the implementation is required to document
>>which one will happen.
>
> Chapter and verse please.
3.4.4
unspecified behavior
behavior where this International Standard provides two or more
possibilities and imposes no further requirements on which is chosen
in any instance
3.4.1
implementation-defined behavior
unspecified behavior where each implementation documents how the
choice is made
My intent was to paraphrase 3.4.1 without referring to the definition of
unspecified behavior. What exactly are you objecting to?
-- Niklas Matthies
James Kuyper Jr.
...
> Then, if I have understood well theese concept, a program like this:
>
> #include <stdio.h>
> /* it has a defined behavior*/
> /* an header of POSIX */
> #include <conio.h>
> /* it has an implementation-definen behavior */
> /* my header */
> #include <my-header.h>
> #include "c:\include\my-header.h"
> /* it has an undefined behavior */
The #include directives search for those files in an
implementation-defined way, but for non-standard headers, once they've
been found, they're included in the text of your program just like the
file that #included them. The behavior from that point on is defined by
the standard, or implementation-defined, or undefined, depending
entirely upon what's actually in those files.
Niklas Matthies
Yes, but the important and defining distinction between undefined
behavior and other behavior is not that other behavior "is supposed
to do something sensible" (sensible with regard to whose needs and
expectations?) in the latter case, but that the range of possible
behaviors is restricted to some limited range by the standard, whereas
in the case of undefined behavior, the range of possible behaviors is
inherently unlimited.
-- Niklas Matthies
Douglas A. Gwyn
> Is it actually possible to simultaneously conform to
That was always the intention. A few things have, in
various versions, caused problems; however, the POSIX.1
C binding was always meant to support a conforming C
implementation with allowed extensions.
Niklas Matthies
Yes, but the important and defining distinction between undefined
behavior and other behavior is not that other behavior "is supposed
to do something sensible" (sensible with regard to whose needs and
expectations?), but that the range of possible behaviors is restricted
Alexander Terekhov
Francis Glassborow wrote:
>
> In message <asq35n$if9$1...@sunnews.cern.ch>, Dan Pop <Dan...@cern.ch>
> writes
>
> Is it actually possible to simultaneously conform to both those
> standards?
http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html
("Conformance")
regards,
alexander.
--
"Implementors seeking to claim conformance using the ISO C standard
shall claim POSIX conformance as described in POSIX Conformance."
t...@cs.ucr.edu
+
+ Francis Glassborow wrote:
+>
+> In message <asq35n$if9$1...@sunnews.cern.ch>, Dan Pop <Dan...@cern.ch>
+> writes
+
+ [ ..."implementor claims POSIX conformance"... ]
+
+>
+> Is it actually possible to simultaneously conform to both those
+> standards?
+
+ http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html
+ ("Conformance")
[...]
+ "Implementors seeking to claim conformance using the ISO C standard
+ shall claim POSIX conformance as described in POSIX Conformance."
What does "conformance using the ISO C standard" mean?
Tom Payne
Alexander Terekhov
Well, I guess that the answer can be found here:
http://www.opengroup.org/onlinepubs/007904975/xrat/xbd_chap01.html#tag_01_01_01_02
(Rationale, "POSIX.1 and the ISO C Standard")
http://www.opengroup.org/onlinepubs/007904975/xrat/xbd_chap02.html#tag_01_02_03
(Rationale, "Language-Dependent Services for the C Programming Language")
regards,
alexander.
Francis Glassborow
<kuy...@wizard.net> writes
However the way in which the range of options for something such as
unspecified behaviour is provided in the Standard is often pretty broad.
t...@cs.ucr.edu
+>
+> +
+> + Francis Glassborow wrote:
+> +>
+> +> In message <asq35n$if9$1...@sunnews.cern.ch>, Dan Pop <Dan...@cern.ch>
+> +
+> + [ ..."implementor claims POSIX conformance"... ]
+> +
+> +> Is it actually possible to simultaneously conform to both those
+> +
+> + http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html
+> + ("Conformance")
+> [...]
+> + "Implementors seeking to claim conformance using the ISO C standard
+> + shall claim POSIX conformance as described in POSIX Conformance."
+>
+> What does "conformance using the ISO C standard" mean?
+
+ Well, I guess that the answer can be found here:
+
+ http://www.opengroup.org/onlinepubs/007904975/xrat/xbd_chap01.html#tag_01_01_01_02
+ (Rationale, "POSIX.1 and the ISO C Standard")
+
+ http://www.opengroup.org/onlinepubs/007904975/xrat/xbd_chap02.html#tag_01_02_03
+ (Rationale, "Language-Dependent Services for the C Programming Language")
Thanks. IIUC, POSIX defers to the ISO C Standard on matters of the
core language but differs a bit on certain libarary functions, and
that those differences are usually (but not always) extensions.
Right?
Tom Payne
evv
> implementation-defined way, but for non-standard headers, once they've
> been found, they're included in the text of your program just like the
> file that #included them. The behavior from that point on is defined by
> the standard, or implementation-defined, or undefined, depending
> entirely upon what's actually in those files.
Hello,
is the solution provide by a compiler for an implementation-defined behavior
or unspecified behavior defined in the standard or the translator can do
every thing?
Thanks.
James Kuyper Jr.
The options available for implementation-defined behavior are supposed
to be listed, at least implicitly, in the standard. Someone put a lot of
hard work in to systematically make sure that this was the case. If he
missed a case, it should be brought up as a Defect Report.
"the translator can do every thing" applies only for undefined behavior,
not for implementation-defined behavior.
Fergus Henderson
>The options available for implementation-defined behavior are supposed
>to be listed, at least implicitly, in the standard. Someone put a lot of
>hard work in to systematically make sure that this was the case. If he
>missed a case, it should be brought up as a Defect Report.
How about 6.7.3 [#6]: "What constitutes an access to an object that has
volatile-qualified type is implementation-defined."
What are the possible alternatives here?
Does this warrant a defect report?
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Alexander Terekhov
t...@cs.ucr.edu wrote:
[...]
> + http://www.opengroup.org/onlinepubs/007904975/xrat/xbd_chap01.html#tag_01_01_01_02
> + (Rationale, "POSIX.1 and the ISO C Standard")
> +
> + http://www.opengroup.org/onlinepubs/007904975/xrat/xbd_chap02.html#tag_01_02_03
> + (Rationale, "Language-Dependent Services for the C Programming Language")
>
> Thanks. IIUC, POSIX defers to the ISO C Standard on matters of the
> core language but differs a bit on certain libarary functions, and
> that those differences are usually (but not always) extensions.
> Right?
IIUC [restrictions ala byte/char-bits aside], RIGHT, unfortunately;
think of "memory isolation"/etc. -- things that just ought to be
'resolved' on pure-language level/layer [stuff that POSIX.Std.folks
'prefer' *NOT* to touch, AFAICS].
regards,
alexander.
Alexander Terekhov
Fergus Henderson wrote:
>
> "James Kuyper Jr." <kuy...@wizard.net> writes:
>
> >The options available for implementation-defined behavior are supposed
> >to be listed, at least implicitly, in the standard. Someone put a lot of
> >hard work in to systematically make sure that this was the case. If he
> >missed a case, it should be brought up as a Defect Report.
>
> How about 6.7.3 [#6]: "What constitutes an access to an object that has
> volatile-qualified type is implementation-defined."
> What are the possible alternatives here?
> Does this warrant a defect report?
Sure. And the most effective [efficient/etc.] resolution: simply get
rid of volatiles [*jmp() including], async.signals [replacing them
by threads] next... TIA.
regards,
alexander.
Douglas A. Gwyn
> How about 6.7.3 [#6]: "What constitutes an access to an object that has
> volatile-qualified type is implementation-defined."
> What are the possible alternatives here?
> Does this warrant a defect report?
The alternatives are almost open-ended. While the wording
could be clearer, it doesn't seem to have caused implementors
much trouble, except for rumored behavior of GCC (which I
haven't personally verified). Presumably a DR could solicit
explanation, but really this is the sort of thing that should
be covered in the Rationale document.
Fergus Henderson
>Fergus Henderson wrote:
>> How about 6.7.3 [#6]: "What constitutes an access to an object that has
>> volatile-qualified type is implementation-defined."
>> What are the possible alternatives here?
>> Does this warrant a defect report?
>
>The alternatives are almost open-ended. While the wording
>could be clearer, it doesn't seem to have caused implementors
>much trouble, except for rumored behavior of GCC (which I
>haven't personally verified).
The standard is a contract between implementors and users. This
particular point may or may not have caused implementors much trouble,
but it has certainly caused a lot of difficulty for users --
witness the long threads about "volatile" in this newsgroup!
Fergus Henderson
What replacement would you propose for accessing device registers?
What replacement would you propose for setjmp()/longjmp()?
Threads are no replacement for those.
Alexander Terekhov
[...]
> What replacement would you propose for accessing device registers?
Java's RTS-like "accessors" [and concerning "C" -- in plain-C notation,
of course].
http://groups.google.com/groups?selm=3DA7FFA2.515FF640%40web.de
(Subject: Re: Talking about volatile and threads synchronization...)
http://www.rtj.org/rtsj-V1.0.pdf
(see "Raw Memory Access")
Uhmm, and, BTW, "BYTE_ORDER" [but not boolean; {_B}/{b}ool [heck, what
a mess ;-)] would be way too restrictive, I guess] wouldn't hurt either
<http://groups.google.com/groups?threadm=3DEFCD57.70324ED5%40web.de>.
> What replacement would you propose for setjmp()/longjmp()?
Exceptions, of course.
http://groups.google.com/groups?selm=1qpb9.25%24sm.365733%40news.cpqcorp.net
(Subject: Re: Why is setjmp a macro?)
> Threads are no replacement for those.
Yup. They [e.g. SIGEV_THREAD, etc.] are meant to replace async.signals;
static volatile sig_atomic_t variables and etceteras.
http://groups.google.com/groups?selm=3B5DD9E5.23EB0A8%40web.de
(Subject: Re: POSIX threads and static volatile sig_atomic_t variables)
regards,
alexander.
Dan Pop
>The options available for implementation-defined behavior are supposed
>to be listed, at least implicitly, in the standard. Someone put a lot of
>hard work in to systematically make sure that this was the case. If he
>missed a case, it should be brought up as a Defect Report.
Then, what are the options for this case:
6 Any pointer type may be converted to an integer type. Except as
previously specified, the result is implementation-defined.
Even worse, the standard's example for implementation-defined behaviour
2 EXAMPLE An example of implementation-defined behavior is the
propagation of the high-order bit when a signed integer is
shifted right.
Doesn't match the actual text of the standard:
5 The result of E1 >> E2 is E1 right-shifted E2 bit positions. If
E1 has an unsigned type or if E1 has a signed type and a
nonnegative value, the value of the result is the integral
part of the quotient of E1 / 2**E2. If E1 has a signed type and
a negative value, the resulting value is implementation-defined.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
No mention at all that only two possible values (corresponding to
propagation / non-propagation of the sign bit) are allowed.
Gabriel Dos Reis
| What replacement would you propose for accessing device registers?
A *clearly* and *well* defined and specified feature ?
-- Gaby
James Kuyper Jr.
> In <3DF3C798...@wizard.net> "James Kuyper Jr." <kuy...@wizard.net> writes:
>
>
>>The options available for implementation-defined behavior are supposed
>>to be listed, at least implicitly, in the standard. Someone put a lot of
>>hard work in to systematically make sure that this was the case. If he
>>missed a case, it should be brought up as a Defect Report.
>
>
> Then, what are the options for this case:
In many cases, the list is considered to be implied. An explicit
statement wouldn't hurt, however. If you feel the implications are
insufficiently clear; file a DR.
> 6 Any pointer type may be converted to an integer type. Except as
> previously specified, the result is implementation-defined.
This only allows the result to be implementation-defined, not the
behavior in general. I think that the result is restricted to valid
values of the specified integer type; though I'll have to admit that
this is less clear.
> Even worse, the standard's example for implementation-defined behaviour
>
> 2 EXAMPLE An example of implementation-defined behavior is the
> propagation of the high-order bit when a signed integer is
> shifted right.
>
> Doesn't match the actual text of the standard:
>
> 5 The result of E1 >> E2 is E1 right-shifted E2 bit positions. If
> E1 has an unsigned type or if E1 has a signed type and a
> nonnegative value, the value of the result is the integral
> part of the quotient of E1 / 2**E2. If E1 has a signed type and
> a negative value, the resulting value is implementation-defined.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> No mention at all that only two possible values (corresponding to
> propagation / non-propagation of the sign bit) are allowed.
I don't see a discrepancy. It seem obvious to me that those aren't the
only two possibilities allowed by this text. For my purposes, that
doesn't matter; the simple fact that the result is
implementation-defined is enough to make the result useless for me. I
never deliberately write code that to which that sentence would apply.
However, if it does matter to you, file a DR to clarify it.
Fergus Henderson
>Fergus Henderson wrote:
>[...]
>> What replacement would you propose for accessing device registers?
>
>Java's RTS-like "accessors" [and concerning "C" -- in plain-C notation,
>of course].
>
>> What replacement would you propose for setjmp()/longjmp()?
>
>Exceptions, of course.
>
>> Threads are no replacement for those.
>
>Yup. They [e.g. SIGEV_THREAD, etc.] are meant to replace async.signals;
>static volatile sig_atomic_t variables and etceteras.
Fair enough.
I have just one question:
what were you planning to name your new language? ;-)
Alexander Terekhov
Fergus Henderson wrote:
[...]
> I have just one question:
> what were you planning to name your new language? ;-)
"The Right Java"-aka-POSIX.C/C++!
regards,
alexander.
Francis Glassborow
<kuy...@wizard.net> writes
>> Even worse, the standard's example for implementation-defined behaviour
>> 2 EXAMPLE An example of implementation-defined behavior is the
>> propagation of the high-order bit when a signed integer is
>> shifted right.
>> Doesn't match the actual text of the standard:
>> 5 The result of E1 >> E2 is E1 right-shifted E2 bit positions. If
>> E1 has an unsigned type or if E1 has a signed type and a
>> nonnegative value, the value of the result is the integral
>> part of the quotient of E1 / 2**E2. If E1 has a signed type and
>> a negative value, the resulting value is implementation-defined.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> No mention at all that only two possible values (corresponding to
>> propagation / non-propagation of the sign bit) are allowed.
>
>I don't see a discrepancy. It seem obvious to me that those aren't the
>only two possibilities allowed by this text. For my purposes, that
>doesn't matter; the simple fact that the result is
>implementation-defined is enough to make the result useless for me. I
>never deliberately write code that to which that sentence would apply.
>However, if it does matter to you, file a DR to clarify it.
Where does the Standard say that an implementation has to make the same
choice in all cases? It may be madness but an implementation that
documented that a different choice would be made in leap-years than in
ordinary years would seem to be conforming.
Wojtek Lerch
> Thanks. IIUC, POSIX defers to the ISO C Standard on matters of the
> core language but differs a bit on certain libarary functions, and
> that those differences are usually (but not always) extensions.
All the standard C functions that I've checked have the following
disclaimer in their POSIX description:
The functionality described on this reference page is aligned
with the ISO C standard. Any conflict between the requirements
described here and the ISO C standard is unintentional. This
volume of IEEE Std 1003.1-2001 defers to the ISO C standard.
Do you know of any exceptions?
Tim Woodall
It's not the sign bit that is the problem, it's the high order bit :-)
Tim.
--
God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t,"
and there was light.
Alexander Terekhov
To me, "restriction" != "extension".
>
> Do you know of any exceptions?
^^^^^^^^^
abort(), of course. ;-) ;-)
Well, it's fixed in the upcoming TC1 [thanks to Mr. Douglas Gwyn ;-) ].
regards,
alexander.
P.S. http://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=austin-group-l&id=4598
Douglas A. Gwyn
> A *clearly* and *well* defined and specified feature ?
Feel free to propose such a specification.
Dan Pop
>Dan Pop wrote:
>> In <3DF3C798...@wizard.net> "James Kuyper Jr." <kuy...@wizard.net> writes:
>>
>>
>>>The options available for implementation-defined behavior are supposed
>>>to be listed, at least implicitly, in the standard. Someone put a lot of
>>>hard work in to systematically make sure that this was the case. If he
>>>missed a case, it should be brought up as a Defect Report.
>>
>>
>> Then, what are the options for this case:
>
>In many cases, the list is considered to be implied.
All these cases are defects in the standard, or the standard should
modify the definition of "unspecified behavior":
1 unspecified behavior
behavior where this International Standard provides two or more
possibilities and imposes no further requirements on which is
chosen in any instance
If the list is implied, then it is NOT provided by the standard, as
required by the above quote.
>An explicit
>statement wouldn't hurt, however. If you feel the implications are
>insufficiently clear; file a DR.
>
>> 6 Any pointer type may be converted to an integer type. Except as
>> previously specified, the result is implementation-defined.
>
>This only allows the result to be implementation-defined, not the
>behavior in general.
The standard doesn't distinguish between the two: the actual example of
implementation-defined *behaviour* refers to the generation of an
implementation-defined *value*. The quote is still awailable below.
>I think that the result is restricted to valid
>values of the specified integer type;
Nope, because the next statements of that paragraph say:
If the result cannot be represented in the integer type, the
behavior is undefined. The result need not be in the range of
values of any integer type.
>though I'll have to admit that this is less clear.
This is an understatement. All that 6.3.2.3p6 says is that the
conversion doesn't require a diagnostic. The last two statements
practically invalidate the first one.
>> Even worse, the standard's example for implementation-defined behaviour
>>
>> 2 EXAMPLE An example of implementation-defined behavior is the
>> propagation of the high-order bit when a signed integer is
>> shifted right.
>>
>> Doesn't match the actual text of the standard:
>>
>> 5 The result of E1 >> E2 is E1 right-shifted E2 bit positions. If
>> E1 has an unsigned type or if E1 has a signed type and a
>> nonnegative value, the value of the result is the integral
>> part of the quotient of E1 / 2**E2. If E1 has a signed type and
>> a negative value, the resulting value is implementation-defined.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> No mention at all that only two possible values (corresponding to
>> propagation / non-propagation of the sign bit) are allowed.
>
>I don't see a discrepancy. It seem obvious to me that those aren't the
>only two possibilities allowed by this text.
Then, the discrepancy between the two paragraphs should be obvious:
the former says that the implementation must document how the sign
is propagated, the latter simply allows an implementation to generate
the bit pattern 1010101010... every time a negative value is right
shifted (does this count as "sign bit propagation" to you?).
>For my purposes, that doesn't matter;
Your purposes are irrelevant in a discussion about the C standard.
So are mine.
James Kuyper
>
> In <3DF4B334...@wizard.net> "James Kuyper Jr." <kuy...@wizard.net> writes:
>
> >Dan Pop wrote:
> >In many cases, the list is considered to be implied.
>
> All these cases are defects in the standard, or the standard should
> modify the definition of "unspecified behavior":
>
> 1 unspecified behavior
> behavior where this International Standard provides two or more
> possibilities and imposes no further requirements on which is
> chosen in any instance
>
> If the list is implied, then it is NOT provided by the standard, as
> required by the above quote.
There's no reason why the list can't be provided by implication. I'll
grant you that an explicit list of options is clearer, but an implicit
list is not the same as a missing list. It's just hidden. If it's hidden
so well that you can't find it, it's not implied, it's missing, and you
should file a DR.
...
> >> 6 Any pointer type may be converted to an integer type. Except as
> >> previously specified, the result is implementation-defined.
> >
> >This only allows the result to be implementation-defined, not the
> >behavior in general.
>
> The standard doesn't distinguish between the two: the actual example of
> implementation-defined *behaviour* refers to the generation of an
> implementation-defined *value*. The quote is still awailable below.
There is a distinction between the two; providing an
implementation-defined value is one kind of implementation-defined
behavior. When the text says "implementation-defined value", that does
NOT give license for any other kind of implementation-defined behavior;
only for that one particular kind.
> >I think that the result is restricted to valid
> >values of the specified integer type;
>
> Nope, because the next statements of that paragraph say:
>
> If the result cannot be represented in the integer type, the
> behavior is undefined. The result need not be in the range of
> values of any integer type.
My main point was that if there's a missing list of options, file a DR.
I didn't pay close attention to the other points, since I was in a bit
of a hurry this morning. I based my judgement of that particular item
solely on the text you presented, without bothering to check the
context. Sorry!
...
> >> Even worse, the standard's example for implementation-defined behaviour
> >>
> >> 2 EXAMPLE An example of implementation-defined behavior is the
> >> propagation of the high-order bit when a signed integer is
> >> shifted right.
> >>
> >> Doesn't match the actual text of the standard:
> >>
> >> 5 The result of E1 >> E2 is E1 right-shifted E2 bit positions. If
> >> E1 has an unsigned type or if E1 has a signed type and a
> >> nonnegative value, the value of the result is the integral
> >> part of the quotient of E1 / 2**E2. If E1 has a signed type and
> >> a negative value, the resulting value is implementation-defined.
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> No mention at all that only two possible values (corresponding to
> >> propagation / non-propagation of the sign bit) are allowed.
> >
> >I don't see a discrepancy. It seem obvious to me that those aren't the
> >only two possibilities allowed by this text.
>
> Then, the discrepancy between the two paragraphs should be obvious:
> the former says that the implementation must document how the sign
> is propagated, the latter simply allows an implementation to generate
> the bit pattern 1010101010... every time a negative value is right
> shifted (does this count as "sign bit propagation" to you?).
OK, I can see that. I still don't see it as a big discrepancy, but it
could stand a re-write. Which way it should be re-written depends upon
which way it was actually intended to work. I think that the standard
clearly allows arbitrary values from right shifts of signed types with
negative values; it's unclear whether that was intended.
> >For my purposes, that doesn't matter;
>
> Your purposes are irrelevant in a discussion about the C standard.
> So are mine.
However, my purpose are extremely relevant to why I wouldn't bother
filing the DR; that's the only reason I mentioned them.
Gabriel Dos Reis
| Gabriel Dos Reis wrote:
| > f...@cs.mu.OZ.AU (Fergus Henderson) writes:
| >
| > | What replacement would you propose for accessing device registers?
| >
| > A *clearly* and *well* defined and specified feature ?
|
| Feel free to propose such a specification.
Be my guest; I would love to learn about what you do think is so
important about "accessing device registers" that volatile solves.
-- Gaby
Douglas A. Gwyn
Apparently you can't read. If *you* think there is a
problem with the specification, then *you* are invited
to write a better specification. (My bet is that your
attempt wouldn't be as good as what we now have.)
Volatile qualification has more applications than just
for accessing device registers. But why *that* is
important is that it supports writing device drivers
in C, even "portably" (to the extent that the hardware
architecture is similar across platforms, as with many
UART devices). This practice goes back to the earliest
days of C, and was becoming difficult as compilers
started optimizing generated code more and more.
Gabriel Dos Reis
| Gabriel Dos Reis wrote:
| > "Douglas A. Gwyn" <DAG...@null.net> writes:
| > | Gabriel Dos Reis wrote:
| > | > f...@cs.mu.OZ.AU (Fergus Henderson) writes:
| > | > | What replacement would you propose for accessing device registers?
| > | > A *clearly* and *well* defined and specified feature ?
| > | Feel free to propose such a specification.
| > Be my guest; I would love to learn about what you do think is so
| > important about "accessing device registers" that volatile solves.
|
| Apparently you can't read.
Oh, really? If you think I can't read, you don't expect me to
decipher what you're writing? Do you?
comp.std.c is full of all kind of surprises.
-- Gaby
Dan Pop
>Dan Pop wrote:
>>
>> In <3DF4B334...@wizard.net> "James Kuyper Jr." <kuy...@wizard.net> writes:
>>
>> >Dan Pop wrote:
>...
>> >In many cases, the list is considered to be implied.
>>
>> All these cases are defects in the standard, or the standard should
>> modify the definition of "unspecified behavior":
>>
>> 1 unspecified behavior
>> behavior where this International Standard provides two or more
>> possibilities and imposes no further requirements on which is
>> chosen in any instance
>>
>> If the list is implied, then it is NOT provided by the standard, as
>> required by the above quote.
>
>There's no reason why the list can't be provided by implication. I'll
>grant you that an explicit list of options is clearer, but an implicit
>list is not the same as a missing list. It's just hidden.
If it's hidden, then it is NOT provided.
>...
>> >> 6 Any pointer type may be converted to an integer type. Except as
>> >> previously specified, the result is implementation-defined.
>> >
>> >This only allows the result to be implementation-defined, not the
>> >behavior in general.
>>
>> The standard doesn't distinguish between the two: the actual example of
>> implementation-defined *behaviour* refers to the generation of an
>> implementation-defined *value*. The quote is still awailable below.
>
>There is a distinction between the two; providing an
>implementation-defined value is one kind of implementation-defined
>behavior. When the text says "implementation-defined value", that does
>NOT give license for any other kind of implementation-defined behavior;
>only for that one particular kind.
>
>> >I think that the result is restricted to valid
>> >values of the specified integer type;
>>
>> Nope, because the next statements of that paragraph say:
>>
>> If the result cannot be represented in the integer type, the
>> behavior is undefined. The result need not be in the range of
>> values of any integer type.
>
>My main point was that if there's a missing list of options, file a DR.
Can you find the "hidden" list of options for this particular case in the
standard?
I don't think that it would be reasonable to ask for such list, in this
particular case (and in some others), therefore my point is that the
definition of "unspecified behaviour" should be replaced by the one
of C89, which was more realistic:
* Unspecified behavior --- behavior, for a correct program construct
and correct data, for which the Standard imposes no requirements.
>I didn't pay close attention to the other points, since I was in a bit
>of a hurry this morning. I based my judgement of that particular item
>solely on the text you presented, without bothering to check the
>context. Sorry!
So, what do you think now, when you know the context?
The example quoted above (3.4.1p2) makes the intention clear.
The normative text (6.5.7p5) doesn't.
James Kuyper Jr.
"Be my guest" would have been a appropriate response if Doug had offered
to propose a specification. He didn't. He was inviting you to propose a
specification that would satisfy your objections. How in the world could
he write such a specification? You're the one who knows most precisely
what your objections to the current specification are.
James Kuyper Jr.
> In <3DF52DF0...@saicmodis.com> James Kuyper <kuy...@saicmodis.com> writes:
>
>
>>Dan Pop wrote:
>>
>>>In <3DF4B334...@wizard.net> "James Kuyper Jr." <kuy...@wizard.net> writes:
>>>
>>>
>>>>Dan Pop wrote:
...
>>>If the list is implied, then it is NOT provided by the standard, as
>>>required by the above quote.
>>
>>There's no reason why the list can't be provided by implication. I'll
>>grant you that an explicit list of options is clearer, but an implicit
>>list is not the same as a missing list. It's just hidden.
>
>
> If it's hidden, then it is NOT provided.
So if I give you an envelope, that you have to open in order to get at
the check inside, does that mean I haven't provided you with a check?
I've only provided you with an envelope containing a check, but not with
an actual check? If you think that the implied list is hidden any more
thoroughly than that check would be, then a DR would be justified.
>>>Nope, because the next statements of that paragraph say:
>>>
>>> If the result cannot be represented in the integer type, the
>>> behavior is undefined. The result need not be in the range of
>>> values of any integer type.
>>My main point was that if there's a missing list of options, file a DR.
>
>
> Can you find the "hidden" list of options for this particular case in the
> standard?
In this case list of options is the set of integers, otherwise the
pointer value can't be considered as having been "converted to an
integer type". Of course, by the same argument, it should also be valid
value for that type, whereas the standard explicitly allows it not to
be, so maybe the wording could be re-worked.
The implementation must document which integer value it is, and if the
value is outside the range of values of any integer type, there's no way
for conforming code to prove that the implementation is lying, but the
implementation must document what the nominal value is. The
documentation could be arbitrarily vague: "the conversion results in
some integer value", from which you can conclude that it's not safe to
use this construct on this implementation. But the result must be
documented, and it can't be documented as being, for instance, a
floating point value. If the documented result is a value that is in
range, that claim is testable, and the implementation would not be
conforming unless the test confirms the documented result.
> I don't think that it would be reasonable to ask for such list, in this
> particular case (and in some others), therefore my point is that the
> definition of "unspecified behaviour" should be replaced by the one
> of C89, which was more realistic:
>
> * Unspecified behavior --- behavior, for a correct program construct
> and correct data, for which the Standard imposes no requirements.
The standard already has a term for behavior for which the Standard
imposes no requirements: "undefined behavior". I'd be thoroughly opposed
to any attempt to describe a program construct for which the Standard
imposes no requirements as "a correct program construct and correct
data". A program construct that's described as "correct" shouldn't be
allowed to format your hard disk (unless that's precisely what it was
intended to do, as in system("format c:")). Your suggestions would mean
that ANY unspecified behavior could include formating your hard disk.
...
> So, what do you think now, when you know the context?
That you're correct; that unless the implementation documents that the
result is in the range of values of the chosen integer type, then
converting a pointer to that type has undefined behavior.
...
>>OK, I can see that. I still don't see it as a big discrepancy, but it
>>could stand a re-write. Which way it should be re-written depends upon
>>which way it was actually intended to work. I think that the standard
>>clearly allows arbitrary values from right shifts of signed types with
>>negative values; it's unclear whether that was intended.
>
>
> The example quoted above (3.4.1p2) makes the intention clear.
> The normative text (6.5.7p5) doesn't.
That's one possibility. The reverse seems at least equally possible to
me. 3.4.1p2 could be describing the ordinary case, but 6.5.7p5 might
have been deliberately intended to allow possibilities not consistent
with the wording of 3.4.1p2. The person who wrote 6.5.7p5 might not even
have been aware of the existence of 3.4.1p2. After all, that wording was
only an example, and it wasn't necessarily kept in sync with the
normative text.
Gabriel Dos Reis
| Gabriel Dos Reis wrote:
| > "Douglas A. Gwyn" <DAG...@null.net> writes:
| > | Gabriel Dos Reis wrote:
| > | > f...@cs.mu.OZ.AU (Fergus Henderson) writes:
| > | >
| > | > | What replacement would you propose for accessing device registers?
| > | >
| > | > A *clearly* and *well* defined and specified feature ?
| > | | Feel free to propose such a specification.
| > Be my guest; I would love to learn about what you do think is so
| > important about "accessing device registers" that volatile solves.
|
| "Be my guest" would have been a appropriate response if Doug had
| offered to propose a specification. He didn't. He was inviting you to
| propose a specification that would satisfy your objections. How in the
| world could he write such a specification?
I'm not telling him to write such a specification.
I'm inviting him to tell me what is so important about "accessing
device registers" that volatile solves.
| You're the one who knows
| most precisely what your objections to the current specification are.
My objections were about non-clearly and non-well-defined specified
feature. Beginning with:
[#6] An object that has volatile-qualified type may be
*modified in ways unknown to the implementation or have other
unknown side effects.* Therefore any expression referring to
such an object shall be evaluated strictly according to the
rules of the abstract machine, as described in 5.1.2.3.
Furthermore, at every sequence point the value last stored
in the object shall agree with that prescribed by the
abstract machine, except as modified by the unknown factors
mentioned previously.114) What constitutes an access to an
object that has volatile-qualified type is implementation-
defined.
(My emphasis)
-- Gaby
Dan Pop
>Dan Pop wrote:
>> In <3DF52DF0...@saicmodis.com> James Kuyper <kuy...@saicmodis.com> writes:
>>
>>
>>>Dan Pop wrote:
>>>
>>>>In <3DF4B334...@wizard.net> "James Kuyper Jr." <kuy...@wizard.net> writes:
>>>>
>>>>
>>>>>Dan Pop wrote:
>
>...
>>>>If the list is implied, then it is NOT provided by the standard, as
>>>>required by the above quote.
>>>
>>>There's no reason why the list can't be provided by implication. I'll
>>>grant you that an explicit list of options is clearer, but an implicit
>>>list is not the same as a missing list. It's just hidden.
>>
>>
>> If it's hidden, then it is NOT provided.
>
>So if I give you an envelope, that you have to open in order to get at
>the check inside, does that mean I haven't provided you with a check?
Am I supposed to know that there is a check inside?
>I've only provided you with an envelope containing a check, but not with
>an actual check?
It depends on whether I know there is a check inside or not. If I do
know, then the check is not hidden inside. If you tell me that the
envelope is empty, then the check is hidden and I may very well throw
away the envelope and thus, not get the check.
>If you think that the implied list is hidden any more
>thoroughly than that check would be, then a DR would be justified.
>
>>>>Nope, because the next statements of that paragraph say:
>>>>
>>>> If the result cannot be represented in the integer type, the
>>>> behavior is undefined. The result need not be in the range of
>>>> values of any integer type.
>>>My main point was that if there's a missing list of options, file a DR.
>>
>>
>> Can you find the "hidden" list of options for this particular case in the
>> standard?
>
>In this case list of options is the set of integers, otherwise the
>pointer value can't be considered as having been "converted to an
>integer type". Of course, by the same argument, it should also be valid
>value for that type, whereas the standard explicitly allows it not to
>be, so maybe the wording could be re-worked.
>
>The implementation must document which integer value it is, and if the
>value is outside the range of values of any integer type, there's no way
>for conforming code to prove that the implementation is lying, but the
>implementation must document what the nominal value is. The
>documentation could be arbitrarily vague: "the conversion results in
>some integer value", from which you can conclude that it's not safe to
>use this construct on this implementation.
Such documentation doesn't match the definition of implementation-defined
behaviour, because it doesn't explain how the choice is made.
>But the result must be
>documented, and it can't be documented as being, for instance, a
>floating point value.
Obviously, since we're talking about converting a pointer to an integer
type, so I fail to see your point.
>If the documented result is a value that is in
>range, that claim is testable,
^^^^^^^^^^^^^^^^^^^^^^
How?
>and the implementation would not be
>conforming unless the test confirms the documented result.
But the documented result need not be in range of any integer type.
>> I don't think that it would be reasonable to ask for such list, in this
>> particular case (and in some others), therefore my point is that the
>> definition of "unspecified behaviour" should be replaced by the one
>> of C89, which was more realistic:
>>
>> * Unspecified behavior --- behavior, for a correct program construct
>> and correct data, for which the Standard imposes no requirements.
>
>The standard already has a term for behavior for which the Standard
>imposes no requirements: "undefined behavior". I'd be thoroughly opposed
>to any attempt to describe a program construct for which the Standard
>imposes no requirements as "a correct program construct and correct
>data". A program construct that's described as "correct" shouldn't be
>allowed to format your hard disk (unless that's precisely what it was
>intended to do, as in system("format c:")). Your suggestions would mean
>that ANY unspecified behavior could include formating your hard disk.
Only in the absence of any other context, which is practically never the
case, e.g. "the order of evaluation is unspecified" or "the result is
unspecified". These are forms of unspecified behaviour where the
formatting of any hard disk is ruled out by the context. Yet, the
standard still doesn't impose any requirement on the order of evaluation
or on the result.
>...
>>>OK, I can see that. I still don't see it as a big discrepancy, but it
>>>could stand a re-write. Which way it should be re-written depends upon
>>>which way it was actually intended to work. I think that the standard
>>>clearly allows arbitrary values from right shifts of signed types with
>>>negative values; it's unclear whether that was intended.
>>
>>
>> The example quoted above (3.4.1p2) makes the intention clear.
>> The normative text (6.5.7p5) doesn't.
>
>That's one possibility. The reverse seems at least equally possible to
>me. 3.4.1p2 could be describing the ordinary case, but 6.5.7p5 might
>have been deliberately intended to allow possibilities not consistent
>with the wording of 3.4.1p2.
Then 3.4.1p2 is *deliberately* misleading.
>The person who wrote 6.5.7p5 might not even
>have been aware of the existence of 3.4.1p2.
If it is allowed to ignore parts of the standard when writing other
parts, there is no guarantee that the result will be self-consistent.
This looks like downright insanity to me.
>After all, that wording was
>only an example, and it wasn't necessarily kept in sync with the
>normative text.
In other words, it is perfectly OK to have misleading examples in the
standard...
James Kuyper Jr.
> | You're the one who knows
> | most precisely what your objections to the current specification are.
>
> My objections were about non-clearly and non-well-defined specified
> feature. Beginning with:
>
> [#6] An object that has volatile-qualified type may be
> *modified in ways unknown to the implementation or have other
> unknown side effects.* Therefore any expression referring to
> such an object shall be evaluated strictly according to the
> rules of the abstract machine, as described in 5.1.2.3.
> Furthermore, at every sequence point the value last stored
> in the object shall agree with that prescribed by the
> abstract machine, except as modified by the unknown factors
> mentioned previously.114) What constitutes an access to an
> object that has volatile-qualified type is implementation-
> defined.
Yes, but no one knows more precisely than you do, exactly why you
consider that unclear and poorly defined. Providing an example of what
you think it should say would be one of the simplest ways of clarifying
what your objection is. It's also something that someone has to do,
somewhere along the line, if that passage is to be changed. Who could
possibly be a better choice to write the first draft of a change, than
someone who believes as strongly as you do that it should be changed?
Gabriel Dos Reis
| Gabriel Dos Reis wrote:
| > "James Kuyper Jr." <kuy...@wizard.net> writes:
| ...
| > | You're the one who knows
| > | most precisely what your objections to the current specification are.
| > My objections were about non-clearly and non-well-defined specified
| > feature. Beginning with:
| > [#6] An object that has volatile-qualified type may be
| > *modified in ways unknown to the implementation or have other
| > unknown side effects.* Therefore any expression referring to
| > such an object shall be evaluated strictly according to the
| > rules of the abstract machine, as described in 5.1.2.3.
| > Furthermore, at every sequence point the value last stored
| > in the object shall agree with that prescribed by the
| > abstract machine, except as modified by the unknown factors
| > mentioned previously.114) What constitutes an access to an
| > object that has volatile-qualified type is implementation-
| > defined.
|
| Yes, but no one knows more precisely than you do, exactly why you
| consider that unclear and poorly defined.
That was debated in this very group in a not so distant past.
It is not clear what
modified in ways unknown to the implementation or have
other unknown side effects.
really means.
[...]
| Who could possibly be a better choice to write the first
| draft of a change, than someone who believes as strongly as you do
| that it should be changed?
I believe it is not cleraly defined and not well-defined.
"Believe strongly as you do" is *your* characterization, and I don't
think it is a fair description of my position.
-- Gaby
James Kuyper Jr.
> In <3DF5E15F...@wizard.net> "James Kuyper Jr." <kuy...@wizard.net> writes:
>
>
>>Dan Pop wrote:
>>
>>>In <3DF52DF0...@saicmodis.com> James Kuyper <kuy...@saicmodis.com> writes:
>>>
>>>
>>>
>>>>Dan Pop wrote:
>>>>
>>>>
>>>>>In <3DF4B334...@wizard.net> "James Kuyper Jr." <kuy...@wizard.net> writes:
>>>>>
>>>>>
>>>>>
>>>>>>Dan Pop wrote:
...
>>
>>So if I give you an envelope, that you have to open in order to get at
>>the check inside, does that mean I haven't provided you with a check?
>
>
> Am I supposed to know that there is a check inside?
In context, yes.
>>I've only provided you with an envelope containing a check, but not with
>>an actual check?
>
>
> It depends on whether I know there is a check inside or not. If I do
> know, then the check is not hidden inside. ...
Then, in precisely the same sense, the list isn't hidden. Since the
standard defines that implementation-defined behavior must have a set of
options provided by the standard, you know that the "envelope" is not
supposed to be empty. In the absence of an explicit list of options,
you're supposed to look at the wording and figure out if a list of
options is provided by implication, rather than explicitly.
...
>>implementation must document what the nominal value is. The
>>documentation could be arbitrarily vague: "the conversion results in
>>some integer value", from which you can conclude that it's not safe to
>>use this construct on this implementation.
>
>
> Such documentation doesn't match the definition of implementation-defined
> behaviour, because it doesn't explain how the choice is made.
You're right, it does need to be a little more specific. It could say
that it's "randomly chosen" or "Twice as large as UINTMAX_MAX on
Wednesdays, and 0 on all other days of the week".
>>But the result must be
>>documented, and it can't be documented as being, for instance, a
>>floating point value.
>
>
> Obviously, since we're talking about converting a pointer to an integer
> type, so I fail to see your point.
My point is that "obviously" the list of options is restricted to
integers. That's what I meant when I talked about the list being
implied. You're "obviously" is my "implication".
>>If the documented result is a value that is in
>>range, that claim is testable,
>
> ^^^^^^^^^^^^^^^^^^^^^^
> How?
By passing it to printf() with an appropriate format code for the type
that you cast the pointer to. Modulo, of course, all of those annoying
complications concerning implementation limits and possibly unreliable I/O.
>>and the implementation would not be
>>conforming unless the test confirms the documented result.
>
>
> But the documented result need not be in range of any integer type.
True, but I wasn't talking about the case where it isn't in range. I
explicitly, earlier in the very same sentence, restricted the
applicability of the rest of that sentence to the case where the value
IS in range.
...
>>The standard already has a term for behavior for which the Standard
>>imposes no requirements: "undefined behavior". I'd be thoroughly opposed
>>to any attempt to describe a program construct for which the Standard
>>imposes no requirements as "a correct program construct and correct
>>data". A program construct that's described as "correct" shouldn't be
>>allowed to format your hard disk (unless that's precisely what it was
>>intended to do, as in system("format c:")). Your suggestions would mean
>>that ANY unspecified behavior could include formating your hard disk.
>
>
> Only in the absence of any other context, which is practically never the
> case, e.g. "the order of evaluation is unspecified" or "the result is
> unspecified". These are forms of unspecified behaviour where the
> formatting of any hard disk is ruled out by the context.
Not if the standard were changed so that unspecified behavior was
defined as behavior "for which the Standard imposes no requirements".
Requiring the behavior to fit the context, IS a requirement. The context
is what I was talking about when I referred to the list of options being
implied.
> ... Yet, the
> standard still doesn't impose any requirement on the order of evaluation
> or on the result.
Which is a infinitely more constrained set of permitted behaviors than
the one described by "no requirements".
...
>>That's one possibility. The reverse seems at least equally possible to
>>me. 3.4.1p2 could be describing the ordinary case, but 6.5.7p5 might
>>have been deliberately intended to allow possibilities not consistent
>>with the wording of 3.4.1p2.
>
>
> Then 3.4.1p2 is *deliberately* misleading.
Only if the intent of 3.4.1p2 were to specify the behavior of a right
shift. The intent of 3.4.1p2 was to provide an example of
implementation-defined behavior, and might have been written by someone
who was unaware of the implications of the way 6.5.7p5 was actually
written; it might not even have had those implications at the time
3.4.1p2 was written. One should generally avoid assuming deliberate
intent when there's less insulting possibilities still open.
>>The person who wrote 6.5.7p5 might not even
>>have been aware of the existence of 3.4.1p2.
>
>
> If it is allowed to ignore parts of the standard when writing other
> parts, there is no guarantee that the result will be self-consistent.
> This looks like downright insanity to me.
Nothing written by a committee can easily be kept entirely
self-consistent. Even for a single author, it's very difficult to write
a completely self-consistent document of the length and complexity of
the C standard. Some parts have to be written first. Some parts have to
be written later. The earlier parts sometimes should be updated in light
of how the later parts actually get written, and sometimes that doesn't
actually happen. It is NOT possible for any reasonable number of people
to check every line of the standard in any reasonable amount of time for
consistency against every possible interaction with every possible
combination of all the other lines in the standard.
>>After all, that wording was
>>only an example, and it wasn't necessarily kept in sync with the
>>normative text.
>
>
> In other words, it is perfectly OK to have misleading examples in the
> standard...
I said that it was possible. I didn't say so explicitly, but I also
consider it plausible. But I never suggested that it was OK. How did you
reach that conclusion?
To the extent that it is possible to check the standard for consistency,
it was probably checked somewhat more thoroughly for consistency of the
normative text with itself, than for consistency with the non-normative
text. Putting equal amounts of effort into checking both kinds of
consistency would have been a waste of severely limited resources.
Expecting the result to be perfect, or criticizing it for not being
perfect, is pretty unrealistic.
Dan Pop
From the text quoted above, only the last statement needs to be changed,
so that it is the standard that actually defines what constitutes an
access... Something like "using the current value or storing a value"
should probably be good enough.
But that's not the whole story.
3 In the abstract machine, all expressions are evaluated as
specified by the semantics. An actual implementation need not
evaluate part of an expression if it can deduce that its value is
not used and that no needed side effects are produced (including
any caused by calling a function or accessing a volatile object).
Also needs some maintenance, so that volatile-related side effects cannot
be optimised away under any circumstance. The concept of "needed side
effects", being defined nowhere in the standard, renders this paragraph
quite ambiguous.
James Kuyper
> | consider that unclear and poorly defined.
>
> That was debated in this very group in a not so distant past.
>
> It is not clear what
>
> modified in ways unknown to the implementation or have
> other unknown side effects.
>
> really means.
Then propose wording that is clearer.
...
> | draft of a change, than someone who believes as strongly as you do
> | that it should be changed?
>
> I believe it is not cleraly defined and not well-defined.
>
> "Believe strongly as you do" is *your* characterization, and I don't
> think it is a fair description of my position.
You left out a key word: the first "as". By definition, it is always a
correct description to say that you "believe as strongly as you do", no
matter how weak your belief is. Of course, if you really don't care much
about this clause, and are just bringing it up as an example, then the
re-write should be done by someone believes in the need for change more
strongly than you do; but it certainly shouldn't be done by someone who
believes in the need less than you do.
Gabriel Dos Reis
[...]
| > | draft of a change, than someone who believes as strongly as you do
| > | that it should be changed?
| >
| > I believe it is not cleraly defined and not well-defined.
| >
| > "Believe strongly as you do" is *your* characterization, and I don't
| > think it is a fair description of my position.
|
| You left out a key word: the first "as".
Sorry.
| By definition, it is always a
| correct description to say that you "believe as strongly as you do", no
| matter how weak your belief is.
No, It doesn't.
| Of course, if you really don't care much
| about this clause, and are just bringing it up as an example, then the
| re-write should be done by someone believes in the need for change more
| strongly than you do;
Why?
| but it certainly shouldn't be done by someone who
| believes in the need less than you do.
Why?
-- Gaby
James Kuyper
> | correct description to say that you "believe as strongly as you do", no
> | matter how weak your belief is.
>
> No, It doesn't.
It doesn't what? Which 'it' are you referring to? Did you mean to say
"It isn't."?
I'm just saying x==x, where x is the level of your belief. How could
that statement be incorrect?
> | Of course, if you really don't care much
> | about this clause, and are just bringing it up as an example, then the
> | re-write should be done by someone believes in the need for change more
> | strongly than you do;
>
> Why?
Because, if you don't believe in the need for change strongly enough to
actually bother writing up a proposed replacement, only someone whose
belief is stronger than yours is likely to actually do it.
> | but it certainly shouldn't be done by someone who
> | believes in the need less than you do.
>
> Why?
Because nothing would get done by anyone that poorly motivated.
Douglas A. Gwyn
> I'm inviting him to tell me what is so important about "accessing
> device registers" that volatile solves.
I explained why it was important, which is all that you asked,
but you didn't further respond to that. Volatile qualification
addresses only part of the full set of possible access-pattern
needs, but it's the most important part, sufficient for many
applications, and is readily specified in terms of the abstract
C machine. More detailed control over access pattern would
require an immense amount more machinery to cover all the ways
in which actual systems can behave; we chose not to attempt
that as the result would most likely be complex and not used.
However, there *is* a proposal afoot for hardware-oriented I/O
addressing API that tackles more of these issues; it hasn't yet
reached the stage of being standardized.
> My objections were about non-clearly and non-well-defined specified
> feature. Beginning with:
> [#6] An object that has volatile-qualified type may be
> *modified in ways unknown to the implementation or have other
> unknown side effects.* Therefore any expression referring to
> such an object shall be evaluated strictly according to the
> rules of the abstract machine, as described in 5.1.2.3.
> Furthermore, at every sequence point the value last stored
> in the object shall agree with that prescribed by the
> abstract machine, except as modified by the unknown factors
> mentioned previously.114) What constitutes an access to an
> object that has volatile-qualified type is implementation-
> defined.
> (My emphasis)
What you applied emphasis to is merely explanatory (motivational).
The actual requirements immediately follow that. The only valid
quibble I know of with this spec is that "what constitutes access"
has misled some into thinking that the access might not even occur.
Douglas A. Gwyn
> So if I give you an envelope, that you have to open in order to get at
> the check inside, does that mean I haven't provided you with a check?
Let's not get too carried away trying to defend the exact usage
in the current standard. There are definitely more shades of
"conformance category" than there are standardese terms to
describe them. I've on occasion suggested that WG14 needs to
improve this situation, but the consensus seems to be that
meddling with conformance requirements is scary, and that there
isn't enough actual problem to justify the work it would take.
Gabriel Dos Reis
| Gabriel Dos Reis wrote:
| > I'm inviting him to tell me what is so important about "accessing
| > device registers" that volatile solves.
|
| I explained why it was important, which is all that you asked,
| but you didn't further respond to that.
Since you started thinking that I can't read, how could you imagine I
would read your explanation and respond?
-- Gaby
Wojtek Lerch
> Wojtek Lerch wrote:
...
> > All the standard C functions that I've checked have the following
> > disclaimer in their POSIX description:
> >
> > The functionality described on this reference page is aligned
> > with the ISO C standard. Any conflict between the requirements
> > described here and the ISO C standard is unintentional. This
> > volume of IEEE Std 1003.1-2001 defers to the ISO C standard.
>
> To me, "restriction" != "extension".
An implementation provides an extension when it *promises*
a behaviour that the C Standard merely *allows*. This kind
of a promise *restricts* the range of the implementation's
possible behaviour. :-)
> > Do you know of any exceptions?
> ^^^^^^^^^
>
> abort(), of course. ;-) ;-)
>
> Well, it's fixed in the upcoming TC1 [thanks to Mr. Douglas Gwyn ;-) ].
... which is why it's not really a good example: as soon as this
*unintentional* conflict was caught, it was handled by deferring to
the ISO C standard. :-)
Gabriel Dos Reis
[...]
| > | Of course, if you really don't care much
| > | about this clause, and are just bringing it up as an example, then the
| > | re-write should be done by someone believes in the need for change more
| > | strongly than you do;
| >
| > Why?
|
| Because, if you don't believe in the need for change strongly enough to
| actually bother writing up a proposed replacement, only someone whose
| belief is stronger than yours is likely to actually do it.
Not necessarily, someone who *understands* the issue _may_ do it.
Actually, I'm not seeking for changes based on strong believes, but
changes based on *rational* understanding. I don't want "to go on
croisade"
| > | but it certainly shouldn't be done by someone who
| > | believes in the need less than you do.
| >
| > Why?
|
| Because nothing would get done by anyone that poorly motivated.
That is your opinion.
-- Gaby
Barry E. Hedquist
from functions specified in POSIX vs expected behavior
under ISO C. For example, in ISO C a function given an
invalid argument is 'undefined-behavior', in POSIX the
same argument may be required to return a specific ERRNO.
Barry
============
Barry E. Hedquist
Perennial, Inc.
============
"Wojtek Lerch" <Wojt...@yahoo.ca> wrote in message
news:ca7e6477.02121...@posting.google.com...
Douglas A. Gwyn
> It is not clear what
> other unknown side effects.
It's clear to me! The "implementation" is the (conforming)
C implementation, i.e. compiler and run-time system.
"Unknown" means that the implementation cannot take into
account the possible actions of or on external agents, at
least not without being given some extra hint. Volatile
qualification provides that hint. In the absence of volatile
qualification, elsewhere the standard permits the actual
generated run-time instructions to short-cut the apparent
object access pattern indicated in the source code, so long
as the required overall effects occur identically. Volatile
qualification instructs the compiler to not take such short
cuts for access of the so-qualified object.
Dan Pop
>Dan Pop wrote:
>> In <3DF5E15F...@wizard.net> "James Kuyper Jr." <kuy...@wizard.net> writes:
>>
>>>Dan Pop wrote:
>>>
>>>>In <3DF52DF0...@saicmodis.com> James Kuyper <kuy...@saicmodis.com> writes:
>>>>
>>>>>Dan Pop wrote:
>>>>>
>>>>>>In <3DF4B334...@wizard.net> "James Kuyper Jr." <kuy...@wizard.net> writes:
>>>>>>
>>>>>>>Dan Pop wrote:
>...
>>>>If it's hidden, then it is NOT provided.
>>>
>>>So if I give you an envelope, that you have to open in order to get at
>>>the check inside, does that mean I haven't provided you with a check?
>>
>> Am I supposed to know that there is a check inside?
>
>In context, yes.
Then, I know where to look for it, it isn't hidden in the envelope.
>>>I've only provided you with an envelope containing a check, but not with
>>>an actual check?
>>
>> It depends on whether I know there is a check inside or not. If I do
>> know, then the check is not hidden inside. ...
>
>Then, in precisely the same sense, the list isn't hidden.
You're the one who introduced "hidden" in this discussion, so please make
up your mind.
>Since the
>standard defines that implementation-defined behavior must have a set of
>options provided by the standard, you know that the "envelope" is not
>supposed to be empty. In the absence of an explicit list of options,
>you're supposed to look at the wording and figure out if a list of
>options is provided by implication, rather than explicitly.
"Provided by implication" means nothing in context (two different people
can imply different things from a text like the C standard). The list
is either provided or it isn't. I gave you concrete examples where
it isn't.
>...
>>>implementation must document what the nominal value is. The
>>>documentation could be arbitrarily vague: "the conversion results in
>>>some integer value", from which you can conclude that it's not safe to
>>>use this construct on this implementation.
>>
>>
>> Such documentation doesn't match the definition of implementation-defined
>> behaviour, because it doesn't explain how the choice is made.
>
>You're right, it does need to be a little more specific. It could say
>that it's "randomly chosen" or "Twice as large as UINTMAX_MAX on
>Wednesdays, and 0 on all other days of the week".
And this is a direct consequence of the fact that the standard doesn't
provide a list of choices.
>>>If the documented result is a value that is in
>>>range, that claim is testable,
>>
>> ^^^^^^^^^^^^^^^^^^^^^^
>> How?
>
>By passing it to printf() with an appropriate format code for the type
>that you cast the pointer to.
How do I know what the pointer value was, so that I can compare the
two values, which is needed in order to test the claim?
>Modulo, of course, all of those annoying
>complications concerning implementation limits and possibly unreliable I/O.
These are the least significant problems of your suggested method.
>>>and the implementation would not be
>>>conforming unless the test confirms the documented result.
>>
>> But the documented result need not be in range of any integer type.
>
>True, but I wasn't talking about the case where it isn't in range. I
>explicitly, earlier in the very same sentence, restricted the
>applicability of the rest of that sentence to the case where the value
>IS in range.
But how do I know whether the value was in range, so the result is
meaningful, or the value was out of range and I have just invoked
undefined behaviour? Some pointer values may be convertible, others may
not, according to the actual wording of the standard.
>>>The standard already has a term for behavior for which the Standard
>>>imposes no requirements: "undefined behavior". I'd be thoroughly opposed
>>>to any attempt to describe a program construct for which the Standard
>>>imposes no requirements as "a correct program construct and correct
>>>data". A program construct that's described as "correct" shouldn't be
>>>allowed to format your hard disk (unless that's precisely what it was
>>>intended to do, as in system("format c:")). Your suggestions would mean
>>>that ANY unspecified behavior could include formating your hard disk.
>>
>>
>> Only in the absence of any other context, which is practically never the
>> case, e.g. "the order of evaluation is unspecified" or "the result is
>> unspecified". These are forms of unspecified behaviour where the
>> formatting of any hard disk is ruled out by the context.
>
>Not if the standard were changed so that unspecified behavior was
>defined as behavior "for which the Standard imposes no requirements".
Well, this was precisely the C89 definition. How many times did you get
your hard disk reformatted while making a function call or evaluating an
expression in a C89 program?
>Requiring the behavior to fit the context, IS a requirement. The context
>is what I was talking about when I referred to the list of options being
>implied.
>
>> ... Yet, the
>> standard still doesn't impose any requirement on the order of evaluation
>> or on the result.
>
>Which is a infinitely more constrained set of permitted behaviors than
>the one described by "no requirements".
The additional restrictions come from the context, not from the definition
of unspecified behaviour.
>...
>>>That's one possibility. The reverse seems at least equally possible to
>>>me. 3.4.1p2 could be describing the ordinary case, but 6.5.7p5 might
>>>have been deliberately intended to allow possibilities not consistent
>>>with the wording of 3.4.1p2.
>>
>>
>> Then 3.4.1p2 is *deliberately* misleading.
>
>Only if the intent of 3.4.1p2 were to specify the behavior of a right
>shift. The intent of 3.4.1p2 was to provide an example of
>implementation-defined behavior, and might have been written by someone
>who was unaware of the implications of the way 6.5.7p5 was actually
>written;
Then, that person was incompetent (in context) and shouldn't have chosen
that example.
>it might not even have had those implications at the time
>3.4.1p2 was written.
False. The behaviour is the same in C89, but the example is new in C99,
AFAIK.
>One should generally avoid assuming deliberate
>intent when there's less insulting possibilities still open.
It was you who (implicitly) suggested this possibility. BTW, I have no
idea what is more insulting here: incompetence or deliberate intent :-)
>>>The person who wrote 6.5.7p5 might not even
>>>have been aware of the existence of 3.4.1p2.
>>
>>
>> If it is allowed to ignore parts of the standard when writing other
>> parts, there is no guarantee that the result will be self-consistent.
>> This looks like downright insanity to me.
>
>Nothing written by a committee can easily be kept entirely
>self-consistent. Even for a single author, it's very difficult to write
>a completely self-consistent document of the length and complexity of
>the C standard.
AFAIK, one of the committee members is the standard editor. It would be
reasonable to assume that, at least this member reads the document before
submitting it for approval.
>Some parts have to be written first. Some parts have to
>be written later. The earlier parts sometimes should be updated in light
>of how the later parts actually get written, and sometimes that doesn't
>actually happen. It is NOT possible for any reasonable number of people
>to check every line of the standard in any reasonable amount of time for
>consistency against every possible interaction with every possible
>combination of all the other lines in the standard.
No such thing is needed for my blatant example: if you know what is the
behaviour of the right shift operator on signed values (and it is
reasonable to assume that every committee member knows it), the example
is obviously wrong. I spotted it when reading the C99 definitions of
terms, without making any special effort.
>>>After all, that wording was
>>>only an example, and it wasn't necessarily kept in sync with the
>>>normative text.
>>
>> In other words, it is perfectly OK to have misleading examples in the
>> standard...
>
>I said that it was possible. I didn't say so explicitly, but I also
>consider it plausible.
It isn't: the actual contents of 6.5.7p5 (it exists in my C89 draft) is
older than the 3.4.1p2 example (which doesn't exist in my C89 draft).
So, your hypothesis that the example wasn't necessarily kept in sync
with the normative text is unfounded.
>But I never suggested that it was OK. How did you
>reach that conclusion?
From your desperate attempts to justify it.
>To the extent that it is possible to check the standard for consistency,
>it was probably checked somewhat more thoroughly for consistency of the
>normative text with itself, than for consistency with the non-normative
>text. Putting equal amounts of effort into checking both kinds of
>consistency would have been a waste of severely limited resources.
I spotted it without wasting any kind of resource, by simply reading one
of the most important parts of the standard (Clause 3). When seeing it,
my first suspicion was that the description of the right shift operator
has been changed, in the sense described by K&R1. A quick check showed
that this was not the case.
>Expecting the result to be perfect, or criticizing it for not being
>perfect, is pretty unrealistic.
We're not talking here about some obscure implications of the new
definition of "lvalue", but about an easy to spot contradiction. If it
is unrealistic to expect that such obvious things are detected before
the standard is approved, then expecting a high degree of coherence
(nobody talks about perfection here) is sheer foolishness...
James Kuyper
> | actually bother writing up a proposed replacement, only someone whose
> | belief is stronger than yours is likely to actually do it.
>
> Not necessarily, someone who *understands* the issue _may_ do it.
Not if they don't believe it's important enough to bother doing. That's
the key point. If you don't believe it's important enough to bother
doing it yourself, don't be surprised if no one else feels that way
either.
James Kuyper
>
> You would have to look carefully at certain returns
> from functions specified in POSIX vs expected behavior
> under ISO C. For example, in ISO C a function given an
> invalid argument is 'undefined-behavior', in POSIX the
> same argument may be required to return a specific ERRNO.
That kind of difference between the standards is fairly innocuous. It's
quite feasible to conform to both, since ISO C undefined behavior can
include, among other things, the behavior that's defined by POSIX.
Gabriel Dos Reis
| Gabriel Dos Reis wrote:
| > It is not clear what
| > modified in ways unknown to the implementation or have
| > other unknown side effects.
| > really means.
|
| It's clear to me! The "implementation" is the (conforming)
| C implementation, i.e. compiler and run-time system.
| "Unknown" means that the implementation cannot take into
| account the possible actions of or on external agents, at
| least not without being given some extra hint.
Thanks.
But then, is an alpha ray fired from Alpha Centauri considered a
possible action or external agent the compiler and the run-time system
cannot take into account? I mean a serious question, not a rhetorical
one.
If
What constitutes an access to an object that has
volatile-qualified type is implementation-defined.
how can one portably rely on volatile to give any common semantics
to rely?
-- Gaby
Gabriel Dos Reis
| Gabriel Dos Reis wrote:
| >
| > James Kuyper <kuy...@saicmodis.com> writes:
| ...
| > | Because, if you don't believe in the need for change strongly enough to
| > | actually bother writing up a proposed replacement, only someone whose
| > | belief is stronger than yours is likely to actually do it.
| >
| > Not necessarily, someone who *understands* the issue _may_ do it.
|
| Not if they don't believe it's important enough to bother doing. That's
| the key point.
That is entirely different from having "someone whose belief is
stronger than mine".
| If you don't believe it's important enough to bother
| doing it yourself, don't be surprised if no one else feels that way
| either.
Sure. But that misses the point. Which is I may find someone (whose
belief isn't stronger than mine) who can conduct the work.
-- Gaby
Ross Ridge
> Thanks. IIUC, POSIX defers to the ISO C Standard on matters of the
> core language but differs a bit on certain libarary functions, and
> that those differences are usually (but not always) extensions.
Wojtek Lerch <Wojt...@yahoo.ca> wrote:
>All the standard C functions that I've checked have the following
>disclaimer in their POSIX description:
>
> The functionality described on this reference page is aligned
> with the ISO C standard. Any conflict between the requirements
> described here and the ISO C standard is unintentional. This
> volume of IEEE Std 1003.1-2001 defers to the ISO C standard.
Hmmm... that must be new in the 2001 edition. Older POSIX.1 editions
didn't even assume Standard C as a base. The 2001 edition is likely to
be as irrlevent as C99 (especially if it requires C99 as a base).
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/
db //
James Kuyper
>
> James Kuyper <kuy...@saicmodis.com> writes:
>
> | Gabriel Dos Reis wrote:
> | >
> | > James Kuyper <kuy...@saicmodis.com> writes:
> | ...
> | > | Because, if you don't believe in the need for change strongly enough to
> | > | actually bother writing up a proposed replacement, only someone whose
> | > | belief is stronger than yours is likely to actually do it.
> | >
> | > Not necessarily, someone who *understands* the issue _may_ do it.
> |
> | Not if they don't believe it's important enough to bother doing. That's
> | the key point.
>
> That is entirely different from having "someone whose belief is
> stronger than mine".
The strength of one's belief in the need for a particular change is very
directly relevant to how hard one is willing to work to achieve that
change.
James Kuyper
>
> In <3DF603AF...@wizard.net> "James Kuyper Jr." <kuy...@wizard.net> writes:
>
> >Dan Pop wrote:
> >> In <3DF5E15F...@wizard.net> "James Kuyper Jr." <kuy...@wizard.net> writes:
> >>
> >>>Dan Pop wrote:
...
> >>>>If it's hidden, then it is NOT provided.
> >>>
> >>>So if I give you an envelope, that you have to open in order to get at
> >>>the check inside, does that mean I haven't provided you with a check?
> >>
> >> Am I supposed to know that there is a check inside?
> >
> >In context, yes.
>
> Then, I know where to look for it, it isn't hidden in the envelope.
It isn't hidden? Then what color is it, what number does it have on it,
how much has it been made out for, who signed it, and what bank is it
drawn upon? If such a check weren't hidden, you would be able answer all
of those questions about it.
> >Then, in precisely the same sense, the list isn't hidden.
>
> You're the one who introduced "hidden" in this discussion, so please make
> up your mind.
Well, actually, I didn't consider that a valid sense of the word
"hidden". I was merely pointing out that if it were, as you suggested, a
valid sense of that word, then the rest of what I said would still
apply. My point was that a missing list should lead to a DR; a list that
was implied by other text is not a missing list.
...
> "Provided by implication" means nothing in context (two different people
> can imply different things from a text like the C standard). The list
You're thinking of 'infer'; that's something the reader does. "imply" is
something that the text does. The text either does or does not imply the
list, regardless of whether or not anybody ever notices the implication;
in fact, the text either implies the list, or does not imply it,
regardless of whether or not anyone ever even reads the text. If you
think it doesn't imply a list of options, file a DR.
> >You're right, it does need to be a little more specific. It could say
> >that it's "randomly chosen" or "Twice as large as UINTMAX_MAX on
> >Wednesdays, and 0 on all other days of the week".
>
> And this is a direct consequence of the fact that the standard doesn't
> provide a list of choices.
No, it follows from the fact that the implied list of choices doesn't
exclude either of those possibilities. Well, not completely, it also
depends upon the fact that the wording in the standard about
implementation choices doesn't specify how frequently, or under which
circumstances, an implementation can change the choices it makes.
...
> How do I know what the pointer value was, so that I can compare the
> two values, which is needed in order to test the claim?
That depends entirely upon what the documented result is. It's quite
possible and legal for the documentation to be uselessly vague about
this. However, even with the vaguest description, if the documentation
says something that guarantees the result will be in range, then you
know that the code is not allowed to fail for that reason. And a test
where the code does fail for that reason would prove non-conformance. A
test that succeeded would not, however, carry the opposite implication.
A single test can only prove non-conformance of an implementation;
proving conformance requires an almost infinite number of test cases.
...
> But how do I know whether the value was in range, so the result is
> meaningful, or the value was out of range and I have just invoked
> undefined behaviour?
That depends entirely upon the implementation's documentation. What I
said about the result being testable, applies only when the
implementation's documentation provides enough information to create a
test case that should have a value that is in range. There's nothing in
the standard that guarantees that there must be such a test case;
however, if there is such a test case, the words of the standard do give
the code defined behavior.
...
> Well, this was precisely the C89 definition. How many times did you get
> your hard disk reformatted while making a function call or evaluating an
> expression in a C89 program?
QoI imposes restrictions that the standard itself does not, so
implementations that did that were fairly rare. But that's irrelevant -
I'm talking about what's allowed; not about what actually happened.
...
> >Which is a infinitely more constrained set of permitted behaviors than
> >the one described by "no requirements".
>
> The additional restrictions come from the context, not from the definition
> of unspecified behaviour.
Agreed. And the context is part of the standard, so it is indeed the
standard itself that imposes those requirements. Whereas an explicit
statement that unspecified behavior "imposes no requirements" would
invalidate every requirement that you could otherwise derive from the
context.
...
> Then, that person was incompetent (in context) and shouldn't have chosen
> that example.
Are you in the habit of working with the Pope? He's the only person I
know of about whom infallibility is even claimed, much less true. I
don't know of anyone so competent that they couldn't miss a subtle
distinction like this one. It would be a different matter if someone
pointed out the discrepancy, and they denied that it existed, but
failing to notice a discrepancy this subtle isn't a serious sign of
incompetence.
> It was you who (implicitly) suggested this possibility. BTW, I have no
> idea what is more insulting here: incompetence or deliberate intent :-)
What I suggested was an example of exactly the kind of mistake that, in
my experience, fully competent people make from time to time. No insult
was intended. Whereas I don't see any way to allege "deliberate intent"
without being insulting.
...
> AFAIK, one of the committee members is the standard editor. It would be
> reasonable to assume that, at least this member reads the document before
> submitting it for approval.
Yes, that's a good idea - a good way of reducing the number of errors
that make their way into the final document. However, if you expect him
to eliminate errors totally, you've had experience with a more god-like
subset of humanity than the one I've spent my life with.
...
> No such thing is needed for my blatant example: if you know what is the
> behaviour of the right shift operator on signed values (and it is
> reasonable to assume that every committee member knows it), the example
> is obviously wrong. I spotted it when reading the C99 definitions of
> terms, without making any special effort.
Good for you. I don't know what the behavior of the right shift operator
is on signed values. I know that it's different on different machines.
I've heard of about four different variants, and I don't know for
certain that there aren't more. I'm proud of you for having the
certainty that I lack! Assuming, of course, that it's justified.
However, the issue wasn't the actual behavior of right shift on signed
values for real machines. The issue is what, if anything, the standard
should require for such behavior.
...
> It isn't: the actual contents of 6.5.7p5 (it exists in my C89 draft) is
> older than the 3.4.1p2 example (which doesn't exist in my C89 draft).
As I've said before, I don't have a copy of that standard; I'll take
your word for that.
> So, your hypothesis that the example wasn't necessarily kept in sync
> with the normative text is unfounded.
Well, they're out of sync, in your opinion. They got that way somehow.
> >But I never suggested that it was OK. How did you
> >reach that conclusion?
>
> From your desperate attempts to justify it.
I made no such attempts. I never suggested that it was a good thing or
acceptable for such a discrepancy to exist. I only attempted to explain
ways in which it might have happened.
> We're not talking here about some obscure implications of the new
> definition of "lvalue", but about an easy to spot contradiction. If it
> is unrealistic to expect that such obvious things are detected before
> the standard is approved, then expecting a high degree of coherence
> (nobody talks about perfection here) is sheer foolishness...
We have radically different opinions about how blatant the discrepancy
is. I don't think there's anything more useful we can say about this.
Everything else depends upon whether you see this as blindingly obvious
or fairly subtle, and I doubt we can reach agreement on that issue.
Francis Glassborow
<kuy...@wizard.net> writes
>>What constitutes an access to an
>> object that has volatile-qualified type is implementation-
>> defined.
So what are the permitted behaviours (implementation defined requires
that the Standard somehow specifies what the choices are, exactly as is
required for unspecified behaviour.
--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Douglas A. Gwyn
> But then, is an alpha ray fired from Alpha Centauri considered a
> possible action or external agent the compiler and the run-time system
> cannot take into account? I mean a serious question, not a rhetorical
> one.
Yes and no. Yes, if the programmer wanted to protect against
an object's contents changing due to a cosmic ray (not alpha,
that wouldn't penetrate), then he'd need to use "volatile".
No, the implementation that is claimed to be "conforming"
would not be specified as including cosmic rays.
> If
> What constitutes an access to an object that has
> volatile-qualified type is implementation-defined.
> how can one portably rely on volatile to give any common semantics
> to rely?
All that that sentence means is that the width, read-modify-
write cycles, caching, etc. are platform-dependent and the
conforming implementation is obliged to document them (at
least well enough that customers won't challenge the
conformance of the implementation in this regard). There is
an almost infinite amount of possible variability in such
details, and the C standard chooses not to get involved in
those details, beyond requiring that the access must *occur*
when the object type has been volatile-qualified. That is
about as far as we felt could be required of *all* reasonable
implementations.
Even with such limited control, volatile qualification is
useful in many situations. The C standard mentions it in
connection with longjmp. I use it to ensure that memory-
mapped device registers are updated as I tweak bits in them.
A recent thread noted that it could be used to ensure that
an attempt to protect data in a reusable memory segment by
overwriting the data with zeros would in fact get the zeros
written; if there was no further use of that memory in the
program, without volatile qualification the C implementation
doesn't have to generate code for the final store, and
reportedly at least one implementation takes advantage of
that license.
Dan Pop
>Dan Pop wrote:
>>
>> In <3DF603AF...@wizard.net> "James Kuyper Jr." <kuy...@wizard.net> writes:
>>
>> >Dan Pop wrote:
>> >> In <3DF5E15F...@wizard.net> "James Kuyper Jr." <kuy...@wizard.net> writes:
>> >>
>> >>>Dan Pop wrote:
>...
>> >>>>If it's hidden, then it is NOT provided.
>> >>>
>> >>>So if I give you an envelope, that you have to open in order to get at
>> >>>the check inside, does that mean I haven't provided you with a check?
>> >>
>> >> Am I supposed to know that there is a check inside?
>> >
>> >In context, yes.
>>
>> Then, I know where to look for it, it isn't hidden in the envelope.
>
>It isn't hidden? Then what color is it, what number does it have on it,
>how much has it been made out for, who signed it, and what bank is it
>drawn upon? If such a check weren't hidden, you would be able answer all
>of those questions about it.
I open the envelope, look at the check and answer all these questions.
I cannot do the same thing by reading the standard, if someone asked me
what is the list of options provided by the standard for the %p printf
conversion specification. But if you can, please provide the *complete*
list.
>> >Then, in precisely the same sense, the list isn't hidden.
>>
>> You're the one who introduced "hidden" in this discussion, so please make
>> up your mind.
>
>Well, actually, I didn't consider that a valid sense of the word
>"hidden". I was merely pointing out that if it were, as you suggested, a
>valid sense of that word, then the rest of what I said would still
>apply. My point was that a missing list should lead to a DR; a list that
>was implied by other text is not a missing list.
OK, what is the list implied by *other text* and what exactly is the
*other text* implying it? Use the %p example above.
>> "Provided by implication" means nothing in context (two different people
>> can imply different things from a text like the C standard). The list
>
>You're thinking of 'infer'; that's something the reader does. "imply" is
>something that the text does. The text either does or does not imply the
>list, regardless of whether or not anybody ever notices the implication;
>in fact, the text either implies the list, or does not imply it,
>regardless of whether or not anyone ever even reads the text. If you
>think it doesn't imply a list of options, file a DR.
You're contradicting yourself: if the implication is an intrinsic property
of the text, then what I think about it shouldn't matter.
However, the standard says "provides", not "implies" and the two are not,
AFAICT, synonyms.
>> >You're right, it does need to be a little more specific. It could say
>> >that it's "randomly chosen" or "Twice as large as UINTMAX_MAX on
>> >Wednesdays, and 0 on all other days of the week".
>>
>> And this is a direct consequence of the fact that the standard doesn't
>> provide a list of choices.
>
>No, it follows from the fact that the implied list of choices doesn't
>exclude either of those possibilities.
Does it exclude any possibility at all, as far as the integer result
is concerned? If it doesn't, how can you call it a list of options?
>...
>> How do I know what the pointer value was, so that I can compare the
>> two values, which is needed in order to test the claim?
>
>That depends entirely upon what the documented result is.
Please pay attention to what I'm actually asking! The answer has
absolutely nothing to do with the documented result, because the
question concerns the *pointer* value, not the *integer* value resulting
from the conversion.
If I don't know what the pointer value was, I can't tell whether the
result of the conversion is conforming to the documentation (except for
the trivial cases that are ruled out by QoI considerations).
>...
>> But how do I know whether the value was in range, so the result is
>> meaningful, or the value was out of range and I have just invoked
>> undefined behaviour?
>
>That depends entirely upon the implementation's documentation. What I
>said about the result being testable, applies only when the
>implementation's documentation provides enough information to create a
>test case that should have a value that is in range. There's nothing in
>the standard that guarantees that there must be such a test case;
>however, if there is such a test case, the words of the standard do give
>the code defined behavior.
Nope, because you haven't provided a proper answer to my previous question
above: if *all* I have is one integer value, how do I know whether it
is the correct one or not, without being able to compare it with the
pointer value that was converted?
>...
>> Well, this was precisely the C89 definition. How many times did you get
>> your hard disk reformatted while making a function call or evaluating an
>> expression in a C89 program?
>
>QoI imposes restrictions that the standard itself does not, so
So, why worry about having the disk reformatted, due to the old
definition, that was far more realistic than the new one?
>implementations that did that were fairly rare.
Name a couple. "Fairly rare" imply they exist.
>But that's irrelevant -
>I'm talking about what's allowed; not about what actually happened.
And the context always restricts the allowed possibilities, even if the
actual definition doesn't. So, where is the problem?
>...
>> >Which is a infinitely more constrained set of permitted behaviors than
>> >the one described by "no requirements".
>>
>> The additional restrictions come from the context, not from the definition
>> of unspecified behaviour.
>
>Agreed. And the context is part of the standard, so it is indeed the
>standard itself that imposes those requirements. Whereas an explicit
>statement that unspecified behavior "imposes no requirements" would
>invalidate every requirement that you could otherwise derive from the
>context.
Not at all. If the standard says: "the result is unspecified" (which is a
form of unspecified-behaviour), the definition of unspecified-behaviour
does not give the implementation a licence to go beyond providing an
unspecified result.
>...
>> No such thing is needed for my blatant example: if you know what is the
>> behaviour of the right shift operator on signed values (and it is
>> reasonable to assume that every committee member knows it), the example
>> is obviously wrong. I spotted it when reading the C99 definitions of
>> terms, without making any special effort.
>
>Good for you. I don't know what the behavior of the right shift operator
>is on signed values.
The behaviour specified by the standard (which is, OBVIOUSLY, the one
I was talking about) is to produce an implementation-defined result.
You were supposed to know that, too, because I have already posted the
relevant paragraph...
>I know that it's different on different machines.
That's irrelevant, when the context is the standard.
>...
>> It isn't: the actual contents of 6.5.7p5 (it exists in my C89 draft) is
>> older than the 3.4.1p2 example (which doesn't exist in my C89 draft).
>
>As I've said before, I don't have a copy of that standard; I'll take
>your word for that.
>
>> So, your hypothesis that the example wasn't necessarily kept in sync
>> with the normative text is unfounded.
>
>Well, they're out of sync, in your opinion.
Nope, in my opinion, either the example is wrong or 6.5.7p5 fails to
reflect the intentions of the committee.
>They got that way somehow.
They were that way from the very beginning. The expression "out of sync"
implies that they were coherent at some, unspecified, point in time.
>> >But I never suggested that it was OK. How did you
>> >reach that conclusion?
>>
>> From your desperate attempts to justify it.
>
>I made no such attempts.
Of course you did. Just reread your contributions to this subthread.
>I never suggested that it was a good thing or
>acceptable for such a discrepancy to exist. I only attempted to explain
>ways in which it might have happened.
You did a lot more than that, like trying to minimalise it.
Gabriel Dos Reis
James Kuyper
>
> In <3DF6579B...@saicmodis.com> James Kuyper <kuy...@saicmodis.com> writes:
>
> >Dan Pop wrote:
> >> Then, I know where to look for it, it isn't hidden in the envelope.
> >
> >It isn't hidden? Then what color is it, what number does it have on it,
> >how much has it been made out for, who signed it, and what bank is it
> >drawn upon? If such a check weren't hidden, you would be able answer all
> >of those questions about it.
>
At which point the check ceases to be hidden. It's the envelope that's
hiding it. The corresponding case for the standard is that implied lists
of options cease to be hidden at the point when you engage your mind
sufficiently to figure out the implication.
...
> I cannot do the same thing by reading the standard, if someone asked me
> what is the list of options provided by the standard for the %p printf
> conversion specification. But if you can, please provide the *complete*
> list.
That's easy: the permitted options are the set of all possible mappings
from pointer values to "sequence[s] of printing characters".
...
> >apply. My point was that a missing list should lead to a DR; a list that
> >was implied by other text is not a missing list.
>
> OK, what is the list implied by *other text* and what exactly is the
> *other text* implying it? Use the %p example above.
7.19.6.1p8 "The value of the pointer is converted to a sequence of
printing characters, in an implementation-defined manner."
> >> "Provided by implication" means nothing in context (two different people
> >> can imply different things from a text like the C standard). The list
> >
> >You're thinking of 'infer'; that's something the reader does. "imply" is
> >something that the text does. The text either does or does not imply the
> >list, regardless of whether or not anybody ever notices the implication;
> >in fact, the text either implies the list, or does not imply it,
> >regardless of whether or not anyone ever even reads the text. If you
> >think it doesn't imply a list of options, file a DR.
>
> You're contradicting yourself: if the implication is an intrinsic property
> of the text, then what I think about it shouldn't matter.
It doesn't. Except to you, of course, and anyone who's discussing the
matter with you. What the text implies is a property of the text.
Whether or not you've figured out any particular implication of the text
is a time-dependent property of you, and a fairly important one if
you're going to actually be using C. Which doesn't mean that the
implication itself depends upon you.
> However, the standard says "provides", not "implies" and the two are not,
> AFAICT, synonyms.
Correct. Implication is only one of the many ways in which a piece of
text can provide information.
...
> Does it exclude any possibility at all, as far as the integer result
> is concerned? If it doesn't, how can you call it a list of options?
Because it's a list (the set of integers), and the implementation has
the option of choosing one particular member of that list. What other
properties must a list of options have?
> >> How do I know what the pointer value was, so that I can compare the
> >> two values, which is needed in order to test the claim?
> >
> >That depends entirely upon what the documented result is.
>
> Please pay attention to what I'm actually asking! The answer has
> absolutely nothing to do with the documented result, because the
> question concerns the *pointer* value, not the *integer* value resulting
> from the conversion.
Well, the answer to your question depends upon the integer value
resulting from the conversion, and therefore depends upon the documented
relationship between the pointer value and that integer value. If the
documentation makes it clear how to construct a pointer value that is
supposed to convert to an in-range integer value, then you can perform
the test.
> If I don't know what the pointer value was, ...
Sorry, I thought that was clear. To set up the test, you need to know
enough about the pointer value to guarantee that the documented result
of conversion will be in range. What that requirement implies in terms
of test code depends entirely upon what that documented conversion is.
For example, if the documented conversion always produces an in-range
value, then you don't need to know anything about the pointer. If the
documented conversion always converts currently valid pointers to
in-range values, then all you need to know is that the pointer is
currently valid. If the documented conversion only converts pointers to
automatically allocated objects to in-range values, and converts other
pointers to out-of-range values, then you need to know that the pointer
points at an automatically allocated object. You can't set up the test
case until you've read the documentation, and possibly not even then,
depending upon how the conversion is documented.
...
> Nope, because you haven't provided a proper answer to my previous question
> above: if *all* I have is one integer value, how do I know whether it
> is the correct one or not, without being able to compare it with the
> pointer value that was converted?
Well, that's a problem. But not the one I was talking about. I was
talking about the documentation's description of the conversion being
testable. That means that it's possible to set up a test case where you
actually know something about the pointer you're attempting to convert.
Specifically, you know enough about the pointer to make a prediction
about the converted value based upon the documentated properites of the
conversion. Depending upon the documentation, the only testable
prediction you might be able to make is that the integer will be
negative, or a multiple of 4, or some similar testable feature, rather
than the precise value of the integer.
...
> >QoI imposes restrictions that the standard itself does not, so
>
> So, why worry about having the disk reformatted, due to the old
> definition, that was far more realistic than the new one?
I'm not worried about the disk being reformatted; I'm worried about a
standard that could be used to label a particular program as "correct",
and a particular implementation as "conforming" , even if that
implementation were to translate that code into a program that could
format the hard disk, when that wasn't what the code was supposed to do.
It doesn't actually matter to me whether such an implementation actually
exists, or whether anybody actually writes such code. A standard that
could be used that way is a seriously defective standard, with a
radically inappropriate concept of the relationship between "correct"
code, "conforming" implementations, and the behavior of the resulting
program.
...
> >But that's irrelevant -
> >I'm talking about what's allowed; not about what actually happened.
>
> And the context always restricts the allowed possibilities, even if the
> actual definition doesn't. So, where is the problem?
With the definition, of course.
...
> Not at all. If the standard says: "the result is unspecified" (which is a
> form of unspecified-behaviour), the definition of unspecified-behaviour
> does not give the implementation a licence to go beyond providing an
> unspecified result.
True, under the current standard. But not with your proposed change to
the definition of unspecified behavior, which is precisely why I'm
opposed to that proposal. If that's not what your proposal was intended
to allow, then it needs rewording.
...
> >Good for you. I don't know what the behavior of the right shift operator
> >is on signed values.
>
> The behaviour specified by the standard (which is, OBVIOUSLY, the one
> I was talking about) is to produce an implementation-defined result.
That's not a single behavior; it's a long (implied) list of permissible
behaviors.
...
> >Well, they're out of sync, in your opinion.
>
> Nope, in my opinion, either the example is wrong or 6.5.7p5 fails to
> reflect the intentions of the committee.
Sorry, I thought you were arguing that the example was absolutely
inconsistent with 6.5.7p5; and I even thought there was some point to
your claim. Are you implying that there's a way to interpret 6.5.7p5
which fails to reflect the intention of the committee, but which would
allow it to be consistent with the example?
...
> >> From your desperate attempts to justify it.
> >
> >I made no such attempts.
>
> Of course you did. Just reread your contributions to this subthread.
I have. Couldn't find any attempts at justification, only attempts at
explaination.
...
> >I never suggested that it was a good thing or
> >acceptable for such a discrepancy to exist. I only attempted to explain
> >ways in which it might have happened.
>
> You did a lot more than that, like trying to minimalise it.
Well, yes, I did that. But saying that something is not very seriously
wrong is very different from saying that it's right. I don't approve of
shoplifting, but I also don't believe that stealing a piece of candy is
as serious as genocide. That doesn't mean I approve of stealing a piece
of candy.
James Kuyper
> | directly relevant to how hard one is willing to work to achieve that
> | change.
>
> Is it your axiom or a universal law?
Neither; it's too vague a statement to qualify as as law, and I
certainly don't consider it an axiom. It's a derived conclusion from
more fundamental beliefs about human nature, which are also not treated
as axioms. Those more fundamental beliefs, and this particular
conclusion, are all supported by my observations of real human beings;
but I'm not claiming to be an expert on human psychology.
That conclusion does, however, strike me as so trivially, obviously
true, that I can't understand why it's even being debated. I have to
conclude that you're misunderstanding it somehow; possibly because I'm
mis-stating it. Possibly you're reading it as as being less vague than I
intended it to be? The vagueness is important, since any less vague
formulation of the principle would be false. I've also seen hints that
you may be interpreting "belief in the need for a particular change" in
some way that seems inconsistent with what I actually mean by that
phrase, but I haven't actually figured out what that way is; it sounds
to me like you're interpreting that as a description of some kind of
fanaticism.
This is really wandering way off topic. If you don't want to bother
writing up a proposed change, don't. If you want to complain about the
fact that no one else is writing up the proposal that you would have
written up if you'd felt like bothering; well, the complaint would be
unjustified, but you're entitled to make it. Just don't be surprised if
the standard never gets changed to accomodate your unwritten proposal.
Dan Pop
>Dan Pop wrote:
>>
>> In <3DF6579B...@saicmodis.com> James Kuyper <kuy...@saicmodis.com> writes:
>>
>> >Dan Pop wrote:
>...
>> >> Then, I know where to look for it, it isn't hidden in the envelope.
>> >
>> >It isn't hidden? Then what color is it, what number does it have on it,
>> >how much has it been made out for, who signed it, and what bank is it
>> >drawn upon? If such a check weren't hidden, you would be able answer all
>> >of those questions about it.
>>
>> I open the envelope, ...
>
>At which point the check ceases to be hidden. It's the envelope that's
>hiding it. The corresponding case for the standard is that implied lists
>of options cease to be hidden at the point when you engage your mind
>sufficiently to figure out the implication.
>
>...
>> I cannot do the same thing by reading the standard, if someone asked me
>> what is the list of options provided by the standard for the %p printf
>> conversion specification. But if you can, please provide the *complete*
>> list.
>
>That's easy: the permitted options are the set of all possible mappings
>from pointer values to "sequence[s] of printing characters".
This sentence is devoid of any (useful) meaning. This set in infinite.
>...
>> >apply. My point was that a missing list should lead to a DR; a list that
>> >was implied by other text is not a missing list.
>>
>> OK, what is the list implied by *other text* and what exactly is the
>> *other text* implying it? Use the %p example above.
>
>7.19.6.1p8 "The value of the pointer is converted to a sequence of
>printing characters, in an implementation-defined manner."
Where is the *other text*? This is the text saying that the sequence of
characters is implementation-defined.
>> However, the standard says "provides", not "implies" and the two are not,
>> AFAICT, synonyms.
>
>Correct. Implication is only one of the many ways in which a piece of
>text can provide information.
Well, in the above example of %p, no useful information was provided by
implication. Am I unreasonable if I expect the standard to provide
*useful* information?
>...
>> Does it exclude any possibility at all, as far as the integer result
>> is concerned? If it doesn't, how can you call it a list of options?
>
>Because it's a list (the set of integers), and the implementation has
>the option of choosing one particular member of that list. What other
>properties must a list of options have?
Exclude something. If every possible combination is included, the list
is useless.
>> >> How do I know what the pointer value was, so that I can compare the
>> >> two values, which is needed in order to test the claim?
>> >
>> >That depends entirely upon what the documented result is.
>>
>> Please pay attention to what I'm actually asking! The answer has
>> absolutely nothing to do with the documented result, because the
>> question concerns the *pointer* value, not the *integer* value resulting
>> from the conversion.
>
>Well, the answer to your question depends upon the integer value
>resulting from the conversion, and therefore depends upon the documented
>relationship between the pointer value and that integer value. If the
>documentation makes it clear how to construct a pointer value that is
>supposed to convert to an in-range integer value, then you can perform
>the test.
The pointer value is obtained from the address-of operator, the
implementation guarantees that any pointer value can be converted to an
unsigned int and the value of the conversion is 12345. How can I
check now whether this is the right result, according to the documentation
since I have no idea about the value produced by the address-of operator?
>...
>> Nope, because you haven't provided a proper answer to my previous question
>> above: if *all* I have is one integer value, how do I know whether it
>> is the correct one or not, without being able to compare it with the
>> pointer value that was converted?
>
>Well, that's a problem. But not the one I was talking about. I was
>talking about the documentation's description of the conversion being
>testable. That means that it's possible to set up a test case where you
>actually know something about the pointer you're attempting to convert.
>Specifically, you know enough about the pointer to make a prediction
>about the converted value based upon the documentated properites of the
>conversion.
Does the standard require the implementation to provide such information?
Chapter and verse, please. All I know about the pointer value is that it
is a valid value, because it comes from the address-of operator (and the
corresponding object is still "alive").
>...
>> >But that's irrelevant -
>> >I'm talking about what's allowed; not about what actually happened.
>>
>> And the context always restricts the allowed possibilities, even if the
>> actual definition doesn't. So, where is the problem?
>
>With the definition, of course.
If it's never used in the manner that's worrying you, where is the
problem?
>...
>> Not at all. If the standard says: "the result is unspecified" (which is a
>> form of unspecified-behaviour), the definition of unspecified-behaviour
>> does not give the implementation a licence to go beyond providing an
>> unspecified result.
>
>True, under the current standard.
True under C89, as well.
>But not with your proposed change to
>the definition of unspecified behavior, which is precisely why I'm
>opposed to that proposal. If that's not what your proposal was intended
>to allow, then it needs rewording.
Nope: "the result is unspecified" gives a C89 implementation no licence
to reformat your hard disk. Only to provide a result.
>...
>> >Good for you. I don't know what the behavior of the right shift operator
>> >is on signed values.
>>
>> The behaviour specified by the standard (which is, OBVIOUSLY, the one
>> I was talking about) is to produce an implementation-defined result.
>
>That's not a single behavior; it's a long (implied) list of permissible
>behaviors.
Labeled as "implementation-defined behaviour". If the standard uses the
singular, so can I.
>...
>> >Well, they're out of sync, in your opinion.
>>
>> Nope, in my opinion, either the example is wrong or 6.5.7p5 fails to
>> reflect the intentions of the committee.
>
>Sorry, I thought you were arguing that the example was absolutely
>inconsistent with 6.5.7p5;
It is, given the actual wording of 6.5.7p5.
>and I even thought there was some point to
>your claim. Are you implying that there's a way to interpret 6.5.7p5
>which fails to reflect the intention of the committee, but which would
>allow it to be consistent with the example?
I'm claiming the opposite: that the intention of the committee might have
been properly reflected by the example, but not by the wording of 6.5.7p5.
Of course, this is only a possibility, made (somewhat) plausible by the
example.
I'm not claiming that it is possible to interpret 6.5.7p5 so that it
becomes consistent with the example.
>...
>> >> From your desperate attempts to justify it.
>> >
>> >I made no such attempts.
>>
>> Of course you did. Just reread your contributions to this subthread.
>
>I have. Couldn't find any attempts at justification, only attempts at
>explaination.
It's the same thing, considering some of your actual explanations.
>...
>> >I never suggested that it was a good thing or
>> >acceptable for such a discrepancy to exist. I only attempted to explain
>> >ways in which it might have happened.
>>
>> You did a lot more than that, like trying to minimalise it.
>
>Well, yes, I did that. But saying that something is not very seriously
>wrong is very different from saying that it's right. I don't approve of
>shoplifting, but I also don't believe that stealing a piece of candy is
>as serious as genocide. That doesn't mean I approve of stealing a piece
>of candy.
But where have you tried to find "reasonable" explanations for
shoplifting, to make your analogy complete? :-)
Gabriel Dos Reis
[...]
| That conclusion does, however, strike me as so trivially, obviously
| true, that I can't understand why it's even being debated.
I guess that may be the root of the problem :-)
[...]
| This is really wandering way off topic. If you don't want to bother
| writing up a proposed change, don't. If you want to complain about the
| fact that no one else is writing up the proposal that you would have
| written up if you'd felt like bothering; well, the complaint would be
| unjustified, but you're entitled to make it.
And the *fact* is that I'm not complaining about
the fact that no one else is writing up the proposal that you would have
written up if you'd felt like bothering
Now back to the facts:
Fergus Henderson asked:
What replacement would you propose for accessing device registers?
I replied:
A *clearly* and *well* defined and specified feature ?
That is all. Plesse let's put aside "belief in need" and look at the
rational and technical issues.
-- Gaby
NOSPA...@sebastian9.com
According to Dan Pop <Dan...@cern.ch>:
> In <3DF7657E...@saicmodis.com> James Kuyper <kuy...@saicmodis.com> writes:
>
> >Dan Pop wrote:
> >> I cannot do the same thing by reading the standard, if someone asked me
> >> what is the list of options provided by the standard for the %p printf
> >> conversion specification. But if you can, please provide the *complete*
> >> list.
> >
> >That's easy: the permitted options are the set of all possible mappings
> >from pointer values to "sequence[s] of printing characters".
>
> This sentence is devoid of any (useful) meaning. This set in infinite.
Hardly. The set of (mathematical) integers is also infinite,
but that does not mean that "x is an integer" is devoid of
useful meaning. In the case of the %p printf spec, it means
that I may, for example, confidently send the result to an output
device whose behavior is only well defined on printing characters.
In an ASCII-based system, I know that it will not, for example, produce
the escape sequence that throws my printer into "Sanskrit mode," because
ESC is not a printing character in ASCII. Likewise, I know
that I may, by counting characters, portably align the result with
other output, since each printing character occupies one
printing position on a display device (C89 definition).
--
Dave Wallace (Remove NOSPAM from my address to email me)
It is quite humbling to realize that the storage occupied by the longest
line from a typical Usenet posting is sufficient to provide a state space
so vast that all the computation power in the world can not conquer it.
t...@cs.ucr.edu
+ t...@cs.ucr.edu wrote in message news:<assb3k$960$1...@glue.ucr.edu>...
+> Thanks. IIUC, POSIX defers to the ISO C Standard on matters of the
+> core language but differs a bit on certain libarary functions, and
+> that those differences are usually (but not always) extensions.
+
+ All the standard C functions that I've checked have the following
+ disclaimer in their POSIX description:
+
+ The functionality described on this reference page is aligned
+ with the ISO C standard. Any conflict between the requirements
+ described here and the ISO C standard is unintentional. This
+ volume of IEEE Std 1003.1-2001 defers to the ISO C standard.
+
+ Do you know of any exceptions?
My impressions are based on very old information, and I hope that your
checking represents what is true overall. This is very good news.
Tom Payne
t...@cs.ucr.edu
[...]
+ My objections were about non-clearly and non-well-defined specified
+ feature. Beginning with:
+
+ [#6] An object that has volatile-qualified type may be
+ *modified in ways unknown to the implementation or have other
+ unknown side effects.* Therefore any expression referring to
+ such an object shall be evaluated strictly according to the
+ rules of the abstract machine, as described in 5.1.2.3.
+ Furthermore, at every sequence point the value last stored
+ in the object shall agree with that prescribed by the
+ abstract machine, except as modified by the unknown factors
+ mentioned previously.114) What constitutes an access to an
+ object that has volatile-qualified type is implementation-
+ defined.
Fair enough. But note that clarity is in the eye of the beholder.
Let's start with the "modified in ways unknown to the implemention
..." This is an obvious attempt to improve the pedagogy of the of the
wording by anthropomorphising the implementation. At the current
stage of technology, implementations don't "know" things. All this
colorful sentence really does is suspend the normal guarantee objects
remember their values. That guarantee is normally stated by saying
that read access to the object yields the object's last-stored value.
We can say that an object doesn't always remember by positing other
agents that mysteriously sneak in a new value, e.g., a user with a
debugger.
Let's continue: "Therefore any expression referring to such an object
shall be evaluated strictly according to the rules of the abstract
machine, as described in 5.1.2.3." So, we turn to 5.1.2.3 and find:
In the abstract machine, all expressions are evaluated as specified
by the semantics. An actual implemenation need not evaluate part of
an expression if it can deduce that its value is not used and that
no needed side effects are produced (including any caused by calling
a function or accessing a volatile object)."
Hmmmm. When I combine those two quotes I get something like:
Therefore any expression referring to an object of volatile-qualified
type shall be evaluated unless it can be deduced that its value is not
used and that accessing this volatile object has no side effects.
Next sentence:
Furthermore, at every sequence point the value last stored
in the object shall agree with that prescribed by the
abstract machine, except as modified by the unknown factors
mentioned previously.114)
So, again, objects of volatile-qualified type are not guaranteed to
remember their values. Those "unknown factors" can sneak in and play
games with their memory, e.g., the user of the debugger might change
the value of the variable, but the implementation is still required to
remember the value last stored by an "unknown factor".
Finally we have the following:
What constitutes an access to an object that has volatile-qualified
type is implementation-defined.
I would normally read that use of "constitutes" as having the same
meaning as in:
This letter does not constitute an offer of employment.
Doug Gwyn insists that this interpretation is not what was intended
and that the committee meant that the constituent actions that occur
during an access to a volatile object are implementation specified.
Linguistic quibbles aside, I concede that Doug's interpretation makes
more sense than mine and that he has the advantage of being there.
So, I now prefer his interpretation.
I have only two remaining issues with the Standard's notion of
"volatile":
* The Standard doesn't say what value(s) of a volatile object may
be used in the evaluation of an expression. Given that values
may change spontaneously due to "unknown factors", one would
hope that the value would be a recent one. But there are no
criteria for how recent is recent enough. I propose that the
value used must be more recent than the most recent sequence
point.
* The specification that non-volatile automatic variables local
to a function containing an invocation of setjmp and modified
since that invocation will have indeterminate value following
a longjmp back to that invocation seems ill advised.
Specifically, to make such variables post-longjmp accessible
requires a solution that requires programmer intervention
(volatile qualification of the variable's type) and enforced
inefficiency. There are other solutions that are automatic
and usually more efficient.
Tom Payne
NOSPA...@sebastian9.com
According to <t...@cs.ucr.edu>:
> Let's continue: "Therefore any expression referring to such an object
> shall be evaluated strictly according to the rules of the abstract
> machine, as described in 5.1.2.3." So, we turn to 5.1.2.3 and find:
>
> In the abstract machine, all expressions are evaluated as specified
> by the semantics. An actual implemenation need not evaluate part of
> an expression if it can deduce that its value is not used and that
> no needed side effects are produced (including any caused by calling
> a function or accessing a volatile object)."
>
> Hmmmm. When I combine those two quotes I get something like:
>
> Therefore any expression referring to an object of volatile-qualified
> type shall be evaluated unless it can be deduced that its value is not
> used and that accessing this volatile object has no side effects.
I think this is wrong - the access to the volatile object is itself
a side effect, and it is always needed. I would read 5.1.2.3 as:
In the abstract machine, all expressions are evaluated as specified
by the semantics. An actual implementation need not evaluate part of
an expression if it can deduce that its value is not used and that
no needed side effects are produced (such as (1): any [needed side
effects] caused by calling a function or (2): accessing a volatile
object)."
So I would boil your combination of the quotes down to:
Therefore any expression referring to an object of volatile-qualified
type shall be evaluated at least to the point of accessing the
volatile object in accordance with the rules of the abstract machine.
[snip]
> I have only two remaining issues with the Standard's notion of
> "volatile":
>
> * The Standard doesn't say what value(s) of a volatile object may
> be used in the evaluation of an expression. Given that values
> may change spontaneously due to "unknown factors", one would
> hope that the value would be a recent one. But there are no
> criteria for how recent is recent enough. I propose that the
> value used must be more recent than the most recent sequence
> point.
I think that it is implicit in the sequence point rules and
the fact that access to a volatile object constitutes a needed side
effect that an expression that evaluates a volatile object
must cause exactly one read access to that object for each
such evaluation between the previous and next sequence points,
and further, that such access must occur on or after the temporal
occurrence of the previous sequence point and on or before the
temporal occurrence of the next sequence point.
Dan Pop
>According to Dan Pop <Dan...@cern.ch>:
>> In <3DF7657E...@saicmodis.com> James Kuyper <kuy...@saicmodis.com> writes:
>>
>> >Dan Pop wrote:
>> >> I cannot do the same thing by reading the standard, if someone asked me
>> >> what is the list of options provided by the standard for the %p printf
>> >> conversion specification. But if you can, please provide the *complete*
>> >> list.
>> >
>> >That's easy: the permitted options are the set of all possible mappings
>> >from pointer values to "sequence[s] of printing characters".
>>
>> This sentence is devoid of any (useful) meaning. This set in infinite.
>
>Hardly. The set of (mathematical) integers is also infinite,
>but that does not mean that "x is an integer" is devoid of
>useful meaning. In the case of the %p printf spec, it means
>that I may, for example, confidently send the result to an output
>device whose behavior is only well defined on printing characters.
But the output of %p may well exceed the processing capabilities of your
device. The output of %p may well be in the petabyte range (or above).
Douglas A. Gwyn
> * The Standard doesn't say what value(s) of a volatile object may
> be used in the evaluation of an expression. Given that values
> may change spontaneously due to "unknown factors", one would
> hope that the value would be a recent one. But there are no
> criteria for how recent is recent enough. I propose that the
> value used must be more recent than the most recent sequence
> point.
I think that's already specified. The side-effects of program-
initiated access, including storage, are required to be brought
up to date (for a volatile-qualified object access) at each s.p.
Conformance to the abstract machine model then requires that a
further use of that object's value must perform an actual read.
(As you note, what is read might not match what was stored, due
to the action of outside agents.) Note that this does not mean
that there is a read-back in a construct like
volatile type_t *vp;
x = (*vp = 42);
since the value of the expression is not required to be obtained
by reading from the stored object. To accomplish the read-back
one has to code like this:
*vp = 42; // sequence point afterward!
x = *vp;
> * The specification that non-volatile automatic variables local
> to a function containing an invocation of setjmp and modified
> since that invocation will have indeterminate value following
> a longjmp back to that invocation seems ill advised.
> Specifically, to make such variables post-longjmp accessible
> requires a solution that requires programmer intervention
> (volatile qualification of the variable's type) and enforced
> inefficiency. There are other solutions that are automatic
> and usually more efficient.
This was the result of considerable investigation and discussion,
and should not be changed without a similar amount of effort to
attain consensus. As it stands it reflects the reality of the
situation for actual implementations.
The supposed "inefficiency" can be minimized by careful choice
of program structure.
Personally I'd like a well-engineered exception mechanism built
into the language.
James Kuyper
...
> But the output of %p may well exceed the processing capabilities of your
> device. The output of %p may well be in the petabyte range (or above).
In principle, the output of "%c" may exceed the processing capabilities
of your device. There are some things the standard leaves unspecified
that aren't really worth worrying about in certain contexts; I think
this is one of those things, in one of those contexts.
As a developer I wouldn't mind having the standard mandate that a
certain minimum amount of standard output must work, no matter what.
However, I suspect that this would present serious problems for
implementors on platforms where you are, for instance, allowed to
re-direct standard output to a device that might not actually be capable
of accepting that many characters.
eri...@lksejb.lks.agilent.com
> Gabriel Dos Reis <g...@integrable-solutions.net> wrote:
> + [#6] An object that has volatile-qualified type may be
> + *modified in ways unknown to the implementation or have other
> + unknown side effects.*
> Let's continue: "Therefore any expression referring to such an object
> shall be evaluated strictly according to the rules of the abstract
> machine, as described in 5.1.2.3." So, we turn to 5.1.2.3 and find:
>
> In the abstract machine, all expressions are evaluated as specified
> by the semantics. An actual implemenation need not evaluate part of
> an expression if it can deduce that its value is not used and that
> no needed side effects are produced (including any caused by calling
> a function or accessing a volatile object)."
>
> Hmmmm. When I combine those two quotes I get something like:
>
> Therefore any expression referring to an object of volatile-qualified
> type shall be evaluated unless it can be deduced that its value is not
> used and that accessing this volatile object has no side effects.
I might be willing accept that. But note that, by definition, it
*can't* be deduced that a volatile value is not used and it *can't* be
deduced that accessing the volatile object has no side effects.
--
Eric Backus
R&D Design Engineer
Agilent Technologies, Inc.
425-335-2495 Tel
t...@cs.ucr.edu
+ t...@cs.ucr.edu wrote:
+> * The Standard doesn't say what value(s) of a volatile object may
+> be used in the evaluation of an expression. Given that values
+> may change spontaneously due to "unknown factors", one would
+> hope that the value would be a recent one. But there are no
+> criteria for how recent is recent enough. I propose that the
+> value used must be more recent than the most recent sequence
+> point.
+
+ I think that's already specified.
It's clear that is somehow intended, and I hope that you are correct.
What I'm looking for is where it says when I may/must read a
(volatile) variable when evaluating the corresponding primary
expression.
I got to the part where it says:
Therefore any expression referring to such an object shall be
evaluated strictly according to the rules of the abstract machine.
But, I look up the rules of the abstract syntax machine, I find:
In the abstract syntax machine, all expressions are evaluated
as specified by the semantics.
So, I look up the semantics primary expressions. There is none.
But I know that the variable should get its value from behavior
attached to lvalue-to-rvalue conversion, so I look for the semantics
of lvalue-to-rvalue conversion. Again there are none. (Rather
lvalue-to-rvalue conversion is presented as a purely syntactic
activity.)
Consider the code:
volatile int x = 0;
... x ...; // some expression involving the rvalue of x
Where is the semantics of the subexpresion "x" defined?
+> * The specification that non-volatile automatic variables local
+> to a function containing an invocation of setjmp and modified
+> since that invocation will have indeterminate value following
+> a longjmp back to that invocation seems ill advised.
+> Specifically, to make such variables post-longjmp accessible
+> requires a solution that requires programmer intervention
+> (volatile qualification of the variable's type) and enforced
+> inefficiency. There are other solutions that are automatic
+> and usually more efficient.
+
+ This was the result of considerable investigation and discussion,
+ and should not be changed without a similar amount of effort to
+ attain consensus.
After considerable investigation and discussion, everyone gets tired
and wants to leave. So we end up with the let-them-use-volatile
solution which:
- requires no implemetation
- puts the burden on the user
- appears to incur significantly more overhead that the most
obvious implementation-based solution.
If the committee had simply left out the exception for the problematic
variables and said nothing about them, implementers could have
achieved conformance simply by treating them as volatile. Then
ambitious implementers could have improved performance via alternative
implementations. Under the current solution, however, to achieve
portability the inefficiency of volatility (for those problematic
objects) must be locked into the source code.
Tom Payne
t...@cs.ucr.edu
+
+ According to <t...@cs.ucr.edu>:
+> Let's continue: "Therefore any expression referring to such an object
+> shall be evaluated strictly according to the rules of the abstract
+> machine, as described in 5.1.2.3." So, we turn to 5.1.2.3 and find:
+>
+> In the abstract machine, all expressions are evaluated as specified
+> by the semantics. An actual implemenation need not evaluate part of
+> an expression if it can deduce that its value is not used and that
+> no needed side effects are produced (including any caused by calling
+> a function or accessing a volatile object)."
+>
+> Hmmmm. When I combine those two quotes I get something like:
+>
+> Therefore any expression referring to an object of volatile-qualified
+> type shall be evaluated unless it can be deduced that its value is not
+> used and that accessing this volatile object has no side effects.
+
+ I think this is wrong - the access to the volatile object is itself
+ a side effect, and it is always needed. I would read 5.1.2.3 as:
+
+ In the abstract machine, all expressions are evaluated as specified
+ by the semantics. An actual implementation need not evaluate part of
+ an expression if it can deduce that its value is not used and that
+ no needed side effects are produced (such as (1): any [needed side
+ effects] caused by calling a function or (2): accessing a volatile
+ object)."
+
+ So I would boil your combination of the quotes down to:
+ Therefore any expression referring to an object of volatile-qualified
+ type shall be evaluated at least to the point of accessing the
+ volatile object in accordance with the rules of the abstract machine.
+
+ [snip]
But does the Standard actually say that reading a volatile object is
(or has) a side effect?
+> I have only two remaining issues with the Standard's notion of
+> "volatile":
+>
+> * The Standard doesn't say what value(s) of a volatile object may
+> be used in the evaluation of an expression. Given that values
+> may change spontaneously due to "unknown factors", one would
+> hope that the value would be a recent one. But there are no
+> criteria for how recent is recent enough. I propose that the
+> value used must be more recent than the most recent sequence
+> point.
+
+ I think that it is implicit in the sequence point rules and
+ the fact that access to a volatile object constitutes a needed side
+ effect that an expression that evaluates a volatile object
+ must cause exactly one read access to that object for each
+ such evaluation between the previous and next sequence points,
+ and further, that such access must occur on or after the temporal
+ occurrence of the previous sequence point and on or before the
+ temporal occurrence of the next sequence point.
I have the same question here: does the Standard actually say that
reading a volatile object is (or has) a side effect?
I agree with both of your analyses and that, if the Standard doesn't
directly or indirectly say that reading a volatile generates a side
effect, it certainly ought to.
Tom Payne
t...@cs.ucr.edu
+ Douglas A. Gwyn <DAG...@null.net> wrote:
+ + t...@cs.ucr.edu wrote:
+ +> * The Standard doesn't say what value(s) of a volatile object may
+ +> be used in the evaluation of an expression. Given that values
+ +> may change spontaneously due to "unknown factors", one would
+ +> hope that the value would be a recent one. But there are no
+ +> criteria for how recent is recent enough. I propose that the
+ +> value used must be more recent than the most recent sequence
+ +> point.
+ +
+ It's clear that is somehow intended, and I hope that you are correct.
+ What I'm looking for is where it says when I may/must read a
+ (volatile) variable when evaluating the corresponding primary
+ expression.
+
+ I got to the part where it says:
+
+ Therefore any expression referring to such an object shall be
+ evaluated strictly according to the rules of the abstract machine.
+
+ But, I look up the rules of the abstract syntax machine, I find:
+
+ In the abstract syntax machine, all expressions are evaluated
+ as specified by the semantics.
+
+ So, I look up the semantics primary expressions. There is none.
+
+ But I know that the variable should get its value from behavior
+ attached to lvalue-to-rvalue conversion, so I look for the semantics
+ of lvalue-to-rvalue conversion. Again there are none. (Rather
+ lvalue-to-rvalue conversion is presented as a purely syntactic
+ activity.)
+
+ Consider the code:
+
+ volatile int x = 0;
+ ... x ...; // some expression involving the rvalue of x
+
+ Where is the semantics of the subexpresion "x" defined?
The following is relevant:
At sequence points volatile objects are stable in the sense that
previous evaluations are completed and SUBSEQUENT EVALUATIONS HAVE
NOT YET OCCURRED. [C89, 5.1.2.3]
This says that any value fetched before the last stored sequence point
must be considered stale. Moreover, if reading a volatile has a side
effect, presumably that side effect must follow the sequence point.
But the last-stored value can keep changing after that sequence point.
Does the Standard actually say (directly or indirectly) that any value
read after the sequence point is fresh enough, even though the
last-store (and presumably the current) value of the object can
immediately change?
This is not a big issue. But, if it isn't there already, something
explicit should probably be included in a future draft.
Tom Payne
Dave Hansen
[...]
>
>But does the Standard actually say that reading a volatile object is
>(or has) a side effect?
No. It says in 5.1.2.3p2 that *accessing* a volatile object is a side
effect. Then 6.7.3.6p6 says what constitutes an access to a volatile
object is implementation-defined. (Both references from n869)
Most *reasonable* people would infer from the above that reading a
volatile object is indeed a side-effect. But this is comp.std.c,
after all...
Regards,
-=Dave
--
Change is inevitable, progress is not.
t...@cs.ucr.edu
+ On Sat, 14 Dec 2002 15:36:19 +0000 (UTC), t...@cs.ucr.edu wrote:
+
+ [...]
+>
+>But does the Standard actually say that reading a volatile object is
+>(or has) a side effect?
+
+ No. It says in 5.1.2.3p2 that *accessing* a volatile object is a side
+ effect.
Oops. Right. Thanks.
+ Then 6.7.3.6p6 says what constitutes an access to a volatile
+ object is implementation-defined. (Both references from n869)
+ Most *reasonable* people would infer from the above that reading a
+ volatile object is indeed a side-effect. But this is comp.std.c,
+ after all...
Doug Gwyn has convincingly made the case that implementations cannot
define away the fact that reads and writes are "accesses", and that
"constitutes" here means that implemenations can add constituents,
e.g., reading from a volatile variable that is an input register might
clear that register.
Tom Payne