C to Java Byte Code

[napi]

I think you would agree with me that a C compiler that directly
produces Java Byte Code to be run on any JVM is something that is
missing to software programmers so far. With such a tool one could
stay with C and still be able to produce Java byte code for
platform independent apps. Also, old programs (with some tweaking)
could be re-compiled and ported to the JVM.

We have been developing such a tool over the last 2 years and currently
beta testing it.

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

Napi

[Arthur J. O'Dwyer]

On Wed, 27 Oct 2004, Alfred Z. Newmane wrote:

Richard Tobin wrote:

Alfred Z. Newmane <a.**************@eastcoastcz.com> wrote:

int i = 3;
i = i++;

The code itself is fine;

No. It starts with the value 3, which is the value of the right-hand
side. Then that value is assigned to i, and i is incremented, but the
order of these two operations is not defined.

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

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

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

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

HTH,
-Arthur

[Old Wolf]

"Alfred Z. Newmane" <a.**************@eastcoastcz.com> wrote :

Old Wolf wrote:

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

int i = 3;
i = i++;
printf("%d\n", i);
How is non portable?

Please read the FAQ entry pertaining to this:
http://www.eskimo.com/~scs/C-faq/q3.3.html
The code it self is fine; i starts with a value of 3, then i gets
assigned to itself, *after* which it gets ++ed. Remember, ++ after the
variable (post inc) takes place *after* the evaluation.
A common misconception. The ++ can occur either before or
after the evaluation (and either before or after the assignment,
in this example). The same goes for pre-increment.
The only difference between pre- and post- increment is that
the result of evaluating is (i) for post- and (i+1) for pre- .
In other words it's the same as:

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

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

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

static int i;

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

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

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

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

[Alfred Z. Newmane]

Old Wolf wrote:

"Alfred Z. Newmane" <a.**************@eastcoastcz.com> wrote :

Old Wolf wrote:

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

int i = 3;
i = i++;
printf("%d\n", i);
How is non portable?

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

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

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

In other words it's the same as:

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

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

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

static int i;

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

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

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

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

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

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

static int i;

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

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

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

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

$ ./test
3

[Richard Bos]

ol*****@inspire.net.nz (Old Wolf) wrote:

"Alfred Z. Newmane" <a.**************@eastcoastcz.com> wrote :

Old Wolf wrote:

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

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

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

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

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

Richard

[Richard Herring]

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

Richard Herring wrote:

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

Richard Herring wrote:
In message <10*************@corp.supernews.com>, Paul Lutus
<no****@nosite.zzz> writes
> Mark McIntyre wrote:
>
>> Marvellous. Since this has nothing to do with C any more,
>
> Do you see a reference to C in the sentence above? No? Is there an
> optometrist available in your neighborhood?
>
> The discussion is about a C to Java cross-compiler. Both languages
> are therefore topical.

Not in comp.lang.c++, they are not. Please take this elsewhere.

Richard, is it going to warp the the fecking space time continuum to
get off your high horse about a topic that is just maybe mere ounces
off topic?
Why is it so important to you to continue crossposting this thread?
What's your agenda? I

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

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

In case you haven't noticed, C and even Java are related languages;
many who use one use or have experience with the others,
In case _you_ haven't noticed, C and C++ are even more closely related
languages, yet comp.lang.c and comp.lang.c++ are separate groups and
there are good reasons for that.

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

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

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

Where did I claim to do that?

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

For some value of "trying to decide" equal to "suggesting", maybe. The
Followup-To header isn't some kind of autocratic overriding of others'
freedom.
Not that this part of the thread matters all that
much, your attempt goes meaningless.

when it might be of interest of people
there?
"Might be"? Have you actually read this group before today?

Yes, plenty, what is your point?

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

As it is, I see no evidence that you've ever made any contribution at
all to the group, or that you have posted anywhere at all under your
current pseudonym until less than a week ago.
People from all these groups may read
one of these groups a lot more then the others. Even if not, why do
*YOU* care?
Never heard of Gresham's law? Too much junk, and the useful
contributors can't even find the sensible threads, so they give up
posting.
If you don't want to see this thread in that group, then
kill file it.

Who the hell is holding a gun to your head making you read this thread?
Ah, the cry of every cross-posting troll since the beginning of usenet.

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

Nice try, but that was never the point.

It's the point of clc++. If you don't realise that, you can't possibly
have read the group for any length of time, as you claimed.
The point was, as you actually
said, that the c and c++ groups are rather seperated, but people in
either might be *interested* in this topic, as it bares some relation.
So far you've failed to demonstrate any.
The original post was not a direct C post, nor was it a direct Java
post, but a post about a utility, that if it works, could be a useful
program.
But the thread has long since degenerated into Paul "never wrong" Lutus
v the world, demonstrating that he doesn't understand the concept of
emulation. Now, I see, we're even getting the "i=i++" debate recycled
for the millionth time. And you are seriously advocating this as an
exemplar of crossposting?
In that sense, there really seems to be no real reason to shout "off
topic" for only in the name of 100% conformity and ultimately complete
utter inflexibility. Only if you really feel the need to make noise by
making a unnecessary fuss.

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

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

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

--
Richard Herring

[Richard Tobin]

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

Richard Tobin wrote:

No. It starts with the value 3, which is the value of the right-hand
side. Then that value is assigned to i, and i is incremented, but the
order of these two operations is not defined.

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

No. The possibilities include

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

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

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

where i ends up as 3.

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

-- Richard

[Richard Tobin]

In article <41****************@news.individual.net>,
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:

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

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

-- Richard

[John Bode]

"Alfred Z. Newmane" <a.**************@eastcoastcz.com> wrote in message news:<2u*************@uni-berlin.de>...

Old Wolf wrote:

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

Old Wolf wrote:

Sorry, you are wrong. There is no requirement in the C standard for
the members of the union to occupy the same piece of memory.
If you disagree then please quote a standard reference.

http://explanation-guide.info/meanin...age-union.html

"Because they occupy the same space, changing u.a also changes the
value of u.b."

"The primary usefulness of a union is to conserve space, since it
provides a way of letting many different types be stored in the same
space."

There are plenty of similar references

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

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

> Show us the Java bytecode that allows one to manipulate
> individual bits of a Java float datatype, as a C union allows.

A C union does not allow that.
Any C program that relies on it is non-portable.

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

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

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

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

Here's a slightly different example:

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

int main (void)
{
int i, j;

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

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

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

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

return 0;
}

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

Hmmmmm...

[Alfred Z. Newmane]

Richard Tobin wrote:

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

Richard Tobin wrote:

No. It starts with the value 3, which is the value of the
right-hand side. Then that value is assigned to i, and i is
incremented, but the order of these two operations is not defined.

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

No. The possibilities include

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

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

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

where i ends up as 3.

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

[Alfred Z. Newmane]

Richard Tobin wrote:

In article <41****************@news.individual.net>,
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:

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

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

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

[Alex Fraser]

"Alfred Z. Newmane" <a.**************@eastcoastcz.com> wrote in message
news:2u*************@uni-berlin.de...

Richard Tobin wrote:

[snip]

No. The possibilities include

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

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

Sounds good.

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

where i ends up as 3.

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

Given:
i = i++;

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

Alex

[Flash Gordon]

On Thu, 28 Oct 2004 09:30:25 -0700
"Alfred Z. Newmane" <a.**************@eastcoastcz.com> wrote:

Richard Tobin wrote:

<snip i = i++>

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

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

This is not actually a completely unreasonable implementation. It makes
sense because i++ is the post increment, so it's value is the value
before incrementing, so if a processor has an instruction for
incrementing data in RAM (I know some processors do) it is reasonable to
use the values in the expression, then do the in-place increment, then
save the result.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Old Wolf]

