Emulating public and private in C structs

Consider:
foo.h:
struct Foo {
        int public_1;
        int public_2;
}
struct Foo * create_Foo ();
void bar_Foo (struct Foo*);
/* etc */
foo.c:
#include "foo.h"
struct Foo_private {
        struct Foo foo; /* ??? */
        int private_1;
        int private_2;
}
struct Foo * create_Foo (void) {
        return malloc (sizeof(Foo_private));
}
void bar_Foo (struct Foo *foo) {
        Foo_private *foo_p = (Foo_private*) foo; /* ??? */
        /* do whatever with foo_p->private_1 and foo_p->private_2 */
}
Is there anything wrong with this? I'm dubious about the lines commented with ???. I don't want to write getters and setters for the 'public' stuff.

>>26
Java allows for modification of private fields as well, through reflection. It makes it more difficult, because it's a language designed for and by idiots, but that's hardly news.
Only under certain conditions. An active security manager can reject all attempts at reflection; this allows truly secure code execution.

>>27
Secure against what? I can't think of any use for checking for encapsulation violations that at runtime if the language itself doesn't allow them. What justifies the added complexity and performance penalty?
Duh, if the language doesn't allow encapsulation violation, then there is a runtime cost to accessor/mutator functions; these can't be inlined at compile-time. Even though the VM can inline such calls, it still has to be done at runtime, or at least in some preparation step somewhere on the user's hardware, otherwise the binary could be modified by an attacker after compilation. The VM has to check for encapsulation violations at load time to provide a secure environment before any such optimizations can be performed. This is why desktop Java apps take so long to start up and wind up in performance, and this is why J2ME apps take so long to install on device.