C to Java Byte Code

[Dik T. Winter]

Re: Not STD C is "not C" ? ----WAS: Re: C to Java Byte Code

In article <Bltgd.6$304.0@ trndny06> "Thomas G. Marshall" <tgm2tothe10thp ower@replacetex twithnumber.hot mail.com> writes:
....[color=blue]
> 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.[/color]

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.
[color=blue]
> 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[/color]

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.
[color=blue]
> 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.[/color]

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(d ouble) * 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.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Jerry Coffin]

Re: Not STD C is &quot;not C&quot; ? ----WAS: Re: C to Java Byte Code

"Thomas G. Marshall" <tgm2tothe10thp ower@replacetex twithnumber.hot mail.com> wrote in message news:<Bltgd.6$3 04.0@trndny06>. ..

[ ... ]
[color=blue]
> There is a *prevailing* notion that:
>
> If it ain't standard C, it ain't C[/color]

This is more than a mere notion: it's a tautology, since C is defined
by the standard.
[color=blue]
> 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[/color]

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.progr amming, 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.progr ammer.

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).
[color=blue]
> 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[/color]

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.
[color=blue]
> 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.[/color]

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.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Thomas G. Marshall]

Re: Not STD C is &quot;not C&quot; ? ----WAS: Re: C to Java Byte Code

Dik T. Winter coughed up:[color=blue]
> In article <Bltgd.6$304.0@ trndny06> "Thomas G. Marshall"
> <tgm2tothe10thp ower@replacetex twithnumber.hot mail.com> writes: ...[color=green]
> > I don't see i=i++ as ever anything useful, but 45° tangental to[/color]
> this > original thread is something that bothers me. There is a
> *prevailing* > notion that:[color=green]
> > If it ain't standard C, it ain't C
> > which I think is not quite true.[/color]
>
> 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.[/color]

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.n ewsgroups:

comp.lang.c Discussion about C

That list is as "official" as it gets.

[color=blue]
>[color=green]
> > It's important because[/color]
> there are > many things that cannot be written in standard C that
> are nonetheless useful > to write in non-std C:[color=green]
> >
> > Device Drivers (usually)
> > malloc()
> > Anything embedded that needs to tweek memory
> > mapped registers[/color]
>
> 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.
>[/color]

[your newsreader munged the indents here, I'll try to fix:]
[color=blue][color=green]
>> 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.[/color]
>
> But what is likely behaviour? How do you define that?[/color]

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

[color=blue]
> The only
> behaviour
> that is likely about "i = i++;"[/color]

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*)0xc045 0000) = 0; // fill specific location with 0.
(ignoring of course vm issues)

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


[color=blue]
> 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.[/color]

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


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

[Thomas G. Marshall]

Re: Not STD C is &quot;not C&quot; ? ----WAS: Re: C to Java Byte Code

Jerry Coffin coughed up:[color=blue]
> "Thomas G. Marshall"
> <tgm2tothe10thp ower@replacetex twithnumber.hot mail.com> wrote in
> message news:<Bltgd.6$3 04.0@trndny06>. ..
>
> [ ... ]
>[color=green]
>> There is a *prevailing* notion that:
>>
>> If it ain't standard C, it ain't C[/color]
>
> This is more than a mere notion: it's a tautology, since C is defined
> by the standard.
>[color=green]
>> 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[/color]
>
> 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.progr amming, 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.progr ammer.[/color]

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.

[color=blue]
> 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).
>[color=green]
>> 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[/color]
>
> 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.[/color]

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

[color=blue]
> 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.
>[color=green]
>> 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.[/color]
>
> 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 --[/color]

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.

[color=blue]
> 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.[/color]

I would assume that this is on-topic for:

comp.lang.c
comp.programmin g

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





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

[Dik T. Winter]

Re: Not STD C is &quot;not C&quot; ? ----WAS: Re: C to Java Byte Code

In article <wAPgd.512$fw2. 217@trndny01> "Thomas G. Marshall" <tgm2tothe10thp ower@replacetex twithnumber.hot mail.com> writes:[color=blue]
> Dik T. Winter coughed up:[/color]
....
Refixing the bad quotes:
[color=blue][color=green]
> > 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.[/color]
>
> I'm not asking anything, I'm making an observation. I need no questions
> answered.[/color]