"Alfred Z. Newmane" <a.**************@eastcoastcz.com> wrote:

Old Wolf wrote:

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

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

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

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

static int i;

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

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

return 0;
}

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.

[Flash Gordon]

On Thu, 28 Oct 2004 09:33:30 -0700
"Alfred Z. Newmane" <a.**************@eastcoastcz.com> wrote:

Richard Tobin wrote:

In article <41****************@news.individual.net>,
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:

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

occur> simultaneously. It isn't inconceivable for this to crash the
program> rather abruptly, or to write a completely unpredictable
value to i.

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

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

There is one very good safeguard. Don't do things the C standard leaves
undefined. The compiler might me making use of the leeway provided (such
as the time when the increment occurs) to do all sorts of strange and
wonderful optimisations. That is (presumably) why the C language defines
sequence points and that it is only once you reach a sequence point that
you can be certain that all the side effects have occurred.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Richard Tobin]

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

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

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

--
"It's easier to be terrified by an enemy you admire."
-Thufir Hawat, Mentat and Master of Assassins to House Atreides

[Programmer Dude]

Thomas G. Marshall writes:

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]

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.

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

In article <Bltgd.6$304.0@trndny06> "Thomas G. Marshall" <tg****************@replacetextwithnumber.hotmail. 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.
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.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Jerry Coffin]

