On Sun, 14 Oct 2007 12:44:02 +0000 (UTC), $)CHarald van D)&k
<truedfx@gmail.com> wrote:

>On Sat, 13 Oct 2007 18:48:38 -0700, Barry Schwarz wrote:
>> On Thu, 11 Oct 2007 19:39:30 +0000 (UTC), roberson@ibd.nrc-cnrc.gc.ca
>> (Walter Roberson) wrote:
>>
>>>In article <1192130548.100801.171110@o3g2000hsb.googlegroups. com>,
>>> <c.a.l@seznam.cz> wrote:
>>>>a) If i do
>>>>pointer = pointer_to_safe_thing - 1000; pointer[1000] ==
>>>>pointer_to_safe_thing[0];
>>>
>>>>then
>>>>I am *not* accessing invalid memory. Nor i am incorrect in mathematical
>>>>sense.
>>>>Nevertheless outcome of pointer_to_safe_memory - 1000 operation
>>>>yielding pointer may be undefined. For i do not know whether pointers
>>>>wraparound like integers?
>>>
>>>Implementation dependant. You can only *safely* have a pointer that is
>>>NULL, or points into an object, or points "one past" the end of the
>>>object.
>>
>> Nope. It is undefined behavior
>
>Undefined behaviour is inherently implementation dependent.
>
Implementation dependent implies that the behavior will be consistent
on a particular implementation (the same today as it was yesterday).
Undefined behavior is not so constrained.


Remove del for email

Barry Schwarz wrote:
> On Sun, 14 Oct 2007 12:44:02 +0000 (UTC), $)CHarald van D)&k
> <truedfx@gmail.com> wrote:
....
>> Undefined behaviour is inherently implementation dependent.
>>
> Implementation dependent implies that the behavior will be consistent
> on a particular implementation (the same today as it was yesterday).

Citation, please?

"Implementation-dependent behavior" isn't a term defined in the C
standard. It's normal English meaning is only that the behavior depends
upon which implementation you use, which is certainly true for undefined
behavior. I don't see any implication that the behavior has to be
consistent.

On Wed, 17 Oct 2007 13:35:44 GMT, "James Kuyper Jr."
<jameskuyper@verizon.net> wrote:

>Barry Schwarz wrote:
>> On Sun, 14 Oct 2007 12:44:02 +0000 (UTC), $)CHarald van D)&k
>> <truedfx@gmail.com> wrote:
>...
>>> Undefined behaviour is inherently implementation dependent.
>>>
>> Implementation dependent implies that the behavior will be consistent
>> on a particular implementation (the same today as it was yesterday).
>
>Citation, please?
>
>"Implementation-dependent behavior" isn't a term defined in the C
>standard. It's normal English meaning is only that the behavior depends
>upon which implementation you use, which is certainly true for undefined
>behavior. I don't see any implication that the behavior has to be
>consistent.

If the behavior is implementation-dependent (I agree with your normal
meaning), and if the implementation doesn't changed, it is reasonable
to conclude that the behavior won't either. If it does, then it
depends on something other (or something more) than the
implementation. Undefined behavior offers no such assurances.


Remove del for email

Barry Schwarz wrote:
> On Wed, 17 Oct 2007 13:35:44 GMT, "James Kuyper Jr."
> <jameskuyper@verizon.net> wrote:
>
> >Barry Schwarz wrote:
> >> On Sun, 14 Oct 2007 12:44:02 +0000 (UTC), $)CHarald van D )& k
> >> <truedfx@gmail.com> wrote:
> >...
> >>> Undefined behaviour is inherently implementation dependent.
> >>>
> >> Implementation dependent implies that the behavior will be consistent
> >> on a particular implementation (the same today as it was yesterday).
> >
> >Citation, please?
> >
> >"Implementation-dependent behavior" isn't a term defined in the C
> >standard. It's normal English meaning is only that the behavior depends
> >upon which implementation you use, which is certainly true for undefined
> >behavior. I don't see any implication that the behavior has to be
> >consistent.
>
> If the behavior is implementation-dependent (I agree with your normal
> meaning), and if the implementation doesn't changed, it is reasonable
> to conclude that the behavior won't either. If it does, then it
> depends on something other (or something more) than the
> implementation. Undefined behavior offers no such assurances.

To say that something depends upon one thing is not the same as saying
that it depends only upon that thing.

If, with implementation A, the behavior depends upon the day of the
week, and with implementation B the behavior depends upon whether or
not the current month has an 'r' in it, then the behavior is
implementation dependent, even though knowing which implementation
you're using is not sufficient to determine what the behavior actually
is. The behavior is also, in both cases, time dependent, which does
not conflict with the fact that it is also implementation-dependent.

Barry Schwarz wrote On 10/19/07 13:27,:
> On Wed, 17 Oct 2007 13:35:44 GMT, "James Kuyper Jr."
> <jameskuyper@verizon.net> wrote:
>
>
>>Barry Schwarz wrote:
>>
>>>On Sun, 14 Oct 2007 12:44:02 +0000 (UTC), $)CHarald van D)&k
>>><truedfx@gmail.com> wrote:
>>
>>...
>>
>>>>Undefined behaviour is inherently implementation dependent.
>>>>
>>>
>>>Implementation dependent implies that the behavior will be consistent
>>>on a particular implementation (the same today as it was yesterday).
>>
>>Citation, please?
>>
>>"Implementation-dependent behavior" isn't a term defined in the C
>>standard. It's normal English meaning is only that the behavior depends
>>upon which implementation you use, which is certainly true for undefined
>>behavior. I don't see any implication that the behavior has to be
>>consistent.
>
>
> If the behavior is implementation-dependent (I agree with your normal
> meaning), and if the implementation doesn't changed, it is reasonable
> to conclude that the behavior won't either. If it does, then it
> depends on something other (or something more) than the
> implementation. Undefined behavior offers no such assurances.

Where is it written that "the implementation" can
have no time-varying components? The behavior of

puts( __TIME__ );

.... clearly changes as the module is compiled and recompiled,
and although __TIME__ itself is not implementation-defined
its value certainly is. Can't the rest of the implementation
have at least this much freedom?

--
Eric.Sosman@sun.com