C to Java Byte Code

[Flash Gordon]

Re: C to Java Byte Code

On Wed, 27 Oct 2004 10:06:18 -0700
"Galga" <none@none.spam blowz> wrote:
[color=blue]
> Gerry Quinn wrote:[color=green]
> > In article <MPG.1be9e02545 c89c61989a6d@ne ws.indigo.ie>,
> > gerryq@DELETETH ISindigo.ie says...[color=darkred]
> >> In article <417E469B.95A63 564@yahoo.com>, cbfalconer@yaho o.com
> >> says...
> >>> Mohd Hanafiah Abdullah wrote:
> >>
> >>>> main()
> >>>> { a_union z;
> >>>>
> >>>> z.x = 1078531719;
> >>>> printf("int val = %d\n", z.x);
> >>>> printf("float val = %f\n", z.y);
> >>>
> >>> illegal statement here. You cannot access a field of a union as a
> >>> type other than what you last wrote into it.
> >>
> >> It's not illegal, any more than casting a float to an int (which it
> >> effectively is) is illegal.[/color]
> >
> > Sorry, I meant casting a float* to an int* and de-referencing.
> > Casting a float to an int does give specified results, of course.[/color]
>
> Good catch, I was about to reply about that, saved me the trouble :-)[/color]

I caught my reply on the outgoing spool before it left.

However, the bit pattern of an int can be a trap representation for a
float, so writing an int then reading it as a float is definitely *not*
guaranteed to leave your program running. I think the only type punning
the C standard actual guarantees won't crash your program is reading
anything as unsigned char, an exception that I believe is explicitly
mentioned.
--
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.

[Flash Gordon]

Re: C to Java Byte Code

On Wed, 27 Oct 2004 08:57:27 -0700
"Alfred Z. Newmane" <a.newmane.remo ve@eastcoastcz. com> wrote:

<snip using a union to overlay structs on an array of unsigned char>
[color=blue]
> You cna use pragmas or other means to force a specific byte alignment,
> can you not?[/color]

You can use pragmas, but there is nothing to say
#pragma align 1
on the next compiler you use doesn't mean align on 1GB boundaries.

There is also nothing to say that any given compiler supports a pragma
for specifying alignment.
[color=blue]
> If it was distributed code, it would most like be
> documented (and commented in the code) reguarding that.[/color]

I've seen plenty of non-portable code that does *not* document what
non-portable extensions it is using.
--
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]

Re: C to Java Byte Code

"Thomas G. Marshall" wrote:[color=blue]
> Old Wolf coughed up:[/color]

Nice description..:)
[color=blue][color=green]
> > typedef union abc
> > { int x;
> > float y;
> > } a_union;
> >
> > main()
> > { a_union z;
> >[/color]
>
> First example:[color=green]
> > z.x = 1;
> > printf("int val = %d\n", z.x);
> > printf("float val = %f\n", z.y);
> > Results:
> > int val = 1
> > float val = 3.142[/color]
>
> How does the mini-PI come out of a union (first example) that was only set
> with integer 1?[/color]

According to the C standard, it is "undefined behaviour" to
read any member of a union except for the one that was most
recently set. This means that an implementation can do whatever
it likes (including printing 3.142, or crashing, or causing
demons to fly out of your nose, as they say).
Imagine that a compiler detects this situation and inserts
code to display 3.142 whenever a float is read from a union
that just had an int put in it (that would be very perverse,
and that vendor wouldn't sell many compilers, but it is allowed).

[Mark McIntyre]

Re: C to Java Byte Code

On Tue, 26 Oct 2004 17:55:28 -0700, in comp.lang.c , Paul Lutus
<nospam@nosite. zzz> wrote:
[color=blue]
>Mark McIntyre wrote:
>[color=green]
>> On Tue, 26 Oct 2004 11:36:02 -0700, in comp.lang.c , Paul Lutus
>> <nospam@nosite. zzz> wrote:
>>[color=darkred]
>>>Yes, it is a union in C, but I am saying it is not a union in the Java
>>>bytecode.[/color]
>>
>> Marvellous. Since this has nothing to do with C any more,[/color]
>
>Do you see a reference to C in the sentence above?[/color]

Do you see comp.lang.c in the x-post list? Yes? So post something topical.

[color=blue]
>The discussion is about a C to Java cross-compiler. Both languages are
>therefore topical.[/color]

Really? Where in the C standard does it define cross compilation to Java?
Which Java group is this x-posted to?
[color=blue]
>The OP, an unscrupulous, predatory commercial vendor, created this
>cross-posted thread. If you don't like it, argue with him.[/color]

You're the one perpetuating the x-post.
[color=blue]
>Do the world a favor. Killfile Usenet.[/color]

Or put you back into mine. but please use your real name when posting, to
make it easier for people to killfile you.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >


----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Mark McIntyre]

Re: C to Java Byte Code

On Wed, 27 Oct 2004 10:35:58 -0700, in comp.lang.c , "Galga"
<none@none.spam blowz> wrote:
[color=blue]
>Richard Herring wrote:[/color]
[color=blue][color=green]
>> Why is it so important to you to continue crossposting this thread?
>> What's your agenda? I[/color]
>
>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.[/color]

Or possibly he wants to stop x-posting to the CLC++ group, because its
annoying the t*ts off everyone there to have a bunch of cretins arguing
about fscking Java bytecode.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >


----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[John Gordon]

Re: C to Java Byte Code

In <2uabniF27ci92U 1@uni-berlin.de> "Alfred Z. Newmane" <a.newmane.remo ve@eastcoastcz. com> writes:
[color=blue][color=green]
> > This sounds like the classic spam defense. "If you don't want to read
> > it, just delete it!"[/color][/color]
[color=blue]
> That maybe a classic defense, but I don't see how this thread (except
> maybe in some views, the original post) could be spam.[/color]

