C to Java Byte Code

[Richard Herring]

[My apologies for accidental double post on comp.lang.c. Mr. Lutus is
now attempting to escape his embarrasment by silently changing follow-
ups.]

Since you're not discussing C++, please spare comp.lang.c++ the rest of
this thread.

Followups set.

 

[joe]

<C>
Is it undefined or unspecified? Annex J.1 in C99, page 488, lists "The
value of a union member other than the last one stored into", as
unspecified and refers to §6.2.6.1.

Errp, sorry my mistake. It's unspecified. There is an exception given
in 6.5.2.5 though.

Joe

 

[Paul Lutus]

Surely the question of if he can unify a java float with a java integer
is not important? The question is if his program can take a program
written in according the the c standard, compile that program, execute
it, and then produce the output the standard says.

Your argument seems to me to read the same as saying "You can't turn C
into assembler on X processor, as X processor doesn't support floating
point". Of course you can, you just emulate the floating point so that
the user cannot tell.

Yes, a point I made earlier, but the product doesn't support anything but
32-bit words, which means a few sample programs I submitted earlier didn't
create the expected results. So I wanted to see if we could establish this
point. If he is performing some internal gymnastics to make it seem as
though a union is present, there may be circumstances when it cannot
function correctly, in particular in Java where there is strict typing.

IOW he is saying unions are supported, but programs that include unions are
misbehaving. I wanted to see if we could get more details, which led to
some of the inquiries in this thread.

 

[Paul Lutus]

[My apologies for accidental double post on comp.lang.c. Mr. Lutus is
now attempting to escape his embarrasment by silently changing follow-
ups.]

typedef union abc
{ int x;
float y;
} a_union;

Of course it's a union. It has two members x and y which are in this
instance of different types, although that is by no means part of the
specification.

Yes, it is a union in C, but I am saying it is not a union in the Java
bytecode. You have made this appear to be the meaning of my statement by
concatenating two unconnected parts of posts, creating the illusion of a
sequence that was not present in the original.

This intentional misquote unermines your entire post. My statement is
clearly that, since Java doesn't support anything like a union, the product
doesn't create unions as its output, it can only read them from the C
source and then figure out what to do with them. What it produces in Java
bytecode is not a union. And, more to the point, what it does produce
behaves differently than the original C code does.

 

[Paul Lutus]

Azumanga wrote:

/ ...

He doesn't have to overlay a java float and a java integer in the same
memory space. He merely has to show whatever he has decided to represent
a C integer and a C floating point number in the same memory location.
Of course it would be more efficent if these were java floats and java
integers, but in no way is this necessary (for example the way I would
do this would be to use a less inefficent implementation just for
unions, and then native java variables for non-unions).

Yes, true, but the result needs to resemble the behavior of the original C
program. We haven't seen anything like that yet in the two submitted test
programs. The product creates results that differ, in large and small ways,
from the original C programs.

On that topic, here is the post containing the third test program:

<[email protected]>

This program uses techniques that are easily managed by C (as well as by
Java if written in Java), but will not produce the expected results if
translated by the product being discussed.

 

[Willem]

Paul wrote:
) Yes, it is a union in C, but I am saying it is not a union in the Java
) bytecode.

It doesnt *need* to be a union in the Java bytecode, you moron.

In case you hadn't noticed, if I compile a piece of C codes with unions
with, say, gcc, then the resulting assembly code does *not* have unions.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[E. Robert Tisdale]

Paul Lutus wrote:

[snip]

Hi Paul,

Welcome back to the comp.lang.c and comp.lang.c++ newsgroups.
I checked Google newsgroups.

http://groups.google.com/

You've been absent from comp.lang.c++ since October 20, 2003
and absent from comp.lang.c since May 30,2002.

No matter. Very little has changed since you've been gone.

 

[Willem]

Paul wrote:
) Yes, a point I made earlier, but the product doesn't support anything but
) 32-bit words, which means a few sample programs I submitted earlier didn't
) create the expected results.

The programs you submitted most certainly *did* create the expected
results. That the results were not what *you* expected is just because
you're either a troll or a moron.

If I used a normal C-compiler on a computer that had hardware with 32-bit
bytes, then the result would be the same as the result gotten with MPC.

Are you claiming that an ordinary C compiler on such hardware 'does not
support unions'?


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[E. Robert Tisdale]

you're either a troll or a moron.

Why not both?

Seriously, check Google groups

http://groups.google.com/

for articles about/by Paul Lutus.
And, once enlightened, consider your own behavior.

 

[Keith Thompson]

Newsgroups trimmed to comp.lang.c

[My apologies for accidental double post on comp.lang.c. Mr. Lutus is
now attempting to escape his embarrasment by silently changing follow-
ups.]

Keith Thompson wrote:
Paul Lutus <[email protected]> writes:

typedef union abc
{ int x;
float y;
} a_union;

