[OT]Re: C to Java Byte Code

G

goose

<snipped>

I think that you have lost the plot here. The consensus here (CLC)
seems to be that if the product under discussion is able to read the
posted code (upthread) and produce java bytecode that works as
expected (including the UB), then there is, in fact, a great possibility
of the product working as advertised.

You seem to be having difficulty imagining java bytecode that
could possibly implement a union (nevermind how many hoops it has to
jump through); I suspect that its merely very difficult and/or
tedious to do, but not impossible.

You would be wise to stop your argument in this area, for reasons all
the other posters (KT et al) pointed out.

</clue>

goose,
my 0.02c worth
 
M

Malcolm

goose said:
You seem to be having difficulty imagining java bytecode that
could possibly implement a union (nevermind how many hoops it has to
jump through); I suspect that its merely very difficult and/or
tedious to do, but not impossible.
I don't know anything about Java bytecode. However a C union may be legally
implemented as a consecutive series of structs. If Java bytecode supports
structs at all then it is difficult to see how unions are unimplementable.
 
P

Paul Lutus

goose said:
<snipped>

I think that you have lost the plot here.

The "plot" is about the behavior of a cerrtain product, versus the claims
for that product. Consensus doesn't cancel evidence.
The consensus here ...

How did I know that would be what you believed "evidence" consisted of?
(CLC)
seems to be that if the product under discussion is able to read the
posted code (upthread) and produce java bytecode that works as
expected ...

This premise is contradicted by the evidence. Read the threads, find the
evidence. Three example prorgams, each fails in large or small ways.
(including the UB), then there is, in fact, a great possibility
of the product working as advertised.

Your premise is flawed, therefore your conclusion. It doesn't work on the
provided example programs, and it certainly cannot meet its claims. Three
posted examples, score 0.
You seem to be having difficulty imagining java bytecode that
could possibly implement a union

No, Java has that problem, not me.
(nevermind how many hoops it has to
jump through); I suspect that its merely very difficult and/or
tedious to do, but not impossible.

You suspect it may not be impossible? What a persuasive argument. The facts
are that the product cannot parse and reproduce the output from the three
provided example programs. Which part of the ascendancy of evidence over
logorrhea bothers you?
You would be wise to stop your argument in this area, for reasons all
the other posters (KT et al) pointed out.

1. "All the other posters" is a lie, and it is also argumentum ad populum.
You are only allowed one strike and you have racked up two.

2. You started a new thread to make this bogus announcement? How does this
achieve what you claim to want?

Want to see the end of this uprooductive discussion? Stop posting about it.
I had already done that, until I saw your valiant effort to keep alive
something you claim to want to see dead.
 
A

Alan Balmer

No, Java has that problem, not me.

You are apparently still missing the point that Java and java bytecode
are not the same thing. Java compiles to java bytecode, just as C can
compile to assembler. Other languages can also compile to java
bytecode.
 
C

Chris Torek

I don't know anything about Java bytecode. However a C union may be legally
implemented as a consecutive series of structs. ...

This may be the case; however, a C compiler must produce 0 for the
result of offsetof() on any union type and member:

union U {
char a;
int b;
float c;
double d;
struct S { int i[10]; } e;
};
...
assert(offsetof(union U, a) == 0);
assert(offsetof(union U, b) == 0);
assert(offsetof(union U, c) == 0);
assert(offsetof(union U, d) == 0);
assert(offsetof(union U, e) == 0);

Note that offsetof(union U, e.i[2]) is *not* zero (assuming this
is even a valid expression -- whether it is, is not entirely clear
to me offhand, although I have never seen it fail myself), but e.i
is not what I would mean by "a member of union U": e is a member
of union U, but i is a member of struct S. (This is why it is not
clear to me whether offsetof(union U, e.i[2]) has to be accepted
at all. The C99 draft I have describes the second argument of
offsetof() as a "member-designator", but never defines member-designator
formally.)
 
P

Paul Lutus

Alan said:
You are apparently still missing the point that Java and java bytecode
are not the same thing.

If by "Java" you mean Java source, they are most certainly the same thing.
If this were not true, the elaborate security and other features of Java
could be circumvented by someone willing to turn raw bytecode into
programs. Also, the utility "javap" would not be able to sort out the
bytecode and convert it into a sort of Java source, but ... this never
happens.

