Thread: Undefined behavior with pointers to different arrays.

Originally Posted by megafiddle

So are there then different "types" of pointers to same type? Something that is unaccessable to the programmer?

No. In C, the type of every pointer is defined.

Originally Posted by megafiddle

Is it that a proper conversion will be done for assignment, but not for comparison?

There is no conversion involved (except that of converting the name of an array into a pointer). It is simply a case where the results of comparison of some pointers are undefined.

Incidentally, IIRC, comparing for equality and inequality does not have undefined behaviour. It is comparisons related to ordering (such as < and <=) that yield undefined behaviour in some circumstances.

Originally Posted by megafiddle

I'm just trying to understand where the danger actually is in the comparison, aside from it providing a possibly useless result.

The real danger is that the standard specifies it has undefined behaviour. From a C language perspective, that is all you need to know.

The standard leaves things undefined (or specifies that they result in undefined behaviour) in a number of circumstances. A common one is that there is variation between implementations (compilers, operating system, host hardware) as to whether something is even technically feasible, whether doing it yields an unrecoverable run-time error, and things like that.

It might make sense to you to test if the address of an X (which is in ROM) is greater than the address of another X (which is in RAM). That doesn't mean it makes sense on all possible implementations.

And the fact that it is undefined behaviour means that a compiler is not required to report the problem. The only way you might know there is a problem is if a program crashes on one host system, but not another.

Originally Posted by grumpy

Incidentally, IIRC, comparing for equality and inequality does not have undefined behaviour. It is comparisons related to ordering (such as < and <=) that yield undefined behaviour in some circumstances.

The text of the standard as quoted by anduril462 in post #8 does not appear to make any exception for comparing for equality and inequality of pointers to elements from different arrays. However, there is a limited exception provided in a different place:

Originally Posted by C99 Clause 6.5.9 Paragraph 6

Two pointers compare equal if and only if both are null pointers, both are pointers to the same object (including a pointer to an object and a subobject at its beginning) or function, both are pointers to one past the last element of the same array object, or one is a pointer to one past the end of one array object and the other is a pointer to the start of a different array object that happens to immediately follow the first array object in the address space.

My C11 draft copy says the same thing.

Originally Posted by megafiddle

Does the undefined behavior only apply to relational operations?

For example, if you printed (printf) the values of two respective pointers to two arrays,
would the printed values agree with the result of a relational operations?

What do you mean by "agree with the result of a relational operations"? Remember, since the behaviour is undefined, there is no constraint given by the standard on the behaviour. Therefore, "the result of a relational operation" that is undefined could be say, the printing of a "Hello world!" program, or the launching of a nuclear weapon (special hardware required), etc, and have nothing to do with what you regard as "the result of a relational operation".

Originally Posted by megafiddle

Does the undefined behavior only apply to relational operations?

There are many other instances of undefined behaviour in the standard, including things you can do to pointers that invoke undefined behaviour. This is just one.

Originally Posted by megafiddle

For example, if you printed (printf) the values of two respective pointers to two arrays,
would the printed values agree with the result of a relational operations?

That question is meaningless, since the relational operators have undefined behaviour. Undefined behaviour trumps everything.

Originally Posted by anduril462

A pointer can hold any value which represents a valid address in memory for that type.

Yes, indeed, my description was incomplete.

Originally Posted by megafiddle

I can see that if the ordinality is undefined, then that "undefinedness" will carry over to the comparison result.

That's the point you're missing. It is not only the ordinality that is undefined. Even the attempt to compare the results (in specified ways) yields undefined behaviour.

Originally Posted by megafiddle

If you compare two random numbers, the result will also be random. But that doesn't mean that that the comparison operation is itself generating random results.

Sure. But random numbers can be produced without invoking undefined behaviour as well. That's not the point.

Originally Posted by megafiddle

Now if the definition of undefined behaviour extends to everything that it affects, then that's fine. In that case I am just being too fussy about the terms and such. But that makes it difficult to ask questions if I am using the terms wrong.

Yeah, well.

1) The definition of undefined behaviour does extend "to everything that it affects"
2) If you are going to be fussy about "terms and such", the onus is on you to properly understand those terms before getting into a debate about them.

For reference, the 1999 C standard, section 3.4, para 1 defines "undefined behavior" (with the joys of american spelling) to be

undefined behavior

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

All C and C++ standards have a similar definition (although the precise wording differs).

Originally Posted by megafiddle

For an example like this, I would expect the ordinal value of the printed pointer values to be unpredictable:

Code:

 int array1[5];
int array2[5];
int *p1;
int *p2;

p1 = array1;
p2 = array2;

printf("p1 = %p\n", p1);
printf("p2 = %p\n", p2);

// so far everything is perfectly valid

if(p1 > p2)
    printf("p1 is greater than p2");
else
    printf("p1 is not greater than p2");

But are you saying that the program could do something other than print either "p1 is greater than p2" or "p1 is not greater than p2"?

Yes.

Let's consider five hypothetical compilers.

1) Compiler A lays out memory, so array1 is at a lower memory location than array2. When built with that compiler, the code will produce "p1 is not greater than p2"
2) Compiler B lays out memory, so array2 is at a lower memory location than array1. When built with that compiler, the code will produce "p1 is greater than p2"
3) Compiler C randomises the location of array1 and array2 every time the program is run. When built with that compiler, the code might randomly produce a different output every time the program is run.
4) Compiler D recognises that array1 and array2 are not otherwise used, so removes them completely. It similarly eliminates p1 and p2 from existence, and emits code so the program always prints out the value 42.
5) Compiler E triggers a voltage surge that fatally electrocutes the programmer, and produces no output to screen other than "RIP young grasshopper".

