pointer offsetting

[CBFalconer]

Re: pointer offsetting

Keith Thompson wrote:

Harald van D©¦k <truedfx@gmail. comwrites:

>Joachim Schmitz wrote:
>>

.... snip ...

>

>>Or if n1124 is a draft, n1256 is one too The pre C99 draft has
>>a 3 digit namber which escapes me at this moment...

>>
>n869, which has the advantage of being available in plain text
>format.

>
PDF can be converted to plain text (with some loss of information).

N869 is available in a properly formatted text version, unlike the
others. So called 'text conversion' just leaves a mess. After
page information is stripped from N869, and the indentation is
reduced, the result is available (compressed) as n869_txt.bz2 at:

<http://cbfalconer.home .att.net/download/>

and is quite suitable for quoting, grepping, etc.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>



--
Posted via a free Usenet account from http://www.teranews.com

[Barry Schwarz]

Re: pointer offsetting

On Wed, 17 Oct 2007 13:35:44 GMT, "James Kuyper Jr."
<jameskuyper@ve rizon.netwrote:

>Barry Schwarz wrote:

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

>...

>>Undefined behaviour is inherently implementation dependent.
>>>

>Implementati on dependent implies that the behavior will be consistent
>on a particular implementation (the same today as it was yesterday).

>
>Citation, please?
>
>"Implementatio n-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

[jameskuyper@verizon.net]

Re: pointer offsetting

Barry Schwarz wrote:

On Wed, 17 Oct 2007 13:35:44 GMT, "James Kuyper Jr."
<jameskuyper@ve rizon.netwrote:
>

Barry Schwarz wrote:

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

...

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

"Implementa tion-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.

[Eric Sosman]

Re: pointer offsetting

Barry Schwarz wrote On 10/19/07 13:27,:

On Wed, 17 Oct 2007 13:35:44 GMT, "James Kuyper Jr."
<jameskuyper@ve rizon.netwrote:
>
>

>>Barry Schwarz wrote:
>>

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

>>
>>...
>>

>>>>Undefined behaviour is inherently implementation dependent.
>>>>
>>>
>>>Implementati on dependent implies that the behavior will be consistent
>>>on a particular implementation (the same today as it was yesterday).

>>
>>Citation, please?
>>
>>"Implementati on-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