Because of the rather elaborate Java security system, in particular that
part taking effect when running an applet in a Web page, there is
absolutely no way one could simply bypass Java's built-in behavioral
constraints by hand-assembling bytecode.

But prove me wrong. Find a counterexample. I assure you, were an example to
be found in which Java bytecode is not representable as Java source in any
significant way, it would be headlines the following morning.
Java compiles to java bytecode, just as C can
compile to assembler. Other languages can also compile to java
bytecode.

Yes, and all those other programs (like the present discussed example) must
adhere to all Java's rather strict rules, and then must pass muster with
the runtime engine.

I never saw more people, as they say, swallowing a camel while straining at
a gnat. The three example programs I submitted do not function as designed
when converted using the product under discussion. The OP's candid
acknowledgments of various technical difficulties posted here are still not
reflected in his Website's marketing-hype prose.

The argument seems to be "Well, it *could* work!" Yes, it could, apart from
the discouraging test results and the choice to shoehorn everything into
32-bit words. On that general topic, bytes might be assumed to always be 32
bits, doubles might be regarded as an unnecessary encumbrance, and so
forth. All possibilities, all equally empty arguments.

Now, again, let's stop this unproductive exchange.
 
G

Galga

Paul said:
If by "Java" you mean Java source, they are most certainly the same
thing.

No, you simp, they are nto the same thing. *Java Byte Code* is the
compiled PRODUCT of Java Source. javac MyClass.java compiles that source
to MyClass.class which is Byte code. Saying the source and compiled
result are the same is the same as saying c source and a compiled c
executable are the same thing. It makes ZERO sense to say that. One Is
the *result* of the other.
If this were not true, the elaborate security and other
features of Java could be circumvented by someone willing to turn raw
bytecode into programs.

Um.., no; see above.

(...snip drivel...)
Now, again, let's stop this unproductive exchange.

Yeah, now that you've made a complete fool of your self, you want ot
hide. How typical of you.
 
G

Galga

Chris said:
I don't know anything about Java bytecode. However a C union may be
legally implemented as a consecutive series of structs. ...

This may be the case; however, a C compiler must produce 0 for the
result of offsetof() on any union type and member:

union U {
char a;
int b;
float c;
double d;
struct S { int i[10]; } e;
};
...
assert(offsetof(union U, a) == 0);
assert(offsetof(union U, b) == 0);
assert(offsetof(union U, c) == 0);
assert(offsetof(union U, d) == 0);
assert(offsetof(union U, e) == 0);

This wouldnt compile on eoither a solaris, a linux, or a win32 system.
Note that offsetof(union U, e.i[2]) is *not* zero (assuming this
is even a valid expression -- whether it is, is not entirely clear
to me offhand, although I have never seen it fail myself), but e.i
is not what I would mean by "a member of union U": e is a member
of union U, but i is a member of struct S. (This is why it is not
clear to me whether offsetof(union U, e.i[2]) has to be accepted
at all. The C99 draft I have describes the second argument of
offsetof() as a "member-designator", but never defines
member-designator formally.)

I could be wrong, but I do believe the standards allow to be something
other than zero; ie it's not required.
 
G

Galga

Paul said:
The "plot" is about the behavior of a cerrtain product, versus the
claims for that product. Consensus doesn't cancel evidence.

You are an idiot. You refuse to accept any points made. So for the last
time: BYTE CODE != JAVA SOURCE. Byte Code is the PRODUCT of compiled
Java Source. WTF is it you do not udnerstand about this?

The product says it will compile into Java Byte Code, Not, I repeat,
NOT, Java Source; Those are two COMPLETELY seperate tasks. Get it right
or shut up Paul, because you're jsut diggering your own usenet grave
deeper and deeper.
 
C

Chris Torek

(I have no idea why you redirected this back to the C++ and Java
groups; even in comp.programming it seems a bit far afield, as it
were.)
Chris said:
... a C compiler must produce 0 for the result of offsetof() on any
union type and member:

union U {
char a;
int b;
float c;
double d;
struct S { int i[10]; } e;
};
...
assert(offsetof(union U, a) == 0);
assert(offsetof(union U, b) == 0);
assert(offsetof(union U, c) == 0);
assert(offsetof(union U, d) == 0);
assert(offsetof(union U, e) == 0);

