Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Pointer Arithmetic & UB

Reply
Thread Tools

Re: Pointer Arithmetic & UB

 
 
Tim Rentsch
Guest
Posts: n/a
 
      01-14-2013
glen herrmannsfeldt <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> wrote:
>
> (snip on my question about interlocked updates to volatile variables,
> and a reply to the question.)
>
>> 4. This question is relatively easy to answer if you have a copy
>> of the Standard avaiable. Do you have copies of the various
>> near-Standard drafts? If not they are easy to get, for free,
>> at, eg,

>
>> http://www.open-std.org/jtc1/sc22/wg...docs/n1256.pdf
>> http://www.open-std.org/jtc1/sc22/wg...docs/n1570.pdf

>
>> and for these sorts of questions serve just as well as having
>> an official copy of the Standard.

>
> Yes, I have one of those. Even though I write more C than
> Fortran, I know where to find things in the draft copies of the
> Fortran standard faster and easier than the C standard.


1. index
2. text search

Either would have gotten you to the paragraph describing the
semantics for volatile access in a few minutes.

> One reason is that for the things that I actually do in C, the
> features of C89 are usually sufficient.


Yes, and think how much better your question would have been if
you had said, "I know that in C99 that how an access to a
volatile object is done is implementation defined, but I don't
have access to a C89 standard. Is it the same under C89 rules?"
Obviously there are different variations on this, but all of
them would have been helped if you had spent a few minutes
looking in a C99 or C11 document first, before asking.
 
Reply With Quote
 
 
 
 
Shao Miller
Guest
Posts: n/a
 
      01-15-2013
On 1/14/2013 08:20, Ben Bacarisse wrote:
> Shao Miller <(E-Mail Removed)> writes:
>
>> On 1/13/2013 22:19, Ben Bacarisse wrote:
>>> Shao Miller <(E-Mail Removed)> writes:
>>>
>>>> On 1/13/2013 20:03, Ben Bacarisse wrote:
>>>>> Shao Miller <(E-Mail Removed)> writes:
>>>>>
>>>>>> On 1/13/2013 19:01, Ben Bacarisse wrote:
>>>>>>> Shao Miller <(E-Mail Removed)> writes:
>>>>>>>
>>>>>>>> On 1/12/2013 19:34, Ben Bacarisse wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Clearly the plain English preposition "on" can be used for a
>>>>>>>>> modification: it's a side effect on an object; but since, in the case of
>>>>>>>>> a volatile object, the access itself is a side effect, I don't see why
>>>>>>>>> that is not equally plainly a side effect "on" the object.
>>>>>>>>>
>>>>>>>>
>>>>>>>> "3.1
>>>>>>>> 1 access
>>>>>>>> <execution-time action> to read or modify the value of an object
>>>>>>>> 2 NOTE 1 Where only one of these two actions is meant, ‘‘read’’ or
>>>>>>>> ‘‘modify’’ is used."
>>>>>>>
>>>>>>> ??
>>>>>>>
>>>>>>
>>>>>> By the note, if "accessing a volatile object" was not supposed to be a
>>>>>> side effect, it ought to have read "modifying a volatile object".
>>>>>> It's not an argument about what's true for 'x = i + i', but about the
>>>>>> English.
>>>>>
>>>>> Still puzzled. Do you think someone is asserting that accessing
>>>>> a volatile object (simply for reading) is not a side-effect?
>>>>>
>>>>
>>>> No; sorry. The context above is of you talking about "on". Plugging
>>>> them together:
>>>>
>>>> By the note, if "accessing a volatile object" was not supposed to be a
>>>> side effect on that object, it ought to have read "modifying a
>>>> volatile object". It's not an argument about what's true for 'x = i +
>>>> i', but about the English.
>>>
>>> So you agree with me that accessing a volatile object is a side effect
>>> on that object? Even if I have now got your meaning, I don't see how
>>> your quote from the standard leads you to that conclusion.
>>>

>>
>> void f(void) {
>> volatile int i = 21;
>> int x;
>> /* UB? */
>> x = i + i;
>> }
>>
>> For the third time, it's not an argument about what's true for 'x = i
>> + i;', but about the English.

>
> Yes, that was the third time, but repeating yourself doesn't help. If I
> am being too stupid to understand, the only person who can help is you.
> There's little I can do since you can (or should) assume that I've tried
> to understand your and read an re-tread what you've written. You need
> to say more, or to say new things, or to say old things in new ways.
>


