C0x 6.5.6 posted:

When an expression that has integer type is added to or subtracted from a pointer, the result has the type of the pointer operand.

If the pointer operand points to an element of an array object, and the array is large enough, the result points to an element offset from the original element such that the difference of the subscripts of the resulting and original array elements equals the integer expression.

In other words, if the expression P points to the i-th element of an array object, the expressions (P)+N (equivalently, N+(P)) and (P)−N (where N has the value n) point to, respectively, the i+n-th and i-n-th elements of the array object, provided they exist.

Moreover, if the expression P points to the last element of an array object, the expression (P)+1 points one past the last element of the array object, and if the expression Q points one past the last element of an array object, the expression (Q)−1 points to the last element of the array object.

If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow;

otherwise, the behavior is undefined.

C0x Rationale 6.5.6 1171 posted:

Any pointer arithmetic that takes a pointer outside of the pointed-to object (apart from the one past exception)
is undefined behavior. There is no requirement that the pointer be dereferenced; creating it within a
subexpression is sufficient.

Joda posted:

comedyblissoption posted:

If you try to clean it up, remember that not all days have 24 hours.

Spatial posted:

I wish language lawyers wouldn't pop out of the woodwork trying to one-up each other every time C is mentioned. Keep it in your pants please.

Spatial posted:

I wish language lawyers wouldn't pop out of the woodwork trying to one-up each other every time C is mentioned. Keep it in your pants please.

rjmccall posted:

Spatial posted:

I wish language lawyers wouldn't pop out of the woodwork trying to one-up each other every time C is mentioned. Keep it in your pants please.

Spatial posted:

I wish language lawyers wouldn't pop out of the woodwork trying to one-up each other every time C is mentioned. Keep it in your pants please.

Jabor posted:

For example, merely computing the value can cause an overflow trap if it's outside the allowed range (while if the newly-computed pointer is inside the allowed range, the compiler must ensure that it doesn't overflow).

rjmccall posted:

compilers generally cannot know statically every possible valid address of an object, it has to let you get away with it.

JawnV6 posted:

Now I'm confused, why could an index into an object not overflow? That seems like the runtime's job to allocate things, if it puts an object right at the edge of memory or going over, the compiler can't know that indexing the last element would overflow.

JawnV6 posted:

Also it's fun that I can't generate pointers outside objects, but the compiler's free to make them and leave them in memory willy nilly.

rjmccall posted:

(But null is different.)

idiotmeat posted:

Except on OS390 where NULL can be dereferenced.

john donne posted:

What does it dereference? 0? Undefined behavior?

rjmccall posted:

By which you mean it's mapped? A lot of operating systems let you map the zero page; it's not a good idea, but they let you do it. It's still undefined behavior even if it doesn't trap.

We get requests on Clang sporadically to support dereferencing the zero address for some embedded / boot-loader project where zero is actually a significant address (that they often need to address by literal value, no less) and I'm always like, how much feature work exactly would you like us to do to simplify this task for you, and would you actually use that feature if we did it?

rjmccall posted:

lol no

Anyway, the restriction people keep quoting is specifically about pointer arithmetic, and it only prevents you from using pointer arithmetic to exceeds the bounds of an object (where those bounds include the one-past-the-end pointer), primarily as a way to allow the compiler to assume that subscripting into an array does not alias arbitrary other memory. It is not a general prohibition against forming or having a pointer that does not point at anything. It is of course undefined behavior to dereference a pointer that does not validly point to an object, outside of the specific exception for &*. The only general restriction on pointer values is that you cannot legally create a pointer that is less aligned than its pointee type; that is a rule that compilers are usually lax about until you actually use it to access the underlying memory.

But if you cast 7 to a pointer type, that is legal (assuming the pointee type is byte-aligned); and if there happens to be an object of that type at address 7, then it is legal to dereference the resulting pointer; and since compilers generally cannot know statically every possible valid address of an object, it has to let you get away with it. (But null is different.)

C0x 6.3.2.3 posted:

An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.
If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.
Conversion of a null pointer to another pointer type yields a null pointer of that type.
Any two null pointers shall compare equal.
An integer may be converted to any pointer type.
Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.

Spatial posted:

I wish language lawyers wouldn't pop out of the woodwork trying to one-up each other every time C is mentioned. Keep it in your pants please.

JewKiller 3000 posted:

language lawyers are the only reason your certified retarded c code even compiles, much less runs efficiently. how dare you, sir, how dare you.

JawnV6 posted:

Also it's fun that I can't generate pointers outside objects, but the compiler's free to make them and leave them in memory willy nilly.

ChaosArgate posted:

code:

if (!a && !b) {
    if (b) {
        c = true;
    } else {
        c = false;
    }
}

It's obfuscated but I found this in a massive file at work.

idiotmeat posted:

Photons.

Factor Mystic posted:

Law & Order of operations

Doc Hawkins posted:

In the software system, the people are represented by two separate, yet equally important, groups: the coders, who write programs; and the posters, who prosecute the coders for their language crimes.

Fergus Mac Roich posted:

Where can I go to get my C code certified as retarded?

DaTroof posted:

These are their user stories.

Rubellavator posted:

Today I broke a jasmine test that looked like this:

code:

controller.js

vm.foo = 
{ 
	p1: "stuff",
	p2: "things",
	bar: function (params) { //do stuff }
}

controller-spec.js

var foo = 
{
	p1: "stuff",
	p2: "things",
	bar: function (params) { //do stuff } 
}

expect(vm.foo).toEqual(foo);

Doom Mathematic posted:

How did that ever pass?