C to Java Byte Code

[Mark McIntyre]

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]

Richard Herring wrote:

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.

 

[Old Wolf]

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.

I disagree (this is all untrodden on territory though, AFAIK..)
For example, imagine that the members of the union reside
in adjacent memory locations. When you cast their addresses
to unsigned char * you get different values, but the logic
for pointer comparison will return TRUE because it knows
that those address values are within the memory space for
that union.
(One way to implement this would be for a pointer to have
2 parts: one being a base address, and one being an offset,
(the members of the union all having the same base address),
and the pointer equality test would be TRUE if the base
address were equal).

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,

You would expect it on a normal architecture, but maybe not
on a weird architecture like a JVM (which doesn't support that,
as Paul Lutus noted). Since the standard says that the
results of accessing or manipulating the representation are
all implementation-defined (except those situations where they
are undefined of course), I can't see any conflict.

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.

Better a perverse one than a non-compliant one.. if you
have a better idea then tell the OP

 

[John Gordon]

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.

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.

 

[Alfred Z. Newmane]

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.


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.

 

[Richard Tobin]

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

[/QUOTE]

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

 

[Alfred Z. Newmane]

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.[/QUOTE]

Good point, thanks for mentioning it Still, either order will still
end up with 4. Either i ++'s to 4 and assigns that bakc to i, or i gets
3, then ++'ed, giving 4 as well. My point was that it was still portable
in that any order it's eval'ed will get ya a value of 4, given that
above code.

 