2. This is not a union, it it two instances of the same variable.
Again, to reply to my post, you need to provide the Java bytecode that
unites a Java float and a Java integer in the same address space,
something that is not allowed in Java.

Of course it's a union. It has two members x and y which are in this
instance of different types, although that is by no means part of the
specification.

Yes, it is a union in C, but I am saying it is not a union in the Java
bytecode. You have made this appear to be the meaning of my statement by
concatenating two unconnected parts of posts, creating the illusion of a
sequence that was not present in the original.

Ok, it's not a union in the Java bytecode because there's no such
thing as a union in Java bytecode. For a C compiler that generates,
say, x86 machine code, there will be no union in the generated code
because there's no such thing as a union in x86 machine code. A union
is a C construct; it's the compiler's job to generate code for the
target system that implements the union. As far as I can tell, the
compiler in question does exactly that. (Details about what the Java
bytecode looks like might be interesting, but are off-topic here.)

This intentional misquote unermines your entire post. My statement is
clearly that, since Java doesn't support anything like a union, the product
doesn't create unions as its output, it can only read them from the C
source and then figure out what to do with them.

Yes, that's exactly what a compiler does.

And just to make the distinction clear, what the Java language
supports is irrelevant; we're talking about what Java bytecode
supports. The language and the bytecode are two different things, and
it's unfortunate that the same name is used for both. They were
designed together, but Java can be compiled to forms other than Java
bytecode, and languages other than Java can be compiled to Java
bytecode.

What it produces in Java
bytecode is not a union.

Of course not; I wouldn't expect it to be.

And, more to the point, what it does produce
behaves differently than the original C code does.

C code by itself has no behavior until it's compiled and executed.
The behavior of a C program that writes to one member of a union and
then reads from another member of the same union is, except in some
limited cases, undefined. And, more to the point, the behavior
indicated by Mohd Hanafiah Abdull several articles upthread was
consistent between MPC and gcc (except for some extra trailing zeros;
I'm not sure which one is correct there, but it's beside the point).

Again, here's the output he posted:

] MPC produced:
] int val = 1078531719
] float val = 3.142
] int val = 1078531719
] float val = 3.142
]
] gcc produced:
] int val = 1078531719
] float val = 3.142000
] int val = 1078531719
] float val = 3.142000

I got the same results myself using gcc on an x86 system; it's
consistent with overlaying a 32-bit integer with a 32-bit IEEE
floating-point value.

So, what exactly were you complaining about?

 

[Mark McIntyre]

Yes, it is a union in C, but I am saying it is not a union in the Java
bytecode.

Marvellous. Since this has nothing to do with C any more, why the heck are
you stupidly crossposting this long and pointless thread in CLC and CLC++.
Go away.

 

[E. Robert Tisdale]

Marvellous. Since this has nothing to do with C any more,
why the heck are you stupidly crossposting this long and pointless thread
in CLC and CLC++.
Go away.

Why are you responding to a post
that you obviously think is a troll?
Honestly,
I don't see any difference between you and Paul Lutus
and I don't know which one of you is worse
I think that you are both trolls
and I'll bet that most other subscribers think so too.

 

[Old Wolf]

Show us the bytecode that overlays a Java float and a Java integer into the
same memory space. That is what a union is.

Sorry, you are wrong. There is no requirement in the C standard for
the members of the union to occupy the same piece of memory.
If you disagree then please quote a standard reference.
(They must all return the same thing when their address is
taken and then converted to (void *), but it does not follow
from that that they occupy the same physical memory).

Show us the Java bytecode that allows one to manipulate
individual bits of a Java float datatype, as a C union allows.

A C union does not allow that. Any C program that
relies on it is non-portable.

The following results are conforming to the C specification
(note, this is a minor modification of a program posted
elsewhere in the thread):

#include <stdio.h>

typedef union abc
{ int x;
float y;
} a_union;

main()
{ a_union z;

z.x = 1;
printf("int val = %d\n", z.x);
printf("float val = %f\n", z.y);

z.y = 3.142;
printf("int val = %d\n", z.x);
printf("float val = %f\n", z.y);
return 0;
}

Results:
int val = 1
float val = 3.142
int val = 1
float val = 3.142

 

[Keith Thompson]

Newsgroups trimmed to comp.lang.c.

Sorry, you are wrong. There is no requirement in the C standard for
the members of the union to occupy the same piece of memory.
If you disagree then please quote a standard reference.
(They must all return the same thing when their address is
taken and then converted to (void *), but it does not follow
from that that they occupy the same physical memory).

I'm not so sure about that. Since any object can be viewed as an
array of unsigned char, I think it follows that objects at the same
address (pointer equality is well defined) must occupy the same
memory.

For example, given

volatile union {
int i;
float f;
} obj;