"Thomas G. Marshall" <tg****************@replacetextwithnumber.hotmail. com> wrote in message news:<Bltgd.6$304.0@trndny06>...

[ ... ]

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.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Thomas G. Marshall]

Dik T. Winter coughed up:

In article <Bltgd.6$304.0@trndny06> "Thomas G. Marshall"
<tg****************@replacetextwithnumber.hotmail. 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.

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.

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

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

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?

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

Jerry Coffin coughed up:

"Thomas G. Marshall"
<tg****************@replacetextwithnumber.hotmail. com> wrote in
message news:<Bltgd.6$304.0@trndny06>...

[ ... ]

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

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.

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.

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

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.

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

In article <wAPgd.512$fw2.217@trndny01> "Thomas G. Marshall" <tg****************@replacetextwithnumber.hotmail. com> writes:

Dik T. Winter coughed up: ....
Refixing the bad quotes:

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.

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.

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.

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.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

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

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

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

[Alfred Z. Newmane]

Dik T. Winter wrote:

In article <wAPgd.512$fw2.217@trndny01> "Thomas G. Marshall"
<tg****************@replacetextwithnumber.hotmail. com> writes: > Dik
T. Winter coughed up: ...
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.

[Thomas G. Marshall]

Alfred Z. Newmane coughed up:

Dik T. Winter wrote:

In article <wAPgd.512$fw2.217@trndny01> "Thomas G. Marshall"
<tg****************@replacetextwithnumber.hotmail. com> writes: > Dik
T. Winter coughed up: ...
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.
--
Everythinginlifeisrealative.Apingpongballseemssmal luntilsomeoneramsitupyourn
ose.

[Floyd L. Davidson]

"Thomas G. Marshall" <tg****************@replacetextwithnumber.hotmail. com> wrote:

Alfred Z. Newmane coughed up:

Dik T. Winter wrote:

In article <wAPgd.512$fw2.217@trndny01> "Thomas G. Marshall"
<tg****************@replacetextwithnumber.hotmail. com> writes: > Dik
T. Winter coughed up: ...
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.

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

[Alfred Z. Newmane]

Floyd L. Davidson wrote:

"Thomas G. Marshall"
<tg****************@replacetextwithnumber.hotmail. com> wrote:

Alfred Z. Newmane coughed up:

Dik T. Winter wrote:
In article <wAPgd.512$fw2.217@trndny01> "Thomas G. Marshall"
<tg****************@replacetextwithnumber.hotmail. com> writes: >
Dik T. Winter coughed up: ...
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]

Thomas G. Marshall wrote:

Dik T. Winter coughed up:

In article <Bltgd.6$304.0@trndny06> "Thomas G. Marshall"
<tg****************@replacetextwithnumber.hotmail. 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.

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]

"Alfred Z. Newmane" <a.**************@eastcoastcz.com> wrote:

Floyd L. Davidson wrote:

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:

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?