[Arthur J. O'Dwyer]

Good point, thanks for mentioning it Still, either order will still
end up with 4. Either i ++'s to 4 and assigns that bakc to i, or i gets
3, then ++'ed, giving 4 as well. My point was that it was still portable
in that any order it's eval'ed will get ya a value of 4, given that
above code.

Your point was WRONG, though. The problem is not that the two
operations' order is unspecified; it's that the effect of the combined
operation is undefined. You can't modify 'i' twice between sequence
points; the language doesn't allow it. 'i = ...' modifies 'i', and then
'i++' modifies it again. That's not valid C.

Thus the code exhibits undefined behavior, and /anything/ can happen ---
'i' could end up equal to 4, or it could end up equal to 3, or 5, or 42,
or "hello world." And if you don't think "hello world" is a valid value
for an 'int' variable, you're right --- undefined behavior is allowed to
do funny things!

(BTW: gcc does emit a warning about the undefined behavior in that code,
if you turn on all warnings. gcc is smart like that.)

HTH,
-Arthur

 

[Old Wolf]

How is non portable?

Please read the FAQ entry pertaining to this:
http://www.eskimo.com/~scs/C-faq/q3.3.html

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.

A common misconception. The ++ can occur either before or
after the evaluation (and either before or after the assignment,
in this example). The same goes for pre-increment.
The only difference between pre- and post- increment is that
the result of evaluating is (i) for post- and (i+1) for pre- .

In other words it's the same as:

int i = 3;
i = i;
i++;

Unfortunately, not. The reason why the rules are as they are
is so that compilers can optimise code. For example if we had:
i--;
a = i++;
an optimising compiler could generate the code for:
a = i - 1;
and not bother with the increments. So you can see why it
would get in trouble if 'a' were changed to 'i'.

(If this is not clear, then consider the example:

static int i;

void foo(int *p) {
i--;
*p = i++;
}

int main(void) {
i = 3;
foo(&i);
printf("%d\n", i);
}

According to your logic above, this should do:
i--; // i is now 2
*p = i; // i is now 2
i++; // i is now 3

and print 3. But if it does the optimisation I suggested
then it prints 2. This is indeed what my gcc 3.4.1 prints (2).

 

[Alfred Z. Newmane]

Please read the FAQ entry pertaining to this:
http://www.eskimo.com/~scs/C-faq/q3.3.html


A common misconception. The ++ can occur either before or
after the evaluation (and either before or after the assignment,
in this example). The same goes for pre-increment.
The only difference between pre- and post- increment is that
the result of evaluating is (i) for post- and (i+1) for pre- .


Unfortunately, not. The reason why the rules are as they are
is so that compilers can optimise code. For example if we had:
i--;
a = i++;
an optimising compiler could generate the code for:
a = i - 1;
and not bother with the increments. So you can see why it
would get in trouble if 'a' were changed to 'i'.

Point taken.

(If this is not clear, then consider the example:

static int i;

void foo(int *p) {
i--;
*p = i++;
}

int main(void) {
i = 3;
foo(&i);
printf("%d\n", i);
}

According to your logic above, this should do:
i--; // i is now 2
*p = i; // i is now 2
i++; // i is now 3

and print 3. But if it does the optimisation I suggested
then it prints 2. This is indeed what my gcc 3.4.1 prints (2).

Mine prints 3
What options, if any, were you using?

test.c
---------------------------------------------------
#include <stdio.h>

static int i;

void foo(int *p) {
i--;
*p = i++;
}

int main(void) {
i = 3;
foo(&i);
printf("%d\n", i);

return 0;
}
---------------------------------------------------

$ gcc test.c -o test
$ gcc --version
gcc (GCC) 3.2.1 20020903 (prerelease)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

$ ./test
3

 

[Richard Bos]

A common misconception. The ++ can occur either before or
after the evaluation (and either before or after the assignment,
in this example).

Worse, in multi-processor or multi-pipeline systems, they could occur
simultaneously. It isn't inconceivable for this to crash the program
rather abruptly, or to write a completely unpredictable value to i.

Richard

 

[Richard Herring]

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.[/QUOTE]

"Something to hide"? Don't be silly, this is Usenet.

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.

Oh, I see. When others cross-post off-topic nonsense and *I* ask them to
take it elsewhere, it's a royal decree. But when I ask people to
consider where they're posting, it's OK for *you* to tell me I'm not
entitled to do that. Did you ever hear that proverb about pots and
kettles?

By trying to decide for everyone what groups this belogns to (ie,
setting follow up.)

For some value of "trying to decide" equal to "suggesting", maybe. The
Followup-To header isn't some kind of autocratic overriding of others'
freedom.

Not that this part of the thread matters all that
much, your attempt goes meaningless.


Yes, plenty, what is your point?

Well, if you want me to spell it out, it's that if, as you claim, you
really were a regular reader, you would be aware of the attitude of most
posters to clc++ to (a) posts not about the standard C++ language, and
(b) crossposting between clc and clc++.

As it is, I see no evidence that you've ever made any contribution at
all to the group, or that you have posted anywhere at all under your
current pseudonym until less than a week ago.

People from all these groups may read
one of these groups a lot more then the others. Even if not, why do
*YOU* care?

Never heard of Gresham's law? Too much junk, and the useful
contributors can't even find the sensible threads, so they give up
posting.

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?

Ah, the cry of every cross-posting troll since the beginning of usenet.

Nice try, but that was never the point.

It's the point of clc++. If you don't realise that, you can't possibly
have read the group for any length of time, as you claimed.

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.

So far you've failed to demonstrate any.

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.

But the thread has long since degenerated into Paul "never wrong" Lutus
v the world, demonstrating that he doesn't understand the concept of
emulation. Now, I see, we're even getting the "i=i++" debate recycled
for the millionth time. And you are seriously advocating this as an
exemplar of crossposting?

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.


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

I generally killfile individuals, not threads. You could do the same.

 

[Richard Tobin]

Richard Tobin wrote:

Good point, thanks for mentioning it Still, either order will still
end up with 4. Either i ++'s to 4 and assigns that bakc to i, or i gets
3, then ++'ed, giving 4 as well.

No. The possibilities include

- the rhs is evaluated as 3
- the rhs (3) is assigned to i
- i is incremented

where the result is that i ends up as 4, and

- the rhs is evaluated as 3
- i is incremented
- the rhs (3) is assigned to i

where i ends up as 3.

The standard allows any other behaviour, but the results above are the
most natural ones.

-- Richard

 

[Richard Tobin]

Worse, in multi-processor or multi-pipeline systems, they could occur
simultaneously. It isn't inconceivable for this to crash the program
rather abruptly, or to write a completely unpredictable value to i.

For example, a C implementation on a multi-processor native INTERCAL
machine might do the assignment half-way through the evaluation of the
addition using the MINGLE and SELECT operators.

-- Richard

 

[John Bode]

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

Here's a slightly different example:

[root@rh170 undef]# more undef.c
#include <stdio.h>

int main (void)
{
int i, j;

i = j = 0; j = i++; j = j + i++;
i = 0; i = i++ + i++;
printf ("j = %d, i = %d\n", j, i);

i = j = 0; j = i++; j = j + ++i;
i = 0; i = i++ + ++i;
printf ("j = %d, i = %d\n", j, i);

i = j = 0; j = ++i; j = j + ++i;
i = 0; i = ++i + ++i;
printf ("j = %d, i = %d\n", j, i);

i = j = 0; j = ++i; j = j + i++;
i = 0; i = ++i + i++;
printf ("j = %d, i = %d\n", j, i);

return 0;
}

[root@rh170 undef]# ./undef
j = 1, i = 2
j = 2, i = 3
j = 3, i = 4
j = 2, i = 3

Hmmmmm...

 

[Alfred Z. Newmane]

No. The possibilities include

- the rhs is evaluated as 3
- the rhs (3) is assigned to i
- i is incremented

where the result is that i ends up as 4, and

Sounds good.

- the rhs is evaluated as 3
- i is incremented
- the rhs (3) is assigned to i

where i ends up as 3.

If "rhs is evaluated as 3" and then "i is incremented", how wil lthat
not give 4? THe key is in the incrementation; when ever I get
incremented, it becomes 4, does it not? If nto can you please better
explain your logic (in the second example)?

 

[Alfred Z. Newmane]

For example, a C implementation on a multi-processor native INTERCAL
machine might do the assignment half-way through the evaluation of the
addition using the MINGLE and SELECT operators.

Sound like that coudl get ugly /fast/. Though I haven't worked with such
setups, aren't there safe guards against such (resulting) data
corruption?

 

[Alex Fraser]

Richard Tobin wrote: [snip]

No. The possibilities include

- the rhs is evaluated as 3
- the rhs (3) is assigned to i
- i is incremented

where the result is that i ends up as 4, and

Sounds good.

- the rhs is evaluated as 3
- i is incremented
- the rhs (3) is assigned to i

where i ends up as 3.

If "rhs is evaluated as 3" and then "i is incremented", how wil lthat
not give 4? THe key is in the incrementation; when ever I get
incremented, it becomes 4, does it not? If nto can you please better
explain your logic (in the second example)?

Given:
i = i++;

The compiler is free to generate code equivalent to:
temp = i; /* evaluate RHS */
i++; /* increment i */
i = temp; /* assign result of evaluation of RHS */

Alex

 

[Flash Gordon]

Richard Tobin wrote:


If "rhs is evaluated as 3" and then "i is incremented", how wil lthat
not give 4? THe key is in the incrementation; when ever I get
incremented, it becomes 4, does it not? If nto can you please better
explain your logic (in the second example)?

You are assuming that one operation is completed before the other, they
could be running in parallel or interleaved. So it could be implemented
as:
Read the value of i in to register a, so reg a=3
Increment value in variable i, so register a=3 and variable i=4
Store register a in i, so i=3

This is not actually a completely unreasonable implementation. It makes
sense because i++ is the post increment, so it's value is the value
before incrementing, so if a processor has an instruction for
incrementing data in RAM (I know some processors do) it is reasonable to
use the values in the expression, then do the in-place increment, then
save the result.

 

[Flash Gordon]

Sound like that coudl get ugly /fast/. Though I haven't worked with
such setups, aren't there safe guards against such (resulting) data
corruption?

There is one very good safeguard. Don't do things the C standard leaves
undefined. The compiler might me making use of the leeway provided (such
as the time when the increment occurs) to do all sorts of strange and
wonderful optimisations. That is (presumably) why the C language defines
sequence points and that it is only once you reach a sequence point that
you can be certain that all the side effects have occurred.