I apologize, Ben. My repetition was in no way intended to produce your
response, above. Please consider it as resulting from a lack of
understanding about whence your response originated; I didn't know how
you had interpreted the post before that one.

>> I'd say that you have made a
>> convincing case for a "natural" interpretation of the Standard text,
>> in this thread. I'd say that 3.1p2's note suggests that the Standard
>> is careful about "access" versus "read" and "modification". I'd say
>> that Mr. T. Rentsch's recent arguments which actually referenced the
>> Standard made a convincing case about the intention, in this thread.
>> It so happens that you weren't arguing about the intention, anyway.

>
> Now this is more and I now understand your position, but I still don't
> understand the purpose of your post. It is, to me, as if you had said
> "custard is yellow". Sure, but what on earth is the connection? Was
> anyone confused about the colour of custard?
>
> Did it seem as if there was some confusion over that fact that "access"
> means both reading and modification and hence that all and any access to
> a volatile object is a side effect?
>


Whether it seems that way or not, I was not attempting to draw attention
to such.

"Accessing a volatile object, modifying an object, modifying a file,
or calling a function that does any of those operations are all side
effects,12) which are changes in the state of the execution environment.
Evaluation of an expression in general includes both value computations
and initiation of side effects. Value computation for an lvalue
expression includes determining the identity of the designated object."

Here "Accessing" is used, instead of "Reading" or "Modifying".

Suppose we have a non-volatile object O1.

Suppose we modify object O1, then ask, "on which object was the act of
modifying performed?" The answer is O1.

Suppose we ask, "on which object was there a side effect?" The answer
is O1.

Then if we give a fair treatment...

Suppose we have a volatile object O2.

Suppose we modify object O2, then ask, "on which object was the act of
modifying performed?" The answer is O2.

Suppose we read object O2, then ask, "on which object was the act of
reading performed?" The answer is O2.

Suppose, for either of these, we ask, "on which object was there an
access performed?" The answer is O2.

Suppose, for either of these, we ask, "on which object was there a side
effect?" The answer is O2.

Any other answer means that 3.1 plus the Standard paragraph above do not
tell enough of the story. And indeed, we need to understand about
reading and modifying in the first place, so 3.1 plus the Standard
paragraph above could be considered an insufficient base.

Moving on...

"If a side effect on a scalar object is unsequenced relative to
either a different side effect on the same scalar object or a value
computation using the value of the same scalar object, the behavior is
undefined. If there are multiple allowable orderings of the
subexpressions of an expression, the behavior is undefined if such an
unsequenced side effect occurs in any of the orderings.84)"

Suppose that we wish to enumerate the possibilities for "side effect on
a scalar object":

1. The scalar object is modified
2. The scalar object is volatile and is accessed
2a. The scalar object is volatile and is read
2b. The scalar object is volatile and is modified

The cases of 2b is a subset of the cases of 1. If we are to exclude all
of 2, then 1 remains and 2b remains as a subset. In this case, why does
it say "side effect on a scalar object" and not "modification of a
scalar object"? Why the indirection via "side effect"?

Moving on...

If we return to "Evaluation", it "includes" the "initiation of side
effects."

"Sequenced before is an asymmetric, transitive, pair-wise relation
between evaluations executed by a single thread, which induces a partial
order among those evaluations. Given any two evaluations A and B, if A
is sequenced before B, then the execution of A shall precede the
execution of B. (Conversely, if A is sequenced before B, then B is
sequenced after A.) If A is not sequenced before or after B, then A and
B are unsequenced. Evaluations A and B are indeterminately sequenced
when A is sequenced either before or after B, but it is unspecified
which.13) The presence of a sequence point between the evaluation of
expressions A and B implies that every value computation and side effect
associated with A is sequenced before every value computation and side
effect associated with B. (A summary of the sequence points is given in
annex C.)"

Here "unsequenced" evaluations A and B do not have a sequence point
between them and all side effects associated with A are not said to
precede nor to follow all side effects associated with B, and vice versa.

I'm sure that you've already considered all of this, but it's gathered
together here so that the puzzling appearance of a quote of 3.1 now has
some surrounding detail. (I hope.)

--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily," -- Richard Harter
 
Reply With Quote
 
 
 
 
88888 Dihedral
Guest
Posts: n/a
 
      01-15-2013