So, which one of these compilers is correct? According to the standard, all of them are. Compiler E might be rather unpopular with programmers because of the result it produces, but it would still be correct according to the standard (but, boy, it would cause the average competence of programmers to increase).

You see, undefined behaviour is not limited to what results a comparison will produce (for example, based on ordinality). It is an all or nothing thing. Undefined behaviour means any action is permitted, by the standard. Particular compilers (or compiler vendors) may choose to do it one way or another. That is what undefined behaviour is about.

Originally Posted by Mr.Lnx

May my question is meaningless but , the point of undefined behavior would exist if compiler put the array1 next to array2 in the memory? all of the times? I think again we will have UB because of two pointers that show to different arrays.

It is one thing for a particular compiler vendor to make such a choice for their compiler. Something else for a standard to mandate it for all possible compilers.

Undefined behaviour allows freedom to compiler vendors to do what works best for their product. The problem comes in with code that assumes a particular (in this case) layout of arrays in memory. That code may not function as intended when built using a different compiler, on a different target machine, etc.

Bear in mind that the standard is based on consensus among relevant experts, including compiler vendors. The fact this is undefined behaviour is a sign that a single approach could not be found that would work for all compilers, for all host systems, etc etc. These things are determined by vote. While there is an implied goal for the standard committee to minimise the number of instances of undefined behaviour in C, sometimes it is unavoidable.

In this sense, C differs from proprietary languages like C# or Java. In those languages, the vendors were able to mandate particular solutions to suit themselves. Vendors of competing products (say, a competing JVM) had to comply, even if that was not best for that product or the particular systems it is supported for. And, AFAIK, those languages or their libraries all have instances of undefined behaviour, albeit fewer than in C, but also not as well known (or even admitted to by vendors) as is the case in C.

Originally Posted by grumpy

2) If you are going to be fussy about "terms and such", the onus is on you to properly understand those terms before getting into a debate about them.

Agreed. But one doesn't always know that their understanding is wrong. It's in things like this that you question it.
Also, not debating, just trying to understand.

Originally Posted by grumpy

That's the point you're missing. It is not only the ordinality that is undefined. Even the attempt to compare the results (in specified ways) yields undefined

behaviour.

Actually, that's the question I am asking. I was just trying to be clear on the answer.

Originally Posted by grumpy

1) The definition of undefined behaviour does extend "to everything that it affects"

Ok, I think that is what my whole question is centered around.

According to that definition, a perfectly operating comparison could produce an undefined result, simply because it was fed
undefined values. In other words, it would evalute as either true or false, indeterminantly, based only on the input values
being indeterminant.
It seems to me that the standard was saying nothing more than that. Now, I don't know for sure, that's why I was asking.
If the comparison itself does in fact exhibit undefined behaviour, then that does simply answer my question.
Why is it necessary that the comparison also be at fault?

Originally Posted by grumpy

Sure. But random numbers can be produced without invoking undefined behaviour as well. That's not the point.

No. It was just an example of input characteristics carrying over into the output.

Originally Posted by grumpy

Let's consider five hypothetical compilers.

1) Compiler A lays out memory, so array1 is at a lower memory location than array2. When built with that compiler, the code will produce "p1 is not greater than p2"
2) Compiler B lays out memory, so array2 is at a lower memory location than array1. When built with that compiler, the code will produce "p1 is greater than p2"
3) Compiler C randomises the location of array1 and array2 every time the program is run. When built with that compiler, the code might randomly produce a different output every time the

program is run.
4) Compiler D recognises that array1 and array2 are not otherwise used, so removes them completely. It similarly eliminates p1 and p2 from existence, and emits code so the program always

prints out the value 42.
5) Compiler E triggers a voltage surge that fatally electrocutes the programmer, and produces no output to screen other than "RIP young grasshopper".

Hypotheticals 1, 2 and 3 illustrate my original question. Isn't that considered undefined behaviour even with a perfectly operating comparison?

Hypothetical 4 - unrelated problem? Couldn't that happen with two pointers to the same array?

Hypothetical 5 - That's a terrible way to do it! Keyboards and mice are typically nonconductive.

-

Originally Posted by megafiddle

According to that definition, a perfectly operating comparison could produce an undefined result, simply because it was fed
undefined values. In other words, it would evalute as either true or false, indeterminantly, based only on the input values
being indeterminant.

Maybe a formal definition of the terms might help you understand:

Originally Posted by C++11 Clause 1.3.10

implementation-defined behavior
behavior, for a well-formed program construct and correct data, that depends on the implementation and that each implementation documents

Originally Posted by C++11 Clause 1.3.24

undefined behavior
behavior for which this International Standard imposes no requirements
[ Note: Undefined behavior may be expected when this International Standard omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed. —end note ]

Originally Posted by C++11 Clause 1.3.25

unspecified behavior
behavior, for a well-formed program construct and correct data, that depends on the implementation
[ Note: The implementation is not required to document which behavior occurs. The range of possible behaviors is usually delineated by this International Standard. —end note ]

For exact reasons you mentioned above (some objects may be in ROM or RAM), or for size & alignment reasons (e.g. Harvard architectures), some pointers may or may not be able to hold certain memory addresses.

'void *' and 'char *' are both able to represent all object pointer types. (6.2.5p28, 6.3.2.3p1)

Could it be that when two pointers are cast to 'void *', that the destination pointers are considered to point into the same aggregate?

I see. This makes me wonder about code like:

Code:

int a[3][10];
a[0] < a[2];

Would you say it has undefined behaviour? On the one hand, both pointers point into separate aggregates, but on the other, those two aggregates are members of the same, larger aggregate.