Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #29128 > unrolled thread
| Started by | Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> |
|---|---|
| First post | 2012-12-10 17:14 +0000 |
| Last post | 2012-12-10 20:20 -0500 |
| Articles | 20 on this page of 99 — 21 participants |
Back to article view | Back to comp.lang.c
Pointer Arithmetic & UB Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2012-12-10 17:14 +0000
Re: Pointer Arithmetic & UB "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-12-10 09:35 -0800
Re: Pointer Arithmetic & UB James Kuyper <jameskuyper@verizon.net> - 2012-12-10 12:55 -0500
Re: Pointer Arithmetic & UB Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-10 13:25 -0500
Re: Pointer Arithmetic & UB falk@rahul.net (Edward A. Falk) - 2012-12-11 00:46 +0000
Re: Pointer Arithmetic & UB James Kuyper <jameskuyper@verizon.net> - 2012-12-10 21:28 -0500
Re: Pointer Arithmetic & UB Ken Brody <kenbrody@spamcop.net> - 2012-12-12 14:36 -0500
Re: Pointer Arithmetic & UB glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-12 20:35 +0000
Re: Pointer Arithmetic & UB James Kuyper <jameskuyper@verizon.net> - 2012-12-12 15:57 -0500
Re: Pointer Arithmetic & UB Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-12 16:02 -0500
Re: Pointer Arithmetic & UB James Kuyper <jameskuyper@verizon.net> - 2012-12-12 16:13 -0500
Re: Pointer Arithmetic & UB Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-12 21:18 -0500
Re: Pointer Arithmetic & UB James Kuyper <jameskuyper@verizon.net> - 2012-12-12 22:42 -0500
Re: Pointer Arithmetic & UB Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-17 12:04 +0200
Re: Pointer Arithmetic & UB Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-17 08:47 -0500
Re: Pointer Arithmetic & UB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-17 14:58 +0000
Re: Pointer Arithmetic & UB Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-17 10:59 -0500
Re: Pointer Arithmetic & UB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-17 17:26 +0000
Re: Pointer Arithmetic & UB Shao Miller <sha0.miller@gmail.com> - 2012-12-17 19:33 -0500
Re: Pointer Arithmetic & UB Ken Brody <kenbrody@spamcop.net> - 2012-12-20 11:00 -0500
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-20 10:03 -0800
Re: Pointer Arithmetic & UB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-20 22:02 +0000
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-21 13:09 -0800
Re: Pointer Arithmetic & UB glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-21 22:40 +0000
Re: Pointer Arithmetic & UB Ken Brody <kenbrody@spamcop.net> - 2012-12-21 23:39 -0500
Re: Pointer Arithmetic & UB glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-22 06:50 +0000
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-22 00:15 -0800
Re: Pointer Arithmetic & UB glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-22 10:34 +0000
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-22 09:32 -0800
Re: Pointer Arithmetic & UB glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-23 09:38 +0000
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-23 09:55 -0800
Re: Pointer Arithmetic & UB Ken Brody <kenbrody@spamcop.net> - 2012-12-26 13:35 -0500
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-27 09:03 -0800
Re: Pointer Arithmetic & UB Ken Brody <kenbrody@spamcop.net> - 2012-12-27 21:31 -0500
Re: Pointer Arithmetic & UB Philip Lantz <prl@canterey.us> - 2012-12-28 01:55 -0800
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-29 13:43 -0800
Re: Pointer Arithmetic & UB Philip Lantz <prl@canterey.us> - 2012-12-28 01:39 -0800
Re: Pointer Arithmetic & UB glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-28 11:31 +0000
Re: Pointer Arithmetic & UB Keith Thompson <kst-u@mib.org> - 2012-12-28 08:47 -0800
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-29 17:45 -0800
Re: Pointer Arithmetic & UB glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-30 04:06 +0000
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-02 10:08 -0800
Re: Pointer Arithmetic & UB Ken Brody <kenbrody@spamcop.net> - 2012-12-26 13:29 -0500
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-27 07:55 -0800
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-27 08:01 -0800
Re: Pointer Arithmetic & UB Ken Brody <kenbrody@spamcop.net> - 2012-12-27 21:10 -0500
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-29 18:03 -0800
Re: Pointer Arithmetic & UB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-23 03:48 +0000
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-23 10:22 -0800
Re: Pointer Arithmetic & UB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-27 10:34 +0000
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-27 10:16 -0800
Re: Pointer Arithmetic & UB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-10 17:26 +0000
Re: Pointer Arithmetic & UB Robert Wessel <robertwessel2@yahoo.com> - 2012-12-20 12:21 -0600
Re: Pointer Arithmetic & UB James Kuyper <jameskuyper@verizon.net> - 2012-12-20 13:40 -0500
Re: Pointer Arithmetic & UB Robert Wessel <robertwessel2@yahoo.com> - 2012-12-20 13:32 -0600
Re: Pointer Arithmetic & UB James Kuyper <jameskuyper@verizon.net> - 2012-12-20 14:58 -0500
Re: Pointer Arithmetic & UB glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-20 21:54 +0000
Re: Pointer Arithmetic & UB Lanarcam <lanarcam1@yahoo.fr> - 2012-12-20 19:49 +0100
Re: Pointer Arithmetic & UB Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-21 02:38 +0200
Re: Pointer Arithmetic & UB Ken Brody <kenbrody@spamcop.net> - 2012-12-21 14:33 -0500
Re: Pointer Arithmetic & UB Shao Miller <sha0.miller@gmail.com> - 2012-12-21 03:18 -0500
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-21 13:16 -0800
Re: Pointer Arithmetic & UB Shao Miller <sha0.miller@gmail.com> - 2012-12-21 17:57 -0500
Re: Pointer Arithmetic & UB glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-21 23:52 +0000
Re: Pointer Arithmetic & UB Shao Miller <sha0.miller@gmail.com> - 2012-12-21 19:47 -0500
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-21 22:54 -0800
Re: Pointer Arithmetic & UB Shao Miller <sha0.miller@gmail.com> - 2012-12-22 03:31 -0500
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-22 09:16 -0800
Re: Pointer Arithmetic & UB Shao Miller <sha0.miller@gmail.com> - 2012-12-24 04:23 -0500
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-27 11:07 -0800
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 02:33 -0800
Re: Pointer Arithmetic & UB Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 02:18 -0800
Re: Pointer Arithmetic & UB Noob <root@127.0.0.1> - 2012-12-11 11:36 +0100
Re: Pointer Arithmetic & UB "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-12-11 10:00 -0800
Re: Pointer Arithmetic & UB Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-17 12:11 +0200
Re: Pointer Arithmetic & UB Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-11 15:27 -0500
Re: Pointer Arithmetic & UB glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-11 21:09 +0000
Re: Pointer Arithmetic & UB Ken Brody <kenbrody@spamcop.net> - 2012-12-12 14:30 -0500
Re: Pointer Arithmetic & UB Keith Thompson <kst-u@mib.org> - 2012-12-12 11:42 -0800
Re: Pointer Arithmetic & UB Ken Brody <kenbrody@spamcop.net> - 2012-12-12 17:12 -0500
Re: Pointer Arithmetic & UB Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-17 12:16 +0200
Re: Pointer Arithmetic & UB Prathamesh Kulkarni <bilbotheelffriend@gmail.com> - 2012-12-10 12:04 -0800
Re: Pointer Arithmetic & UB James Kuyper <jameskuyper@verizon.net> - 2012-12-10 15:29 -0500
Re: Pointer Arithmetic & UB Prathamesh Kulkarni <bilbotheelffriend@gmail.com> - 2012-12-10 12:44 -0800
Re: Pointer Arithmetic & UB Prathamesh Kulkarni <bilbotheelffriend@gmail.com> - 2012-12-10 12:47 -0800
Re: Pointer Arithmetic & UB James Kuyper <jameskuyper@verizon.net> - 2012-12-10 16:02 -0500
Re: Pointer Arithmetic & UB Prathamesh Kulkarni <bilbotheelffriend@gmail.com> - 2012-12-10 13:08 -0800
Re: Pointer Arithmetic & UB Ken Brody <kenbrody@spamcop.net> - 2012-12-12 14:26 -0500
Re: Pointer Arithmetic & UB Greg Martin <greg@softsprocket.com> - 2012-12-10 14:55 -0800
Re: Pointer Arithmetic & UB Sjouke Burry <s@b> - 2012-12-10 21:18 +0000
Re: Pointer Arithmetic & UB falk@rahul.net (Edward A. Falk) - 2012-12-11 00:48 +0000
Re: Pointer Arithmetic & UB glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-10 21:01 +0000
Re: Pointer Arithmetic & UB Ken Brody <kenbrody@spamcop.net> - 2012-12-12 14:24 -0500
Re: Pointer Arithmetic & UB Robert Wessel <robertwessel2@yahoo.com> - 2012-12-12 14:34 -0600
Re: Pointer Arithmetic & UB glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-12 20:45 +0000
Re: Pointer Arithmetic & UB Robert Wessel <robertwessel2@yahoo.com> - 2012-12-12 15:29 -0600
Re: Pointer Arithmetic & UB glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-13 02:02 +0000
Re: Pointer Arithmetic & UB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-12-17 05:57 -0800
Re: Pointer Arithmetic & UB pete <pfiland@mindspring.com> - 2012-12-10 20:20 -0500
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> |
|---|---|
| Date | 2012-12-10 17:14 +0000 |
| Subject | Pointer Arithmetic & UB |
| Message-ID | <ka559a$hdg$1@speranza.aioe.org> |
Hello Would the following code invoke an undefined behavior? char a[10]; size_t i=20,j=15; *(a+i-j)=42; It potentially constructs the invalid pointer a+i as an intermediate value. But overall the access is inbounds.
[toc] | [next] | [standalone]
| From | "christian.bau" <christian.bau@cbau.wanadoo.co.uk> |
|---|---|
| Date | 2012-12-10 09:35 -0800 |
| Message-ID | <597db9dd-85b5-4515-bff3-08f592878c84@eo2g2000vbb.googlegroups.com> |
| In reply to | #29128 |
On Dec 10, 5:14 pm, Edward Rutherford <edward.p.rutherfor...@REMOVETHIS.gmail.com> wrote: > Hello > > Would the following code invoke an undefined behavior? > > char a[10]; > size_t i=20,j=15; > *(a+i-j)=42; > > It potentially constructs the invalid pointer a+i as an intermediate > value. But overall the access is inbounds. Undefined behaviour. It is _very_ likely, and also legal, that it will behave exactly the same as a [i - j] = 42; but not guaranteed.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-12-10 12:55 -0500 |
| Message-ID | <50C621F9.8050705@verizon.net> |
| In reply to | #29128 |
On 12/10/2012 12:14 PM, Edward Rutherford wrote: > Hello > > Would the following code invoke an undefined behavior? "invoke" is a bad term to use for this purpose; it implies that there's some particular kind of behavior which is called "undefined behavior". You should ask "Would the following code have undefined behavior?" > char a[10]; > size_t i=20,j=15; > *(a+i-j)=42; > > It potentially constructs the invalid pointer a+i as an intermediate > value. But overall the access is inbounds. Yes, it does have undefined behavior. To make this seem more reasonable, consider a platform with the following real-world characteristics: there are registers specialized for storing addresses, and when an invalid address is stored in one of those registers, the current process aborts immediately, as a safety measure - it doesn't wait for the invalid address to be used. On such an implementation, a conforming implementation could translate your code so that 'a' is allocated near the end of a block of valid memory addresses, so that adding 20 to a gives an invalid address. It could generate instructions that load 'a' into an address register, then adds 'i' to it. Execution of those instructions would result in the register containing an invalid address, thus causing your program being aborted.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-12-10 13:25 -0500 |
| Message-ID | <ka59e6$mq7$1@dont-email.me> |
| In reply to | #29131 |
On 12/10/2012 12:55 PM, James Kuyper wrote:
> On 12/10/2012 12:14 PM, Edward Rutherford wrote:
>> Hello
>>
>> Would the following code invoke an undefined behavior?
>
> "invoke" is a bad term to use for this purpose; it implies that there's
> some particular kind of behavior which is called "undefined behavior".
> You should ask "Would the following code have undefined behavior?"
>
>> char a[10];
>> size_t i=20,j=15;
>> *(a+i-j)=42;
>>
>> It potentially constructs the invalid pointer a+i as an intermediate
>> value. But overall the access is inbounds.
>
> Yes, it does have undefined behavior.
> To make this seem more reasonable, consider a platform with the
> following real-world characteristics: [...]
A colleague who did some work on IBM's AS/400 (they've
changed the name; I forget the new one) told me that simply
trying to calculate an out-of-range pointer yielded a null
pointer as a result. In the O.P.'s case, the intermediate
steps would go something like
a // OK so far
a + i // too big: result = NULL
NULL - j // not sure, but surely not good
*(NULL - j) // really Really REALLY not good
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | falk@rahul.net (Edward A. Falk) |
|---|---|
| Date | 2012-12-11 00:46 +0000 |
| Message-ID | <ka5vq2$lq6$1@blue-new.rahul.net> |
| In reply to | #29133 |
In article <ka59e6$mq7$1@dont-email.me>, Eric Sosman <esosman@comcast-dot-net.invalid> wrote: > > A colleague who did some work on IBM's AS/400 (they've >changed the name; I forget the new one) told me that simply >trying to calculate an out-of-range pointer yielded a null >pointer as a result. Heh; learn something new every day. I never would have guessed that there was an actual architecture that would blow up with this construct. I assume that *(a+(i-j)) would be ok? -- -Ed Falk, falk@despams.r.us.com http://thespamdiaries.blogspot.com/
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-12-10 21:28 -0500 |
| Message-ID | <ka65o0$703$1@dont-email.me> |
| In reply to | #29144 |
Context:
char a[10];
size_t i=20,j=15;
*(a+i-j)=42;
On 12/10/2012 07:46 PM, Edward A. Falk wrote:
...
> Heh; learn something new every day. I never would have guessed
> that there was an actual architecture that would blow up with
> this construct.
>
> I assume that *(a+(i-j)) would be ok?
That should be safe for all conforming implementations of C.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Ken Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-12-12 14:36 -0500 |
| Message-ID | <50C8DCC5.1020205@spamcop.net> |
| In reply to | #29147 |
On 12/10/2012 9:28 PM, James Kuyper wrote: > Context: > char a[10]; > size_t i=20,j=15; > *(a+i-j)=42; > > On 12/10/2012 07:46 PM, Edward A. Falk wrote: > ... >> Heh; learn something new every day. I never would have guessed >> that there was an actual architecture that would blow up with >> this construct. >> >> I assume that *(a+(i-j)) would be ok? > > That should be safe for all conforming implementations of C. Are you sure? Does anything in the Standard *require* that "i-j" be evaluated prior to adding it to "a"? Haven't we had this discussion earlier, related to other forms of UB, with the questioner asking if adding parentheses would "fix" the problem?
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-12-12 20:35 +0000 |
| Message-ID | <kaappq$emd$1@speranza.aioe.org> |
| In reply to | #29176 |
Ken Brody <kenbrody@spamcop.net> wrote: > On 12/10/2012 9:28 PM, James Kuyper wrote: >> Context: >> char a[10]; >> size_t i=20,j=15; >> *(a+i-j)=42; (snip) >>> I assume that *(a+(i-j)) would be ok? >> That should be safe for all conforming implementations of C. > Are you sure? Does anything in the Standard *require* that "i-j" be > evaluated prior to adding it to "a"? On many systems, the result is the same until you try to dereference the result. Seems to me that on any system where the result isn't the same, that the compiler better do it in the appropriate order. With the appropriate wrap on overflow characteristic, fixed point arithmetic is associative. If the compiler knows that, it can compute i+(j-k) as (i+j)-k, knowing the result is the same. If something else happens on overflow, the compiler shouldn't do that. It gets more interesting with floating point. > Haven't we had this discussion earlier, related to other forms of UB, with > the questioner asking if adding parentheses would "fix" the problem? -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-12-12 15:57 -0500 |
| Message-ID | <50C8EFB3.90107@verizon.net> |
| In reply to | #29176 |
On 12/12/2012 02:36 PM, Ken Brody wrote:
> On 12/10/2012 9:28 PM, James Kuyper wrote:
>> Context:
>> char a[10];
>> size_t i=20,j=15;
>> *(a+i-j)=42;
>>
>> On 12/10/2012 07:46 PM, Edward A. Falk wrote:
>> ...
>>> Heh; learn something new every day. I never would have guessed
>>> that there was an actual architecture that would blow up with
>>> this construct.
>>>
>>> I assume that *(a+(i-j)) would be ok?
>>
>> That should be safe for all conforming implementations of C.
>
> Are you sure? Does anything in the Standard *require* that "i-j" be
> evaluated prior to adding it to "a"?
Yes, I'm sure; if you aren't, perhaps there's been a miscommunication of
some kind?
Check the grammar rules. The right operand of a binary '+' expression
must be a multiplicative-expression (6.5.6p1). '(' doesn't qualify;
neither does '(i', or '(i+' or '(i+j'; the only thing that can be parsed
as the right operand of the '+' operator in that expression is (i+j),
which parses as primary-expression (6.5.1p1), and therefore as a
postfix-expression (6.5.2p1), a unary-expression (6.5.3p1), a
cast-expression (6.5.4p1), and a multiplicative expression (6.5.5p1), in
that order.
For C99, I would have stopped the explanation at that point, considering
that my point had already been made. However, in order to support
multi-threaded code, C2011 had to be more explicit about when the order
of two events is specified, and when it isn't, so there's a couple of
additional citations that are relevant. I believe that what they say was
inherently true even in C99, where it was not explicitly said:
"The value computations of the operands of an operator
are sequenced before the value computation of the result of the
operator." 6.5p1.
"An evaluation A happens before an evaluation B if A is sequenced before
B." 5.1.2.4p9
> Haven't we had this discussion earlier, related to other forms of UB, with
> the questioner asking if adding parentheses would "fix" the problem?
The problem with *(a+i-j) is that the standard mandates that 'i' be
added to 'a' before 'j' is subtracted from the result. Putting a
parenthesis around 'i - j' converts those three tokens into a single
primary-expression. That's why *(a+(i-j)) fixes the problem. It forces
the value computations for the subtraction expression to happen before
the value computations of the binary addition expression.
Kenneth gives i+(i++) as an example of a case where parentheses do
nothing to resolve the underlying problem. That is because the problem
is the absences of a sequence point separating 'i' from 'i++'.
Parenthesis do not insert a sequence point, and therefore do NOT solve
that problem.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-12-12 16:02 -0500 |
| Message-ID | <kaarct$au1$1@dont-email.me> |
| In reply to | #29176 |
On 12/12/2012 2:36 PM, Ken Brody wrote:
> On 12/10/2012 9:28 PM, James Kuyper wrote:
>> Context:
>> char a[10];
>> size_t i=20,j=15;
>> *(a+i-j)=42;
>>
>> On 12/10/2012 07:46 PM, Edward A. Falk wrote:
>> ...
>>> Heh; learn something new every day. I never would have guessed
>>> that there was an actual architecture that would blow up with
>>> this construct.
>>>
>>> I assume that *(a+(i-j)) would be ok?
>>
>> That should be safe for all conforming implementations of C.
>
> Are you sure? Does anything in the Standard *require* that "i-j" be
> evaluated prior to adding it to "a"?
No, but the Standard requires that the thing added to `a'
be the value of `i-j'. The "as if" rule still applies, so an
actual implementation might calculate something that might be
written as `a-j+i' or `i+a-j' or `a-(j-i)' or a host of other
possibilities. Still, the result -- including the definedness
of the result -- must be as for "`a' plus `i-j'".
> Haven't we had this discussion earlier, related to other forms of UB,
> with the questioner asking if adding parentheses would "fix" the problem?
Nitpick: Since this isn't UB, "other" is out of place.
The usual misunderstanding is that the association of
operators with their operands -- "expression tree order" --
dictates evaluation order, which it doesn't. (Except for
certain special operators like ||, and even then only in
part.)
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-12-12 16:13 -0500 |
| Message-ID | <50C8F391.3050605@verizon.net> |
| In reply to | #29182 |
On 12/12/2012 04:02 PM, Eric Sosman wrote: ... > The usual misunderstanding is that the association of > operators with their operands -- "expression tree order" -- > dictates evaluation order, which it doesn't. (Except for > certain special operators like ||, and even then only in > part.) The expression tree does not impose an evaluation order on it's branches at the same level (with the exceptions that you noted), but it does impose a requirement that the operands be evaluated before the expression itself. I believe that this requirement has always been implied by the semantics of each expression, but C2011 has made this requirement explicit for all expression in 6.5p1 and 5.1.2.4p18 (which I just mis-cited in my response to Kenneth as 5.1.2.4p9).
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-12-12 21:18 -0500 |
| Message-ID | <kabdua$rn3$1@dont-email.me> |
| In reply to | #29183 |
On 12/12/2012 4:13 PM, James Kuyper wrote:
> On 12/12/2012 04:02 PM, Eric Sosman wrote:
> ...
>> The usual misunderstanding is that the association of
>> operators with their operands -- "expression tree order" --
>> dictates evaluation order, which it doesn't. (Except for
>> certain special operators like ||, and even then only in
>> part.)
>
> The expression tree does not impose an evaluation order on it's branches
> at the same level (with the exceptions that you noted), but it does
> impose a requirement that the operands be evaluated before the
> expression itself. I believe that this requirement has always been
> implied by the semantics of each expression, but C2011 has made this
> requirement explicit for all expression in 6.5p1 and 5.1.2.4p18 (which I
> just mis-cited in my response to Kenneth as 5.1.2.4p9).
Although I haven't studied the C11 stuff in detail, I'd
be surprised (and disappointed!) if in
#define WHICH 1
...
int r = WHICH * (x + y) + (1 - WHICH) * (z - x);
... the Standard required that `z - x' be evaluated at all,
much less "before" the entire expression.
However, neither surprise nor disappointment is entirely
strange to me. Embarrassment is an old pal, too ...
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-12-12 22:42 -0500 |
| Message-ID | <kabirf$hs6$1@dont-email.me> |
| In reply to | #29193 |
On 12/12/2012 09:18 PM, Eric Sosman wrote: ... > Although I haven't studied the C11 stuff in detail, I'd > be surprised (and disappointed!) if in > > #define WHICH 1 > ... > int r = WHICH * (x + y) + (1 - WHICH) * (z - x); > > ... the Standard required that `z - x' be evaluated at all, > much less "before" the entire expression. Well, the as-if rule always trumps any other requirements, when it applies - if a strictly conforming program can't determine whether or not sub-expressions were evaluated in the required order, evaluating them in that order isn't really required. If it can't even determine whether they were evaluated, they don't even have to be evaluated. > However, neither surprise nor disappointment is entirely > strange to me. Embarrassment is an old pal, too ... Yep, I know him well myself. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2012-12-17 12:04 +0200 |
| Message-ID | <874njlkn92.fsf@bazspaz.fatphil.org> |
| In reply to | #29193 |
Eric Sosman <esosman@comcast-dot-net.invalid> writes: > On 12/12/2012 4:13 PM, James Kuyper wrote: > > On 12/12/2012 04:02 PM, Eric Sosman wrote: > > ... > >> The usual misunderstanding is that the association of > >> operators with their operands -- "expression tree order" -- > >> dictates evaluation order, which it doesn't. (Except for > >> certain special operators like ||, and even then only in > >> part.) > > > > The expression tree does not impose an evaluation order on it's branches > > at the same level (with the exceptions that you noted), but it does > > impose a requirement that the operands be evaluated before the > > expression itself. I believe that this requirement has always been > > implied by the semantics of each expression, but C2011 has made this > > requirement explicit for all expression in 6.5p1 and 5.1.2.4p18 (which I > > just mis-cited in my response to Kenneth as 5.1.2.4p9). > > Although I haven't studied the C11 stuff in detail, I'd > be surprised (and disappointed!) if in > > #define WHICH 1 > ... > int r = WHICH * (x + y) + (1 - WHICH) * (z - x); > > ... the Standard required that `z - x' be evaluated at all, > much less "before" the entire expression. I am deliriously happy that the Standard requires that (the implementation behave as if) `z - x' is evaluated. That would be, and is, consistent behaviour. Pulling out the big cannon - if z and x are volatile, of course you want x read twice, and z read once. If you meant to say int r = WHICH ? (x+y) : (z-x); then write that, not some other silly expression which does arithmetic rather than conditional evaluation. Phil -- I'm not saying that google groups censors my posts, but there's a strong link between me saying "google groups sucks" in articles, and them disappearing. Oh - I guess I might be saying that google groups censors my posts.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-12-17 08:47 -0500 |
| Message-ID | <kan7qh$7lf$1@dont-email.me> |
| In reply to | #29371 |
On 12/17/2012 5:04 AM, Phil Carmody wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>>[...]
>> Although I haven't studied the C11 stuff in detail, I'd
>> be surprised (and disappointed!) if in
>>
>> #define WHICH 1
>> ...
>> int r = WHICH * (x + y) + (1 - WHICH) * (z - x);
>>
>> ... the Standard required that `z - x' be evaluated at all,
>> much less "before" the entire expression.
>
> I am deliriously happy that the Standard requires that (the implementation
> behave as if) `z - x' is evaluated. That would be, and is, consistent behaviour.
>
> Pulling out the big cannon - if z and x are volatile, of course you
> want x read twice, and z read once.
If `x' is volatile, the behavior is undefined.
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-12-17 14:58 +0000 |
| Message-ID | <0.fcf5c97d853c43699f51.20121217145817GMT.87txrkbu9i.fsf@bsb.me.uk> |
| In reply to | #29399 |
Eric Sosman <esosman@comcast-dot-net.invalid> writes: > On 12/17/2012 5:04 AM, Phil Carmody wrote: >> Eric Sosman <esosman@comcast-dot-net.invalid> writes: >>>[...] >>> Although I haven't studied the C11 stuff in detail, I'd >>> be surprised (and disappointed!) if in >>> >>> #define WHICH 1 >>> ... >>> int r = WHICH * (x + y) + (1 - WHICH) * (z - x); >>> >>> ... the Standard required that `z - x' be evaluated at all, >>> much less "before" the entire expression. >> >> I am deliriously happy that the Standard requires that (the implementation >> behave as if) `z - x' is evaluated. That would be, and is, consistent behaviour. >> >> Pulling out the big cannon - if z and x are volatile, of course you >> want x read twice, and z read once. > > If `x' is volatile, the behavior is undefined. Are you referring to the new C11 wording of 6.5 p2? If so, I wonder if this is intended because it looks to me like a change between C99 and C11. If you mean that it's undefined even in C99, I'd welcome an explanation. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-12-17 10:59 -0500 |
| Message-ID | <kanfgh$qju$1@dont-email.me> |
| In reply to | #29403 |
On 12/17/2012 9:58 AM, Ben Bacarisse wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>
>> On 12/17/2012 5:04 AM, Phil Carmody wrote:
>>> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>>>> [...]
>>>> Although I haven't studied the C11 stuff in detail, I'd
>>>> be surprised (and disappointed!) if in
>>>>
>>>> #define WHICH 1
>>>> ...
>>>> int r = WHICH * (x + y) + (1 - WHICH) * (z - x);
>>>>
>>>> ... the Standard required that `z - x' be evaluated at all,
>>>> much less "before" the entire expression.
>>>
>>> I am deliriously happy that the Standard requires that (the implementation
>>> behave as if) `z - x' is evaluated. That would be, and is, consistent behaviour.
>>>
>>> Pulling out the big cannon - if z and x are volatile, of course you
>>> want x read twice, and z read once.
>>
>> If `x' is volatile, the behavior is undefined.
>
> Are you referring to the new C11 wording of 6.5 p2? If so, I wonder if
> this is intended because it looks to me like a change between C99 and
> C11. If you mean that it's undefined even in C99, I'd welcome an
> explanation.
I may be wrong (it's happened before and will happen again),
but here's my reasoning:
- If `x' is volatile, any use of it is a side-effect (5.1.2.3,
C99 p2 or C11 p3).
- The side-effect may change the value of `x' (6.7.3, C99 p6
or C11 p7).
- The two uses of `x' are not separated by sequence points
(Cxx, passim).
- Two modifications to one object without an intervening
sequence point is U.B. (6.5, C99 p2 or C11 p2, with different
wordings).
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-12-17 17:26 +0000 |
| Message-ID | <0.4d99a98f83de2c71de35.20121217172611GMT.87fw34bnf0.fsf@bsb.me.uk> |
| In reply to | #29406 |
Eric Sosman <esosman@comcast-dot-net.invalid> writes: > On 12/17/2012 9:58 AM, Ben Bacarisse wrote: >> Eric Sosman <esosman@comcast-dot-net.invalid> writes: >> >>> On 12/17/2012 5:04 AM, Phil Carmody wrote: >>>> Eric Sosman <esosman@comcast-dot-net.invalid> writes: >>>>> [...] >>>>> Although I haven't studied the C11 stuff in detail, I'd >>>>> be surprised (and disappointed!) if in >>>>> >>>>> #define WHICH 1 >>>>> ... >>>>> int r = WHICH * (x + y) + (1 - WHICH) * (z - x); >>>>> >>>>> ... the Standard required that `z - x' be evaluated at all, >>>>> much less "before" the entire expression. >>>> >>>> I am deliriously happy that the Standard requires that (the implementation >>>> behave as if) `z - x' is evaluated. That would be, and is, consistent behaviour. >>>> >>>> Pulling out the big cannon - if z and x are volatile, of course you >>>> want x read twice, and z read once. >>> >>> If `x' is volatile, the behavior is undefined. >> >> Are you referring to the new C11 wording of 6.5 p2? If so, I wonder if >> this is intended because it looks to me like a change between C99 and >> C11. If you mean that it's undefined even in C99, I'd welcome an >> explanation. > > I may be wrong (it's happened before and will happen again), > but here's my reasoning: > > - If `x' is volatile, any use of it is a side-effect (5.1.2.3, > C99 p2 or C11 p3). > > - The side-effect may change the value of `x' (6.7.3, C99 p6 > or C11 p7). > > - The two uses of `x' are not separated by sequence points > (Cxx, passim). > > - Two modifications to one object without an intervening > sequence point is U.B. (6.5, C99 p2 or C11 p2, with different > wordings). I'd call that "may be undefined in C99". If you know that the side-effect does not change x, it would be defined would it not? In contrast, the new wording in C11 (6.5 p2) makes it undefined regardless of the nature of the side-effect which seems a little odd. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2012-12-17 19:33 -0500 |
| Message-ID | <kaodld$4gb$1@dont-email.me> |
| In reply to | #29408 |
On 12/17/2012 12:26, Ben Bacarisse wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>
>> On 12/17/2012 9:58 AM, Ben Bacarisse wrote:
>>> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>>>
>>>> On 12/17/2012 5:04 AM, Phil Carmody wrote:
>>>>> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>>>>>> [...]
>>>>>> Although I haven't studied the C11 stuff in detail, I'd
>>>>>> be surprised (and disappointed!) if in
>>>>>>
>>>>>> #define WHICH 1
>>>>>> ...
>>>>>> int r = WHICH * (x + y) + (1 - WHICH) * (z - x);
>>>>>>
>>>>>> ... the Standard required that `z - x' be evaluated at all,
>>>>>> much less "before" the entire expression.
>>>>>
>>>>> I am deliriously happy that the Standard requires that (the implementation
>>>>> behave as if) `z - x' is evaluated. That would be, and is, consistent behaviour.
>>>>>
>>>>> Pulling out the big cannon - if z and x are volatile, of course you
>>>>> want x read twice, and z read once.
>>>>
>>>> If `x' is volatile, the behavior is undefined.
>>>
>>> Are you referring to the new C11 wording of 6.5 p2? If so, I wonder if
>>> this is intended because it looks to me like a change between C99 and
>>> C11. If you mean that it's undefined even in C99, I'd welcome an
>>> explanation.
>>
>> I may be wrong (it's happened before and will happen again),
>> but here's my reasoning:
>>
>> - If `x' is volatile, any use of it is a side-effect (5.1.2.3,
>> C99 p2 or C11 p3).
>>
>> - The side-effect may change the value of `x' (6.7.3, C99 p6
>> or C11 p7).
>>
>> - The two uses of `x' are not separated by sequence points
>> (Cxx, passim).
>>
>> - Two modifications to one object without an intervening
>> sequence point is U.B. (6.5, C99 p2 or C11 p2, with different
>> wordings).
>
> I'd call that "may be undefined in C99". If you know that the
> side-effect does not change x, it would be defined would it not?
>
> In contrast, the new wording in C11 (6.5 p2) makes it undefined
> regardless of the nature of the side-effect which seems a little odd.
>
The C11 footnote 84 says that
a[i] = i;
is fine. It doesn't mention whether or not 'i' is volatile. 6.5.16p3
("Assignment operators") has that "The evaluations of the operands are
unsequenced."
It might've been nice if the footnote had mentioned 'volatile', or had a
declaration for 'i' that excluded it.
- Shao Miller
[toc] | [prev] | [next] | [standalone]
| From | Ken Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-12-20 11:00 -0500 |
| Message-ID | <kavcm1$pv9$1@dont-email.me> |
| In reply to | #29448 |
On 12/17/2012 7:33 PM, Shao Miller wrote:
[...]
Condensed version of the discussion so far, in this subthread:
=====
Given:
extern volatile int x;
int i = x + x;
And citing several C&V from different standards regarding the fact merely
accessing a volatile is a "side effect".
Does the above invoke UB? (No sequence point between the two "side effects"
of accessing "x".)
=====
The Standard also requires (5.1.2.3p2) that all side effects be "complete"
at the next sequence point.
Given that whatever side effect the access of "x" may have is outside the
control of the abstract machine, I fail to see how the sequence point
requirement applies to the side effect of accessing a volatile.
Consider, for example, a memory-mapped I/O system, where reading from a
given address causes the printer to start printing whatever is in its
buffer. How can C enforce the "shall be complete" requirement of 5.1.2.3p2?
How is "i=x;i+=x;" any better than "i=x+x;"?
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web