quoted text i na full line blah blah blah which is screwy la
la la la la
There is your example text, properly reformatted at 64 columns.
Wanna see something even more fun, here it is a 40 columns,
quoted text i na full line blah blah
blah which is screwy la la la la la
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.
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.

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?

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

[Floyd L. Davidson]

"Alfred Z. Newmane" <a.**************@eastcoastcz.com> wrote:

Thomas G. Marshall wrote:

Dik T. Winter coughed up:

> In article <Bltgd.6$304.0@trndny06> "Thomas G. Marshall"
> <tg****************@replacetextwithnumber.hotmail. 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.

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!

"Dik T. Winter" <Di********@cwi.nl> wrote:In article <Bltgd.6$304.0@trndny06> "Thomas G. Marshall"
<tg****************@replacetextwithnumber.hotmail .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.

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" <Di********@cwi.nl> wrote:In article <Bltgd.6$304.0@trndny06> "Thomas G. Marshall" <tg****************@replacetextwithnumber.hotmail. 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.

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.

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

[Alfred Z. Newmane]

Floyd L. Davidson wrote:

"Alfred Z. Newmane" <a.**************@eastcoastcz.com> wrote:

Floyd L. Davidson wrote:

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:

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?

>> quoted text i na full line blah blah blah which is screwy la
>> la la la la
There is your example text, properly reformatted at 64 columns.
Wanna see something even more fun, here it is a 40 columns,
>> quoted text i na full line blah blah
>> blah which is screwy la la la la la
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.
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.

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

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

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"??
--
Randy Howard (2reply remove FOOBAR)

[Alfred Z. Newmane]

Floyd L. Davidson wrote:

"Alfred Z. Newmane" <a.**************@eastcoastcz.com> wrote:

Thomas G. Marshall wrote:

Dik T. Winter coughed up:
In article <Bltgd.6$304.0@trndny06> "Thomas G. Marshall"
<tg****************@replacetextwithnumber.hotmail. 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.

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!

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]

Randy Howard <ra*********@FOOverizonBAR.net> wrote:

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.

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

[Floyd L. Davidson]

"Alfred Z. Newmane" <a.**************@eastcoastcz.com> wrote:

Floyd L. Davidson wrote:

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

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

[Dik T. Winter]

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

Dik T. Winter wrote:

In article <wAPgd.512$fw2.217@trndny01> "Thomas G. Marshall"
<tg****************@replacetextwithnumber.hotmail. com> writes: > Dik
T. Winter coughed up: ...
Refixing the bad quotes:
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:

> quoted text with whitespace before the quote token. 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, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Floyd L. Davidson]

"Alfred Z. Newmane" <a.**************@eastcoastcz.com> wrote:

Floyd L. Davidson wrote:

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

That won't make OE any better, but you do have a point that it
may not be the worst. But... what I said was "one of if not
the"... ;-) (There are several that actually are worse, to the
point of being simply unusable in any reasonable fashion.)
OE is actually a pretty solid news reader, if one knows how to use it
Cough. giggle. choke. laugh. Barrrfffffff!

(Now just look at the mess on my keyboard! I'm not worried
about how Dik quotes text, but I sure wish you wouldn't say
things like *that*.)
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.
I'm not sure what "Watched threads" do in OE, but as one example,
Gnus (which is an eLisp package for news and email that runs
under either Emacs or XEmacs) does all of your other
requirements, plus a great deal more. And it comes with its own
little editor too. ;-)
(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.)

I think most folks that use Microsoft systems recommend Forte
Agent, though I haven't kept up on that for a long time. There
is a free version and a commercial (greatly enhanced) version
too. Somebody who uses an MS platform can give you better
advice on that.

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

[Dik T. Winter]

In article <hcbhd.842$o52.240@trndny03> "Thomas G. Marshall" <tg****************@replacetextwithnumber.hotmail. com> writes:
....

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?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Dik T. Winter]

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

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 generally reformat text I quoted to remain in my 80 character window.
Including all quote characters that are needed to make it a full textual
quote with reasonably filled lines. (Yes, I say 80, but in general I
keep it quite a bit below that figure.)

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.

