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.

>>36
carolingian miniscule's nonsensical mixed case was invented in what is now france, by ancestors of modern french people. byzantium had nothing to do with it.

>>41
It was created at the court of Charlemagne, which was at Aachen, in present-day Germany, you blithering ignoramus. There's a whole country between Aachen and France nowadays.

>>42
Not to mention that the Carolingians didn't come up with it just to be different or to spite people; they came up with it because it was a palpable improvement over the old system. That's why mixed case was individually invented at Constantinople (though the Byzantium comment was just to illustrate the stupidity of thinking a term like ``Frank'' implies a connection with modern-day France) and, albeit in a different form, in Japan. It's also why every alphabetic writing system invented since then has incorporated it. It just makes writing and reading easier.

>>42
germany is part of france. it split off for a while and then they were reunited in 1957, except for the eastern half of germany, which was reunited with the rest of france in 1990.

>>43
That's why mixed case was individually invented at Constantinople
no, it wasn't.

(though the Byzantium comment was just to illustrate the stupidity of thinking a term like ``Frank'' implies a connection with modern-day France)
see >>34.

and, albeit in a different form, in Japan.
The distinction between hiragana and katakana in Japanese is similar to, but not the same as, case; it may also be considered analogous to upright and italics characters. While each sound has both a hiragana and katakana, any given word will use only one of the two scripts normally. If a word is written with hiragana, it is not normally considered correct to write it with katakana, and vice versa.

It's also why every alphabetic writing system invented since then has incorporated it. It just makes writing and reading easier.
younger futhark, glagolithic, mandaic, mongolian, manchu...
also, i notice you intentionally said "invented since then" so you could exclude aramaic and arabic.

>>44
I genuinely wonder if you think any of that constitutes a counter-argument, or if you've just given up and gone for full retard. It's always hard to tell, with people like you.

>>37
You still haven't explained what ``secure'' even means in this context, and what is gained by it. It's clear you've drunk the Kool-Aid without pausing to consider what it was you were actually consuming.
Jesus fucking christ. Secure means you can create a security context which defines what a set of Java classes are allowed to do (e.g. no reflection, no file access, no access to any classes outside of x.x.x package, etc.), and the VM can enforce this and ensure that the Java bytecode cannot violate these rules - without running in a separate process, without help from the OS (i.e. virtual memory permissions), with a totally shared heap. Without fuck all anything special.

There. Happy now?

>>39
If the attacker has the means to do so, then he's already in control of the system running the VM. This is what I don't understand. No amount of VM trickery will save you in that situation.
What the fuck are you talking about? Anyone can modify .class files after compilation with javac. This won't help you hack through a VM because, wait for it, the Java VM is secure - it can verify bytecode to make sure it doesn't violate any of the rules of its security manager. This is fundamentally impossible in C because it is weakly typed; this is why we have modern memory protection, among many other things, to prevent a badly behaved or malicious program from taking down the OS.

Are you confusing this with JIT compilation? If so, you're an idiot.

>>46
There. Happy now?
No, because it seems to have fuck-all to do with private variables anymore. Remember, that's what the discussion was about?

this is why we have modern memory protection, among many other things, to prevent a badly behaved or malicious program from taking down the OS.
You really don't have a clue, do you? Enjoy your ENTERPRISE SECURITY SOLUTION, if you must, but please promise me you'll never, ever get into language design or implementation.

>>46
this is why we have modern memory protection, among many other things, to prevent a badly behaved or malicious program from taking down the OS.

And what is this ``modern memory protection'' written in?

I thought so.

>>1,8
struct { ... }
WHERE IS YOUR SEMI-COLON AT THE END OF STRUCT DEFINITION?

modern memory protection considered harmful

>>46
This won't help you hack through a VM because, wait for it, the Java VM is secure - it can verify bytecode to make sure it doesn't violate any of the rules of its security manager.
So the VM is impervious to any attacks because it relies on itself for security instead of the operating system it's running on? BRILLIANT!

>>49
I apologise sincerely.
>>21
I may actually go the whole way and do that. I really just wanted to try something different with this as a learning exercise; it worked, but quickly got clunky.

^{Everyone else, continue derailing this thread.}

>>52
_{Everyone else, continue derailing this thread.}
You should mention Xarn for that. ^Oh _snap!

IHBX

>>47
No, because it seems to have fuck-all to do with private variables anymore.
Of course it does. If the security context doesn't allow reflection, then there's no way to access private variables.

In contrast to C++, where you can #define private public and access them, or in C, simply do some pointer arithmetic to access the internals of a library. Java provides real, run-time guarantees that encapsulation won't be violated.

And what is this ``modern memory protection'' written in?
There are platforms that don't deal in this at all you know. There are literally Java hardware CPUs that run Java bytecode (or some equivalent transformation of it). Such CPUs and the OS that runs on them don't need memory protection for different processes; they can even all share the same heap, and yet they're perfectly isolated and secure, with no danger of buggy or malicious code violating encapsulation.

Aside from a hardware Java CPU (this is what a VM is simulating), this is actually how many J2ME and all BlackBerry phones work. They run a Java OS, and any third-party application you download just gets loaded into the VM and run alongside the OS. There's no memory space protection because there doesn't need to be; Java is secure against this.

http://en.wikipedia.org/wiki/Java_processor

>>55
Of course it does. If the security context doesn't allow reflection, then there's no way to access private variables.
Way to miss the point on a ridiculous level. Jesus fucking Christ.

>>55
So you're saying that private variables are good because they're secure, and you define secure as not being able to access private variables? Is that the gist of it?
No wonder you use Java.

My eyes, along with my bowels, are bleeding

62 Name: Anonymous 2011-02-04 17:52

---

Newer Posts

---

Don't change these.

Name:		Email:
Entire Thread Thread List