C to Java Byte Code

[Thomas G. Marshall]

...
Refixing the bad quotes:


But your observation was about questions asked.

So? You said *I'd* better ask in a newsgroup related to my platform. There
is nothing to ask.

....[rip]...

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.

Yes, you're completely correct, I'm sorry. I've never seen OE_QuoteFix
behave this way before. I have no idea what happened to it all of a sudden.
Perhaps it's something in your message source. Perhaps it's the phase of
the moon. I shut it off for now.

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


Perhaps. But it is indeed not portable.

Of course not.

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.

I have worked on machines where the sizeof char, short, and long were all 1,
were all 32 bits, and that example produces 1 for that reason. In my DSP
image processing days in particular I came across a number of odd chips.

But what /byte addressable/ 32 bit data 32 bit instruction machine produced
a 1 for that example /while at the same time/ has a sizeof(long) == 8 ?????
I don't think that's possible: Doesn't C increment a pointer internally by
the sizeof() the object?

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.

Huh? Which? Seriously, an honest question. It is converted to a long
pointer, the contents of which (a long) are filled with 0. A long filled
with 0 says nothing about the number of characters involved. What goes
"into" that location had better be sizeof(long).

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?

In most operating systems, such libraries are most likely in a text segment,
disallowing such manipulation anyway. But it is important to understand the
statement because it might be needed in any number of device drivers or
embedded systems without VM.

....[rip]...

 

[Dik T. Winter]

> news:[email protected]... .... ....
> But what /byte addressable/ 32 bit data 32 bit instruction machine produced
> a 1 for that example /while at the same time/ has a sizeof(long) == 8 ?????
> I don't think that's possible: Doesn't C increment a pointer internally by
> the sizeof() the object?

The byte addressable machine that would return "2" and is a Data General.
The machine that returns "1" is not byte addressable and is a Cray.
But indeed C does increment a pointer by sizeof() of the object. However,
your lines of code:has undefined behaviour also on the third line. printf will probably cast
the pointer to int, but on that byteaddressable machine the layout of a
word pointer is different from the layout of a byte pointer.

>
> Huh? Which? Seriously, an honest question.

Sorry, I indeed was wrong here. But on a Data General MV it will clear
from byte-address 0x1808a0000, probably not what was intended.

> But it is important to understand the
> statement because it might be needed in any number of device drivers or
> embedded systems without VM.

There are (I think) better ways to do it. Anyhow, at the moment you are
working on device drivers you are very platform specific. A statement with
a better chance to survive portability issues would be:
*((long *)(char *)0xc0450000) = 0;
on a machine with a flat address space.

 

[Alfred Z. Newmane]

Refixing the bad quotes:

Could you please not put any white space /before/ the quote character
">"

Like this:

The is quoted text.

Putting white space, like:

> quoted text with whitespace before the quote token.

interfears with quote level color-coders and "quoted text wrap fixers."

I hope you can fix it. If you do not know how, post what reader you are
using, as your headers don't show, and maybe some of us can help.

 

[Chris Torek]

(I dropped comp.lang.c++ and comp.unix.programmer from the
newsgroups line.)

Right, which (IMO) means that your statement:
YOU:
Since these languages are defined by standards,
"C" and "standard C" are synonymous.
Is not true (?).

(It is not clear to me who "you" might have been. Remember that
"you" is both the second person singular and the second person
plural, so this might mean one particular author of one or more
articles in some group(s), or some group of authors. It is also
not at all obvious to me where this statement might have been
made. The claim is true in some contexts, and false in others,
in my opinion.)

Why is this /not merely/ a symantic argument?

(Aside: you mean "semantic"; "symantic" seems like a cross between
this word and Symantec, which is the name of a company that sells
software to help those poor souls who insist on running Microsoft
products. )

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

