Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > [union] Pointers to inherited structs are valid ?

Reply
Thread Tools

[union] Pointers to inherited structs are valid ?

 
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-22-2013
Shao Miller <(E-Mail Removed)> writes:
> On 1/21/2013 16:05, Ben Bacarisse wrote:
>> Shao Miller <(E-Mail Removed)> writes:
>>
>>> On 1/21/2013 11:31, Ben Bacarisse wrote:

>> <snip>
>>>> Geoff's post looks simple and correct: the standard permits trap
>>>> representations that produce undefined behaviour so an implementation is
>>>> permitted to use special values to trigger interesting effects (either
>>>> in a debugger or else where).
>>>
>>> I agree that his post does look that way and that C does allow for
>>> that. There's a subtle bit here, though: If we're discussing a
>>> program, once that program invokes undefined behaviour, anything goes.
>>> However, if I'm not mistaken, with Windows NT, if you have a pointer
>>> value which does not point to an object, the program will continue to
>>> operate as per the C semantics until such a time (if ever) as that
>>> pointer might be used for indirect access.

>>
>> Of course. The "C semantics" are exactly as you describe: "anything
>> goes". If such a program caused the machine to halt, that, too, would
>> be operating as per "C semantics".
>>

>
> No, it wouldn't. The C semantics do not include undefined behaviour.


This is such an odd statement that a recap is probably needed. What do
you mean by "the C semantics"? And are we still talking about a program
that accesses a pointer whose bit-pattern looks like 0xC?

I use the phrase to mean what the C standard say about the meaning of a
C program. The standard says that such a pointer representation *might*
be a trap representation. No one is saying that *is* one (well, I'm
not) but I have disagreed with the arguments you've put forward for
asserting that it is *not* one.

> "[...what a constraint violation is...] Undefined behavior is
> otherwise indicated in this International Standard by the words
> ‘‘undefined behavior’’ or by the omission of any explicit definition
> of behavior. There is no difference in emphasis among these three;
> they all describe ‘‘behavior that is undefined’’."
>
> I used the word "subtle." There is _no_chance_ that _anything_other_
> than what _is_ described by the C Standard will happen. No undefined
> behaviour. No trap representation.


Too subtle for me. What, then, does the C standard say will happen when
the representation in question is used as a pointer?

>>> So it is imprecise to say that such a value has a trap representation,
>>> because the behaviour is still well-defined. Otherwise, the last
>>> sentence of N1570's 6.5.3.2p4 is redundant:
>>>
>>> "If an invalid value has been assigned to the pointer, the behavior
>>> of the unary * operator is undefined.102)"

>>
>> Presumably you read the footnote so you must be aware of all the invalid
>> values that this clause covers.
>>
>> A particular bit-pattern (0xC in this case, I think) can either
>> represent a valid value (for the pointer type in question), an invalid
>> value, or it can be a trap representation. These three possibilities
>> are, at a particular time in the program's execution, mutually
>> exclusive. The middle category, invalid pointer values, needs 6.5.3.2
>> p4.

>
> You appear to be agreeing with me. Did you think I meant something
> else?


Yes, of course I did.

>>> But anyway, a pointer value pointing to no object can still be
>>> "trapped" by Windows during indirection and can still provide useful
>>> information to a Windows debugger. It just does not precisely match
>>> C's trap representation, for behavioural differences.

>>
>> What's the difference? The behaviour you describe here matches what you
>> can expect from what C calls a trap representation.

>
> The difference is that the behaviour is _defined_, instead of
> _undefined_. Yes, the behaviour for both can match. No, the
> expectation is different between them; you don't know what to expect
> from undefined behaviour.


I can't unpick this. If it's central to your point, then I don't
understand what your point is. If it isn't, maybe we can just put it to
one side.

>>>> It could be an unspecified value (you are explicitly using C terms here)
>>>> if it is a valid pointer value. It may well be. Is it? It may equally
>>>> well not be. It could be either a trap representation or an unspecified
>>>> value but you seem to suggest that it is one not the other. You seem to
>>>> suggest that one possibility is more likely than the other for reasons
>>>> that are spurious. The best evidence that it might not be a trap
>>>> representation is that it's a valid pointer, but you give no evidence for
>>>> that -- quite the contrary in fact.
>>>
>>> I'd say that it is not a trap representation.

