C to Java Byte Code

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

Jul 22 '05 #52

Mark McIntyre

On Tue, 26 Oct 2004 11:36:02 -0700, in comp.lang.c , Paul Lutus
<no****@nosite.zzz> wrote:

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.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Jul 22 '05 #53

Mark McIntyre wrote:

Paul Lutus wrote:
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.

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.

Jul 22 '05 #54

Old Wolf

Paul Lutus <no****@nosite.zzz> wrote:

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

Jul 22 '05 #55

Paul Lutus

Mark McIntyre wrote:

On Tue, 26 Oct 2004 11:36:02 -0700, in comp.lang.c , Paul Lutus
<no****@nosite.zzz> wrote:
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,

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
http://www.arachnoid.com

Jul 22 '05 #56

Paul Lutus

Willem wrote:

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
http://www.arachnoid.com

Jul 22 '05 #57

Paul Lutus

Old Wolf wrote:

Paul Lutus <no****@nosite.zzz> wrote:
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.

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/meanin...age-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.

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.

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

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

--
Paul Lutus
http://www.arachnoid.com

Jul 22 '05 #58

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]...
--
Framsticks. 3D Artificial Life evolution. You can see the creatures
that evolve and how they interact, hunt, swim, etc. (Unaffiliated with
me). http://www.frams.alife.pl/

Jul 22 '05 #59

CBFalconer coughed up:

Paul Lutus wrote:
Willem wrote:

... snip ...
) But if they are both Java native integers, no mapping is taking
place. If ) there are two accesses to a simple integer value, the
term "mapping" is not ) appropriate, but if a C union is provided
and two different data types are ) mapped/conjoined, the term in

You really need to set up your newsreader properly. Use this post
as an example of standard quoting style.

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.

--
Framsticks. 3D Artificial Life evolution. You can see the creatures
that evolve and how they interact, hunt, swim, etc. (Unaffiliated with
me). http://www.frams.alife.pl/

Jul 22 '05 #60

Old Wolf coughed up:

Paul Lutus <no****@nosite.zzz> wrote:
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;

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

--
Framsticks. 3D Artificial Life evolution. You can see the creatures
that evolve and how they interact, hunt, swim, etc. (Unaffiliated with
me). http://www.frams.alife.pl/

Jul 22 '05 #61

Thomas G. Marshall coughed up:

Old Wolf coughed up:
Paul Lutus <no****@nosite.zzz> wrote:
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;

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

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

--
Framsticks. 3D Artificial Life evolution. You can see the creatures
that evolve and how they interact, hunt, swim, etc. (Unaffiliated with
me). http://www.frams.alife.pl/

Jul 22 '05 #62

CBFalconer

Mark McIntyre wrote:

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

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Jul 22 '05 #63

Richard Herring

In message <cl**********@nntp1.jpl.nasa.gov>, E. Robert Tisdale
<E.**************@jpl.nasa.gov> writes

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.
--
Richard Herring

Jul 22 '05 #64

Richard Herring

In message <10*************@corp.supernews.com>, Paul Lutus
<no****@nosite.zzz> writes

Mark McIntyre wrote:
On Tue, 26 Oct 2004 11:36:02 -0700, in comp.lang.c , Paul Lutus
<no****@nosite.zzz> wrote:
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,

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

Jul 22 '05 #65

In article <10*************@corp.supernews.com>, no****@nosite.zzz
says...

Gerry Quinn wrote:

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.

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

Jul 22 '05 #66

In article <10*************@corp.supernews.com>, no****@nosite.zzz
says...

Willem wrote
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.

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

Jul 22 '05 #67

dandelion

"Gerry Quinn" <ge****@DELETETHISindigo.ie> wrote in message
news:MP************************@news.indigo.ie...

In article <10*************@corp.supernews.com>, no****@nosite.zzz
says...
Willem wrote
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.

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.

Jul 22 '05 #68

On Wed, 27 Oct 2004 13:06:51 +0200
"dandelion" <da*******@meadow.net> wrote:

<snip unions>

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.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

Jul 22 '05 #69

In article <41***********************@dreader14.news.xs4all.n l>,
da*******@meadow.net says...

"Gerry Quinn" <ge****@DELETETHISindigo.ie> wrote in message
news:MP************************@news.indigo.ie...
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