But your observation was about questions asked.
[color=blue]
> 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.n ewsgroups:
>
> comp.lang.c Discussion about C
>
> That list is as "official" as it gets.[/color]

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.
[color=blue][color=green]
> > 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.
> >[/color]
>
> [your newsreader munged the indents here, I'll try to fix:][/color]

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.
[color=blue][color=green]
> > But what is likely behaviour? How do you define that?[/color]
>
> You *DON'T* define it. That's the whole point! But you /do/ need to
> understand it. That's /my/ point.[/color]

But I do not understand what likely behaviour is. That is *my* point.
[color=blue]
> 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).[/color]

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.
[color=blue]
> And here is "likely behavior:"
> *((long*)0xc045 0000) = 0; // fill specific location with 0.
> (ignoring of course vm issues)
> Of course it's platform specific, but it's still important to understand.[/color]

I think the intent is to set "sizeof(lon g)" chars to 0. There are machines
where that will set "sizeof(lon g) * 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.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[hanzac@hotmail.com]

Re: C to Java Byte Code

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]

Re: Welcome back Paul Lutus

[color=blue][color=green]
> >E. Robert Tisdale:
> >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. :-)[/color][/color]
[color=blue]
> Richard Herring:
> Please don't trollishly crosspost between C and C++ groups. The outcome
> is rarely beneficial.[/color]

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

[Alfred Z. Newmane]

Re: Not STD C is &quot;not C&quot; ? ----WAS: Re: C to Java Byte Code

Dik T. Winter wrote:[color=blue]
> In article <wAPgd.512$fw2. 217@trndny01> "Thomas G. Marshall"
> <tgm2tothe10thp ower@replacetex twithnumber.hot mail.com> writes: > Dik
> T. Winter coughed up: ...
> Refixing the bad quotes:[/color]

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

Like this:
[color=blue]
> The is quoted text.[/color]

Putting white space, like:
[color=blue]
> quoted text with whitespace before the quote token.[/color]

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.

[Thomas G. Marshall]

Re: Not STD C is &quot;not C&quot; ? ----WAS: Re: C to Java Byte Code

Alfred Z. Newmane coughed up:[color=blue]
> Dik T. Winter wrote:[color=green]
>> In article <wAPgd.512$fw2. 217@trndny01> "Thomas G. Marshall"
>> <tgm2tothe10thp ower@replacetex twithnumber.hot mail.com> writes: > Dik
>> T. Winter coughed up: ...
>> Refixing the bad quotes:[/color]
>
> Could you please not put any white space /before/ the quote character
> ">"[/color]

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


--
Everythinginlif eisrealative.Ap ingpongballseem ssmalluntilsome oneramsitupyour n
ose.

[Floyd L. Davidson]

Re: Not STD C is &quot;not C&quot; ? ----WAS: Re: C to Java Byte Code

"Thomas G. Marshall" <tgm2tothe10thp ower@replacetex twithnumber.hot mail.com> wrote:[color=blue]
>Alfred Z. Newmane coughed up:[color=green]
>> Dik T. Winter wrote:[color=darkred]
>>> In article <wAPgd.512$fw2. 217@trndny01> "Thomas G. Marshall"
>>> <tgm2tothe10thp ower@replacetex twithnumber.hot mail.com> writes: > Dik
>>> T. Winter coughed up: ...
>>> Refixing the bad quotes:[/color]
>>
>> Could you please not put any white space /before/ the quote character
>> ">"[/color]
>
>...[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.[/color]

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.

--
FloydL. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.co m

[Alfred Z. Newmane]

Re: Not STD C is &quot;not C&quot; ? ----WAS: Re: C to Java Byte Code

Floyd L. Davidson wrote:[color=blue]
> "Thomas G. Marshall"
> <tgm2tothe10thp ower@replacetex twithnumber.hot mail.com> wrote:[color=green]
>> Alfred Z. Newmane coughed up:[color=darkred]
>>> Dik T. Winter wrote:
>>>> In article <wAPgd.512$fw2. 217@trndny01> "Thomas G. Marshall"
>>>> <tgm2tothe10thp ower@replacetex twithnumber.hot mail.com> writes: >
>>>> Dik T. Winter coughed up: ...
>>>> Refixing the bad quotes:
>>>
>>> Could you please not put any white space /before/ the quote
>>> character ">"[/color]
>>
>> ...[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.[/color]
>
> 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.[/color]

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:
[color=blue]
> quoted text i na full line blah blah blah
> which is
> screwy la la la la la[/color]

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]

Re: Not STD C is &quot;not C&quot; ? ----WAS: Re: C to Java Byte Code

Thomas G. Marshall wrote:[color=blue]
> Dik T. Winter coughed up:[color=green]
> > In article <Bltgd.6$304.0@ trndny06> "Thomas G. Marshall"
> > <tgm2tothe10thp ower@replacetex twithnumber.hot mail.com> writes: ...[color=darkred]
> > > I don't see i=i++ as ever anything useful, but 45° tangental to[/color]
> > this > original thread is something that bothers me. There is a
> > *prevailing* > notion that:[color=darkred]
> > > If it ain't standard C, it ain't C
> > > which I think is not quite true.[/color][/color][/color]

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]