>>
>> But you don't say why. The "it" above presumably refers to what we've
>> been talking about -- that 0xC bit-pattern. Your only evidence that
>> it's not a trap representation seems to be that nothing "odd" happens
>> until you dereference it. That's entirely consistent with it being a
>> trap representation.

>
> I say why right below. I didn't realize that you couldn't easily
> accept this and that you required evidence.


I don't object to the conclusion, I object to the argument. If, below,
you say why 0xC can't be a trap representation in this particular
implementation, then I'll happily accept it. What I did not accept is
what looked to me like your spurious arguments in support of this
claim.

>>> Take Windows NT's 'IRP' structure. It has a sub-member called
>>> Tail.Overlay.DriverContext', which is an array of 4 'void *'. This is
>>> one of _very_few_ places where a driver can associate information with
>>> an IRP, and is extremely valuable for that reason.
>>>
>>> The implementation defines the results of casting an
>>> appropriately-sized integer value to a 'void *', so such an integer
>>> can be "passed" via this mechanism. We _certainly_ would not wish to
>>> believe that this results in undefined behaviour, so we certainly
>>> would not wish to believe that such a result is a trap representation.

>>
>> Are you saying that something can't be a trap representation because
>> something other than C defines what happens when it's used? That's
>> exactly why, in part, C leaves so many things undefined (the behaviour
>> of trap representations being one such thing) so that implementations
>> are free to do useful things in such situations.

>
> I'm not suggesting that at all. This is a case of Standard behaviour
> plus implementation-defined behaviour. Since Keith asked for it, I
> dug it up from Microsoft:
>
> "an integral type can be converted to a pointer type according to
> the following rules:
>
> - If the integral type is the same size as the pointer type, the
> conversion simply causes the integral value to be treated as a pointer
> (an unsigned integer)."
>
> Does that help in any way? Can the subject of the parentheses have a
> trap representation if all 32 bits are value bits?


This does not say that a pointer object can not hold a trap
representation. The phrase "treated as a pointer" is just too vague to
be sure. Let's say that some bit pattern like 0xC is indeed a void *
trap representation. The conversion (void *)0xC "treats it as a
pointer" but does not involve a representation, so we can't say from
that phrase alone whether that bit-pattern would be a trap
representation if it were in a pointer object.

It seems likely that this text intends to say that all bit patterns
represent valid or invalid (i.e. non-trap) representations for all
pointer types, but it does not get round to actually saying it. And
since the behaviour of a trap representation is a free-for-all, there
is very little way to tell, other than an actual statement of that
fact.

--
Ben.
 
Reply With Quote
 
 
 
 
Shao Miller
Guest
Posts: n/a
 
      01-22-2013
On 1/21/2013 18:50, Keith Thompson wrote:
> Shao Miller <(E-Mail Removed)> writes:
>> On 1/21/2013 15:17, Keith Thompson wrote:
>>> Shao Miller <(E-Mail Removed)> writes:
>>>> - VA32: Any pointer type with a representation that is 32 bits and
>>>> which has no trap representations.
>>>
>>> What makes you think that 32-bit pointers on MS Windows have no
>>> trap representations? `(void*)0x0000000C` almost certainly is a
>>> trap representation for the implementation in question. (I'm using
>>> the phrase "trap representation" as the C standard uses it; I lack
>>> interest in any other meanings *unless* some documentation uses
>>> that exact phrase with a different meaning.)

>>
>> Well I didn't quite say that. I was referring to a particular subset of
>> 32-bit pointers. I would certainly consider the representation
>> 0x00000001 to be a trap representation for an 'int *' in 32-bit Windows.

>
> Yes, you did quite say that. You said the pointer type "has no trap
> representations".
>


I did _not_ say "that 32-bit pointers on MS Windows have no trap
representations". I said that a "VA32", an "unsafe pointer" and a "lull
pointer" do not have trap representations. Yes, I meant to imply that
there was some relevance to Windows. The relationship I would suggest
between a VA32 and Windows is described immediately below.