This generally happens when a newsreader tries to reformat quotes without
having the faintest idea.
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.

My point is that (with my non-colour coded newsreader) I find quotes
flushed to the left quite unreadable, and unseparable from the actual
new text.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Dik T. Winter]

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

Thomas G. Marshall wrote:

Dik T. Winter coughed up:

In article <Bltgd.6$304.0@trndny06> "Thomas G. Marshall"
<tg****************@replacetextwithnumber.hotmail. 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.

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

My newsreader is a bit more intelligent. I have instructed it to insert
" > " before quotations. But if the quoted text already starts with a
space it will only insert " >".
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Floyd L. Davidson]

"Dik T. Winter" <Di********@cwi.nl> wrote:

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

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.

My point is that (with my non-colour coded newsreader) I find quotes
flushed to the left quite unreadable, and unseparable from the actual
new text.

I had to look twice to even figure out what they were
complaining about. Gnus does "quote-level color-coding", and it
works just as expected... which is to say quite correctly with
your articles as well as with others.

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

[Thomas G. Marshall]

Floyd L. Davidson coughed up:

....[rip]...

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

You've tried them all, have you?

And that number isn't weighted by the number of folks actually using them.
I'm guessing that the number of folks using OE with OE_QuoteFix is very
large.

And this is the first time I've ever seen this issue before, and I've been
in usenet for a long time. So Dik T. Winters' style post is certainly not a
common occurrence.

....[rip]...

--
Onedoctortoanother:"Ifthisismyrectalthermometer,wh erethehell'smypen???"

[Thomas G. Marshall]

"Dik T. Winter" <Di********@cwi.nl> wrote in message
news:I6********@cwi.nl...

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

> Dik T. Winter wrote:

> > In article <wAPgd.512$fw2.217@trndny01> "Thomas G. Marshall"
> > <tg****************@replacetextwithnumber.hotmail. com> writes: > Dik
> > T. Winter coughed up: ...
> > Refixing the bad quotes:

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

OE_QuoteFix didn't exist back that far.

Well, let me put it a slightly different way:

1. OE is enormously common.
2. More and more OE folks are using OE_QuoteFix
3. OE_QuoteFix does not regard {space}{reply marker}
as part of a reply.

So you're going to be dedicatedly producing posts that are hard to reply to
for a rather large number of people.

....[rip]...

--
It'salwaysbeenmygoalinlifetocreateasignaturethaten dedwiththeword"blarphoogy"
..

[Alfred Z. Newmane]

Thomas G. Marshall wrote:

Floyd L. Davidson coughed up:

...[rip]...

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

You've tried them all, have you?

And that number isn't weighted by the number of folks actually using
them. I'm guessing that the number of folks using OE with OE_QuoteFix
is very large.

And this is the first time I've ever seen this issue before, and I've
been in usenet for a long time. So Dik T. Winters' style post is
certainly not a common occurrence.

And as I was trying to point out, it's not common for very good reasons.

[Alfred Z. Newmane]

Thomas G. Marshall wrote:

"Dik T. Winter" <Di********@cwi.nl> wrote in message
news:I6********@cwi.nl...

In article <2u*************@uni-berlin.de> "Alfred Z. Newmane"

<a.**************@eastcoastcz.com> writes:

> Dik T. Winter wrote:
> > In article <wAPgd.512$fw2.217@trndny01> "Thomas G. Marshall"
> > <tg****************@replacetextwithnumber.hotmail. com> writes:
> Dik > > T. Winter coughed up: ...
> > Refixing the bad quotes:
>
> 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.

OE_QuoteFix didn't exist back that far.

Well, let me put it a slightly different way:

1. OE is enormously common.
2. More and more OE folks are using OE_QuoteFix
3. OE_QuoteFix does not regard {space}{reply marker}
as part of a reply.

So you're going to be dedicatedly producing posts that are hard to
reply to for a rather large number of people.

And not just people using OE_QuoteFix, other readers as well. OEQF is
just the tip of the ice burg. I've seen styles like Dik make things hard
to read in google groups as well.