C to Java Byte Code

[Old Wolf]

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;
}

Same as yours (ie. gcc -o test test.c) . It didn't make a
difference whether I went -O0 or -O2 or -O3. FWIW I get
2 on gcc 3.4.1 but 3 on egcs 2.91.66 which I also have
installed.

 

[Richard Tobin]

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

where i ends up as 3.

[/QUOTE]

If "rhs is evaluated as 3" and then "i is incremented", how wil lthat
not give 4?

The variable i is incremented. The value of the right-hand-side has
already been evaluated, and is equal to three. So i is set to 4 when
it is incremented, and back to 3 when the rhs is assigned to it.

Imagine it with a temporary variable for the right-hand side. The two
possibilities I listed are:

rhs = i;
i = rhs;
i = i+1;

and

rhs = i;
i = i+1;
i = rhs;

-- Richard

 

[Brian Raiter]

Worse, in multi-processor or multi-pipeline systems, they could

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.

*light bulb*

I bet THAT's what's causing the bug in my multithreaded INTERCAL-based
C compiler!

*runs off to check code*

b





(PS: okay not really)

 

[Alan Morgan]

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

the compiler is also free to generate code equivalent to

i = 42; /* RIP DNA */
or
system("mail -s \"I'm leaving you\" <your girlfriend's name>");
or
reformat("/dev0/hda");
send_rude_noise_to_speakers();
catch_fire();
i = 4;

The statement "i=i++;" invokes undefined behavior. Your compiler
will very likely behave rationally and give you an answer that you
might reasonably consider "correct". Don't be fooled. The technical
definition of "undefined" is "Will give consistent and repeatable
results until your boss asks for a demo, at which point it starts
behaving randomly".

Alan

 

[John Bode]

Even more interesting (this is gcc 3.2.3 on Red Hat 2.4.21-9.ELsmp, btw):

#include <stdio.h>

int main (void)
{
int i, j, k;

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

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

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

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

return 0;
}

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

 

[Alfred Z. Newmane]

Same as yours (ie. gcc -o test test.c) . It didn't make a
difference whether I went -O0 or -O2 or -O3. FWIW I get
2 on gcc 3.4.1 but 3 on egcs 2.91.66 which I also have
installed.

I wonder why there is that sort of difference between 3.4 and 3.2* (and
previous) ?

 

[Willem]

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

That, as I said before, is because it is non-portable code.
If I compile your program with gcc (a standard, contemporary C compiler) on
hardware that has 32-bit bytes, then I get the same result as MPC.
Therefore, the result *is* the result one gets on a starndard, contemporary
C compiler, and your claim is false.

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

What you presented is not a fact, as I just proved. Therefore I can most
certainly argue it away, as I just did.

)> That the results were not what *you* expected is just because
)> you're either a troll or a moron.
)
) Thank you for moving to your area of conpetence so swiftly. Do you think the
) readers of this newsgroup will find this useful, despite it being false?

Probably not. Some of them will probably tell me to killfile you, because
it's bad form to reply to trolls.

)> Are you claiming that an ordinary C compiler on such hardware 'does not
)> support unions'?
)
) No, you are. I have never said this, and you have used this exact same
) tactic on countless occasions -- invent a position someone has never taken,
) then argue with it. This is called "onanism". Don't wear yourself out.

It's not onanism if the intended result is for you to take the opposite
position.

So, are you claiming that assembly code does, or does not support unions ?

If it does, then that invalidates your claims about java bytecode not
supporting them.

If assembly code does not support unions, then how can you claim that a C
compiler that produces assembly code does support unions, while claiming
that a C compiler that produces java bytecode does not ?


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

 

[Willem]

Paul 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's a very odd thing to say. His product is a C compiler.


Let me ask you a question:

Does GCC support unions ?


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

 

[Thomas G. Marshall]

Alan Morgan coughed up:

....[rip]...

The statement "i=i++;" invokes undefined behavior. Your compiler
will very likely behave rationally and give you an answer that you
might reasonably consider "correct". Don't be fooled. The technical
definition of "undefined" is "Will give consistent and repeatable
results until your boss asks for a demo, at which point it starts
behaving randomly".

(For yucks, the term "undefined behavior" is actually defined in the C
specification, but that is neither here nor there.)

I don't see i=i++ as ever anything useful, but 45° tangental to this
original thread is something that bothers me. There is a *prevailing*
notion that:

If it ain't standard C, it ain't C

which I think is not quite true. This is related to something else I also
think is false:

If it ain't standard C, you should not write in it

I've been digging here and there about this for a while now and am not sure
that there is a /complete/ consensus on this notion, though the majority
seem to agree with the above statement. It's important because there are
many things that cannot be written in standard C that are nonetheless useful
to write in non-std C:

Device Drivers (usually)
malloc()
Anything embedded that needs to tweek memory
mapped registers

This issue was raised to my attention recently when I was educated by many
here on what the standard actually allows. But knowing the standard, IMHO,
isn't the bottom line. Knowing the "usual" rules of C, particularly the
/likely/ behavior of something undefined or platform dependent in the spec,
is, particularly if you're recruiting.

 

[Programmer Dude]

There is a *prevailing* notion that:

If it ain't standard C, it ain't C

which I think is not quite true.

Of course not. The only place that "notion" really prevails is in the
comp.lang.c group. And as a number of regulars (or in my case, former
regulars) hang out here, too, we get it here, too.

This is related to something else I also think is false:

If it ain't standard C, you should not write in it

Right (it's false).

But knowing the standard, IMHO, isn't the bottom line.

Right. It's the first line! It's somewhat like an artist needing
to know how to paint a face correctly before they start experimenting
with alternate forms and formats. *Knowledgeable* departure from
the standard is the key.

Knowing the "usual" rules of C, particularly the /likely/ behavior
of something undefined or platform dependent in the spec, is,
particularly if you're recruiting.

I don't agree it's the bottom line, but it's an important one, IMO.

 

[Alfred Z. Newmane]

Paul 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's a very odd thing to say. His product is a C compiler.


Let me ask you a question:

Does GCC support unions ?

2.9.5 and 3.2 seem to.

 

[Willem]

Alfred wrote:
) Willem wrote:
)> Paul 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's a very odd thing to say. His product is a C compiler.
)>
)>
)> Let me ask you a question:
)>
)> Does GCC support unions ?
)
) 2.9.5 and 3.2 seem to.

I specifically asked Paul, because he seems to have a strange notion of
what it means for a compiler to 'support unions'.


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

 

[Dik T. Winter]

> I don't see i=i++ as ever anything useful, but 45° tangental to this
> original thread is something that bothers me. There is a *prevailing*
> notion that:
> If it ain't standard C, it ain't C
> which I think is not quite true.

In this groups it is true. The aim in this group is portable C. If your
programming is platform sepcific you better ask in a newsgroup related to
your platform.

> It's important because there are
> many things that cannot be written in standard C that are nonetheless useful
> to write in non-std C:
>
> Device Drivers (usually)
> malloc()
> Anything embedded that needs to tweek memory
> mapped registers

Indeed, they can not be written in standard C as the code is necesarily
very platform specific. So a newsgroup related to your platform is a
better place to ask.

> This issue was raised to my attention recently when I was educated by many
> here on what the standard actually allows. But knowing the standard, IMHO,
> isn't the bottom line. Knowing the "usual" rules of C, particularly the
> /likely/ behavior of something undefined or platform dependent in the spec,
> is, particularly if you're recruiting.

But what is likely behaviour? How do you define that? The only behaviour
that is likely about "i = i++;" is that it probably will set "i" to either
the value before the statement or to the incremented value. And that is
not very useful information either.

And that is what happens in most cases of undefined behaviour, it can do
one thing or something else, and most likely both can occur on different
platforms, or sometimes on the same platform with different compilers,
or sometimes on the same platform with different generations of the same
compiler.

I once got a program that crashed reliably on the platform where I wished
to use it. The culprit was a snippet of code that assumed that pointers
to character were plain long ints. So it contained the following code:
char *c, *c1;
c = malloc(sizeof(double) * 2);
/* get a double aligned pointer in the array */
c1 = (char *)((long int)(c + sizeof(double) - 1) & ~(sizeof(double) - 1));
the crash occurred when c1 was used. Not only was the code misguided
(malloc returns a pointer suitably aligned), it was also totally wrong
on that platform, because c1 pointed to c[7], which was not suitably
aligned.

 

[Jerry Coffin]

[ ... ]

There is a *prevailing* notion that:

If it ain't standard C, it ain't C

This is more than a mere notion: it's a tautology, since C is defined
by the standard.

which I think is not quite true. This is related to something else I also
think is false:

If it ain't standard C, you should not write in it

I've never gotten any impression of anybody having that idea at all.
There is, however, an idea that could easily be mistaken for it:

If it ain't C, it ain't topical in comp.lang.c, and if it ain't C++ it
ain't topical in comp.lang.c++. Since these languages are defined by
standards, "C" and "standard C" are synonymous. While I'm not a
regular participant in comp.unix.programming, I'd imagine it's run
along more or less similar lines. Just to give a concrete example,
consider MacOS 9.1 -- opinions of its quality, goodness,
acceptability, etc., undoubtedly vary widely, but regardless of
anybody's opinion about its quality, there seems little room for doubt
that it's off-topic in comp.unix.programmer.

In any of the above cases, when somebody's pointing out that the
subject is off-topic, there's a pretty fair chance that the original
poster will be insulted to some degree -- even if it's done politely
(which, in fairness, it often isn't).

I've been digging here and there about this for a while now and am not sure
that there is a /complete/ consensus on this notion, though the majority
seem to agree with the above statement. It's important because there are
many things that cannot be written in standard C that are nonetheless useful
to write in non-std C:

Device Drivers (usually)
malloc()
Anything embedded that needs to tweek memory
mapped registers

Saying that something is written in "standard C" is a difficult term
to pin down. Most of these can be written in C that is "conforming",
but not "strictly conforming". Realistically, nearly _all_ useful C
code falls somewhere between those two extremes.

I think the consensus on c.l.c and c.l.c++ is that there's a line
somewhere between those two that's sometimes been (unofficially)
titled "strongly conforming" C -- basically, code that should run on
any reasonable implementation of C, and should produce similar results
on all of them.

The fact is, however, that C and C++ are both used in thousands of
situations (especially if you include non-standard dialects) and
without a pretty strict definition of what's topical and what's not,
the most informative participants would almost inevitably leave. In a
newsgroup that attracts less attention, it's much easier to define the
subject much more broadly, and to allow much more chatting that's only
marginally topical at best.

This issue was raised to my attention recently when I was educated by many
here on what the standard actually allows. But knowing the standard, IMHO,
isn't the bottom line. Knowing the "usual" rules of C, particularly the
/likely/ behavior of something undefined or platform dependent in the spec,
is, particularly if you're recruiting.

I think you're making a bit of a mistake between that the standard
_allows_ (which is quite broad) and what the standard says always has
defined behavior (which is considerably narrower). I don't know of
anybody who's claimed that knowing the standard is all there is --
quite the contrary I think most of the regulars probably consider
problem solving, knowledge of algorithms, style, etc. quite important
-- but they also realize that something that's off-topic is still
off-topic, regardless of how interesting it might be.

 

[Thomas G. Marshall]

Dik T. Winter coughed up:

this > original thread is something that bothers me. There is a
*prevailing* > notion that:

In this groups it is true. The aim in this group is portable C. If
your
programming is platform sepcific you better ask in a newsgroup
related to
your platform.

I'm not asking anything, I'm making an observation. I need no questions
answered.

Are you sure about the aim in the comp.lang.c group being "portable C"? I
don't see that as the charter at all. (I apologize for the huge
crosspost---it was inherited, and perhaps I should have narrowed it away
from C++). Here is what the official list of big eight newsgroups says, as
posted continually in news.announce.newsgroups:

comp.lang.c Discussion about C

That list is as "official" as it gets.

there are > many things that cannot be written in standard C that
are nonetheless useful > to write in non-std C:

Indeed, they can not be written in standard C as the code is
necesarily
very platform specific. So a newsgroup related to your platform is a
better place to ask.