Re: Not STD C is &quot;not C&quot; ? ----WAS: Re: C to Java Byte Code

"Alfred Z. Newmane" <a.newmane.remo ve@eastcoastcz. com> wrote:[color=blue]
>Floyd L. Davidson wrote:[color=green]
>> If it didn't turn out that way, then *your* newsreader is either
>> misconfigured or broken.[/color]
>
>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:[/color]

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?
[color=blue][color=green]
>> quoted text i na full line blah blah blah which is screwy la
>> la la la la[/color][/color]

There is your example text, properly reformatted at 64 columns.
Wanna see something even more fun, here it is a 40 columns,
[color=blue][color=green]
>> quoted text i na full line blah blah
>> blah which is screwy la la la la la[/color][/color]

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.
[color=blue][color=green]
>> quoted text i na full line blah blah blah
>> which is
>> screwy la la la la la[/color]
>
>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.[/color]

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...
[color=blue]
>The point here, is that 99.9% of UseNet uses >, or |, or soem other[/color]

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.
[color=blue]
>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.[/color]

See above. Why not get a better newsreader?

--
FloydL. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.co m

[Floyd L. Davidson]

Re: Not STD C is &quot;not C&quot; ? ----WAS: Re: C to Java Byte Code


"Alfred Z. Newmane" <a.newmane.remo ve@eastcoastcz. com> wrote:[color=blue]
>Thomas G. Marshall wrote:[color=green]
>> Dik T. Winter coughed up:[color=darkred]
>> > In article <Bltgd.6$304.0@ trndny06> "Thomas G. Marshall"
>> > <tgm2tothe10thp ower@replacetex twithnumber.hot mail.com> writes: ...
>> > > 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.[/color][/color]
>
>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 :-)[/color]

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!

"Dik T. Winter" <Dik.Winter@cwi .nl> wrote:[color=blue]
>In article <Bltgd.6$304.0@ trndny06> "Thomas G. Marshall"
><tgm2tothe10th power@replacete xtwithnumber.ho tmail.com> writes:
>...[color=green]
> > 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.[/color][/color]

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

"Dik T. Winter" <Dik.Winter@cwi .nl> wrote:[color=blue]
>In article <Bltgd.6$304.0@ trndny06> "Thomas G. Marshall" <tgm2tothe10thp ower@replacetex twithnumber.hot mail.com> writes:
>...[color=green]
> > 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.[/color]
>
>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.[/color]

--
FloydL. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.co m

[Alfred Z. Newmane]

Re: Not STD C is &quot;not C&quot; ? ----WAS: Re: C to Java Byte Code

Floyd L. Davidson wrote:[color=blue]
> "Alfred Z. Newmane" <a.newmane.remo ve@eastcoastcz. com> wrote:[color=green]
> > Floyd L. Davidson wrote:[color=darkred]
> > > If it didn't turn out that way, then *your* newsreader is either
> > > misconfigured or broken.[/color]
> >
> > 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:[/color]
>
> 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?
>[color=green][color=darkred]
> >> quoted text i na full line blah blah blah which is screwy la
> >> la la la la[/color][/color]
>
> There is your example text, properly reformatted at 64 columns.
> Wanna see something even more fun, here it is a 40 columns,
>[color=green][color=darkred]
> >> quoted text i na full line blah blah
> >> blah which is screwy la la la la la[/color][/color]
>
> 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.
>[color=green][color=darkred]
> > > quoted text i na full line blah blah blah
> > > which is
> > > screwy la la la la la[/color]
> >
> > 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.[/color]
>
> 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...[/color]


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.
[color=blue][color=green]
> > The point here, is that 99.9% of UseNet uses >, or |, or soem other[/color]
>
> 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.[/color]

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