Jul 22 '05 #70

dandelion

"Gerry Quinn" <ge****@DELETETHISindigo.ie> wrote in message
news:MP************************@news.indigo.ie...

In article <41***********************@dreader14.news.xs4all.n l>,
da*******@meadow.net says...
"Gerry Quinn" <ge****@DELETETHISindigo.ie> wrote in message
news:MP************************@news.indigo.ie...
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.

Jul 22 '05 #71

dandelion

"dandelion" <da*******@meadow.net> wrote in message news:417fadf9$0$148

Question restracted. Thanks for the cooperation.

Jul 22 '05 #72

Flash Gordon wrote:

On Wed, 27 Oct 2004 13:06:51 +0200
"dandelion" <da*******@meadow.net> wrote:

<snip unions>
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.

Jul 22 '05 #73

In article <10*************@corp.supernews.com>, no****@nosite.zzz
says...

http://explanation-guide.info/meanin...age-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."

And:

"The meaning of the new value of u.b is implementation dependent, and in
fact the C Standard states that it is invalid to read u.b if u.a was
last written."

- Gerry Quinn

Jul 22 '05 #74

Galga

Richard Herring wrote:

In message <10*************@corp.supernews.com>, Paul Lutus
<no****@nosite.zzz> writes
Mark McIntyre wrote:
On Tue, 26 Oct 2004 11:36:02 -0700, in comp.lang.c , Paul Lutus
<no****@nosite.zzz> wrote:

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,

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

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

Jul 22 '05 #75

Galga

Gerry Quinn wrote:

In article <10*************@corp.supernews.com>, no****@nosite.zzz
says...
Gerry Quinn wrote:

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.

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

Jul 22 '05 #76

Galga

CBFalconer wrote:

Mark McIntyre wrote:

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

Because the core topic can be relevant to any of those groups; who are
you to speak for everyone in those groups? As a matter of fact, people
from all those groups (that I've seen posting regularly in those
respective groups) have been jumping into this thread.

It's the whole long established *POINT* of cross posting, to make a
thread available where it may serve common interests, which this thread
has done.

~Galga

Jul 22 '05 #77

In article <41***************@yahoo.com>, cb********@yahoo.com says...

Mohd Hanafiah Abdullah wrote:

main()
{ a_union z;

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

illegal statement here. You cannot access a field of a union as a
type other than what you last wrote into it.

It's not illegal, any more than casting a float to an int (which it
effectively is) is illegal.

What Paul seems not to understand is that, while it is legal, the
results are unspecified, and tend to be implementation-dependent.

- Gerry Quinn

Jul 22 '05 #78

In article <cl**********@news.astound.net>, no**@none.spamblowz says...

Gerry Quinn wrote:
In article <10*************@corp.supernews.com>, no****@nosite.zzz
says...
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.

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

Which is exactly what I'm saying. C has unions. Bytecode and object
code don't. Paul's objections are meaningless.

- Gerry Quinn

Jul 22 '05 #79

In article <MP************************@news.indigo.ie>,
ge****@DELETETHISindigo.ie says...

In article <41***************@yahoo.com>, cb********@yahoo.com says...
Mohd Hanafiah Abdullah wrote:

main()
{ a_union z;

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

illegal statement here. You cannot access a field of a union as a
type other than what you last wrote into it.

It's not illegal, any more than casting a float to an int (which it
effectively is) is illegal.

Sorry, I meant casting a float* to an int* and de-referencing. Casting
a float to an int does give specified results, of course.

- Gerry Quinn

Jul 22 '05 #80

Galga

Paul Lutus wrote:

Dave Vandervies wrote:
In article <10*************@corp.supernews.com>,
Paul Lutus <no****@nosite.zzz> wrote:

/ ...
When you are ready to address the topic of this thread, post again.

I'm attempting to address the suitability of using an array of 32-bit
values to store values of varying types and use a union to convert
between the values stored there.

That is not the topic, and you need to find out what "thread drift"
refers to. You are always free to start any thread, on any topic, in
any suitable newsgroup. For this thread, a thread originated and
cross-posted to four nearly unrelated newsgroups by an unscrupulous
commercial vendor eager for free publicity, you have limited options
other than addressing the topic.
Since that's obviously not what you think the topic of this thread
is,