>> For VA32 (which would correspond to 'void *', 'char *', etc.), the
>> reason I would think that is that I've over a decade of use, I guess. I
>> could be wrong! But here's a starting-point, perhaps:
>>
>> http://msdn.microsoft.com/en-us/library/k26sa92e.aspx

>
> That looks a lot like the C Standard's requirements for pointer
> conversions, with some extra information about how Microsoft's compiler
> performs such conversions. Unlike the standard, it doesn't mention trap
> representations.
>


There is a good reason for this: It conforms to C90. There were no trap
representations in C90. Fortunately, developing for Windows doesn't
require any. What we do have are what's been available since the
dinosaurs roamed the data-centre: Bit patterns that carry useful
debugging information.

>> Wait, are you saying that any pointer that does not match one of {null
>> pointer, points to an object} must necessarily be a trap representation?

>
> I believe so, yes.
>
> Given a pointer value that is neither a null pointer nor a pointer to an
> object [or function], what criteria would cause you to claim that it's *not* a trap
> representation?
>


I think it has to work the other way around. I think the implementation
has to define it as a trap representation. I don't think we can infer
this property from anything that any Standard says. This could be where
our agreement diverges.

>> I haven't intentionally backed away from any claims. I wish I knew what
>> claims you might be referring to.
>>

> /* Let struct foo have a member m at offset 12 (0xc) */
> struct foo *ptr = NULL;
> do_something_with(foo->m);
>
> The evaluation of `foo->m` has undefined behavior because the value of
> `foo` is a null pointer.


Agreed.

> It's likely that the generated code will take
> the value stored in `foo` (0x00000000), add the offset 12 to it
> (yielding 0x0000000c), and then attempt to dereference the resulting
> pointer value. If the program is being executed under the debugger,
> this is likely to cause a trap. The debugger sees an attempt to
> dereference address 0x0000000c and, quite reasonably, infers that it was
> probably the result of accessing a member of a structure or class, at an
> offset of 12 bytes, via a null pointer. The debugger may well have
> other information available that makes that inference stronger.
>
> (Conceivably a compiler could generate code to test the value of ptr
> against 0x00000000 before attempting to add the offset to it; that could
> catch the error slightly sooner and more directly, but at a considerable
> performance cost.)
>
> I believe you've been implying that this means that 0x0000000c is
> a null pointer. It isn't. Seeing Philip's remark, quoted above,
> it's a little clearer why you might have thought so.
>


I did not mean to imply that. Glen Herrmannsfeldt suggested a scenario
where that could be true, but I responded by saying that his case was
"along the lines that might be" the case I was talking about, which is
exactly true: The Microsoft debugger distinguishes between an invalid
pointer and an invalid pointer in the "null class". This implies that
the bits are significant and Glen's masking comes into play. It does
_not_ imply that that I'm saying 0x0000000C is a null pointer. If it
was confusing before, it should have been clear once I answered you
about it comparing as unequal with a null pointer. Sorry about the
confusion.

> [snip]



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

Cheerily," -- Richard Harter
 
Reply With Quote
 
 
 
 
Shao Miller
Guest
Posts: n/a
 
      01-22-2013
On 1/21/2013 23:59, Ben Bacarisse wrote:
> Shao Miller <(E-Mail Removed)> writes:
>> On 1/21/2013 16:05, Ben Bacarisse wrote:
>>> Shao Miller <(E-Mail Removed)> writes:
>>>
>>>> On 1/21/2013 11:31, Ben Bacarisse wrote:
>>> <snip>
>>>>> Geoff's post looks simple and correct: the standard permits trap
>>>>> representations that produce undefined behaviour so an implementation is
>>>>> permitted to use special values to trigger interesting effects (either
>>>>> in a debugger or else where).
>>>>
>>>> I agree that his post does look that way and that C does allow for
>>>> that. There's a subtle bit here, though: If we're discussing a
>>>> program, once that program invokes undefined behaviour, anything goes.
>>>> However, if I'm not mistaken, with Windows NT, if you have a pointer
>>>> value which does not point to an object, the program will continue to
>>>> operate as per the C semantics until such a time (if ever) as that
>>>> pointer might be used for indirect access.
>>>
>>> Of course. The "C semantics" are exactly as you describe: "anything
>>> goes". If such a program caused the machine to halt, that, too, would
>>> be operating as per "C semantics".
>>>