[your newsreader munged the indents here, I'll try to fix:]

But what is likely behaviour? How do you define that?

You *DON'T* define it. That's the whole point! But you /do/ need to
understand it. That's /my/ point.

The only
behaviour
that is likely about "i = i++;"

Wrong example to use---I see no use for it.

Here is something that you can gauge "likely behavior", for example on a
byte addressable 32 bit sparcstation 1:

long *a = 0; // C99: not platform independent null pointer
a++; // C99: not allowed to increment null
pointer
printf ("%d\n", a); // C99: not using %p

Likely output on byte addressable, 32 bit data, 32 bit instruction,
machines:

4

Portable or not, it was what I would find on nearly all my workstations back
when I was porting a postscript interpreter to a myriad of them as head of
the "unix department" (three people lol).

And here is "likely behavior:"

*((long*)0xc0450000) = 0; // fill specific location with 0.
(ignoring of course vm issues)

Of course it's platform specific, but it's still important to understand.

is that it probably will set "i" to
either
the value before the statement or to the incremented value. And that
is
not very useful information either.

Like I said in my OP, i=i++ is not IMO useful, so take that off the table.


....[rip]...

 

[Thomas G. Marshall]

Jerry Coffin coughed up:

"Thomas G. Marshall"
message
[ ... ]

There is a *prevailing* notion that:

If it ain't standard C, it ain't C

This is more than a mere notion: it's a tautology, since C is defined
by the standard.

which I think is not quite true. This is related to something else
I also think is false:

If it ain't standard C, you should not write in it

I've never gotten any impression of anybody having that idea at all.
There is, however, an idea that could easily be mistaken for it:

If it ain't C, it ain't topical in comp.lang.c, and if it ain't C++ it
ain't topical in comp.lang.c++. Since these languages are defined by
standards, "C" and "standard C" are synonymous. While I'm not a
regular participant in comp.unix.programming, I'd imagine it's run
along more or less similar lines. Just to give a concrete example,
consider MacOS 9.1 -- opinions of its quality, goodness,
acceptability, etc., undoubtedly vary widely, but regardless of
anybody's opinion about its quality, there seems little room for doubt
that it's off-topic in comp.unix.programmer.

I apologize, but I was thinking specifically of unix malloc() when I wrote
this. I more or less inherited the crossposting, but should have narrowed
it.

In any of the above cases, when somebody's pointing out that the
subject is off-topic, there's a pretty fair chance that the original
poster will be insulted to some degree -- even if it's done politely
(which, in fairness, it often isn't).


Saying that something is written in "standard C" is a difficult term
to pin down. Most of these can be written in C that is "conforming",
but not "strictly conforming". Realistically, nearly _all_ useful C
code falls somewhere between those two extremes.

Right, which (IMO) means that your statement:

YOU:
Since these languages are defined by standards,
"C" and "standard C" are synonymous.

Is not true (?). Why is this /not merely/ a symantic argument? Because
being able (IMHO) to understand non-STD likely behavior is critical: When I
was interviewing for C programmers, I *really* needed to hear their
discussions about such things. (This is a larger topic I'll not descend
into, but interviews are not about right nor wrong answers, they are about
the ensuing discussions).

I think the consensus on c.l.c and c.l.c++ is that there's a line
somewhere between those two that's sometimes been (unofficially)
titled "strongly conforming" C -- basically, code that should run on
any reasonable implementation of C, and should produce similar results
on all of them.

The fact is, however, that C and C++ are both used in thousands of
situations (especially if you include non-standard dialects) and
without a pretty strict definition of what's topical and what's not,
the most informative participants would almost inevitably leave. In a
newsgroup that attracts less attention, it's much easier to define the
subject much more broadly, and to allow much more chatting that's only
marginally topical at best.


I think you're making a bit of a mistake between that the standard
_allows_ (which is quite broad) and what the standard says always has
defined behavior (which is considerably narrower). I don't know of
anybody who's claimed that knowing the standard is all there is --

I got considerable flak for suggesting otherwise before. I didn't fully
understand what the latest standards actually said, (I was a C programmer
back when Things Were Rotten), and was educated to that extent, but it was
made clear that asking interviewees questions regarding non-conforming C
constructs was somehow, well, /wrong/.

It's that notion I was hoping to address here.

quite the contrary I think most of the regulars probably consider
problem solving, knowledge of algorithms, style, etc. quite important
-- but they also realize that something that's off-topic is still
off-topic, regardless of how interesting it might be.

I would assume that this is on-topic for:

comp.lang.c
comp.programming

After this post, I'll confine it to those two, but I'm afraid that the cat
is out of the bag.

 

[Keith Thompson]

Newsgroups trimmed to comp.lang.c.
"Thomas G. Marshall"

Dik T. Winter coughed up: [...]
Are you sure about the aim in the comp.lang.c group being "portable C"? I
don't see that as the charter at all. (I apologize for the huge
crosspost---it was inherited, and perhaps I should have narrowed it away
from C++). Here is what the official list of big eight newsgroups says, as
posted continually in news.announce.newsgroups:

comp.lang.c Discussion about C

That list is as "official" as it gets.

Not really. comp.lang.c is too old to have an explicit charter.
Topicality is determined mostly by consensus. The consensus is that
we discuss standard C, as defined by the standard(s). Use of
extensions is often necessary, but we don't discuss the details here;
that's what system-specific newsgroups are for. (Even with the
restriction to standard C, we're in no danger of running out of things
to talk about.)

