C to Java Byte Code

[Thomas G. Marshall]

CBFalconer coughed up:

His problem is extremely simple - stop using a non-standard quote
character. The standard is '>', not ')'.

I agree---there might be news readers that otherwise offer the ability to
reformat replied indented paragraphs into non-broken lines. Furthermore,
/most/ offer the ability to color the paragraphs based upon indent level,
making it much easier to read, like OE_QuoteFix does for my OE.

This ")" business is a rude train wreck.

 

[Thomas G. Marshall]

Old Wolf coughed up:

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).


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;

First example:

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

Second example:

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

How does the mini-PI come out of a union (first example) that was only set
with integer 1?

How does a 1 get pulled out of a union set with a value of mini-PI? A
/structure would do that at this point, since .x was set to 1, but not a
union.

Unless I'm going nuts here (possible)...

 

[Thomas G. Marshall]

Thomas G. Marshall coughed up:

Old Wolf coughed up:

First example:

Second example:


How does the mini-PI come out of a union (first example) that was
only set with integer 1?

How does a 1 get pulled out of a union set with a value of mini-PI? A
/structure would do that at this point, since .x was set to 1, but
not a union.

Unless I'm going nuts here (possible)...

What I mean is, /unless the integer 1 representation happens to match a
float's mini-PI's bit pattern/...

 

[CBFalconer]

.... snip ...

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.

Not only that but some mentally challenged posters insist on
restoring the mess when follow-ups have been set.

 

[Richard Bos]

C code by itself has no behavior until it's compiled and executed.

Or interpreted.

Richard

 

[Richard Herring]

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.

Not in comp.lang.c++, they are not. Please take this elsewhere.

 

[Richard Herring]

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.

Please don't trollishly crosspost between C and C++ groups. The outcome
is rarely beneficial.

 

[chris]

Gerry Quinn wrote:

[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.

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.

The C standard says nothing about "Java bytecode" or anything else
similar. All that matters is that this system takes a C program and if
it is valid according to the C standard then it produces the required
output. How the union is actually represented in whatever the program is
transformed into (java bytecode in this case) should be a) invisable to
the user and b) not important to the user.

It appears to me that this system can take a C program with a union and
then execute it as required by the C standard. What else could possibly
be required?

Chris

 

[chris]

Willem wrote:




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

There is an important seperation to make here.

I believe all MPC claims to do is "implement the C standard". This
appears to be slightly different from what you appear to want to it do,
which is produce the same result one gets on a "standard, contemporary C
compiler". In particular any code which writes to one variable in a
union and then reads from another is in the world of undefined
behaviour, and so how such a program is executed should not enter the
discussion.

Chris

 

[Gerry Quinn]

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

How could it be a union in the Java bytecode? Java bytecode doesn't
have unions, any more than machine code does. Unions are a feature of
C. The compiler compiles bytecode from C source. The C source may
contain unions. The bytecode doesn't, any more than a conventional
executable would.

This intentional misquote unermines your entire post. My statement is

There was no misquote.

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.

No C compiler creates unions as its output. How could it? The target
platforms, be they bytecode or machine code, don't have unions. What it
produces behaves perfectly in accordance with the specifications of the
C language.

Your program even works quite well, except that it investigates data
storage on the "C-emulation platform" that is created by the compiler.
If the results surprise you, that is your problem. The C language
specification does not say what will be investigated, or even promise
that anything consistent will be. If you expect that the program should
give identical results to a standard executable if the bytecode is run
on the same platform, that expectation arises only because you don't
understand C. Suppose another program measured the time to do a long
calculation - would you expect the same result on that too? There is no
difference.

- Gerry Quinn

 

[Gerry Quinn]

Willem wrote

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.

That is just lunacy. His product is a C compiler, of sorts. It
converts statements that reference unions consistently into bytecode.
Therefore it supports unions.

It supports unions in much the same way that (say) MSVC supports unions,
by converting statements that reference unions consistently into object
code.

Neither object code nor bytecode have unions. Unions are a feature of
C. Put C source containing unions into a compiler, turn the handle, and
object code comes out that doesn't contain unions. It is *influenced*
by the union declarations in the source code, but it contains no unions
because unions do not exist in object code.

- Gerry Quinn

 

[dandelion]

That is just lunacy. His product is a C compiler, of sorts. It
converts statements that reference unions consistently into bytecode.
Therefore it supports unions.