>>
>> No, it wouldn't. The C semantics do not include undefined behaviour.

>
> This is such an odd statement that a recap is probably needed. What do
> you mean by "the C semantics"? And are we still talking about a program
> that accesses a pointer whose bit-pattern looks like 0xC?
>


The C semantics are defined by the Standard. A strictly conforming
program's behaviour is predictable, given these.

Where we see a mention of implementation-defined subject matter, a C
program's behaviour is defined by both the C semantics as well as
implementation-specific definitions. The program's behaviour is
predictable, because the implementation documents their definitions.

Where we see a mention of undefined behaviour, a C program's behaviour
is not guaranteed to be defined by any known means. The program's
behaviour is unpredictable, _unless_ we happen to know it by means which
aren't referred to by the Standard. An implementation or other Standard
(such as POSIX) can certainly define the behaviour.

I'm trying to argue that case for undefined behaviour does not apply.

> I use the phrase to mean what the C standard say about the meaning of a
> C program. The standard says that such a pointer representation *might*
> be a trap representation. No one is saying that *is* one (well, I'm
> not) but I have disagreed with the arguments you've put forward for
> asserting that it is *not* one.
>


Ok. I understand that you didn't like my argument. My recent argument
about IRPs used the English "extremely valuable." This is supposed to
suggest that the English "value" might have some relevance to C's "valid
value": The implementation wishes to allow for something that is
valuable to be represented and worked-with in a well-defined manner. It
is roughly a thought experiment. Maybe that's not the argument that you
didn't enjoy.

>> "[...what a constraint violation is...] Undefined behavior is
>> otherwise indicated in this International Standard by the words
>> ‘‘undefined behavior’’ or by the omission of any explicit definition
>> of behavior. There is no difference in emphasis among these three;
>> they all describe ‘‘behavior that is undefined’’."
>>
>> I used the word "subtle." There is _no_chance_ that _anything_other_
>> than what _is_ described by the C Standard will happen. No undefined
>> behaviour. No trap representation.

>
> [...] What, then, does the C standard say will happen when
> the representation in question is used as a pointer?
>


The C Standard _plus_ the implementation say: It can be stored, read,
passed, discarded, converted, compared, its size determined, etc.
Pretty well anything that doesn't involve using the pointer for indirect
access.

>
> I can't unpick this. If it's central to your point, then I don't
> understand what your point is. If it isn't, maybe we can just put it to
> one side.
>


It is central. Please see my notes about predictability, above.

>> I say why right below. I didn't realize that you couldn't easily
>> accept this and that you required evidence.

>
> I don't object to the conclusion, I object to the argument. If, below,
> you say why 0xC can't be a trap representation in this particular
> implementation, then I'll happily accept it. What I did not accept is
> what looked to me like your spurious arguments in support of this
> claim.
>


Ok. I understand your objection. I didn't think it'd be objectionable.

>> Since Keith asked for it, I
>> dug it up from Microsoft:
>>
>> "an integral type can be converted to a pointer type according to
>> the following rules:
>>
>> - If the integral type is the same size as the pointer type, the
>> conversion simply causes the integral value to be treated as a pointer
>> (an unsigned integer)."
>>
>> Does that help in any way? Can the subject of the parentheses have a
>> trap representation if all 32 bits are value bits?

>
> This does not say that a pointer object can not hold a trap
> representation. The phrase "treated as a pointer" is just too vague to
> be sure. Let's say that some bit pattern like 0xC is indeed a void *
> trap representation. The conversion (void *)0xC "treats it as a
> pointer" but does not involve a representation, so we can't say from
> that phrase alone whether that bit-pattern would be a trap
> representation if it were in a pointer object.
>