This wouldnt compile on eoither a solaris, a linux, or a win32 system.

You will need to turn the above into a complete program, e.g.:

% cat t.c
#include <assert.h>
#include <stddef.h>
#include <stdio.h>

union U {
char a;
int b;
float c;
double d;
struct S { int i[10]; } e;
};

int main(void) {
assert(offsetof(union U, a) == 0);
assert(offsetof(union U, b) == 0);
assert(offsetof(union U, c) == 0);
assert(offsetof(union U, d) == 0);
assert(offsetof(union U, e) == 0);
puts("success");
return 0;
}
% cc -O -Wall -W -o t t.c
% ./t
success
% cc -v
[snippage]
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-34)
I could be wrong, but I do believe the standards allow [the offset]
to be something other than zero; ie it's not required.

This has to be constructed, but I think this sentence in the C99
draft I am using, section 6.5.2.1 ("Structure and union specifiers"),
paragraph 13, is the (or at least a) key one:

A pointer to a union object, suitably converted, points to each
of its members (or if a member is a bit-field, then to the unit
in which it resides), and vice versa.

Note that paragraph 12 immediately before this includes the lines:

A pointer to a structure object, suitably converted, points to
its initial member (or if that member is a bit-field, then to
the unit in which it resides), and vice versa. There may be
unnamed padding within a structure object, but not at its
beginning.

Given "struct S *p" whose initial member has type T, (T *)p is a
pointer to p->initial_member, i.e., (T *)p == &p->initial_member.
The definition of offsetof() is that it produces the offset
in bytes. Hence:

/* assume we already have: struct S { T initial_member; ... } *p; */
unsigned char *uc_p;
T *im_p;
T *offset_p;
unsigned char *im_p_as_uc;

im_p = &p->initial_member; /* straightforward */
im_p_as_uc = (unsigned char *)im_p; /* also straightforward */
uc_p = (unsigned char *)p; /* converted from "ptr to S" */
assert(uc_p == im_p_as_uc); /* required by paragraph 12 */

uc_p += offsetof(struct S, initial_member);
assert(uc_p == im_p_as_uc); /* still required by paragraph 12 */

Clearly if neither assert() may fail, uc_p has not moved, so
offsetof() produced 0.

The same technique can be applied to each union member to show that
it, too, must have its offsetof() being zero. The ultimate difference
between "struct" and "union" is that a struct's members are at
successively larger offsets, as determined by the size of each
previous member plus any post-member padding, while a union's
members are all at offset 0.
 
J

Joona I Palaste

Galga <[email protected]> scribbled the following
No, you simp, they are nto the same thing. *Java Byte Code* is the
compiled PRODUCT of Java Source. javac MyClass.java compiles that source
to MyClass.class which is Byte code. Saying the source and compiled
result are the same is the same as saying c source and a compiled c
executable are the same thing. It makes ZERO sense to say that. One Is
the *result* of the other.

I do not believe Paul meant to say that Java source code and Java
byte code are the exact same thing and interchangable with each other.
I think what he meant was more like that they are so closely "tied" to
each other that it is difficult to produce Java byte code from anything
other than Java source code.
Um.., no; see above.

Please explain how the fact that Java source code and Java byte code
are not the exact same thing allows the elaborate security and other
features of Java to be circumvented. As Paul said, just try to prove
him wrong. Try to change Java byte code directly and get a runnable
class file that circumvents the Java security system.

(Snip personal insults)
 
G

Gerry Quinn

I never saw more people, as they say, swallowing a camel while straining at
a gnat. The three example programs I submitted do not function as designed
when converted using the product under discussion.

Since the code resulting from C unions functions as *written*, the above
speaks only of the incompetence of the designer.

Absence of a large bandwidth double is a minor issue, which will likely
be corrected in future versions if the product is successful, and in any
case satisfies the criterion of "with some tweaking".

On this thread you have demonstrated only egotism, incompetence,
dishonesty, and (worst) vicious and unjustified bile directed at the
developers of a novel and seemingly useful product.

- Gerry Quinn
 
C

Chris Dollin