Tim Rentsch於 2013年1月15日星期二UTC+8上午2時23分01秒 寫道:
> Ben Bacarisse <(E-Mail Removed)> writes:
>
>
>
> > Tim Rentsch <(E-Mail Removed)> writes:

>
> >

>
> >> Ben Bacarisse <(E-Mail Removed)> writes:

>
> >>

>
> >>> Tim Rentsch <(E-Mail Removed)> writes:

>
> >>>

>
> >>>> Ben Bacarisse <(E-Mail Removed)> writes:

>
> >>>>

>
> >>>>> Tim Rentsch <(E-Mail Removed)> writes:

>
> >>>>> <snip -- I hoe too dramatic a snip>

>
> >>>>>>> Yes, the consequences of a volatile access are unconstrained, and

>
> >>>>>>> the standard has no business restricting what an implementation

>
> >>>>>>> may do in such circumstances, but the standard *does* have a

>
> >>>>>>> legitimate role in determining that some programs are undefined as

>
> >>>>>>> far it is concerned. One thing that makes the behaviour undefined

>
> >>>>>>> is the situation described in 6.5 p2.

>
> >>>>>>

>
> >>>>>> (Since you have responded briefly I will also, on just one

>
> >>>>>> point. We can get back to the others sometime later if

>
> >>>>>> that's important.)

>
> >>>>>>

>
> >>>>>> Can you identify for me which scalar object is modified

>
> >>>>>> twice as a result of executing 'int i = x + x;', with x

>
> >>>>>> being declared volatile? Remember, a volatile-qualified

>
> >>>>>> access is a side effect, but it is a non-specific one, not

>
> >>>>>> one that modifies the object being accessed. There is no

>
> >>>>>> guarantee that the side effect of accessing a particular

>
> >>>>>> volatile object will modify any given scalar object, or even

>
> >>>>>> any object at all.

>
> >>>>>

>
> >>>>> Agree, but I don't see why that is relevant. The wording has

>
> >>>>> changed, I thought, so that side-effects of any type are the

>
> >>>>> issue. So 6.5 p2 talks only about side-effects on scalar

>
> >>>>> objects, and simply accessing a volatile object constitutes a

>
> >>>>> side effect. What, if anything, changes it not obviously

>
> >>>>> relevant.

>
> >>>>

>
> >>>> First let me be sure I understand you correctly. The wording

>
> >>>> describing sequencing and access rules obviously has changed

>
> >>>> between, well, let's be specific, N1256 and N1570. Do you

>
> >>>> believe the intended meaning of these passages is significantly

>
> >>>> different between these two versions of the Standard?

>
> >>>

>
> >>> I find it hard enough to follow what is written without trying to

>
> >>> deduce what is intended. Others have said that no change in meaning

>
> >>> is intended but who am I to say either way? My remarks were based

>
> >>> solely on what is written in N1570.

>
> >>

>
> >> For giving answers in comp.lang.c, I often (or usually?) find

>
> >> that looking for the intended meaning results in better answers,

>
> >> ie, answers that are more consistent with statements made in

>
> >> Defect Reports and the Rationale document, etc, than reading just

>
> >> what's written in (one revision of) the Standard. It's different

>
> >> in comp.std.c -- there the whole point is to talk about whether

>
> >> or how well the Standard expresses, or could express, what is

>
> >> intended (or sometimes should be intended).

>
> >

>
> > Just a note: I did start all this by saying: "I'm having trouble

>
> > squaring this with the wording of 6.5 p2". In other words it was, from

>
> > the start, a comp.std.c type reply. The problem was always about the

>
> > words, not the intent.

>
> >

>
> >> Here though I asked

>
> >> the question only to better understand your opinion or point of

>
> >> view. Who are you to say? Just the foremost and most reliable

>
> >> authority as to your own conscious thoughts, and without doubt

>
> >> the person most qualified to answer the question I was asking.

>
> >

>
> > I am also the most reliable authority as to whether I believe you prefer

>
> > cod to haddock when getting a fish supper, but I'd still reply "who am I

>
> > to say" if asked which I believe you prefer!

>
> >

>
> > I'm not being evasive. I am pretty certain that the intent was not to

>
> > change the meaning with respect to non-volatile objects, but there has

>
> > been so much revision of the standard in the area of threads and side

>
> > effect sequencing, with the goal of producing a memory model consistent

>
> > with modern hardware, that I don't feel able to even hazard a wild

>
> > guess. I have not read any of those parts, so I don't know if the

>
> > change of wording was intended to produce different semantics in the

>
> > case of volatile objects because, somehow, it now matters.

>
> >

>
> > <snip>

>
> >>>> Maybe I see what you're getting at -- accessing a volatile object

>
> >>>> is supposed to count as a side effect "on that scalar object". But

>
> >>>> I don't see any text in the Standard that supports that conclusion.

>
> >>>> Can you offer any? Or am I still misunderstanding you?

>
> >>>

>
> >>> No, that's exactly it. The new wording -- the switch from talking

>
> >>> about modification to talking about side effects -- now includes

>
> >>> accesses to volatile objects, at least in my naive reading of

>
> >>> 5.1.2.3 p2:

>
> >>>

>
> >>> "Accessing a volatile object, modifying an object, modifying a

>
> >>> file, or calling a function that does any of those operations are

>
> >>> all side effects,12) which are changes in the state of the