I did not start this thread, cross-post it, or choose its topic.

But you *DID* participate and *YOU* are just as much to blame for the
"thread drift" you speak of, yet it's everyone else's fault. How
convenient.

Actually, the part of the thread you are referring to discusses the
validity of the OP's product, which has to do with the original topic.
Since when is posting about weather the program can do what it's claimed
to be able to do off-topical from the root topic? Granted it's
stretched, but not so far as to warrant another thread, IMHO.

Jul 22 '05 #81

Galga

Gerry Quinn wrote:

In article <cl**********@news.astound.net>, no**@none.spamblowz
says...
Gerry Quinn wrote:
In article <10*************@corp.supernews.com>, no****@nosite.zzz
says...
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.

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

Which is exactly what I'm saying. C has unions. Bytecode and object
code don't. Paul's objections are meaningless.

Quite right. I think most of this thread could have been avoided if Paul
had admitted his blunder, or had not made it in the first place. But,
sigh, you can't expect much of PL anymore, as he is *never* wrong....

Jul 22 '05 #82

Galga

Gerry Quinn wrote:

In article <MP************************@news.indigo.ie>,
ge****@DELETETHISindigo.ie says...
In article <41***************@yahoo.com>, cb********@yahoo.com
says...
Mohd Hanafiah Abdullah wrote:

main()
{ a_union z;

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

illegal statement here. You cannot access a field of a union as a
type other than what you last wrote into it.

It's not illegal, any more than casting a float to an int (which it
effectively is) is illegal.

Sorry, I meant casting a float* to an int* and de-referencing.
Casting a float to an int does give specified results, of course.

- Gerry Quinn

Good catch, I was about to reply about that, saved me the trouble :-)

~Galga

Jul 22 '05 #83

Richard Herring

In message <cl**********@news.astound.net>, Galga <no**@none.spamblowz>
writes

Richard Herring wrote:
In message <10*************@corp.supernews.com>, Paul Lutus
<no****@nosite.zzz> writes
Mark McIntyre wrote:

On Tue, 26 Oct 2004 11:36:02 -0700, in comp.lang.c , Paul Lutus
<no****@nosite.zzz> wrote:

> 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,

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, 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?

Why is it so important to you to continue crossposting this thread?
What's your agenda? I
In case you haven't noticed, C and even Java are related languages; many
who use one use or have experience with the others,
In case _you_ haven't noticed, C and C++ are even more closely related
languages, yet comp.lang.c and comp.lang.c++ are separate groups and
there are good reasons for that.
and who are you to
speak for everyone in c.l.c++,
Where did I claim to do that?
when it might be of interest of people
there?
"Might be"? Have you actually read this group before today?
Actually many people I've seen post there have taken interest in
this thread,
Yeah, right. Name five. Then show that they aren't reading it in one of
the other groups where it might be on topic.
so I think you are proven wrong just by that.
Logic failure. Even *I* take an interest in some off-topic threads. That
doesn't bring them back on topic.
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.
So why don't we just add misc.misc to the Newsgroup: line?
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 what exactly is the "similar interest" in this case? Feel free to
point out which features of the standard C++ language
and this topic is just that and
has DONE just that.
In your opinion, perhaps.
So again, kindly kill file this thread if you don't want to see it.

--
Richard Herring

Jul 22 '05 #84

Galga

Richard Herring wrote:

In message <cl**********@news.astound.net>, Galga
<no**@none.spamblowz> writes
Richard Herring wrote:
In message <10*************@corp.supernews.com>, Paul Lutus
<no****@nosite.zzz> writes
Mark McIntyre wrote:

> On Tue, 26 Oct 2004 11:36:02 -0700, in comp.lang.c , Paul Lutus
> <no****@nosite.zzz> wrote:
>
>> 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,

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, 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?

Why is it so important to you to continue crossposting this thread?
What's your agenda? I

Because you wanted to speak on behalf of that group, it made no sense
*NOT* to reply to that group. Unless you have something to hide.

In case you haven't noticed, C and even Java are related languages;
many who use one use or have experience with the others,

In case _you_ haven't noticed, C and C++ are even more closely related
languages, yet comp.lang.c and comp.lang.c++ are separate groups and
there are good reasons for that.