While I agree on the "ensuing discussion" part, I also have to
agree with Dik Winter on the problem of defining "likely behavior"
for things that are technically "undefined behavior" in C. The
problem here is that what is "likely" on Machine A is often quite
*un*likely on Machine B. Cray compilers that store byte offsets
in high bits within machine-word addreses behave very differently
from Eclipse compilers that store byte addresses in byte pointers
and word addresses in word pointers, and both behave quite differently
from x86-32 C compilers, which are in turn different from x86-64
and Alpha C compilers, and so on.

If I may quote from some private email (with names filed off),
consider writing a C compiler for this Lisp machine (which did
in fact have a C compiler, as I recall):

The 3600 (L-machine) had a 36 bit word, divided up as 4 or 8
bits of tags, and 32 bits of data or 28 bits of memory address.
Memory words were 44 bits, the additional 8 bits being used
for error-correcting code (ECC). The instruction set was that
of a stack machine. The 3600 architecture provided 4,096 hardware
registers, of which half were used as a cache for the top of
the control stack; the rest were used by the microcode and
time-critical routines of the operating system.

(Note that tag bits, which are critical for addressing -- you get
runtime errors if you try to use something improperly according to
its tag bits -- are not even representable as data!)

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

I think it is not *wrong* at all -- but at the same time, if you
(as an interviewer) ask something like:

What is the output from this code fragment?
int *p = 0;
printf("%d\n", p + 1);

you really should be prepared for answers like: "I don't know and
can't know until you give me more information about the system" or
"undefined by the C standard".

If the underlying machine has separate "address" and "data" registers,
and the C compiler passes pointers in address registers (even to
variadic functions like printf()), the output here is quite
unpredictable, because "%d" will print the contents of a data
register, while p+1 will have been passed in an address register.

If someone answers this question with "2" or "4" (depending on what
sizeof(int) they are used to), or even "2 or 4 depending on
sizeof(int)", you might want to watch out. As Mark Twain said,
"It ain't what you don't know that gets you into trouble. It's
what you know for sure that just ain't so."

 

[Thomas G. Marshall]

The byte addressable machine that would return "2" and is a Data General.
The machine that returns "1" is not byte addressable and is a Cray.

As I've said already, I've used similar machines, but you claimed that they
had vastly differing sizeof(long)'s while at the same time yielding such
small results from my example. Please verify-----Does the C on that DG
return 1 yet still have sizeof(long) == 8 ????? Having either one of those
is fine, but I'd like to know if both would be true. And precisely /what/
DG chip is it? It isn't the old Aviion 88000 based system, that was one of
mine.

Recap:

<selfquote (from upthread)>
long *a = 0; // C99: not platform independent null pointer
a++; // C99: not allowed to increment null
pointer

But indeed C does increment a pointer by sizeof() of the object.

So you're wrong then about the sizeof()'s? This is critical. You didn't
directly answer that.

However,
your lines of code:
has undefined behaviour also on the third line.

Of course----The whole thing is undefined behavior if you strictly look at
every system possible.

....[rip]...

Sorry, I indeed was wrong here. But on a Data General MV it will clear
from byte-address 0x1808a0000, probably not what was intended.

A 33 bit address???????????

There are (I think) better ways to do it. Anyhow, at the moment you are
working on device drivers you are very platform specific. A statement with
a better chance to survive portability issues would be:
*((long *)(char *)0xc0450000) = 0;
on a machine with a flat address space.

Doubt that's the case, but again---making it survive portability isn't the
issue either.

The point is to discuss with the applicant what he can /likely/ expect
results to be, and if that includes discussions about the particulars of
various platforms, then all the better. C programmers often have to stray
from the specification.

 

[Thomas G. Marshall]

Alfred Z. Newmane coughed up:

Could you please not put any white space /before/ the quote character
">"

....[rip]...


IS THAT WHAT'S BEEN GOING ON????????????????



Dik T. Winter, if it's ok with you, *please* change that. The *standard* is
to quote a line by placing a ">" at the very beginning of the line.

 

[Thomas G. Marshall]

Chris Torek coughed up:

(I dropped comp.lang.c++ and comp.unix.programmer from the
newsgroups line.)

Good. I had already done that elsewhere as well.

(It is not clear to me who "you" might have been. Remember that
"you" is both the second person singular and the second person
plural, so this might mean one particular author of one or more
articles in some group(s), or some group of authors. It is also
not at all obvious to me where this statement might have been
made.

It was made in the same quoted reply-section that appeared in my post, and
that reply section was fully attributed to Jerry Coffin. It was obvious.
You snipped it away, and hence no longer see it. /Others/ downthread from
here might get confused, which is why I normally don't use "YOU" when making
quotations. But /you/ should have seen the reference right there.

The claim is true in some contexts, and false in others,
in my opinion.)


(Aside: you mean "semantic"; "symantic" seems like a cross between
this word and Symantec, which is the name of a company that sells
software to help those poor souls who insist on running Microsoft
products. )

Point. Thanks.

While I agree on the "ensuing discussion" part, I also have to
agree with Dik Winter on the problem of defining "likely behavior"
for things that are technically "undefined behavior" in C. The
problem here is that what is "likely" on Machine A is often quite
*un*likely on Machine B.

It's "likely" on machine A when you understand how machine A is architected.
That's part of the discussion. But need not be:

It's "likely" in general, when you understand that the vast majority of
machines operate that way. Even if you remove the 75% of intel cpu's which
operate that way, the majority remaining machines IME have similar "likely"
behavior.

In my example, there is the setting of a long pointer to an immediate 0,
incrementing that pointer, and printing it out. These are /all/ no-no's
according to the strict interpretation of the spec. However, the vast
majority of machines will print out a 4. And the vast vast ( ) majority
of machines will allow the first two lines enough such that the printed out
number is the sizeof(long).

Cray compilers that store byte offsets
in high bits within machine-word addreses behave very differently
from Eclipse compilers that store byte addresses in byte pointers
and word addresses in word pointers, and both behave quite differently
from x86-32 C compilers, which are in turn different from x86-64
and Alpha C compilers, and so on.

Sure......and.....well.......yada. This was understood, and part of the
premise.

If I may quote from some private email (with names filed off),
consider writing a C compiler for this Lisp machine (which did
in fact have a C compiler, as I recall):

The 3600 (L-machine) had a 36 bit word, divided up as 4 or 8
bits of tags, and 32 bits of data or 28 bits of memory address.
Memory words were 44 bits, the additional 8 bits being used
for error-correcting code (ECC). The instruction set was that
of a stack machine. The 3600 architecture provided 4,096 hardware
registers, of which half were used as a cache for the top of
the control stack; the rest were used by the microcode and
time-critical routines of the operating system.

(Note that tag bits, which are critical for addressing -- you get
runtime errors if you try to use something improperly according to
its tag bits -- are not even representable as data!)


I think it is not *wrong* at all -- but at the same time, if you
(as an interviewer) ask something like:

What is the output from this code fragment?
int *p = 0;
printf("%d\n", p + 1);

you really should be prepared for answers like: "I don't know and
can't know until you give me more information about the system" or
"undefined by the C standard".

If the underlying machine has separate "address" and "data" registers,
and the C compiler passes pointers in address registers (even to
variadic functions like printf()), the output here is quite
unpredictable, because "%d" will print the contents of a data
register, while p+1 will have been passed in an address register.

If someone answers this question with "2" or "4" (depending on what
sizeof(int) they are used to), or even "2 or 4 depending on
sizeof(int)", you might want to watch out. As Mark Twain said,
"It ain't what you don't know that gets you into trouble. It's
what you know for sure that just ain't so."

The code example that I use is the following, and it sparks a wonderful
conversation:

The preamble are words to the effect of "on a sparcstation 1, but on
basically a byte addressable 32 bit address/data space, etc., nothing
'tricky'"...

long *a = 0;
long *b = 0;
a++;
b++; b++
printf("%d %d %d\n", a, b, b-a);

