C free

[pete]

I expect it to be the same value that it was last assigned.
Why do you think it is indeterminate?

Like Eric Sosman said, because that's what the standard says.

The only possibilties for a pointer value are:
1 null pointer
2 pointer to object
3 pointer to one past object
4 indeterminate

A freed pointer isn't any of the first three.

 

[Vladimir Oka]

No, even accessing it can cause UB. Section 6.2.4 para 2 of N1124 says:

| The lifetime of an object is the portion of program execution during
| which storage is guaranteed to be reserved for it. An object exists,
| has a constant address,25) and retains its last-stored value
| throughout its lifetime.26) If an object is referred to outside of its
| lifetime, the behavior is undefined. The value of a pointer becomes
| indeterminate when the object it points to reaches the end of its
| lifetime.

So the pointer becomes indeterminate. An indeterminate value is either
an unspecified value or a trap representation, and if it is a trap
reading it is UB.

Ah, OK. Didn't occur to me that it may happent to be a trap. Thanks for
clarifying that.

 

[pete]

Vladimir Oka wrote:

Hmm. The Standard obviously makes a difference between UB and
`indeterminate` value,

Using one causes the other.

I'm inclined to interpret "indeterminate" more as "you may get
unexpected values on inspection" than "even looking invokes UB".

But you're misinterpreting UB.