>
> >>> execution environment. Evaluation of an expression in general

>
> >>> includes both value computations and initiation of side

>
> >>> effects. Value computation for an lvalue expression includes

>
> >>> determining the identity of the designated object."

>
> >>>

>
> >>> So "accessing a volatile object" and "modifying an object" are both

>
> >>> side effects expressed in exactly the same terms. Neither is

>
> >>> explicitly said to be "on the object" so I don't see how can you say

>
> >>> that one is "on the object" but the other is not. I'd argue that if

>
> >>> the intent is that modification of an object is a side effect on the

>
> >>> object, but accessing a volatile object is not, then that distinction

>
> >>> that needs to be made clear. The default understanding has to be

>
> >>> that they are both side effect on an object.

>
> >>

>
> >> I'm not sure if I'm shocked by this last statement or merely very

>
> >> surprised. On the one hand it is clear from other passages in

>
> >> the Standard that there are some kinds of side effects that are

>
> >> not "on a scalar object"; but, the default understanding has to

>
> >> be, when the Standard does _not_ say, that a side effect must be

>
> >> a side effect on a scalar object (and not just some scalar object

>
> >> but the same one)? Normally I'd expect the default assumption to

>
> >> be just the opposite - that a particular condition is met only

>
> >> when the Standard includes some sort of explicit statement as

>
> >> to the condition in question.

>
> >

>
> > Maybe "default understanding" is the wrong phrase. All I meant was that

>
> > the ordinary meaning of the words makes both of these side effects "on

>
> > an object".

>
> >

>
> >> Beyond that general reaction,

>
> >> however, let's look into some specifics.

>
> >>

>
> >> The operators that directly change scalar objects are postfix ++

>
> >> and --, prefix ++ and --, and assignment.

>
> >>

>
> >> The semantics of postfix ++ (and --) are given in section 6.5.2.4,

>
> >> which says in part:

>
> >>

>
> >> As a side effect, the value of the operand object is

>
> >> incremented (that is, the value 1 of the appropriate

>
> >> type is added to it). [...] The value computation of

>
> >> the result is sequenced before the side effect of

>
> >> updating the stored value of the operand.

>
> >>

>
> >> The semantics of prefix ++ (and --) are given in section 6.5.3.1,

>
> >> which says in part:

>
> >>

>
> >> The expression ++E is equivalent to (E+=1). See the

>
> >> discussions of additive operators and compound assignment

>
> >> for information on constraints, types, side effects, [and

>
> >> some other things].

>
> >>

>
> >> The semantics of assignment are given in section 6.5.16, which

>
> >> says in part:

>
> >>

>
> >> The side effect of updating the stored value of the left

>
> >> operand is sequenced after the value computations of the

>
> >> left and right operands.

>
> >>

>
> >> To me all of these explicitly reference a particular object that

>
> >> the side effect will modify.

>
> >

>
> > Yes, and there's no argument at all about these cases. But 5.1.2.3 p3

>
> > says that accessing a volatile object is a side effect. There's a

>
> > particular object being referenced there as well -- the one being

>
> > accessed.

>
> >

>
> > Clearly the plain English preposition "on" can be used for a

>
> > modification: it's a side effect on an object; but since, in the case of

>
> > a volatile object, the access itself is a side effect, I don't see why

>
> > that is not equally plainly a side effect "on" the object.

>
> >

>
> >> Compare the passages above to the

>
> >> semantics of volatile access, given in 6.7.3 p7, which says in

>
> >> part:

>
> >>

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

>
> >>