It supports unions in much the same way that (say) MSVC supports unions,
by converting statements that reference unions consistently into object
code.

Neither object code nor bytecode have unions. Unions are a feature of
C. Put C source containing unions into a compiler, turn the handle, and
object code comes out that doesn't contain unions. It is *influenced*
by the union declarations in the source code, but it contains no unions
because unions do not exist in object code.

- Gerry Quinn

So if I read from a stream of data, I can overlay a set of nested
structs/unions in order to decypher the byte-array into a structured
message? As in the following?

typedef struct
{
uint8 inputs;
uint8 outputs;
uint8 timers;
} lc_statr_t;

typedef struct
{
uint8 errno;
char message[1];
} lc_error_t;

typedef struct
{
uint8 opcode;
uint8 sequence;
} lc_msg_header_t;

typedef struct
{
lc_msg_header_t hdr;

union
{
lc_statr_t statr;
lc_error_t error;

uint8 cmd[LC_CMD_LEN]; /* placeholder */
char name[LC_NAME_LEN];
} data;
} lc_msg_t;

typedef struct
{
uint32 addr; /* originating ip_address */
uint16 port; /* originating port */
uint16 len; /* length of the packet */
} lc_packet_header_t;

typedef struct
{
lc_packet_header_t hdr;

union
{
lc_msg_t msg;
lc_tftp tftp;
char buffer[LC_BUFFERSIZE];
} u;
} lc_packet_t;

lc_packet_t.buffer is read (recv) and I can use lc_packet_t.msg.hdr.opcode
to get at the opcode? Without actually moving *anything* in memory, of
course, since I don't have enough RAM available.

 

[Flash Gordon]

On Wed, 27 Oct 2004 13:06:51 +0200

So if I read from a stream of data, I can overlay a set of nested
structs/unions in order to decypher the byte-array into a structured
message? As in the following?

typedef struct
{
uint8 inputs;

The compiler might insert padding here...

uint8 outputs;

or here...

uint8 timers;

or here.

} lc_statr_t;

Well, in C you might not have an 8 bit data type, which is presumably
what uint8 is...

typedef struct
{
uint8 errno;

The compiler might insert different padding here to that which it might
(or might not) have inserted in lc_statr_t

char message[1];
} lc_error_t;

typedef struct
{
uint8 opcode;
uint8 sequence;
} lc_msg_header_t;

I believe that lc_msgs_header_t is required to map correctly on to the
first 2 elements of lc_statr_t when they are combined in a union since
the first two elements are the same type.

typedef struct
{
lc_msg_header_t hdr;

union
{
lc_statr_t statr;
lc_error_t error;

uint8 cmd[LC_CMD_LEN]; /* placeholder */
char name[LC_NAME_LEN];
} data;
} lc_msg_t;

typedef struct
{
uint32 addr; /* originating ip_address */
uint16 port; /* originating port */
uint16 len; /* length of the packet */
} lc_packet_header_t;

typedef struct
{
lc_packet_header_t hdr;

union
{
lc_msg_t msg;
lc_tftp tftp;
char buffer[LC_BUFFERSIZE];
} u;
} lc_packet_t;

lc_packet_t.buffer is read (recv) and I can use
lc_packet_t.msg.hdr.opcode to get at the opcode? Without actually
moving *anything* in memory, of course, since I don't have enough RAM
available.

*If* your compiler pads structs in the way your incoming data is padded
then I believe that you will get what you expect. However, version x.1
of your compiler might use different padding, and changing compiler
options might change the padding. So it is not a portable solution.
Also, if you had a double in there you would have a real danger of
reading a trap representation.

So if you want portable code you have to strip your message apart by
hand.

 

[Gerry Quinn]

Neither object code nor bytecode have unions. Unions are a feature of
C. Put C source containing unions into a compiler, turn the handle, and
object code comes out that doesn't contain unions. It is *influenced*
by the union declarations in the source code, but it contains no unions
because unions do not exist in object code.

So if I read from a stream of data, I can overlay a set of nested
structs/unions in order to decypher the byte-array into a structured
message? As in the following?

typedef struct
{
uint8 inputs;
uint8 outputs;
uint8 timers;
} lc_statr_t;
[etc.]