True, but that alomne doesn't mean you cannot have cross topic
disccusion. Again, please do not act like you are some sort of owner of
the news groups. Your opinion is only that, it's not an administrative
or royal decry.

and who are you to
speak for everyone in c.l.c++,

Where did I claim to do that?

By trying to decide for everyone what groups this belogns to (ie,
setting follow up.) Not that this part of the thread matters all that
much, your attempt goes meaningless.

when it might be of interest of people
there?

"Might be"? Have you actually read this group before today?

Yes, plenty, what is your point? People from all these groups may read
one of these groups a lot more then the others. Even if not, why do
*YOU* care? If you don't want to see this thread in that group, then
kill file it.

Who the hell is holding a gun to your head making you read this thread?

And what exactly is the "similar interest" in this case? Feel free to
point out which features of the standard C++ language

Nice try, but that was never the point. The point was, as you actually
said, that the c and c++ groups are rather seperated, but people in
either might be *interested* in this topic, as it bares some relation.
The original post was not a direct C post, nor was it a direct Java
post, but a post about a utility, that if it works, could be a useful
program.

In that sense, there really seems to be no real reason to shout "off
topic" for only in the name of 100% conformity and ultimately complete
utter inflexibility. Only if you really feel the need to make noise by
making a unnecessary fuss.

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

And again, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^

~Galga

Jul 22 '05 #85

John Gordon

In <cl**********@news.astound.net> "Galga" <no**@none.spamblowz> writes:

If you don't want to see this thread in that group, then kill file it.
Who the hell is holding a gun to your head making you read this thread?

This sounds like the classic spam defense. "If you don't want to read
it, just delete it!" And we all know how well that works...

--
John Gordon "Between BST melee, their spells, their warders' melee,
go****@panix.com and their warders' procs, they put out enough damage
to make monks cry." -- Dark Tyger

Jul 22 '05 #86

John Gordon wrote:

In <cl**********@news.astound.net> "Galga" <no**@none.spamblowz>
writes:
If you don't want to see this thread in that group, then kill file
it. Who the hell is holding a gun to your head making you read this
thread?
This sounds like the classic spam defense. "If you don't want to read
it, just delete it!"

That maybe a classic defense, but I don't see how this thread (except
maybe in some views, the original post) could be spam.

In this case, I think the "kill the thread if you dont like it" hold
water, as no one is forcing anyone to read it.
And we all know how well that works...

Works rather well if you know how to delete a thread that you /really/
don't want to read. Is it /that/ hard?

Jul 22 '05 #87

Old Wolf

Paul Lutus <no****@nosite.zzz> wrote:

Old Wolf wrote:
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.

http://explanation-guide.info/meanin...age-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

And what makes you think those pages are accurate?
None of these contain references to the C standard.
They are comments made by people who are used to programming on
implementations that do the what those quotes say. However it is
possible to have a conforming C implementation without
these quotes applying.

As an analogy, I could find screensful of quotes saying that
bytes have 8 bits. But as we all know, there are C implementations
in which a byte has 9, or 32, or some other amount of bits.

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.

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

In C it is possible to have a syntactically correct
program that is not portable (by which I mean, it may
work reliably on one platform, but give different results,
or crash entirely, on different platforms). For example:

int i = 3;
i = i++;
printf("%d\n", i);

Here is another example of non-portability that doesn't
include undefined behaviour:

int x = 12;
assert( *(unsigned char *)&x == 0 );

Jul 22 '05 #88

John Gordon wrote:

Something that calls itself Galga writes:
If you don't want to see this thread in that group, then kill file it.
Who the hell is holding a gun to your head making you read this thread?

This sounds like the classic spam defense.
"If you don't want to read it, just delete it!"
And we all know how well that works...

Please don't feed the trolls.

Jul 22 '05 #89

On Wed, 27 Oct 2004 16:17:29 +0200
"dandelion" <da*******@meadow.net> wrote:

<snip using union to pan array of unsigned char to structs containing
unsigned chars>

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

Reading using a different type to the type used for writing. IIRC some
of the elements of your struct we actually declared as uint16
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.