There was no claim that this Microsoft quote states that a pointer
cannot hold a trap representation. Such a claim would be impossible,
since there are no trap representations in C90 (which Microsoft conforms
to). The quote is certainly a hint that Microsoft represents pointers
the same way as unsigned integers with the same size. Since we happen
to know (I hope "we" applies) that all bits are value bits for the
integer representation, it suggests to me that the number of pointer
values == the number of the corresponding unsigned integer type's values.

However, although C90 has no trap representations, I would still say
that a pointer-to-object whose representation addresses a misaligned
object is a trap representation. I couldn't prove such a statement, but
it makes sense, to me.

> It seems likely that this text intends to say that all bit patterns
> represent valid or invalid (i.e. non-trap) representations for all
> pointer types, but it does not get round to actually saying it. And
> since the behaviour of a trap representation is a free-for-all, there
> is very little way to tell, other than an actual statement of that
> fact.
>


The reason why it doesn't get around to saying it is discussed, above.
Else-thread:

On 1/22/2013 00:18, Shao Miller wrote:
> Fortunately, developing for Windows doesn't require any. What we do
> have are what's been available since the dinosaurs roamed the
> data-centre: Bit patterns that carry useful debugging information.


(Which is what Geoff was talking about, I surely 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
 
Philip Lantz
Guest
Posts: n/a
 
      01-22-2013
Tim Rentsch wrote:
> Ben Bacarisse writes:
> > A particular bit-pattern (0xC in this case, I think) can either
> > represent a valid value (for the pointer type in question), an invalid
> > value, or it can be a trap representation. These three possibilities
> > are, at a particular time in the program's execution, mutually
> > exclusive. The middle category, invalid pointer values, needs 6.5.3.2
> > p4.

>
> Actually there are four kinds of pointer values (with the
> understanding that "value" here includes some that cannot
> be used definedly):
>
> 1. unusable (any use is undefined behavior)
> 2. null pointers (can be compared for equality/inequality)
> 3. equality, pointer arithmetic, relational (eg <) comparison
> 4. like 3 but also can be dereferenced
>
> Type 3 values are, eg, pointers one past the end of an array, or
> non-null values returned from doing a malloc(0). Type 4 values
> are regular pointers to objects.
>
> The footnote makes it clear that the phrase 'invalid value' used
> in 6.5.3.2 p4 means categories 1-3 above. However this meaning
> of the phrase is meant to apply only to this section.
>
> If a pointer value is stored, the resulting object representation
> can be a trap representation only for values of type 1. (Of
> course any attempt to store a value of type 1 could store anything
> at all, including some representation of any of the above
> categories.)
>
> If an object is read as a pointer type, and the resulting value
> is of type 1 (and assuming there wasn't anything else causing
> undefined behavior), then the object representation of that
> object must be (or have been) a trap representation (when
> considered as the type used to do the access). This follows from
> the definition of trap representation.


I think there may be one more kind of pointer value, which is the kind
that caused this thread. It is a value that may appear in a pointer
object as a result of some prior undefined behavior. This is of course
outside the scope of the C standard--which is why it correctly doesn't
appear in your list--but it does occur in actual implementations.

It behaves much like your type 1, but I'm not sure it's identical; in
particular, its behavior can't be described by referring to the
standard. Before reading this thread, I would not have ever thought to
call it a trap representation, but it is pretty similar.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-22-2013
Shao Miller <(E-Mail Removed)> writes:
<all snipped>

I don't have anything more to add to this exchange. Commenting on your
comments will just add to the noise, I fear, without adding anything
new.

--
Ben.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-22-2013
Shao Miller <(E-Mail Removed)> writes:
> On 1/21/2013 16:32, Keith Thompson wrote:
>> Shao Miller <(E-Mail Removed)> writes:
>>> So it is imprecise to say that such a value has a trap representation,
>>> because the behaviour is still well-defined. Otherwise, the last
>>> sentence of N1570's 6.5.3.2p4 is redundant:
>>>
>>> "If an invalid value has been assigned to the pointer, the behavior
>>> of the unary * operator is undefined.102)"