And I look for the 99% common incorrect answer of "4 8 4", and here them say
"...........oh........." when I explain why the 3rd number is wrong.

Such a discussion is valuable.

 

[Floyd L. Davidson]

Alfred Z. Newmane coughed up:

Could you please not put any white space /before/ the quote character
">"

...[rip]...

IS THAT WHAT'S BEEN GOING ON????????????????



Dik T. Winter, if it's ok with you, *please* change that. The *standard* is
to quote a line by placing a ">" at the very beginning of the line.

The *standard* is that whatever form of reformatting the
newsreader does, it *won't* do it to a line that has leading
white space. Some would of course argue that *no* reformatting
should ever be done by the newsreader! But few would argue that
a newsreader should ever reformat lines with leading white
space. That allows tables, ascii drawings, and other format
specific text in an article. It is clearly very useful.

All that Dik is doing is using the standard method of telling
the newsreader that *he* is formatting his paragraphs the way he
wants the reader to see them, not the way some fool programmer
decided that a newsreader should format them. Given the
newsgroups and the content of his articles (technical newsgroups
about programming, and the articles contained quoted snippets of
program source code which definitely should *not* be
reformatted), it seems like a *very* sharp decision on his part
to notice that he could insure that the quoted text in his
response would indeed still be readable.

If it didn't turn out that way, then *your* newsreader is either
misconfigured or broken.

 

[Alfred Z. Newmane]

"Thomas G. Marshall"

Alfred Z. Newmane coughed up:

Dik T. Winter wrote:
Refixing the bad quotes:

Could you please not put any white space /before/ the quote
character ">"

...[rip]...

IS THAT WHAT'S BEEN GOING ON????????????????



Dik T. Winter, if it's ok with you, *please* change that. The
*standard* is to quote a line by placing a ">" at the very beginning
of the line.

The *standard* is that whatever form of reformatting the
newsreader does, it *won't* do it to a line that has leading
white space. Some would of course argue that *no* reformatting
should ever be done by the newsreader! But few would argue that
a newsreader should ever reformat lines with leading white
space. That allows tables, ascii drawings, and other format
specific text in an article. It is clearly very useful.

All that Dik is doing is using the standard method of telling
the newsreader that *he* is formatting his paragraphs the way he
wants the reader to see them, not the way some fool programmer
decided that a newsreader should format them. Given the
newsgroups and the content of his articles (technical newsgroups
about programming, and the articles contained quoted snippets of
program source code which definitely should *not* be
reformatted), it seems like a *very* sharp decision on his part
to notice that he could insure that the quoted text in his
response would indeed still be readable.

If it didn't turn out that way, then *your* newsreader is either
misconfigured or broken.

I don't reformat quoted text, I only fix word wrap snafus, where you
have full line, followed by another line with 1 or 2 words, then another
full line:

quoted text i na full line blah blah blah
which is
screwy la la la la la

This usuaully happens after a coupel levels of quoting, or when the
person being quoted made their lines too long to begin with, which is
more the case than the former.

The point here, is that 99.9% of UseNet uses >, or |, or soem other
quote character, /without/ and leading white space, and this is how most
quote-level color-coding and broken-word-wrap fixers work, liek for what
I described above, which only serve on the client end, to make the text
mor readable.

I my self use OE Quote Fix, which does wonders for MS's news reader, OE.

 

[Alfred Z. Newmane]

Dik T. Winter coughed up:

Mr Dik Winter, this is the result of white spae before the quote token.
This serves as an exellent example of what can happen, and why we are
asking you to fix this

 

[Floyd L. Davidson]

I don't reformat quoted text, I only fix word wrap snafus, where you
have full line, followed by another line with 1 or 2 words, then another
full line:

I've seen where you attempted to do that, and failed miserably.
Regardless, that *is* reformatting! (And if you do it right, it
isn't bad at all...)

Heh... you want to see something done right?

There is your example text, properly reformatted at 64 columns.
Wanna see something even more fun, here it is a 40 columns,

Now, what I did to do that was fairly easy, since I do use just
about the best newsreader in existence. I copied the original
text (you can see it below) and the first reformat was simply
done by typing two keys, 'ESC' and 'q'. The second required
that I provide an argument to tell it not to use the default 64
columns, so it was "ESC 4 0 ESC q", or 5 keystrokes.

Notice that when I did the cut and paste I left spaces in front
of each line so that your newsreader won't reformat them, and
that when I did a reformat it worked quite well with the white
space prefix. That's the way it works if you have the proper
tools.

This usuaully happens after a coupel levels of quoting, or when the
person being quoted made their lines too long to begin with, which is
more the case than the former.

I see that you format your lines at 70 columns. You'll notice
that I use 64. Sometimes I consider making my lines default to
something even shorter...

The point here, is that 99.9% of UseNet uses >, or |, or soem other

The point you have *missed* is that 99.9% of all Usenet readers
do the appropriate thing with what Dik T. Winters is posting.

The fact that you use one of if not the *worst* newsreaders
available, and apparently both have it misconfigured and don't
understand what it is or is not doing, has no effect on the
correctness of what Dik posted.

quote character, /without/ and leading white space, and this is how most
quote-level color-coding and broken-word-wrap fixers work, liek for what
I described above, which only serve on the client end, to make the text
mor readable.

I my self use OE Quote Fix, which does wonders for MS's news reader, OE.

See above. Why not get a better newsreader?

 

[Floyd L. Davidson]

Mr Dik Winter, this is the result of white spae before the quote token.
This serves as an exellent example of what can happen, and why we are
asking you to fix this

I had my newsreader reformat Dik's article and it came out
looking just fine (see below). If OE won't do that, get a
better newsreader!


Indeed, below is what it looked like *without* reformatting.
Other than the long attribute line, the text ends up at 74
columns... which hardly seems to need reformatting! *Your*
text ends up at 72 columns, should I reformat that too???

 

[Alfred Z. Newmane]

I've seen where you attempted to do that, and failed miserably.
Regardless, that *is* reformatting! (And if you do it right, it
isn't bad at all...)

Heh... you want to see something done right?


There is your example text, properly reformatted at 64 columns.
Wanna see something even more fun, here it is a 40 columns,


Now, what I did to do that was fairly easy, since I do use just
about the best newsreader in existence. I copied the original
text (you can see it below) and the first reformat was simply
done by typing two keys, 'ESC' and 'q'. The second required
that I provide an argument to tell it not to use the default 64
columns, so it was "ESC 4 0 ESC q", or 5 keystrokes.

Notice that when I did the cut and paste I left spaces in front
of each line so that your newsreader won't reformat them, and
that when I did a reformat it worked quite well with the white
space prefix. That's the way it works if you have the proper
tools.


I see that you format your lines at 70 columns. You'll notice
that I use 64. Sometimes I consider making my lines default to
something even shorter...

Ok I get your point. What I meant was I don't use HTML, where one can
muck with the fotns, styles, extra.

Fixing quoting for readability sake should not be a problem.

Nor should asking someone to fix how thye quote text.

The point you have *missed* is that 99.9% of all Usenet readers
do the appropriate thing with what Dik T. Winters is posting.

The fact that you use one of if not the *worst* newsreaders
available, and apparently both have it misconfigured and don't
understand what it is or is not doing, has no effect on the
correctness of what Dik posted.

It may nto be the best news reader, but I'd hardly call it the worst. I
don't think you've seen Netscape/Mozilla Messenger (the one that would
come with NS4 and mozilla equivalent at least.)

OE is actually a pretty solid news reader, if one knows how to use it
right. OEQuoteFix fixes the quoting/wrapping problems it has, which has
always been the biggest problem, it also color-codes quoted text, which
is also a godsend. Through the ability to sort Watched threads /AND/
still sort by Date, I'd say it's a decent reader, when used with
OEQuoteFix.

If you don't want to use it, fine. We all use what we are comfortable
with.

(That said, if you know of a better news reader that can do what I
mentioned, I'll be open & happy to try something new.)

 

[Alfred Z. Newmane]

Floyd L. Davidson wrote:
[...]

The point you have *missed* is that 99.9% of all Usenet readers
do the appropriate thing with what Dik T. Winters is posting.

I have to respectifully disagree. Most news readers that do some sort of
color coding and/or lien wrap fixing wont treat quoted text with leading
quotespace /before/ the quote char as quote, but as local text. Hence
the request I and others have made.

 

[Randy Howard]

Floyd,

Sorry for the NMI in the middle of this otherwise interesting
newsreader war, but what is the correct pronunciation of
"Ukpeagvik"??

 

[Alfred Z. Newmane]

I had my newsreader reformat Dik's article and it came out
looking just fine (see below). If OE won't do that, get a
better newsreader!

I must onec again respectfully disagree; it has long been accepted on
UseNet to use a 72 column, starting with the console/terminal based
readers.

The text after "Dik T. Winter coughed up:" is in fact Thomas's quoting
of Dik, which got horribly miss wrapped, mainly because of the white
space before his quote char. Why should everyone change the way thing
have bene done the past decade anda half because one person decides to
diverge from that accepted norm?

 

[Floyd L. Davidson]

Floyd,

Sorry for the NMI in the middle of this otherwise interesting
newsreader war, but what is the correct pronunciation of
"Ukpeagvik"??

Oh, probably you'd be best understood if you say it

B a r r o w !

However, youk'-pee-agg-vik is probably as close as I can come to
right. The emphasis is on the first 'k'. I'm not sure about
that first syllable either, and "ook" or "you-uk" is what I
hear, but my ears are not good and I know that I don't hear the
subtle differences in many words.

There are other spellings too. Utqiagvik and Ukpiagvik are also
commonly seen.

At one time there was another village, Nuwuk, right out on Point
Barrow, but it hasn't been occupied since the 1930's or so.

 

[Floyd L. Davidson]

I must onec again respectfully disagree; it has long been accepted on
UseNet to use a 72 column, starting with the console/terminal based
readers.

The "accepted" thing is simply don't make the line longer than
80. Everybody and their brother has a different idea of exactly
how much less than 80 is acceptable.

The text after "Dik T. Winter coughed up:" is in fact Thomas's quoting
of Dik, which got horribly miss wrapped, mainly because of the white
space before his quote char.

It got messed up *only* because someone attempted to reformat it
with a program unable to do it properly. 1) the text should
*not* be reformatted automatically, because it has leading white
space, 2) the text should not be manually reformatted with a
program that cannot correctly handle leading white space.

And *clearly* appropriate software exists, as I demonstrated to
you exactly how nicely it is done by Gnus.

Why should everyone change the way thing
have bene done the past decade anda half because one person decides to
diverge from that accepted norm?

Dik was *very astute* in placing the white space as he did,
given that the text contained a snipped of source code that
would be mangled by any reformatting.

The fact that you 1) don't know that Usenet has existed for 25
years now, and 2) don't know what the appropriate effect of
leading white space is, still won't make OE anything other than
a bit of trash that you should replace.

 

[Dik T. Winter]

>
> Could you please not put any white space /before/ the quote character
> ">"

You know. I do it on purpose. You are the third person complaining in the
about 20 years I am posting on Usenet.

> Putting white space, like:
> interfears with quote level color-coders and "quoted text wrap fixers."

But it makes quotations clearer for those not using quote level color-codes.

> I hope you can fix it. If you do not know how, post what reader you are
> using, as your headers don't show, and maybe some of us can help.

I know how to change it, and my newsreader is rn, thank you.

 

[Dik T. Winter]

> Dik T. Winter, if it's ok with you, *please* change that. The *standard* is
> to quote a line by placing a ">" at the very beginning of the line.

What standard?