lc_packet_t.buffer is read (recv) and I can use lc_packet_t.msg.hdr.opcode
to get at the opcode? Without actually moving *anything* in memory, of
course, since I don't have enough RAM available.

I don't see why not, so long as you have reason to believe that the
conversion of disparate types within a union (undefined in C) is
consistent for a given implementation [seems to be in this case, and
probably would be on most conventional hardware], that the storage of
relevant data types does not appear as padding in the storage of others
[you will want to check on that, I think], and that you are capable of
identifying the opcode corresponding to the reinterpretation of one or
more chars or part of chars into whatever you have defined as uint8.

I recommend, however, that you do not rely so heavily on undefined
behaviour. If you intend to read a series of chars, it would be a good
idea to define your opcodes or whatever in terms of chars. Then you
need have no fears that your code will give unpredictable results on
different implementations.

- Gerry Quinn

 

[dandelion]

Neither object code nor bytecode have unions. Unions are a feature of
C. Put C source containing unions into a compiler, turn the handle, and
object code comes out that doesn't contain unions. It is *influenced*
by the union declarations in the source code, but it contains no unions
because unions do not exist in object code.

So if I read from a stream of data, I can overlay a set of nested
structs/unions in order to decypher the byte-array into a structured
message? As in the following?

typedef struct
{
uint8 inputs;
uint8 outputs;
uint8 timers;
} lc_statr_t;
[etc.]

lc_packet_t.buffer is read (recv) and I can use lc_packet_t.msg.hdr.opcode
to get at the opcode? Without actually moving *anything* in memory, of
course, since I don't have enough RAM available.

I don't see why not, so long as you have reason to believe that the
conversion of disparate types within a union (undefined in C) is
consistent for a given implementation [seems to be in this case, and
probably would be on most conventional hardware], that the storage of
relevant data types does not appear as padding in the storage of others
[you will want to check on that, I think],

I checked. I'm on an 8 bit platform, so padding isn't an issue.

and that you are capable of
identifying the opcode corresponding to the reinterpretation of one or
more chars or part of chars into whatever you have defined as uint8.

typedef unsigned char uint8;

I recommend, however, that you do not rely so heavily on undefined
behaviour.

Which undefined behavior? If you knew the compiler i'm using, you'd
(probably) laugh your arse off thinking of "undefined behavior". It is
(putting it mildly) not very conforming. In fact, it isn't even C, just
(vaguely) C-like. However, the structure as presented in my previous post is
what's running (more or less) on the host aswell. Although padding *is* an
issue (a tackled one) there.

If you intend to read a series of chars, it would be a good
idea to define your opcodes or whatever in terms of chars.

I intend to read a structured message coming in from a UDP connection
and/or a RS485 serial line (allthough the latter uses a slightly different
definition on the lowest level). So, no... There's no naked 'char' in sight,
only a number of 8-bit values (in order to avoid endianness issues). That's
why I defined everything using uint8 (which is typedeffed as an unsigned
char). The chances of any of the uint8's mentioned containing anything
printable is not very big.

Then you
need have no fears that your code will give unpredictable results on
different implementations.

Does the 'Byte-code compiler' of the OP move memory or not? As previously
mentioned, the intended platform is a micro-controller in an embedded
environment.

 

[dandelion]

Question restracted. Thanks for the cooperation.

 

[Michael Wojcik]

Intentions and program design have nothing to do with whether a C
implementation is conforming.

Nonsense. There are contemporary conforming C implementations where
CHAR_BIT is not 8. Thus your first example, at least, does not
produce consitent results on at least some "standard, contemporary C"
implementations, and can safely be ignored.

There is an important seperation to make here.

The only important fact is that Paul is arguing that MPC does not
implement a language of his own specification, which appears to be
something vaguely like ISO standard C plus various restrictions on
implementation-defined and unspecified behavior (and possibly on
undefined behavior as well). That is true, but it is also irrelevant
to his claim, which is that MPC is not a conforming C implementation.

Apparently Paul is unwilling or unable to distinguish between "C" and
"C as Paul would like it to be".

I believe all MPC claims to do is "implement the C standard". This
appears to be slightly different from what you appear to want to it do,

It's vastly different. Either we are talking about standard C, or we
are talking about some particular subset of implementations. The
authors of MPC have made no claims about the latter, and Paul's
arguments are inapplicable to the former.

which is produce the same result one gets on a "standard, contemporary C
compiler".

