Thread: Memory pools, object lifetimes and strict aliasing

Originally Posted by MOS-6581

The strict aliasing rule prevents you from accessing objects unless you're using a type that is compatible with the effective type of the object. The problem with that is that once you've specified the effective type for allocated memory then you can only change the effective type by using memcpy or memmove.

That's not true. You're reading more into that clause than warranted. It is not saying the only way the effective type of an object can change is by using memcpy() or memmove(). The various usages of the term "lvalue" are describing other ways.

Originally Posted by MOS-6581

I do not find anything in the standard that supports the line of reasoning that grumpy has taken with regards to peeking etc

You also would not have found anything in the standard which contradicts that line of reasoning.

Originally Posted by MOS-6581

What does the bolded part mean? That you can change the effective type of an allocated object simply by modifying it since the object doesn't have an effective type for accesses that modify it?

I would remove everything from the "since", but yeah.

Originally Posted by MOS-6581

As far as "peeking" is concerned I recommend that you read this defective report: Defect Report #236

It appears that defect report is working on the premise that "peeking" is not required, with this "(This function can be in translation unit of its own and have no knowledge about the union or the allocated object.)".

Originally Posted by grumpy

I would remove everything from the "since", but yeah..

Yeah I realize that the wording of that part was not entirely accurate since the type of the lvalue accessing the object will set the effective type for an access that modifies the object. What I meant was that whatever effective type the object had before that access won't matter as long as it's an allocated object we're talking about.

Originally Posted by grumpy

It appears that defect report is working on the premise that "peeking" is not required, with this "(This function can be in translation unit of its own and have no knowledge about the union or the allocated object.)".

It's perfectly clear to me now why the compiler is allowed to do what it did in that example. I did some experimentation in Visual Studio and noticed even stranger results from much simpler code so breaking the strict aliasing rule really can lead to unpredictable behaviour.

I'm still not sure what allows placement new to create objects (int, float, etc) in a char[] that wasn't dynamically allocated though. It's definitely not legal for other code to reinterpret that char[] as anything except a (signed or unsigned) char object.

>> Your example looks very similar to what's going on this blog post: Embedded in Academia : C Puzzle: Double Trouble
Not impressed. Both examples have undefined behavior. Mine does not.

gg

Originally Posted by Codeplug

Not impressed. Both examples have undefined behavior. Mine does not.

This defective report may indicate that your example isn't or at least shouldn't be legal: Fixing the rules for type-based aliasing

The committee's decision concerning DR 236 was that the form of an lvalue is significant in determining what operations on a union are valid. Accesses to a union member through a pointer to non-union type are not allowed to change the identity of the last-stored member of the union; changing the "effective type" of the union is allowed only where the appropriate union member's name actually appears in the expression effecting the change.

That's almost exactly what you're doing; you're trying to change the effective type of the union through a pointer of non-union type. Whether or not something should be illegal simply because the C committee intended it to be is not for me to say.

The example in that report specifically mentions that it's okay to change the effective type through an union pointer to &g_mem but it's not clear if you're allowed to to do it through an int or float pointer to &g_mem.

The following isn't allowed so why should it be allowed to do it through a pointer?

Code:

union X {int x; float y;} x;
x = 5; // Illegal, "cannot convert from 'int' to 'X'"
int *p = &x;
*p = 42; // Why should this be legal?

It just so happens that Visual Studio doesn't complain about the second line but I'm not sure if that means it's legal or not. I know the standard says this:

A pointer to a union object, suitably converted, points to each of its members

The issue from the defective report still remains even after the pointer is "suitably converted" to an int or float pointer like in your code or my example above.

Have you stopped to think about the rationale behind the strict aliasing rule?

Taken in isolation, the C and C++ standards are simply a list of rules which conforming compilers must follow, along with a non-exhaustive list of situations where the standard "has nothing to say." But WHY is it this way?

What is aliasing? Really what we mean is referential aliasing, i.e. the existence of distinct referent objects which can access the same "real object" in memory. Why do we care? Because compilers must assume that, without prior knowledge, these referents may overlap. In order to produce code which is correct in all situations the compiler has to assume that nearly all referents are overlapping. This can lead to extremely poor performance of the compiled code.

What do we do about it? Well, static analysis can help. In some situations where the compiler can see all the code at once, it might be able to prove the distinctness of the referents and thereby avoid many pointless memory loads and stores. But it cannot in general do this.

But can we "cheat" in some way that boosts performance while still remaining correct? Well, it depends what we're willing to declare in the standard. Boiled down to the grossest resolution, what the strict aliasing rule does it permit the compiler to assume that referents which refer to different types of objects may never alias each other. We give up a little bit of flexibility by doing this -- we can no longer reliably play games like converting a floating point bit pattern directly to an integer -- but in return, the compiler gains enormous leverage to assume that many referents don't overlap, and aggressively optimize the compiled code.

I bother to say this because knowing the rationale behind the rule helps you to better understand the (plausible) compiler decisions that go into applying it.

The rationale behind the rule has always been clear to me, but it can be difficult to decipher how the rule will be applied. Judging by some of the defect reports I've linked to it seems that even the people writing the standard are a bit confused. Defect report #236 is a good example of this (it's still not resolved after all these years as far as I know): Defect Report #236

Code:

#include <stdlib.h>#include <stdio.h>


void f(int *qi, double *qd) {
    int i = *qi + 2;
    *qd = 3.1;       /* Can the compiler move this assignment to the top of function? */
    *qd *= i;
    printf("qd = %f\n", *qd);
    return;
}
int main(void) {
    void *vp;
    int *pi;
    double *pd;
    vp = malloc(sizeof(int) + sizeof(double));
    pi = vp;
    *pi = 7;
    pd = vp;
    f(pi, pd);
    free(vp);
    return 0;
}

The committee responded with this:

Both programs invoke undefined behavior, by calling function f with pointers qi and qd that have different types but designate the same region of storage. The translator has every right to rearrange accesses to *qi and *qd by the usual aliasing rules.

There is nothing in the standard that forbids this since the aliasing rule is entirely defined in terms of how you access memory; not what kind of pointers you have to it. No wonder I'm confused when even the people who are writing the standard can't get it right. With that said, common sense should dictate that you don't write code like the one in this post.

I'm not sure if this violates aliasing rules (it probably does) but at a point in time, I think the only way to make a pool work is to violate the aliasing rules.

O_o

That is not necessarily the case.

As has been said numerous times by numerous people, where the memory lives is irrelevant.

If you attempt to read/write the same memory location from incompatible pointers you are likely violating the "Strict Aliasing" rule.

If your code really violates the strict aliasing rule, the "allocated buffer" is not your problem--at least only problem.

Soma

>> The standard is still unclear about this but one of the defect reports made it clear that you're not allowed to change the effective type of unions through a pointer that isn't a union.
Are you talking about "Report #236" - which is closed and ends with:

Committee Response

Both programs invoke undefined behavior, ...

Which is common sense to me - even though language lawyers aren't happy with the current wording of the standard.

>> That's why I believe Codeplug's example isn't correct.
Don't base your beliefs on an old, closed defect report that didn't go anywhere.
6.5p6 of C99 still has the same wording that 236 tried to change. I don't see anything else in C99 that says the effective type of a union can not be changed via a pointer.

I still believe my example is well defined.

If being a language lawyer is something you enjoy:
C99 revisited | Software is Crap

gg