you can expect that storing a value to obj.i will change the
representation (viewed as an array of unsigned char) of obj.f, and
vice versa, even though examining the values themselves would invoke
undefined behavior.

Even if an implementation can somehow make union members occupy
disjoint pieces of memory without violating the standard, that would
be a perverse thing to do. It's fairly clear that union members are
*intended* to occupy the same memory.

In any case, Paul Lutus's error is in insisting that Java floats and
Java integers are somehow relevant to this discussion. Java bytecode
floats and integers (assuming Java bytecode defines such things; I
don't know whether it does are not) *might* be relevant; if that's
what Paul means, he should make that clear. But even if so, there's
no requirement that a C compiler targetting Java bytecode has to use
any particular construct; it just has to implement C's semantics.

 

[Paul Lutus]

Paul wrote:
) Yes, a point I made earlier, but the product doesn't support anything
but ) 32-bit words, which means a few sample programs I submitted earlier
didn't ) create the expected results.

The programs you submitted most certainly *did* create the expected
results.

False. For both programs, the result was not the intended, design output,
the result one gets on a standard, contemporary C compiler.

You know, you cannot argue facts away. This is not philosophy and it is not
a tea party. You cannot twist the truth into a knot, then claim victory.

That the results were not what *you* expected is just because
you're either a troll or a moron.

Thank you for moving to your area of conpetence so swiftly. Do you think the
readers of this newsgroup will find this useful, despite it being false?

Are you claiming that an ordinary C compiler on such hardware 'does not
support unions'?

No, you are. I have never said this, and you have used this exact same
tactic on countless occasions -- invent a position someone has never taken,
then argue with it. This is called "onanism". Don't wear yourself out.

 

[Paul Lutus]

Marvellous. Since this has nothing to do with C any more,

Do you see a reference to C in the sentence above? No? Is there an
optometrist available in your neighborhood?

The discussion is about a C to Java cross-compiler. Both languages are
therefore topical.

why the heck are
you stupidly crossposting this long and pointless thread in CLC and CLC++.

The OP, an unscrupulous, predatory commercial vendor, created this
cross-posted thread. If you don't like it, argue with him.

Go away.

Do the world a favor. Killfile Usenet.

 

[Paul Lutus]

Paul wrote:
) Yes, it is a union in C, but I am saying it is not a union in the Java
) bytecode.

It doesnt *need* to be a union in the Java bytecode, you moron.

The claim made by Mr. Abdullah is that unions are supported by his product.
Since unions are already supported in C, this can only mean his claim
refers to Java. But Java does not support unions, and you cannot force Java
to accept anything resembling a union. What you can do is switch data back
and forth using existing getter and setter methods for some data types, but
this masquerade will not always work, as has been shown in this and the
prior thread.

In case you hadn't noticed, if I compile a piece of C codes with unions
with, say, gcc, then the resulting assembly code does *not* have unions.

In case you haven't noticed, you have lost the ability to post anything of
any use to anyone. This is why you find it necessary to leave the topic
with such regularity -- it induces in your fingers a belief that your brain
is still online.

 

[Paul Lutus]

Sorry, you are wrong. There is no requirement in the C standard for
the members of the union to occupy the same piece of memory.

I never said it was a requirement. What I said is quoted clearly above your
targetless demurrer.

If you disagree then please quote a standard reference.

http://explanation-guide.info/meaning/C-language-union.html

"Because they occupy the same space, changing u.a also changes the value of
u.b."

"The primary usefulness of a union is to conserve space, since it provides a
way of letting many different types be stored in the same space."

There are plenty of similar references, but beyond this, I am not going to
waste my time disabusing you of your misconception. I am sure that, were
you inclined, you could find and read your own definitions.

(They must all return the same thing when their address is
taken and then converted to (void *), but it does not follow
from that that they occupy the same physical memory).

This is not required, but then, that claim was never made.

A C union does not allow that.

It certainly does.

Any C program that
relies on it is non-portable.

Non sequitur. It is a question of syntactic correctness, not portability.

 

[Mohd Hanafiah Abdullah]

/ ...


A union is two or more disparate variable types that share the same memory
space. Because of its strong data typing, Java simply doesn't allow this.
As a result, the program in question has to jump through hoops to pretend
to support a union such as is imagined to exist in the above examples and
those I provided earlier.

This is why I asked to see the Java bytecode, and this is why Mr. Abdullah
refused my request.

You can do it yourself by downloading the package, but you have already said
you wouldn't. Anyway, the effect of our implementation is a union.

Napi

 

[Thomas G. Marshall]

Willem coughed up:

....[rip]...

I assume you understood that perfectly and, unable to respond to the
actual argument, chose this ad hominem approach instead.
....[rip]...

You must be trolling, [...]

I don't believe that he is trolling per se, but you should recognize his
descent into insulting attacks and hand-waving as his standard MO and place
him in your killfile asap.

....[rip]...