>
> >> Here there is no statement about what the side effects of reading

>
> >> a volatile object might be.

>
> >

>
> > I don't think it matters. The access alone is a side effect. Yes,

>
> > there may be others unknown, but however little the standard says about

>
> > modifications and other side effects, access to object alone is one

>
> > certain side effect.

>
> >

>
> >> They might modify the object being

>
> >> read, or they might not; they might modify some other scalar

>
> >> object, or they might not;

>
> >

>
> > [Aside: could it? Only if it, too, is volatile I'd have thought.]

>
> >

>
> >> they change some other physically

>
> >> detectable state of the machine running the program, or they might

>
> >> not. (The modifications mentioned in the first sentence may occur

>
> >> at any time, indepedent of any access in program expressions.)

>
> >> Certainly there is no explicit statement that reading a volatile

>
> >> object modifies (or updates, or has a side effect on) an object.

>
> >> That is a clear distinction with every other operation that might

>
> >> be affected by 6.5 p2.

>
> >

>
> > You are talking about modification but 6.5 p2 does not. All that

>
> > matters is whether the side effect of accessing a volatile scalar object

>
> > falls into the description of "a side effect on a scalar object". Even

>
> > if nothing is modified, the access alone is a side effect and I contend

>
> > that the normal English meaning of "on an object" applies here: it's a

>
> > side effect and there is a specific object associated with the side

>
> > effect (the object being accessed) so it is a "side effect on an

>
> > object". (Forgive me for sometimes including and sometimes dropping the

>
> > qualification "scalar".)

>
> >

>
> >> Finally, there is 5.1.2.3 p9:

>
> >>

>
> >> EXAMPLE 1 An implementation might define a one-to-one

>
> >> correspondence between abstract and actual semantics: at

>
> >> every sequence point, the values of the actual objects would

>
> >> agree with those specified by the abstract semantics. The

>
> >> keyword volatile would then be redundant.

>
> >>

>
> >> Under your theory, volatile would not be redundant in such cases,

>
> >> because adding volatile would change the semantics of programs

>
> >> like the sample code that started the discussion, and so the

>
> >> above EXAMPLE would be contradicted.

>
> >

>
> > This is a good argument for the intent (unless, of course, it was simply

>
> > overlooked) but my argument has always been about the words. I

>
> > previously expressed no opinion about the intent of the committee, but

>
> > this is evidence of intent, so I do now have an opinion (a weak one, but

>
> > an opinion none the less) on this question!

>
> >

>
> >> Admittedly, this paragraph

>
> >> is informative rather than normative. But, considered along with

>
> >> the other cited passages, the evidence favors the position that

>
> >> reading a volatile-qualified object, even though it is a side

>
> >> effect, is not in and of itself "a side effect on a scalar object"

>
> >> as the phrase is used in 6.5 p2.

>
> >>

>
> >> Does this convince you? If it doesn't, do you have any other

>
> >> evidence to offer that reading a volatile object constitutes, for

>
> >> the purpose of 6.5 p2, "a side effect on a scalar object"?

>
> >

>
> > We may soon just have to agree to differ because I don't see anything

>
> > you've presented as being evidence against my contention. Yes, I accept

>
> > that there is evidence that my reading is not what was intended, but my

>
> > point has always been about the words. If reading a scalar is a side

>
> > effect, clearly associated with a unique object, then it's a side effect

>
> > on that object.

>
> >

>
> > Let me try another tack. Imagine C! -- a language like C but in which

>
> > access to a volatile object is not special. C! compilers can remove,

>
> > re-order, and duplicate such accesses just as they can any other. In

>
> > order to get some use back from a volatile object, C! has a new unary

>
> > prefix operator, !!x, which reads x. The C! standard says:

>
> >

>
> > "The operand of !! must denote a volatile-qualified object. An

>
> > expression of the form !!x has the type and value of x, but the

>
> > evaluation is also an 'entaglement'."

>
> >

>
> > It also says that there are other types of entanglement: modifying an

>
> > object is an entanglement, doing IO is another.

>
> >

>
> > Given that we don't know the intent of the C! standards committee, would

>
> > you interpret:

>
> >

>
> > "If an entanglement on a scalar object is unsequenced relative to

>
> > either a different entanglement on the same scalar object or a value

>
> > computation using the value of the same scalar object, the behavior is

>
> > undefined."

>
> >

>
> > as applying to

>
> >

>
> > volatile int x;