[...]

Wrong example to use---I see no use for it.

Agreed, "i = i++;" is useful only as an example of bad code.

Here is something that you can gauge "likely behavior", for example on a
byte addressable 32 bit sparcstation 1:

long *a = 0; // C99: not platform independent null pointer
a++; // C99: not allowed to increment null
pointer
printf ("%d\n", a); // C99: not using %p

Likely output on byte addressable, 32 bit data, 32 bit instruction,
machines:

4

This is also useful only as an example of bad code. There are simpler
and more portable ways to print "4" or sizeof(long). If you have code
that attempts to increment a null pointer, it's broken; fix it. (Or,
if it happens to behave as you want it to, you can leave it in place,
but you need to be aware that it's a time bomb waiting to go off when
you recompile on another platform or with a new compiler version.
Risk analysis is left as an exercise.)

It can be useful to understand *why* it prints "4" on many systems,
mostly as a way to understand why C is defined the way it is. But
it's equally important to understand the multiple non-portable
assumptions that are required to conclude that the code will print "4".

 

[Dik T. Winter]

> Dik T. Winter coughed up:

....
Refixing the bad quotes:

>
> I'm not asking anything, I'm making an observation. I need no questions
> answered.

But your observation was about questions asked.

> Are you sure about the aim in the comp.lang.c group being "portable C"? I
> don't see that as the charter at all. (I apologize for the huge
> crosspost---it was inherited, and perhaps I should have narrowed it away
> from C++). Here is what the official list of big eight newsgroups says, as
> posted continually in news.announce.newsgroups:
>
> comp.lang.c Discussion about C
>
> That list is as "official" as it gets.

Yes. comp.lang.c does not have a charter. It did not have a charter when
it was called news.lang.c either. It never has had a charter.

> > Indeed, they can not be written in standard C as the code is
> > necesarily
> > very platform specific. So a newsgroup related to your platform is a
> > better place to ask.
> >

>
> [your newsreader munged the indents here, I'll try to fix:]

My newsreader munges nothing. It inserts my quotation sequence reliably
before every line I quote. When I see lines grow to long I readjust those
lines to suitable length, shifting text from one line to the next. It
appears that your newsreader thinks it is smart enough to reformat
quotations, but isn't. My newsreader does not think it is as smart as
that, so it does not reformat.

>
> You *DON'T* define it. That's the whole point! But you /do/ need to
> understand it. That's /my/ point.

But I do not understand what likely behaviour is. That is *my* point.

> Here is something that you can gauge "likely behavior", for example on a
> byte addressable 32 bit sparcstation 1:
>
> long *a = 0; // C99: not platform independent null pointer
> a++; // C99: not allowed to increment null
> pointer
> printf ("%d\n", a); // C99: not using %p
> Likely output on byte addressable, 32 bit data, 32 bit instruction,
> machines:
> 4
> Portable or not, it was what I would find on nearly all my workstations back
> when I was porting a postscript interpreter to a myriad of them as head of
> the "unix department" (three people lol).

Perhaps. But it is indeed not portable. I have worked on two machines,
one of them byte addressable, 32 bit data, 32 bit instruction, where the
output would *not* be 4. On one of them the output would be "1" (while
sizeof(long) == 8), on the other it would be "2" (with sizeof(long) == 4).
Try porting, say, the Bourne shell to such machines.

> And here is "likely behavior:"
> *((long*)0xc0450000) = 0; // fill specific location with 0.
> (ignoring of course vm issues)
> Of course it's platform specific, but it's still important to understand.

I think the intent is to set "sizeof(long)" chars to 0. There are machines
where that will set "sizeof(long) * 2" chars to 0. There is a large number
of compilers that will flag it as an error. And indeed, it is not allowed
in standard C, for a good reason. Also it may happen that when you
execute that statement on a byte addressable, 32 bit machine, after that
statement some library functions will fail to work (there are machines where
shared libraries are mapped to high addresses). So, what is the purpose of
understanding that statement?

It is the usage of "reliable behaviour" that makes so many programs
non-portable to other systems, and that will get you in the end.

 

[hanzac]

Interesting, maybe this will be useful for some
multi-language/cross-language projects and make the C programmers work
on the Java project.

 

[Merrill & Michele]

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

But that indeed might be in this case, as I might learn how to do so, and
this event, in turn, might allow me to teach nasa a little rocket science.
Although I saw no signs of intelligent life in usenet besides here, how is
crossposting done? MPJ