N869
3. Terms and definitions
3.18
[#1] undefined behavior
behavior, upon use of a nonportable or erroneous program
construct, of erroneous data, or of indeterminately valued
objects, for which this International Standard imposes no
requirements

 

[Guest]

Like Eric Sosman said, because that's what the standard says.

The only possibilties for a pointer value are:
1 null pointer
2 pointer to object
3 pointer to one past object
4 indeterminate

A freed pointer isn't any of the first three.

4 should be "trap representation". An indeterminate pointer value can
turn out to be a valid pointer value, even though you cannot rely on
this.

 

[Guest]

Hmm. The Standard obviously makes a difference between UB and
`indeterminate` value,

Using one causes the other.

I'm inclined to interpret "indeterminate" more as "you may get
unexpected values on inspection" than "even looking invokes UB".

But you're misinterpreting UB.

N869
3. Terms and definitions
3.18
[#1] undefined behavior
behavior, upon use of a nonportable or erroneous program
construct, of erroneous data, or of indeterminately valued
objects, for which this International Standard imposes no
requirements

N1124:

undeï¬ned behavior
behavior, upon use of a nonportable or erroneous program construct or
of erroneous data, for which this International Standard imposes no
requirements

indeterminate value
either an unspeciï¬ed value or a trap representation

unspeciï¬ed value
valid value of the relevant type where this International Standard
imposes no requirements on which value is chosen in any instance
NOTE An unspeciï¬ed value cannot be a trap representation.

 

[pete]

Like Eric Sosman said, because that's what the standard says.

The only possibilties for a pointer value are:
1 null pointer
2 pointer to object
3 pointer to one past object
4 indeterminate

A freed pointer isn't any of the first three.

Unless you're freeing null pointers,
which does happen sometimes.

 

[Vladimir Oka]

Hmm. The Standard obviously makes a difference between UB and
`indeterminate` value,

Using one causes the other.

I'm inclined to interpret "indeterminate" more as "you may get
unexpected values on inspection" than "even looking invokes UB".

But you're misinterpreting UB.

N869
3. Terms and definitions
3.18
[#1] undefined behavior
behavior, upon use of a nonportable or erroneous program
construct, of erroneous data, or of indeterminately valued
objects, for which this International Standard imposes no
requirements

N1124:

undeï¬ned behavior
behavior, upon use of a nonportable or erroneous program construct or
of erroneous data, for which this International Standard imposes no
requirements

indeterminate value
either an unspeciï¬ed value or a trap representation

unspeciï¬ed value
valid value of the relevant type where this International Standard
imposes no requirements on which value is chosen in any instance
NOTE An unspeciï¬ed value cannot be a trap representation.

Ah, so the rules change! In C99 it's not UB, but before it was.
Interesting.

(PS I'm not advocating use indeterminate values.)

 

[pete]

Hmm. The Standard obviously makes a difference between UB and
`indeterminate` value,

Using one causes the other.

I'm inclined to interpret "indeterminate" more as "you may get
unexpected values on inspection" than "even looking invokes UB".

But you're misinterpreting UB.

N869
3. Terms and definitions
3.18
[#1] undefined behavior
behavior, upon use of a nonportable or erroneous program
construct, of erroneous data, or of indeterminately valued
objects, for which this International Standard imposes no
requirements

N1124:

undeï¬ned behavior
behavior, upon use of a nonportable or erroneous program construct or
of erroneous data, for which this International Standard imposes no
requirements

indeterminate value
either an unspeciï¬ed value or a trap representation

unspeciï¬ed value
valid value of the relevant type where this International Standard
imposes no requirements on which value is chosen in any instance
NOTE An unspeciï¬ed value cannot be a trap representation.

OK. It's undefined in C89.

ISO/IEC 9899: 1990

3 Definitions and conventions

3.16 undefined behavior:
Behavior, upon use of a nonportable or erroneous program construct,
of erroneous data, or of indeterminately valued objects,
for which this International Standard imposes no requirements.

 

[Guest]

Vladimir Oka wrote:

Hmm. The Standard obviously makes a difference between UB and
`indeterminate` value,

Using one causes the other.

I'm inclined to interpret "indeterminate" more as "you may get
unexpected values on inspection" than "even looking invokes UB".

But you're misinterpreting UB.

N869
3. Terms and definitions
3.18
[#1] undefined behavior
behavior, upon use of a nonportable or erroneous program
construct, of erroneous data, or of indeterminately valued
objects, for which this International Standard imposes no
requirements

N1124:

undeï¬ned behavior
behavior, upon use of a nonportable or erroneous program construct or
of erroneous data, for which this International Standard imposes no
requirements

indeterminate value
either an unspeciï¬ed value or a trap representation

unspeciï¬ed value
valid value of the relevant type where this International Standard
imposes no requirements on which value is chosen in any instance
NOTE An unspeciï¬ed value cannot be a trap representation.

Ah, so the rules change! In C99 it's not UB, but before it was.
Interesting.

To clarify: it's still undefined behaviour if pointer types have trap
representations on your implementation, since even reading trap
representations has undefined behaviour. If all bit patterns represent
valid pointer values in all cases, though, there's no UB in C99.

(PS I'm not advocating use indeterminate values.)

Good idea

 

[Flash Gordon]

Hmm. The Standard obviously makes a difference between UB and
`indeterminate` value, as the sentence just before the one you quote
explicitely says that trying to refer to an object after its lifetime
ends invokes UB (to losely paraphrase). The whole paragraph is:

The lifetime of an object is the portion of program execution during
which
storage is guaranteed to be reserved for it. An object exists, has a
constant
address, and retains its last-stored value throughout its lifetime.
If an object
is referred to outside of its lifetime, the behavior is undefined.
The value of a
pointer becomes indeterminate when the object it points to reaches
the end
of its lifetime.

I'm inclined to interpret "indeterminate" more as "you may get
unexpected values on inspection" than "even looking invokes UB".
Probably something along the lines of Schroedinger's cat (apologies for
likely misspelling of the great man's name).

See my previous response. An indeterminate value is explicitly defined
as being allowed to be a trap representation. Reading a trap
representation invokes undefined behaviour. So, IMHO, it is
conditionally UB. It is UB if the pointer value becomes a trap
representation (which it is allowed to) but not if it becomes an
unspecified value. Interestingly, if it becomes an unspecified value it
*could* compare equal to a valid pointer...

Of course, since there is no way to determine in advance whether you
will get UB or not you effectively have UB.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php

 

[Eric Sosman]

Consider the following programme:

#include <stdio.h>

int *p ;

void foo(void) {
int a ;

p = &a ;
}

int main() {

foo() ;
printf("p is %p\n",p) ;
}

Is this undefined behaviour ?

Yes, for two reasons. For one thing, it uses the "%p"
specifier with an `int*' argument instead of the required
`void*'. Even before that, though, it tries to use the value
of `p' (it must evaluate `p' as part of the printf() function
call), and the value of `p' is indeterminate because `a' no
longer exists.

 

[Default User]

Thank you all for your responses...

Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the other 99% of the posts in this
group or <http://www.caliburn.nl/topposting.html (thanks Keith).




Brian

 

[ena8t8si]

I would expect, in most implementations, that the pointer passed to
free() will retain its previous representation (it's been argued that
this is required),

The standard explicitly allows representations to change during writes,
but not explicitly during reads, and since every object can be accessed
as an array of unsigned char, where each element is itself an object
which must "[retain] its last-stored value throughout its lifetime", I
would've thought this is required.

However, according to
http://open-std.org/JTC1/SC22/WG14/www/docs/dr_260.htm
it is not. I'm not sure what to say about it, though, other than that
another part of the response already directly contradicts the standard:

"If two objects have identical bit-pattern representations and their
types are the same they may still compare as unequal [...]"

6.2.6.1#4: "Two values (other than NaNs) with the same object
representation compare equal,"

"[...] (for example if one object has an indeterminate value) and if
one is an indeterminate value attempting to read such an object invokes
undefined behavior."

If either is an indeterminate value, the behaviour is undefined before
any comparison is made. This means indeterminate values are not an
example of the above.

The response to DR260 is misguided. First of all it
doesn't make clear what's allowed and what's not
allowed. More important though is the problem that
what's allowed depends on some wild and unexplained
inner workings of the compiler (some compiler? the DR
is quite nonspecific).

The C community, compiler writers included, would be
better served if the misguided notion of "provenance"
were completely stricken. Pointer variables have
out-of-band information that affects how they behave
(namely whether the address is valid or not). But
a value is a value is a value, and the same value
must carry the same behavior if we don't want to
fall into the pit of letting compilers define the
language.

 

[ena8t8si]

Like Eric Sosman said, because that's what the standard says.

The only possibilties for a pointer value are:
1 null pointer
2 pointer to object
3 pointer to one past object
4 indeterminate

A freed pointer isn't any of the first three.

Does the Standard say anything about what
happens to a pointer one past an object that
has been deallocated? Just curious.