>
> > int y = !!x + !!x;

>
> >

>
> > or not? Is the string association of "side effect on" with

>
> > "modification of" at the heart of your argument?

>
>
>
> Well, this has been kind of a comedy of errors, each of us not
>
> understanding where the other person was coming from.
>
>
>
> My worldview of what is being described is simple and easy to
>
> explain. Probably I should have just done this at the beginning,
>
> but 20-20 hindsight and all that.
>
>
>
> Some operations have (or cause, or produce) side effects. Example:
>
> an assignment operation has a side effect of modifying its
>
> left-hand-side operand.
>
>
>
> (Note: technically I should have said evaluating an operation is
>
> what causes a side effect. As long as the distinction is understood
>
> it isn't important to emphasize it.)
>
>
>
> A side effect is what the Standard says it is: a change in the
>
> state of the execution environment.
>
>
>
> Considering all changes in the state of an execution environment,
>
> some are changes to the state of an object. A side effect on an
>
> object is a side-effecting operation that has an effect on that
>
> object, ie, the state of the object is what's being changed (perhaps
>
> among other, unrelated, changes).
>
>
>
> (Note: I'm leaving out the 'scalar' part of 'scalar object' because
>
> I think we agree that it doesn't change the discussion in any
>
> important way.)
>
>
>
> There also can be changes to the state of an execution environment
>
> arising from "outside forces", eg, RAM being hit by a cosmic ray,
>
> or less exotically a buffer being filled in by doing a particular
>
> system call (ie, a system-specific system call not part of any
>
> standard library function or regular C operation). Such changes
>
> are also side effects, but they are (by definition) outside of
>
> what the Standard defines.
>
>
>
> To me the above description seems like the most natural reading of
>
> the text of the Standard, and quite consistent with the ordinary
>
> meaning of the words. For example, considering an environment of
>
> city streets and traffic, we could by analogy call a traffic
>
> accident a "side effect" of city traffic, but when a car hits a
>
> pedestrian the most significant consequence will likely be the
>
> effect on the pedestrian rather than the effect (if any) on the car.
>
>
>
> Based on the above, those operations that modify an object count as
>
> side effects on that object, but reading a volatile object does not.
>
> (The Standard sometimes uses the word update basically as a synonym
>
> for modify.) This is so because a write access necessarily involves
>
> a modification -- ie, a change -- to the object in question, but a
>
> read access of a volatile object does not (necessarily) change the
>
> object in question. (The volatile object being read may change as
>
> a result of the unknown side effects mentioned in 6.7.3 p7, but that
>
> is outside the discussion of whether reading a volatile object must
>
> be a side effect on that object.) Reading a volatile object is a
>
> change to the state of the execution environment, but not a change
>
> to the state of the volatile object itself; there is some effect
>
> _on the system as a whole_, but no effect _on the particular object_.
>
>
>
> An argument might be given that an object might "change" even if its
>
> state remains the same, so reading a volatile object might have an
>
> effect on the object, ie, the effect of leaving it alone. However,
>
> such an argument is undercut by text in section 3.1, defining the
>
> different types of access. Surely if it is important to note that a
>
> object is modified when even the value being stored is the same as
>
> its previous value (as is done in 3.1 p3), then it would also be
>
> important to have a similar note saying an access of a volatile
>
> object counts as a change to the object (or an effect on the object)
>
> even when the access is a read rather than a write. But there is
>
> no such note. Again, reading a volatile object has an effect on
>
> the execution environment, but there is nothing to indicate it
>
> has an effect on the object itself.
>
>
>
> So there in a nutshell is both my view of what the words mean and an
>
> argument based on that reading that supports my conclusions (eg, my
>
> earlier statement about the non-undefinedness of 'x + x').
>
>
>
> Having said all this I invite your response in whatever way you
>
> think best. Originally I had started by responding to individual
>
> paragraphs, but at some point I decided it would be more helpful to
>
> take this approach instead. There may still be some loose ends but
>
> hopefully the discussion has been moved farther along than it was up
>
> to now. (And I hope you have gotten answers to your questions even
>
> though I didn't specifically address them.)


OK, do we have to talk about auto-lifting
of the type of the object in the left handside
of "=" to hold any "valid" result of
the right hand side?

But this is kind asking too much for a fixed type
language such as C.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-15-2013
Shao Miller <(E-Mail Removed)> writes:

> On 1/14/2013 08:20, Ben Bacarisse wrote:

<snip>
>> Did it seem as if there was some confusion over that fact that "access"
>> means both reading and modification and hence that all and any access to
>> a volatile object is a side effect?

>
> Whether it seems that way or not, I was not attempting to draw
> attention to such.


Ah, right. It's useful to know that. Thanks.
<snip>

--
Ben.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-15-2013
Tim Rentsch <(E-Mail Removed)> writes:

> Ben Bacarisse <(E-Mail Removed)> writes:
>
>> Tim Rentsch <(E-Mail Removed)> writes:
>>>
>>> [discussing the "other unknown side effects" related to volatile
>>> objects] They might modify the object being read, or they might
>>> not; they might modify some other scalar object, or they might
>>> not;

>>
>> [Aside: could it? Only if it, too, is volatile I'd have thought.]

>
> The Standard says only that there may be other unknown side
> effects. AFAIK the Standard puts no limitations on what those
> other side effects might be, so they could include changes to other
> objects, even non-volatile ones.


Footnote 34 on 6.2.4 p2 seems to suggest otherwise, does it not?

2. An object exists, has a constant address, and retains
its last-stored value throughout its lifetime.[34]

34) In the case of a volatile object, the last store need not be
explicit in the program.

<snip>
--
Ben.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-15-2013
Tim Rentsch <(E-Mail Removed)> writes:
<snip>
> Well, this has been kind of a comedy of errors, each of us not
> understanding where the other person was coming from.


That's not the impression I get. I thought you did understand what I
was saying, and I don't feel there are things in your point of view that
are at all unclear to me (at least not now). Still, either way, there's
not really anywhere this discussion can go: if we don't understand each
other by now is there really any hope that can be remedied, and if we
do is there any point in saying more?

You wrote another very clear post which must have taken some
considerable time so I fell sad not to respond at more length, but I
don't think I can say more, at least not any more that would be worth
saying.

<snip>
--
Ben.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      01-16-2013
88888 Dihedral <(E-Mail Removed)> writes:

> [700+ lines snipped]
>
> OK, do we have to talk about auto-lifting of the type of
> the object in the left handside of "=" to hold any "valid"
> result of the right hand side? [snip]


No, we don't.

 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      01-16-2013
Ben Bacarisse <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
> <snip>
>> Well, this has been kind of a comedy of errors, each of us not
>> understanding where the other person was coming from.

>
> That's not the impression I get. I thought you did understand
> what I was saying, and I don't feel there are things in your point
> of view that are at all unclear to me (at least not now).


Yet more evidence that there was confusion on both sides! Oops..
well on one side anyway.

> Still, either way, there's not really anywhere this discussion can
> go: if we don't understand each other by now is there really any
> hope that can be remedied, and if we do is there any point in
> saying more?


I would say yes...

> You wrote another very clear post which must have taken some
> considerable time so I fell sad not to respond at more length,
> but I don't think I can say more, at least not any more that
> would be worth saying.


Here is what I'm left with: I understand what but I don't
understand why. That is, I think I know what you believe about how
the phrases should be read, but I don't understand what your
reasons are for believing that. To me it looks like you're saying,
"phrase X should be read as <something> because that's what makes
sense". (I don't mean for this to be an unfair characterization.
I have taken liberties in the paraphrase only for the sake of
brevity -- please adjust accordingly.) Furthermore your conclusions
don't fit with my sense of how the language (ie, the English language)
is normally read here. For example, suppose we try a parallel
construction:

"Building a house is a /construction event/, which is a set
or series of actions that creates a new physical arrangement
in the environment."

Now, after reading this, would I say that "building a house is a
construction event on a house"? No, of course I wouldn't. I think
most people who speak English as a first language would be surprised
to hear such a (linguistic) construction -- the word "on" just isn't
right there. Yet this example seems parallel to what you are saying
(or at least what I understand you to be saying). Assuming I
understand you, your reasoning is basically linguistic in nature
(eg, referring to "ordinary meanings"). But I don't see what those
reasons are. You see my problem? I'm looking for examples of
similar phrasings that seem natural, and also match what you said
(ie, what I understood you to say) about how the statement regarding
"Accessing a volatile object" being a side effect means that there
is a side effect on that particular object (or for that matter, on
any object).

If your response now is that this is just what seems linguistically
natural to you, then there probably isn't much more to say, and I
will just be left baffled. On the other hand, if you have some
parallel examples or other supporting linguistic evidence to offer,
I would very much like to hear some.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      01-16-2013
Ben Bacarisse <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
>
>> Ben Bacarisse <(E-Mail Removed)> writes:
>>
>>> Tim Rentsch <(E-Mail Removed)> writes:
>>>>
>>>> [discussing the "other unknown side effects" related to volatile
>>>> objects] They might modify the object being read, or they might
>>>> not; they might modify some other scalar object, or they might
>>>> not;
>>>
>>> [Aside: could it? Only if it, too, is volatile I'd have thought.]

>>
>> The Standard says only that there may be other unknown side
>> effects. AFAIK the Standard puts no limitations on what those
>> other side effects might be, so they could include changes to other
>> objects, even non-volatile ones.

>
> Footnote 34 on 6.2.4 p2 seems to suggest otherwise, does it not?
>
> 2. An object exists, has a constant address, and retains
> its last-stored value throughout its lifetime.[34]
>
> 34) In the case of a volatile object, the last store need not be
> explicit in the program.
>