>>
>> No. Accessing an object with a trap representation has undefined
>> behavior.

>
> I don't understand this as an answer for "it is imprecise to say that
> such a value has a trap representation, because the behaviour is still
> well-defined." I don't understand it as an answer for "Otherwise, the
> last sentence of N1570's 6.5.3.2p4 is redundant." Did you think that I
> didn't think that accessing a trap representation was undefined behaviour?


I *think* the phrase "such a value" refers to a pointer value such as
(void*)0x0000000C, in a Microsoft Windows 32-bit environment. If you're
talking about something else, the following probably won't make much
sense.

Let's try a concrete example. Given this code snippet:

int *ptr;
uintptr_t x = 0x0000000C;
memcpy(&ptr, &x, sizeof ptr);
int deref = *ptr;

I assert that evaluating `*ptr` has undefined behavior. I also assert,
though with slightly less confidence, that after the memcpy() call ptr
contains a trap representation.

Do you disagree? If so, can you cite where the C standard defines the
behavior of the dereference?

[snip]

>> "I see a Microsoft debugger catch these things and call them [non-C]
>> null pointers." -- I don't believe you have seen that.

>
> "These things" == the subject that Geoff had most recently discussed:
> "[non-C] trap values".


What you've seen, as I recall, is the Microsoft debugger, on an
empt to dereference (on the machine code level) a pointer with
the representation 0x0000000C, printing an error message that
includes the identifier "NULL_CLASS_PTR_DEREFERENCE". That is not
the debugger calling 0x0000000C a null pointer. It's the debugger
inferring, from the attempt to dereference 0x0000000C, that there
was an attempt to dereference a C null pointer (0x00000000). Or am
I missing something?

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-22-2013
Shao Miller <(E-Mail Removed)> writes:
> On 1/21/2013 18:50, Keith Thompson wrote:

[...]
>> I believe you've been implying that this means that 0x0000000c is
>> a null pointer. It isn't. Seeing Philip's remark, quoted above,
>> it's a little clearer why you might have thought so.

>
> I did not mean to imply that. Glen Herrmannsfeldt suggested a scenario
> where that could be true, but I responded by saying that his case was
> "along the lines that might be" the case I was talking about, which is
> exactly true: The Microsoft debugger distinguishes between an invalid
> pointer and an invalid pointer in the "null class". This implies that
> the bits are significant and Glen's masking comes into play. It does
> _not_ imply that that I'm saying 0x0000000C is a null pointer. If it
> was confusing before, it should have been clear once I answered you
> about it comparing as unequal with a null pointer. Sorry about the
> confusion.


You're inferring that the debugger message "NULL_CLASS_PTR_DEREFERENCE"
refers to pointers in the "null class". I don't think that's what it
means.

Microsoft's development environment places a greater emphasis on C++
than on C. An attempted dereference of address 0x0000000C is likely
to result from an attempt to dereference a pointer to a class type
(in C++, structs are classes), and the debugger may have more
information that strengthens this inference.

class foo {
public:
char x[12];
int y;
};

foo* ptr = 0;
int kaboom = ptr->y;