This phrase is no better at specifying Paul's special version of C,
since there are standard, contemporary C implementations where CHAR_BIT
is not 8.

Paul is entirely wrong about C; while he is correct that MPC does not
use 8-bit chars (which, in C, are the same as bytes), that is irrelevant
to the question of whether MPC is a conforming C implementation.

Now, had Paul been wise enough to frame his arguments correctly - to
critique MPC for not supplying a CHAR_BIT==8 implementation, on the
grounds that such implementations are dominant in hosted environments,
say - then he might have had a valid point. It's an open question who
else might care, since rather than constructing a valid argument he's
resorted to stamping his feet and shouting.

 

[Alfred Z. Newmane]

On Wed, 27 Oct 2004 13:06:51 +0200

So if I read from a stream of data, I can overlay a set of nested
structs/unions in order to decypher the byte-array into a structured
message? As in the following?

typedef struct
{
uint8 inputs;

The compiler might insert padding here...

uint8 outputs;

or here...

uint8 timers;

or here.

} lc_statr_t;

Well, in C you might not have an 8 bit data type, which is presumably
what uint8 is...

typedef struct
{
uint8 errno;

The compiler might insert different padding here to that which it
might (or might not) have inserted in lc_statr_t

char message[1];
} lc_error_t;

typedef struct
{
uint8 opcode;
uint8 sequence;
} lc_msg_header_t;

I believe that lc_msgs_header_t is required to map correctly on to the
first 2 elements of lc_statr_t when they are combined in a union since
the first two elements are the same type.

typedef struct
{
lc_msg_header_t hdr;

union
{
lc_statr_t statr;
lc_error_t error;

uint8 cmd[LC_CMD_LEN]; /* placeholder */
char name[LC_NAME_LEN];
} data;
} lc_msg_t;

typedef struct
{
uint32 addr; /* originating ip_address */
uint16 port; /* originating port */
uint16 len; /* length of the packet */
} lc_packet_header_t;

typedef struct
{
lc_packet_header_t hdr;

union
{
lc_msg_t msg;
lc_tftp tftp;
char buffer[LC_BUFFERSIZE];
} u;
} lc_packet_t;

lc_packet_t.buffer is read (recv) and I can use
lc_packet_t.msg.hdr.opcode to get at the opcode? Without actually
moving *anything* in memory, of course, since I don't have enough RAM
available.

*If* your compiler pads structs in the way your incoming data is
padded then I believe that you will get what you expect. However,
version x.1 of your compiler might use different padding, and
changing compiler options might change the padding. So it is not a
portable solution. Also, if you had a double in there you would have
a real danger of reading a trap representation.

So if you want portable code you have to strip your message apart by
hand.

You cna use pragmas or other means to force a specific byte alignment,
can you not? If it was distributed code, it would most like be
documented (and commented in the code) reguarding that.

 

[Galga]

Not in comp.lang.c++, they are not. Please take this elsewhere.

Richard, is it going to warp the the fecking space time continuum to get
off your high horse about a topic that is just maybe mere ounces off
topic?

In case you haven't noticed, C and even Java are related languages; many
who use one use or have experience with the others, and who are you to
speak for everyone in c.l.c++, when it might be of interest of people
there? Actually many people I've seen post there have taken interest in
this thread, so I think you are proven wrong just by that.

If you don't like a thread, then kill it on your end, please don't try
to push your tastes on other people; even though this thread may not be
100% topical, but it still can have a place in any of the groups listed.

In fact, this was the entire point of cross posted, as par a gigantic
thread a couple years ago about cross posting; ultimately it's to bring
people of similar interests together, and this topic is just that and
has DONE just that.

So again, kindly kill file this thread if you don't want to see it.

~Galga

 

[Galga]

How could it be a union in the Java bytecode? Java bytecode doesn't
have unions, any more than machine code does. Unions are a feature of
C. The compiler compiles bytecode from C source. The C source may
contain unions. The bytecode doesn't, any more than a conventional
executable would.

*JAVA* doesn't have unions, they could be compiled to *byte code*, in
the same way Visual Studio (v6 I believe) compiles unions into object
code. I get the feeling you just jumped on the band wagon here, rather
then check the facts. It is *ENTIRELY* possible for the OP's compiler to
support unions, in a similar way many normal C/C++ compilers, like VC
do.

~Galga