From the sounds of it you will be using implementation specific trickery
and/or work arounds for implementation deficiencies, so I would not
worry about using implementation specific knowledge about unions.

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.

I thought I saw a uint16 or something like that? Maybe a typo or faulty
memory on my part.

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.

Using the union to map the different types all on to one piece of memory
*does* achieve what you want, i.e. it does *not* move the data around to
copy with the accesses by different types. So in *your* case I would
say hang the portability issues (but comment them) and go for it.

You would be probably be best discussing this on groups/mailing lists
dedicated to your platforms of interest since on comp.lang.c we won't
know the limitations of your C-like implementation and the would be off
topic in any case.

It is probably off topic for most of the other groups as well, so I've
set follow ups to comp.programming as the most likely group of the ones
this is cross-posted to.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

Jul 22 '05 #90

On Wed, 27 Oct 2004 10:06:18 -0700
"Galga" <no**@none.spamblowz> wrote:

Gerry Quinn wrote:
In article <MP************************@news.indigo.ie>,
ge****@DELETETHISindigo.ie says...
In article <41***************@yahoo.com>, cb********@yahoo.com
says...
Mohd Hanafiah Abdullah wrote:

> main()
> { a_union z;
>
> z.x = 1078531719;
> printf("int val = %d\n", z.x);
> printf("float val = %f\n", z.y);

illegal statement here. You cannot access a field of a union as a
type other than what you last wrote into it.

It's not illegal, any more than casting a float to an int (which it
effectively is) is illegal.

Sorry, I meant casting a float* to an int* and de-referencing.
Casting a float to an int does give specified results, of course.

Good catch, I was about to reply about that, saved me the trouble :-)

I caught my reply on the outgoing spool before it left.

However, the bit pattern of an int can be a trap representation for a
float, so writing an int then reading it as a float is definitely *not*
guaranteed to leave your program running. I think the only type punning
the C standard actual guarantees won't crash your program is reading
anything as unsigned char, an exception that I believe is explicitly
mentioned.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

Jul 22 '05 #91

On Wed, 27 Oct 2004 08:57:27 -0700
"Alfred Z. Newmane" <a.**************@eastcoastcz.com> wrote:

<snip using a union to overlay structs on an array of unsigned char>

You cna use pragmas or other means to force a specific byte alignment,
can you not?
You can use pragmas, but there is nothing to say
#pragma align 1
on the next compiler you use doesn't mean align on 1GB boundaries.

There is also nothing to say that any given compiler supports a pragma
for specifying alignment.
If it was distributed code, it would most like be
documented (and commented in the code) reguarding that.

I've seen plenty of non-portable code that does *not* document what
non-portable extensions it is using.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

Jul 22 '05 #92

Old Wolf

"Thomas G. Marshall" wrote:

Old Wolf coughed up:

Nice description..:)

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);
Results:
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?

According to the C standard, it is "undefined behaviour" to
read any member of a union except for the one that was most
recently set. This means that an implementation can do whatever
it likes (including printing 3.142, or crashing, or causing
demons to fly out of your nose, as they say).
Imagine that a compiler detects this situation and inserts
code to display 3.142 whenever a float is read from a union
that just had an int put in it (that would be very perverse,
and that vendor wouldn't sell many compilers, but it is allowed).

Jul 22 '05 #93

Mark McIntyre

On Tue, 26 Oct 2004 17:55:28 -0700, in comp.lang.c , Paul Lutus
<no****@nosite.zzz> wrote:

Mark McIntyre wrote:
On Tue, 26 Oct 2004 11:36:02 -0700, in comp.lang.c , Paul Lutus
<no****@nosite.zzz> wrote:
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,

Do you see a reference to C in the sentence above?

Do you see comp.lang.c in the x-post list? Yes? So post something topical.

The discussion is about a C to Java cross-compiler. Both languages are
therefore topical.
Really? Where in the C standard does it define cross compilation to Java?
Which Java group is this x-posted to?
The OP, an unscrupulous, predatory commercial vendor, created this
cross-posted thread. If you don't like it, argue with him.
You're the one perpetuating the x-post.
Do the world a favor. Killfile Usenet.

Or put you back into mine. but please use your real name when posting, to
make it easier for people to killfile you.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Jul 22 '05 #94

Mark McIntyre

On Wed, 27 Oct 2004 10:35:58 -0700, in comp.lang.c , "Galga"
<no**@none.spamblowz> wrote:

Richard Herring wrote:

Why is it so important to you to continue crossposting this thread?
What's your agenda? I

Because you wanted to speak on behalf of that group, it made no sense
*NOT* to reply to that group. Unless you have something to hide.

Or possibly he wants to stop x-posting to the CLC++ group, because its
annoying the t*ts off everyone there to have a bunch of cretins arguing
about fscking Java bytecode.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Jul 22 '05 #95

John Gordon

In <2u*************@uni-berlin.de> "Alfred Z. Newmane" <a.**************@eastcoastcz.com> writes:

This sounds like the classic spam defense. "If you don't want to read
it, just delete it!"
That maybe a classic defense, but I don't see how this thread (except
maybe in some views, the original post) could be spam.
I didn't mean to say that this thread was spam; I was just observing the
perils of assigning the burden of content filtering to the reader rather
than the writer.
In this case, I think the "kill the thread if you dont like it" hold
water, as no one is forcing anyone to read it. And we all know how well that works...