I didn't mean to say that this thread was spam; I was just observing the
perils of assigning the burden of content filtering to the reader rather
than the writer.
[color=blue]
> In this case, I think the "kill the thread if you dont like it" hold
> water, as no one is forcing anyone to read it.[/color]
[color=blue][color=green]
> > And we all know how well that works...[/color][/color]
[color=blue]
> Works rather well if you know how to delete a thread that you /really/
> don't want to read. Is it /that/ hard?[/color]

For a small number of threads, no. But it doesn't scale. Just like spam.

--
John Gordon "Between BST melee, their spells, their warders' melee,
gordon@panix.co m and their warders' procs, they put out enough damage
to make monks cry." -- Dark Tyger

[E. Robert Tisdale]

Re: C to Java Byte Code

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

I used Google

http://www.google.com/

to search for

+"C to Java byte code"

and I found lots of stuff.

There have been lots of such projects for a long time.
Why do you say that this is something that has been "missing"?
How is your product better than all of the other offerings?
[color=blue]
> 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.[/color]
[color=blue]
> 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[/color]

[Alfred Z. Newmane]

Re: C to Java Byte Code

Old Wolf wrote:[color=blue]
> Paul Lutus <nospam@nosite. zzz> wrote:[color=green]
>> Old Wolf wrote:
>>[color=darkred]
>>> 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.[/color]
>>
>> 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[/color]
>
> 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.
>[color=green][color=darkred]
>>>> 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.[/color]
>>
>> Non sequitur. It is a question of syntactic correctness, not
>> portability.[/color]
>
> 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);[/color]

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

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

int i = 3;
i = i;
i++;
[color=blue]
> Here is another example of non-portability that doesn't
> include undefined behaviour:
>
> int x = 12;
> assert( *(unsigned char *)&x == 0 );[/color]

You might be right on this one.

[Richard Tobin]

Re: C to Java Byte Code

In article <2uamopF26f9lmU 1@uni-berlin.de>,
Alfred Z. Newmane <a.newmane.remo ve@eastcoastcz. com> wrote:
[color=blue][color=green]
>> int i = 3;
>> i = i++;
>> printf("%d\n", i);[/color][/color]
[color=blue]
>The code it self is fine; i starts with a value of 3, then i gets
>assigned to itself, *after* which it gets ++ed.[/color]

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.
[color=blue]
>Remember, ++ after the variable (post inc) takes place *after* the
>evaluation.[/color]

Yes, but not necessarily after the assignment.

-- Richard

[Alfred Z. Newmane]

Re: C to Java Byte Code

Richard Tobin wrote:[color=blue]
> In article <2uamopF26f9lmU 1@uni-berlin.de>,
> Alfred Z. Newmane <a.newmane.remo ve@eastcoastcz. com> wrote:
>[color=green][color=darkred]
>>> int i = 3;
>>> i = i++;
>>> printf("%d\n", i);[/color][/color]
>[color=green]
>> The code it self is fine; i starts with a value of 3, then i gets
>> assigned to itself, *after* which it gets ++ed.[/color]
>
> 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.
>[color=green]
>> Remember, ++ after the variable (post inc) takes place *after* the
>> evaluation.[/color]
>
> Yes, but not necessarily after the assignment.[/color]

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