Galga said:
The product says it will compile into Java Byte Code, Not, I repeat,
NOT, Java Source; Those are two COMPLETELY seperate tasks. Get it right
or shut up Paul, because you're jsut diggering your own usenet grave
deeper and deeper.

I must point out that Java bytecodes *that pass the bytecode verifier*
can almost always be back-translated to Java methods, and that the
exceptions (that I know of) are trivial [1] rather than interesting.

So, while Paul may be wrong, I don't think it's for that reason.

[1] I don't think the verifier complains about unreachable code, nor
about code-not-involving-this before the superconstructor gets
called; directly expressed in Java these provoke diagnostics.
 
C

Chris Dollin

Chris said:
Galga wrote:

[OT-in-CLC-stuff snipped]

I'd like to apologise for not reading the newsgroups line
carefully; *someone* had included comp.lang.c[++] as well
as comp.programming (where I read & responded to it) and
alt.sex.gay (for what I can only assume are trollish reasons).
 
D

Dik T. Winter

> Galga wrote:
>
> > The product says it will compile into Java Byte Code, Not, I repeat,
> > NOT, Java Source; Those are two COMPLETELY seperate tasks. Get it right
> > or shut up Paul, because you're jsut diggering your own usenet grave
> > deeper and deeper.
>
> I must point out that Java bytecodes *that pass the bytecode verifier*
> can almost always be back-translated to Java methods, and that the
> exceptions (that I know of) are trivial [1] rather than interesting.
>
> So, while Paul may be wrong, I don't think it's for that reason.

Of course Paul is wrong (the compiler emulates all C types using Java
integers), and indeed not for that reason. You can translate it back
to Java, where all C types are still emulated using Java integers.
 
T

Thomas Stegen

Dik said:
Of course Paul is wrong

He does not know that, and he probably never will. He seems to have some
sort of disease. He is now doing defense by redefinition of original
position.
 
A

Alan Balmer

If by "Java" you mean Java source, they are most certainly the same thing.
If this were not true, the elaborate security and other features of Java
could be circumvented by someone willing to turn raw bytecode into
programs.

That's true. There's nothing that prevents one developing an evil jvm.
 
O

Old Wolf

I should mention that this is not a particularly
odd thing to claim; MS's C++.net can compile C or C++
into a bytecode which I understand is not majorly different
to Java bytecode.
I must point out that Java bytecodes *that pass the bytecode verifier*
can almost always be back-translated to Java methods

So if this compiler does what it claims, then we have a
method for transforming conforming C source into Java source
and it still runs correctly. I wonder if the converse is
possible? (converting a Java program to a conforming C
program that runs correctly).
 
G

goose

Chris Dollin said:
Galga said:
The product says it will compile into Java Byte Code, Not, I repeat,
NOT, Java Source; Those are two COMPLETELY seperate tasks. Get it right
or shut up Paul, because you're jsut diggering your own usenet grave
deeper and deeper.

I must point out that Java bytecodes *that pass the bytecode verifier*
can almost always be back-translated to Java methods, and that the
exceptions (that I know of) are trivial [1] rather than interesting.

<WARNING: Clueless about java bytecode>
ISTR that the mnemonics(sp?) that I've seen for java have
seperate instructions for working with different primitive
types.

So, assuming an "uc_push" and "uc_pop" instruction
for "push unsigned char on stack" and "pop unsigned char
from stack" respectively, and "f_push" and "f_pop" for
the floating point equivalents, it then follows that
the union code that paul posted can be trivially written
in java bytecode.

f_push 3.14
uc_pop first_byte
uc_pop secnd_byte
uc_pop third_byte
uc_pop forth_byte

Now I really am curious, is there anyone here (maybe the OP
who created the c->java bytecode product) who can verify
that the JVM does indeed work as I think it does?
So, while Paul may be wrong, I don't think it's for that reason.

[1] I don't think the verifier complains about unreachable code, nor
about code-not-involving-this before the superconstructor gets
called; directly expressed in Java these provoke diagnostics.


Yes, but will it complain about code like above (if above
code is actually java bytecode).

goose,
WTH was this crossposted to alt.sex.gay?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,776
Messages
2,569,603
Members
45,189
Latest member
CryptoTaxSoftware

Latest Threads

Top