Works rather well if you know how to delete a thread that you /really/
don't want to read. Is it /that/ hard?

For a small number of threads, no. But it doesn't scale. Just like spam.

--
John Gordon "Between BST melee, their spells, their warders' melee,
go****@panix.com and their warders' procs, they put out enough damage
to make monks cry." -- Dark Tyger

Jul 22 '05 #96

napi wrote:

I think you would agree with me that a C compiler
that directly produces Java Byte Code to be run on any JVM
is something that is missing to software programmers so far.
I used Google

http://www.google.com/

to search for

+"C to Java byte code"

and I found lots of stuff.

There have been lots of such projects for a long time.
Why do you say that this is something that has been "missing"?
How is your product better than all of the other offerings?
With such a tool one could stay with C
and still be able to produce Java byte code for platform independent apps.
Also, old programs (with some tweaking)
could be re-compiled and ported to the JVM. We have been developing such a tool over the last 2 years
and currently beta testing it.

It's called MPC (for Multi-Platform C) and you can download the beta
version at http://www.axiomsol.com or at http://freshmeat.net

Jul 22 '05 #97

Old Wolf wrote:

Paul Lutus <no****@nosite.zzz> wrote:
Old Wolf wrote:
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.
http://explanation-guide.info/meanin...age-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

And what makes you think those pages are accurate?
None of these contain references to the C standard.
They are comments made by people who are used to programming on
implementations that do the what those quotes say. However it is
possible to have a conforming C implementation without
these quotes applying.

As an analogy, I could find screensful of quotes saying that
bytes have 8 bits. But as we all know, there are C implementations
in which a byte has 9, or 32, or some other amount of bits.
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.

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

In C it is possible to have a syntactically correct
program that is not portable (by which I mean, it may
work reliably on one platform, but give different results,
or crash entirely, on different platforms). For example:

int i = 3;
i = i++;
printf("%d\n", i);

How is non portable? This returns 4 on GCC 3.2.1 (Linux), VC6 & BCB5
(Win32), and on GCC 2.95.3 (FreeBSD)

The code it self is fine; i starts with a value of 3, then i gets
assigned to itself, *after* which it gets ++ed. Remember, ++ after the
variable (post inc) takes place *after* the evaluation. In other words
it's the same as:

int i = 3;
i = i;
i++;
Here is another example of non-portability that doesn't
include undefined behaviour:

int x = 12;
assert( *(unsigned char *)&x == 0 );

You might be right on this one.

Jul 22 '05 #98

Richard Tobin

In article <2u*************@uni-berlin.de>,
Alfred Z. Newmane <a.**************@eastcoastcz.com> wrote:

int i = 3;
i = i++;
printf("%d\n", i);
The code it self is fine; i starts with a value of 3, then i gets
assigned to itself, *after* which it gets ++ed.
No. It starts with the value 3, which is the value of the right-hand
side. Then that value is assigned to i, and i is incremented, but the
order of these two operations is not defined.
Remember, ++ after the variable (post inc) takes place *after* the
evaluation.

Yes, but not necessarily after the assignment.

-- Richard

Jul 22 '05 #99