[Arthur J. O'Dwyer]

Re: C to Java Byte Code


On Wed, 27 Oct 2004, Alfred Z. Newmane wrote:[color=blue]
> Richard Tobin wrote:[color=green]
>> Alfred Z. Newmane <a.newmane.remo ve@eastcoastcz. com> wrote:
>>[color=darkred]
>>>> int i = 3;
>>>> i = i++;[/color]
>>[color=darkred]
>>> The code itself is fine;[/color]
>>
>> 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.[/color][/color]
[color=blue]
> 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.[/color]

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]

Re: C to Java Byte Code

"Alfred Z. Newmane" <a.newmane.remo ve@eastcoastcz. com> wrote :[color=blue]
> Old Wolf wrote:[color=green]
> > 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);[/color]
>
> How is non portable?[/color]

Please read the FAQ entry pertaining to this:

http://www.eskimo.com/~scs/C-faq/q3.3.html

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

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- .
[color=blue]
> In other words it's the same as:
>
> int i = 3;
> i = i;
> i++;[/color]

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]

Re: C to Java Byte Code

Old Wolf wrote:[color=blue]
> "Alfred Z. Newmane" <a.newmane.remo ve@eastcoastcz. com> wrote :[color=green]
>> Old Wolf wrote:[color=darkred]
>>> 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);[/color]
>>
>> How is non portable?[/color]
>
> Please read the FAQ entry pertaining to this:
> http://www.eskimo.com/~scs/C-faq/q3.3.html
>[color=green]
>> 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.[/color]
>
> 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- .
>[color=green]
>> In other words it's the same as:
>>
>> int i = 3;
>> i = i;
>> i++;[/color]
>
> 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'.[/color]

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

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]

Re: C to Java Byte Code

oldwolf@inspire .net.nz (Old Wolf) wrote:
[color=blue]
> "Alfred Z. Newmane" <a.newmane.remo ve@eastcoastcz. com> wrote :[color=green]
> > Old Wolf wrote:[color=darkred]
> > > 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);[/color]
> >
> > 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.[/color]
>
> A common misconception. The ++ can occur either before or
> after the evaluation (and either before or after the assignment,
> in this example).[/color]

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]

Re: C to Java Byte Code

In message <clombd$d04$1@n ews.astound.net >, Galga <none@none.spam blowz>
writes[color=blue]
>Richard Herring wrote:[color=green]
>> In message <cloijm$b7b$1@n ews.astound.net >, Galga
>> <none@none.spam blowz> writes[color=darkred]
>>> Richard Herring wrote:
>>>> In message <10ntsg1o8vbi16 f@corp.supernew s.com>, Paul Lutus
>>>> <nospam@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?[/color]
>>
>> Why is it so important to you to continue crossposting this thread?
>> What's your agenda? I[/color]
>
>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.[/color]

"Something to hide"? Don't be silly, this is Usenet.[color=blue]
>[color=green][color=darkred]
>>> In case you haven't noticed, C and even Java are related languages;
>>> many who use one use or have experience with the others,[/color]
>>
>> 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.[/color]
>
>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.[/color]

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?
[color=blue][color=green][color=darkred]
>>> and who are you to
>>> speak for everyone in c.l.c++,[/color]
>>
>> Where did I claim to do that?[/color]
>
>By trying to decide for everyone what groups this belogns to (ie,
>setting follow up.)[/color]

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.
[color=blue]
> Not that this part of the thread matters all that
>much, your attempt goes meaningless.
>[color=green][color=darkred]
>>> when it might be of interest of people
>>> there?[/color]
>>
>> "Might be"? Have you actually read this group before today?[/color]
>
>Yes, plenty, what is your point?[/color]

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.
[color=blue]
>People from all these groups may read
>one of these groups a lot more then the others. Even if not, why do
>*YOU* care?[/color]

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

Ah, the cry of every cross-posting troll since the beginning of usenet.
[color=blue][color=green]
>> And what exactly is the "similar interest" in this case? Feel free to
>> point out which features of the standard C++ language[/color]
>
>Nice try, but that was never the point.[/color]

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

So far you've failed to demonstrate any.
[color=blue]
>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.[/color]

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?
[color=blue]
>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.
>[color=green][color=darkred]
>>>
>>> So again, kindly kill file this thread if you don't want to see it.[/color][/color]
>
>And again, ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^[/color]

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

--
Richard Herring