An object declared volatile is allowed to change at any time,
with no explicit program actions. That's why this footnote
is there.

More significantly, this paragraph (and indeed almost all of the
Standard) is concerned only with what an implementation may do (or
not do). The consequences of accessing a volatile are outside the
control of, and even the knowledge of, the implementation. If
there is text in the Standard that is meant to impose limitations
outside of the domain of just implementations, that distinction
would have to be made apparent in the text. I just don't know of
any such cases (or at least I can't remember any).
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-16-2013
Tim Rentsch <(E-Mail Removed)> writes:

> Ben Bacarisse <(E-Mail Removed)> writes:
>
>> Tim Rentsch <(E-Mail Removed)> writes:
>>
>>> Ben Bacarisse <(E-Mail Removed)> writes:
>>>
>>>> Tim Rentsch <(E-Mail Removed)> writes:
>>>>>
>>>>> [discussing the "other unknown side effects" related to volatile
>>>>> objects] They might modify the object being read, or they might
>>>>> not; they might modify some other scalar object, or they might
>>>>> not;
>>>>
>>>> [Aside: could it? Only if it, too, is volatile I'd have thought.]
>>>
>>> The Standard says only that there may be other unknown side
>>> effects. AFAIK the Standard puts no limitations on what those
>>> other side effects might be, so they could include changes to other
>>> objects, even non-volatile ones.

>>
>> Footnote 34 on 6.2.4 p2 seems to suggest otherwise, does it not?
>>
>> 2. An object exists, has a constant address, and retains
>> its last-stored value throughout its lifetime.[34]
>>
>> 34) In the case of a volatile object, the last store need not be
>> explicit in the program.
>>

>
> An object declared volatile is allowed to change at any time,
> with no explicit program actions. That's why this footnote
> is there.


My point is that it's worded in a very odd way. It might also say:

34) In the case of a program that declares at least one volatile
object, the last store on *any* object need not be explicit in the
program.

Why is the current wording so very conservative? The retraining of an
object's explicitly last-stored value does not apply to any object in a
program that has at least one volatile, so it seems to be a rather
measly clarification.

> More significantly, this paragraph (and indeed almost all of the
> Standard) is concerned only with what an implementation may do (or
> not do). The consequences of accessing a volatile are outside the
> control of, and even the knowledge of, the implementation. If
> there is text in the Standard that is meant to impose limitations
> outside of the domain of just implementations, that distinction
> would have to be made apparent in the text. I just don't know of
> any such cases (or at least I can't remember any).


I don't have any trouble with that interpretation but it sets up a
tension. The standard doesn't want to restrict what an implementation
does in the presence of volatile accesses, but it also wants to
document what is likely to happen with implementations that define more
normal behaviour for volatile objects. The result is some rather coy
wording.

--
Ben.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Pointer to pointer or reference to pointer A C++ 7 07-05-2011 07:49 PM
Pointer to pointer Vs References to Pointer bansalvikrant@gmail.com C++ 4 07-02-2009 10:20 AM
passing the address of a pointer to a func that doesnt recieve a pointer-to-a-pointer jimjim C Programming 16 03-27-2006 11:03 PM
Usual Arithmetic Conversions-arithmetic expressions joshc C Programming 5 03-31-2005 02:23 AM
Pointer-to-pointer-to-pointer question masood.iqbal@lycos.com C Programming 10 02-04-2005 02:57 AM



Advertisments