(I just tried running a C++ program with the above code under MS Visual
C++ 2010 Express, and didn't get that message; instead, I got "Unhandled
exception at 0x009013a8 in null_class_ptr.exe: 0xC0000005: Access
violation reading location 0x0000000c.".)

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-22-2013
Tim Rentsch <(E-Mail Removed)> writes:
[...]
> Actually there are four kinds of pointer values (with the
> understanding that "value" here includes some that cannot
> be used definedly):
>
> 1. unusable (any use is undefined behavior)
> 2. null pointers (can be compared for equality/inequality)
> 3. equality, pointer arithmetic, relational (eg <) comparison
> 4. like 3 but also can be dereferenced
>
> Type 3 values are, eg, pointers one past the end of an array, or
> non-null values returned from doing a malloc(0). Type 4 values
> are regular pointers to objects.

[...]

And I believe that type 1 is exactly the set of trap representations,
but I haven't been able to prove it.

The definition of "trap representation" in 3.19.4 is a bit vague:

trap representation

an object representation that need not represent a value of the
object type

I wonder why it doesn't say "does not" rather than "need not".

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-22-2013
Shao Miller <(E-Mail Removed)> writes:
[...]
> The C semantics are defined by the Standard. A strictly conforming
> program's behaviour is predictable, given these.
>
> Where we see a mention of implementation-defined subject matter, a C
> program's behaviour is defined by both the C semantics as well as
> implementation-specific definitions. The program's behaviour is
> predictable, because the implementation documents their definitions.
>
> Where we see a mention of undefined behaviour, a C program's behaviour
> is not guaranteed to be defined by any known means. The program's
> behaviour is unpredictable, _unless_ we happen to know it by means
> which aren't referred to by the Standard. An implementation or other
> Standard (such as POSIX) can certainly define the behaviour.


I agree with the above.

> I'm trying to argue that case for undefined behaviour does not apply.


Does not apply *to what*?

Can you provide a small self-contained program that's relevant to
the point you're making?

If you're saying that there's some construct whose behavior you
say is implementation-defined, and I say is undefined, then please
point out the construct in question in your program.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-22-2013
Philip Lantz <(E-Mail Removed)> writes:
> Tim Rentsch wrote:
>> Ben Bacarisse writes:
>> > A particular bit-pattern (0xC in this case, I think) can either
>> > represent a valid value (for the pointer type in question), an invalid
>> > value, or it can be a trap representation. These three possibilities
>> > are, at a particular time in the program's execution, mutually
>> > exclusive. The middle category, invalid pointer values, needs 6.5.3.2
>> > p4.

>>
>> Actually there are four kinds of pointer values (with the
>> understanding that "value" here includes some that cannot
>> be used definedly):
>>
>> 1. unusable (any use is undefined behavior)
>> 2. null pointers (can be compared for equality/inequality)
>> 3. equality, pointer arithmetic, relational (eg <) comparison
>> 4. like 3 but also can be dereferenced
>>
>> Type 3 values are, eg, pointers one past the end of an array, or
>> non-null values returned from doing a malloc(0). Type 4 values
>> are regular pointers to objects.
>>
>> The footnote makes it clear that the phrase 'invalid value' used
>> in 6.5.3.2 p4 means categories 1-3 above. However this meaning
>> of the phrase is meant to apply only to this section.
>>
>> If a pointer value is stored, the resulting object representation
>> can be a trap representation only for values of type 1. (Of
>> course any attempt to store a value of type 1 could store anything
>> at all, including some representation of any of the above
>> categories.)
>>
>> If an object is read as a pointer type, and the resulting value
>> is of type 1 (and assuming there wasn't anything else causing
>> undefined behavior), then the object representation of that
>> object must be (or have been) a trap representation (when
>> considered as the type used to do the access). This follows from
>> the definition of trap representation.

>
> I think there may be one more kind of pointer value, which is the kind
> that caused this thread. It is a value that may appear in a pointer
> object as a result of some prior undefined behavior. This is of course
> outside the scope of the C standard--which is why it correctly doesn't
> appear in your list--but it does occur in actual implementations.
>
> It behaves much like your type 1, but I'm not sure it's identical; in
> particular, its behavior can't be described by referring to the
> standard. Before reading this thread, I would not have ever thought to
> call it a trap representation, but it is pretty similar.


How does "its behavior can't be described by referring to the standard"
differ from "any use is undefined behavior"? (Apart from the quibble
that pointer values don't have behavior; operations on them do.)

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
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
'Class.inherited' v. 'inherited' syntax inside Class 7stud -- Ruby 11 11-09-2007 06:45 PM
Packed structs vs. unpacked structs: what's the difference? Daniel Rudy C Programming 15 04-10-2006 08:10 AM
Array of structs instead of an array with pointers to structs? Paminu C Programming 5 10-11-2005 07:18 PM
const structs in other structs Chris Hauxwell C Programming 6 04-27-2004 07:03 PM
structs with fields that are structs Patricia Van Hise C Programming 5 04-05-2004 01:37 AM



Advertisments