what's wrong with the macro

[DaVinci]

#include<stdio.h>
#include<stdlib.h>
#include<string.h>

#define SECONDS_PER_YEAR (60*60*24*365)UL
int main()
{
unsigned long int u_i = SECONDS_PER_YEAR;
printf("%lu\n",u_i);

return 0;
}
cc -g -c -Wall -std=c99 -DDEBUG define.c
define.c: In function 'main':
define.c:17: error: expected ',' or ';' before 'UL'
make: *** [define.o] error 1

[Malcolm]

The qualifer must follow the digits directly.

--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.

"DaVinci" <ap***********@gmail.comwrote in message
news:11*********************@m73g2000cwd.googlegro ups.com...

>
#include<stdio.h>
#include<stdlib.h>
#include<string.h>

#define SECONDS_PER_YEAR (60*60*24*365)UL
int main()
{
unsigned long int u_i = SECONDS_PER_YEAR;
printf("%lu\n",u_i);

return 0;
}
cc -g -c -Wall -std=c99 -DDEBUG define.c
define.c: In function 'main':
define.c:17: error: expected ',' or ';' before 'UL'
make: *** [define.o] error 1

[Frederick Gotham]

Malcolm posted:

The qualifer must follow the digits directly.

It can be changed to simply:

#define SECONDS_PER_YEAR(60LU*60*24*365)

--

Frederick Gotham

[Giorgio Silvestri]

"Frederick Gotham" <fg*******@SPAM.comha scritto nel messaggio
news:Vf*******************@news.indigo.ie...

Malcolm posted:

The qualifer must follow the digits directly.

It can be changed to simply:

#define SECONDS_PER_YEAR(60LU*60*24*365)

A space is necessary

#define SECONDS_PER_YEAR (60LU*60*24*365)
--
Giorgio Silvestri
DSP/Embedded/Real Time OS Software Engineer

[Andrew Poelstra]

On Sun, 2006-10-22 at 00:03 -0700, DaVinci wrote:

#include<stdio.h>
#include<stdlib.h>
#include<string.h>

#define SECONDS_PER_YEAR (60*60*24*365)UL
int main()
{
unsigned long int u_i = SECONDS_PER_YEAR;
printf("%lu\n",u_i);

return 0;
}
cc -g -c -Wall -std=c99 -DDEBUG define.c
define.c: In function 'main':
define.c:17: error: expected ',' or ';' before 'UL'
make: *** [define.o] error 1

You are attempting to compile a file called define.c, which has a syntax
error on line 17. If you want help, you'll have to post the code.
--
Andrew Poelstra <http://www.wpsoftware.net/projects/>

[Richard Heathfield]

DaVinci said:

>
#include<stdio.h>
#include<stdlib.h>
#include<string.h>

#define SECONDS_PER_YEAR (60*60*24*365)UL

It doesn't work like that, I'm afraid. You can, however, do either this:

#define SECONDS_PER_YEAR 31536000UL

or this:

#define SECONDS_PER_YEAR (unsigned long)(60UL * 60UL * 24UL * 365UL)

or something along similar lines.

(Incidentally, your calculation ignores leap years.)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Frederick Gotham]

Richard Heathfield posted:

#define SECONDS_PER_YEAR (unsigned long)(60UL * 60UL * 24UL * 365UL)

Something that came to mind recently...

Do you think one would be right to _always_ enclose macros in parentheses,
irrespective of the fact that it might be impossible to yield to
inappropriate parse? (What I mean by inappropriate parse is the following:

#define DOUBLE(x) (x)+(x)

int i = 5 * DOUBLE(3) * 2; /* Wups! */

As the operator precendence table currently stands (the metaphysical one,
that is :P), there's no problem with your macro above... but should we make
allowances for future additions to the language. It's not impossible that a
new operator would be added which could possibly result in an inappropriate
parse after the macro has been substituted.

Just a thought!

--

Frederick Gotham

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalidwrites:

DaVinci said:

>#include<stdio.h>
#include<stdlib.h>
#include<string.h>

#define SECONDS_PER_YEAR (60*60*24*365)UL

It doesn't work like that, I'm afraid. You can, however, do either this:

#define SECONDS_PER_YEAR 31536000UL

or this:

#define SECONDS_PER_YEAR (unsigned long)(60UL * 60UL * 24UL * 365UL)

or something along similar lines.

(Incidentally, your calculation ignores leap years.)

You want parentheses around the second defintion:

#define SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL)(

Consider "sizeof SECONDS_PER_YEAR".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Giorgio Silvestri]

"Keith Thompson" <ks***@mib.orgha scritto nel messaggio
news:ln************@nuthaus.mib.org...

Richard Heathfield <in*****@invalid.invalidwrites:

DaVinci said:

#include<stdio.h>
#include<stdlib.h>
#include<string.h>

#define SECONDS_PER_YEAR (60*60*24*365)UL

It doesn't work like that, I'm afraid. You can, however, do either this:

#define SECONDS_PER_YEAR 31536000UL

or this:

#define SECONDS_PER_YEAR (unsigned long)(60UL * 60UL * 24UL * 365UL)

or something along similar lines.

(Incidentally, your calculation ignores leap years.)

You want parentheses around the second defintion:

#define SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL)(

Probably:

#define SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL))

is better :-)

>
Consider "sizeof SECONDS_PER_YEAR".

--
Giorgio Silvestri
DSP/Embedded/Real Time OS Software Engineer

[Frederick Gotham]

Keith Thompson posted:

You want parentheses around the second defintion:

#define SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL)(

Consider "sizeof SECONDS_PER_YEAR".

I don't understand... what could that have parsed to?

--

Frederick Gotham

[Keith Thompson]

"Giorgio Silvestri" <gi**************@libero.itwrites:

"Keith Thompson" <ks***@mib.orgha scritto nel messaggio
news:ln************@nuthaus.mib.org...

[...]

>You want parentheses around the second defintion:

#define SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL)(

Probably:

#define SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL))

is better :-)

Um, yeah, thanks for catching that.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Frederick Gotham <fg*******@SPAM.comwrites:

Keith Thompson posted:

>You want parentheses around the second defintion:

#define SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL)(

Consider "sizeof SECONDS_PER_YEAR".

I don't understand... what could that have parsed to?

Frederick, I don't want to leave you waiting for a response from me,
so I'll remind you of this:

<http://groups.google.com/group/comp.lang.c/msg/a03c532b26664ed4>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[pete]

Keith Thompson wrote:

>
"Giorgio Silvestri" <gi**************@libero.itwrites:

"Keith Thompson" <ks***@mib.orgha scritto nel messaggio
news:ln************@nuthaus.mib.org...

[...]

You want parentheses around the second defintion:

#define SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL)(

Probably:

#define SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL))

is better :-)

Um, yeah, thanks for catching that.

What is the cast for?

--
pete

[Walter Roberson]

In article <45***********@mindspring.com>,
pete <pf*****@mindspring.comwrote:

>"Giorgio Silvestri" <gi**************@libero.itwrites:

#define SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL))

>What is the cast for?

Once the constant (without the cast) is computed by the parser, it
becomes a numeric value of indeterminate width -- through some unspecified
mechanism the parser knows the minimum width needed to represent it,
but it is not specifically that minimum width and not specifically UL
and so on. If the cast-less constant were determined
to be too large to match the other operand of the expression, then
widening is going to take place. In some contexts, if the constant
were determined to be able to fit within the *signed* version of
a larger type, it would be widened to *signed* rather than to
unsigned [remember, the system knows it as a numeric value at that point,
not specifically as an unsigned numeric value.]. The (unsigned long) cast
stops any uncertainty about exactly what type is going to be there.
Now try printf("%d\n", CASTLESS_SECONDS_PER_YEAR); -- is that right?
It is if the CASTLESS_SECONDS_PER_YEAR is accomedated as a signed int,
but not if CASTLESS_SECONDS_PER_YEAR requires long on that system.
60UL * 60UL * 24UL * 365UL as a numeric value takes about 25 bits.
On a system with 32 bit int and 64 bit unsigned long,
the cast-less version it would fit within a signed int on that system
and %d would be correct and %ld would be wrong. So cast-less, the
value is not as easily portable. Add the cast and you -know- the type
and can always use %lu.
--
Programming is what happens while you're busy making other plans.

[Keith Thompson]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

In article <45***********@mindspring.com>,
pete <pf*****@mindspring.comwrote:

>>"Giorgio Silvestri" <gi**************@libero.itwrites:

>#define SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL))

>>What is the cast for?

I believe it's superfluous.

Once the constant (without the cast) is computed by the parser, it
becomes a numeric value of indeterminate width -- through some unspecified
mechanism the parser knows the minimum width needed to represent it,
but it is not specifically that minimum width and not specifically UL
and so on. If the cast-less constant were determined
to be too large to match the other operand of the expression, then
widening is going to take place. In some contexts, if the constant
were determined to be able to fit within the *signed* version of
a larger type, it would be widened to *signed* rather than to
unsigned [remember, the system knows it as a numeric value at that point,
not specifically as an unsigned numeric value.]. The (unsigned long) cast
stops any uncertainty about exactly what type is going to be there.

I don't think so. C99 6.6p11 says:

The semantic rules for the evaluation of a constant expression are
the same as for nonconstant expressions.

The expression:

(60UL * 60UL * 24UL * 365UL)

is a constant expression, but not a constant (i.e., a literal).

A single integer literal with a UL suffix is of type unsigned long int
or unsigned long long int, depending on the value; all the constants
in the above are well within the guaranteed range of unsigned long, so
that's their type. Multiplying an unsigned long by an unsigned long
yields an unsigned long, so the entire expression is of type unsigned
long.

As it happens, the final result, 31536000, is also within the
guaranteed range of unsigned long, so there's no possibility of
overflow. But even if there were (say, if you wanted the number of
seconds in a millenium), an overflow wouldn't change the type of the
expression.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Keith Thompson said:

Frederick Gotham <fg*******@SPAM.comwrites:

>Keith Thompson posted:

>>You want parentheses around the second defintion:

#define SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL)(

Consider "sizeof SECONDS_PER_YEAR".

I don't understand... what could that have parsed to?

Frederick, I don't want to leave you waiting for a response from me,
so I'll remind you of this:

<http://groups.google.com/group/comp.lang.c/msg/a03c532b26664ed4>

A waste of time, Keith. If he were interested in responses from you, he'd
have apologised a long time ago.

Personally, whenever I see a question from Mr Gotham, I simply don't bother
to reply. When I see others giving him wrong answers, I don't bother to
correct them. If he wants expert assistance, he should not alienate
experts.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Frederick Gotham]

Walter Roberson posted:

>>What is the cast for?

Once the constant (without the cast) is computed by the parser, it
becomes a numeric value of indeterminate width -- through some unspecified
mechanism the parser knows the minimum width needed to represent it,
but it is not specifically that minimum width and not specifically UL
and so on.

Incorrect.

Multiply a UL by a UL and you get a UL.
--

Frederick Gotham

[Frederick Gotham]

Keith Thompson posted:

<snip tripe>

Richard Heathfield posted:

<snip tripe>

Since the two self-proclaimed masters of this newsgroup won't reply to me,
I'd like to ask any other programmers to explain to me why:

sizeof (unsigned long)(60UL * 60UL * 24UL * 365UL)

would have been undesireable.

Actually, don't bother, because I already know the answer: Keith was wrong.

The expression in question has only one possible parse, because the operand
of "sizeof" cannot be a cast expression. Therefore, the following two
expressions are exactly equivalent:

sizeof (unsigned long)(60UL * 60UL * 24UL * 365UL)

sizeof ((unsigned long)(60UL * 60UL * 24UL * 365UL))

--

Frederick Gotham

[Frederick Gotham]

Frederick Gotham posted:

The expression in question has only one possible parse, because the
operand of "sizeof" cannot be a cast expression.

And even if it could be, there would be a syntax error.

--

Frederick Gotham

[Eric Sosman]

Frederick Gotham wrote On 10/24/06 11:23,:

Keith Thompson posted:

<snip tripe>

Richard Heathfield posted:

<snip tripe>

Since the two self-proclaimed masters of this newsgroup won't reply to me,
I'd like to ask any other programmers to explain to me why:

sizeof (unsigned long)(60UL * 60UL * 24UL * 365UL)

would have been undesireable.

Actually, don't bother, because I already know the answer: Keith was wrong.

The expression in question has only one possible parse, because the operand
of "sizeof" cannot be a cast expression. Therefore, the following two
expressions are exactly equivalent:

sizeof (unsigned long)(60UL * 60UL * 24UL * 365UL)

sizeof ((unsigned long)(60UL * 60UL * 24UL * 365UL))

It's a funny thing, but when I tried these out on three
completely different C compilers, all three treated the two
"exactly equivalent" expressions differently. Specifically,
they all rejected the first with complaints about "syntax
error" or some such, but they all accepted the second.

Three out of three identical mistakes from independent
compiler authors -- that's too much for coincidence, don't
you think? There must be an enormous shadowy conspiracy
at work to retard progress in programming by producing and
promoting faulty C compilers! They're probably taking steps
to silence us even now; I hope I can get this posted befor

--
Er*********@sun.com

[Richard Tobin]

In article <8e*******************@news.indigo.ie>,
Frederick Gotham <fg*******@SPAM.comwrote:

>I'd like to ask any other programmers to explain to me why:

sizeof (unsigned long)(60UL * 60UL * 24UL * 365UL)

would have been undesireable.

Because it's a syntax error.

>The expression in question has only one possible parse, because the operand
of "sizeof" cannot be a cast expression.

It has no possible parses.

>Therefore, the following two
expressions are exactly equivalent:

sizeof (unsigned long)(60UL * 60UL * 24UL * 365UL)

sizeof ((unsigned long)(60UL * 60UL * 24UL * 365UL))

No, one of them's an error and the other one isn't.

-- Richard

[Frederick Gotham]

Richard Tobin posted:

> sizeof (unsigned long)(60UL * 60UL * 24UL * 365UL)

Because it's a syntax error.

So you can turn a cast expression into a normal expression (or whatever it's
called) by enclosing it in parentheses?

--

Frederick Gotham

[Richard Tobin]

In article <JJ*******************@news.indigo.ie>,
Frederick Gotham <fg*******@SPAM.comwrote:

>So you can turn a cast expression into a normal expression (or whatever it's
called) by enclosing it in parentheses?

Yes, it becomes a primary expression (IIRC - I don't have the grammar
handy). That's the basic way of making the grammar handle arbitrarily
complicated expressions: by putting a subexpression in parentheses it
becomes usable in the same contexts as numbers and strings.

-- Richard

[Chris Dollin]

Frederick Gotham wrote:

Richard Tobin posted:

>> sizeof (unsigned long)(60UL * 60UL * 24UL * 365UL)

Because it's a syntax error.

So you can turn a cast expression into a normal expression (or whatever it's
called) by enclosing it in parentheses?

Looking at the grammar ...

The operand of a `sizeof` must be a unary-expression. A unary-expression
can be a postfix-expression, which can be a primary-expression, which can
be any expression enclosed in parentheses.

So yes, parenthesising a cast-expression makes it suitable as an
operand of `sizeof`.

I wouldn't have thought this was surprising: putting bracketty things
around big wobbly expresssions to make them into snug tight expressions
is a common grammatical trick, eg `2 * (20 + 1)`.

--
Chris "common, but not universal" Dollin
A rock is not a fact. A rock is a rock.

[Clark S. Cox III]

Frederick Gotham wrote:

Richard Tobin posted:

>> sizeof (unsigned long)(60UL * 60UL * 24UL * 365UL)

Because it's a syntax error.

So you can turn a cast expression into a normal expression (or whatever it's
called) by enclosing it in parentheses?

Of course you can it's spelled out pretty clearly in the grammar. Any
'expression' enclosed in parentheses is a 'primary-expression':

(6.5.1)primary-expression:
identifier
constant
string-literal
( expression )

And a 'cast-expression' is a 'multiplicative-expression'
which is, in turn an 'additive-expression'
which is, in turn a 'shift-expression'
which is, in turn a 'relational-expression'
which is, in turn an 'equality-expression'
which is, in turn an 'AND-expression'
which is, in turn a 'exclusive-OR-expression'
which is, in turn a 'inclusive-OR-expression'
which is, in turn a 'logical-AND-expression'
which is, in turn a 'logical-OR-expression'

which is, in turn a 'conditional-expression'
which is, in turn a 'assignment-expression'
which is, in turn an 'expression'

*pant* *pant* *pant*
--
Clark S. Cox III
cl*******@gmail.com

[Mark McIntyre]

On Tue, 24 Oct 2006 15:23:48 GMT, in comp.lang.c , Frederick Gotham
<fg*******@SPAM.comwrote:

>Since the two self-proclaimed masters of this newsgroup won't reply to me,

Lets all recall that the reason these (and other) regulars don't reply
is because you're offensive. Nobody can be bothered.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[CBFalconer]

Frederick Gotham wrote:

Keith Thompson posted:

<snip tripe>

Richard Heathfield posted:

<snip tripe>

Since the two self-proclaimed masters of this newsgroup won't reply
to me, I'd like to ask any other programmers to explain to me why:

Well, I haven't gone quite that far, but the fact is that you know
very well how to repair that situation. You have chosen not to do
so for your own incomprehensible reasons, and continue to insult
them. I suspect many others are ignoring you without advising you
of the fact.

Enjoy Coventry.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalidwrites:

Keith Thompson said:

>Frederick Gotham <fg*******@SPAM.comwrites:

>>Keith Thompson posted:
You want parentheses around the second defintion:

#define SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL)(

Consider "sizeof SECONDS_PER_YEAR".

I don't understand... what could that have parsed to?

Frederick, I don't want to leave you waiting for a response from me,
so I'll remind you of this:

<http://groups.google.com/group/comp.lang.c/msg/a03c532b26664ed4>

A waste of time, Keith. If he were interested in responses from you, he'd
have apologised a long time ago.

I'm not waiting for, or expecting, an apology from him. See the
article I cited if you care (but there's no real reason you should).
I wasn't trying to elicit any particular response from him, just
reminding him that he shouldn't expect one from me.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Christopher Benson-Manica]

Keith Thompson <ks***@mib.orgwrote:

You want parentheses around the second defintion:

^^^^^^^^^

#define SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL)(

Did you mean

#defin SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL))

or was that a typo too? :-)

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Keith Thompson]

Christopher Benson-Manica <at***@otaku.freeshell.orgwrites:

Keith Thompson <ks***@mib.orgwrote:

>You want parentheses around the second defintion:

^^^^^^^^^

>#define SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL)(

Did you mean

#defin SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL))

or was that a typo too? :-)

Yes, taht wsa a tpyo. :)-

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[pete]

Keith Thompson wrote:

>
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

In article <45***********@mindspring.com>,
pete <pf*****@mindspring.comwrote:

>"Giorgio Silvestri" <gi**************@libero.itwrites:

#define SECONDS_PER_YEAR ((unsigned long)(60UL * 60UL * 24UL * 365UL))

>What is the cast for?

I believe it's superfluous.

Once the constant (without the cast) is computed by the parser, it
becomes a numeric value of indeterminate width -- through some unspecified
mechanism the parser knows the minimum width needed to represent it,
but it is not specifically that minimum width and not specifically UL
and so on. If the cast-less constant were determined
to be too large to match the other operand of the expression, then
widening is going to take place. In some contexts, if the constant
were determined to be able to fit within the *signed* version of
a larger type, it would be widened to *signed* rather than to
unsigned [remember, the system knows it as a numeric value at that point,
not specifically as an unsigned numeric value.]. The (unsigned long) cast
stops any uncertainty about exactly what type is going to be there.

I don't think so. C99 6.6p11 says:

The semantic rules for the evaluation of a constant expression are
the same as for nonconstant expressions.

The expression:

(60UL * 60UL * 24UL * 365UL)

is a constant expression, but not a constant (i.e., a literal).

A single integer literal with a UL suffix is of type unsigned long int
or unsigned long long int, depending on the value; all the constants
in the above are well within the guaranteed range of unsigned long, so
that's their type. Multiplying an unsigned long by an unsigned long
yields an unsigned long, so the entire expression is of type unsigned
long.

As it happens, the final result, 31536000, is also within the
guaranteed range of unsigned long, so there's no possibility of
overflow. But even if there were (say, if you wanted the number of
seconds in a millenium), an overflow wouldn't change the type of the
expression.

(60UL * 60 * 24 * 365) would be OK
even if (60 * 24 * 365) was greater than INT_MAX.

--
pete

[Serve Laurijssen]

"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:8e*******************@news.indigo.ie...

Keith Thompson posted:

<snip tripe>

Richard Heathfield posted:

<snip tripe>

Since the two self-proclaimed masters of this newsgroup won't reply to me,

I'm also a self-proclaimed master of this newsgroup and I'm replying to you
here. There is still hope

[Clever Monkey]

Serve Laurijssen wrote:

"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:8e*******************@news.indigo.ie...

>Keith Thompson posted:

<snip tripe>

Richard Heathfield posted:

<snip tripe>

Since the two self-proclaimed masters of this newsgroup won't reply to me,

I'm also a self-proclaimed master of this newsgroup and I'm replying to you
here. There is still hope

"I'm in charge, here."

[Keith Thompson]

"Serve Laurijssen" <se*@n.tkwrites:

"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:8e*******************@news.indigo.ie...

>Keith Thompson posted:

<snip tripe>

Richard Heathfield posted:

<snip tripe>

Since the two self-proclaimed masters of this newsgroup won't reply to me,

I'm also a self-proclaimed master of this newsgroup and I'm replying to you
here. There is still hope

You're a bit late. The article to which you're replying was posted on
October 24. Frederick Gotham apologized handsomely for his earlier
behavior on November 11, and has been quite untrollish since then
(though he hasn't posted here in about a month).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Kenny McCormack]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>"Serve Laurijssen" <se*@n.tkwrites:

>"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:8e*******************@news.indigo.ie...

>>Keith Thompson posted:

<snip tripe>

Richard Heathfield posted:

<snip tripe>

Since the two self-proclaimed masters of this newsgroup won't reply to me,

I'm also a self-proclaimed master of this newsgroup and I'm replying to you
here. There is still hope

You're a bit late. The article to which you're replying was posted on
October 24. Frederick Gotham apologized handsomely for his earlier
behavior on November 11, and has been quite untrollish since then
(though he hasn't posted here in about a month).

I think it was pretty well established at the time that those "apologies"
were forged by the "regulars".

[Keith Thompson]

Keith Thompson <ks***@mib.orgwrites:
[...]

You're a bit late. The article to which you're replying was posted on
October 24. Frederick Gotham apologized handsomely for his earlier
behavior on November 11, and has been quite untrollish since then
(though he hasn't posted here in about a month).

And there's been zero evidence that his apology was anything other
than genuine (if it were forged, Frederick would have had ample
opportunity to say so).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Kenny McCormack said:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

<snip>

>>You're a bit late. The article to which you're replying was posted on
October 24. Frederick Gotham apologized handsomely for his earlier
behavior on November 11, and has been quite untrollish since then
(though he hasn't posted here in about a month).

I think it was pretty well established at the time that those "apologies"
were forged by the "regulars".

Mr McCormack is incorrect, as usual.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[CBFalconer]

Clever Monkey wrote:

Serve Laurijssen wrote:

>"Frederick Gotham" <fg*******@SPAM.comwrote in message

.... snip ...

>>>
Since the two self-proclaimed masters of this newsgroup won't
reply to me,

I'm also a self-proclaimed master of this newsgroup and I'm
replying to you here. There is still hope

"I'm in charge, here."

"I'm the commander--see, I don't have to explain -- I don't need
to explain why I say things. That's the interesting thing about
being the President. Maybe somebody needs to explain to me why
they say something, but I don't feel like I owe anybody an
explanation." - George W. Bush, 2002-11-19

"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - GWB 2004-2-8

"If I knew then what I know today, I would still have invaded
Iraq. It was the right decision" - G.W. Bush, 2004-08-02

"This notion that the United States is getting ready to attack
Iran is simply ridiculous. And having said that, all options
are on the table." - George W. Bush, Brussels, 2005-02-22

Who's in charge?

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Richard Bos]

CBFalconer <cb********@yahoo.comwrote:

Clever Monkey wrote:

Serve Laurijssen wrote:

"Frederick Gotham" <fg*******@SPAM.comwrote in message

... snip ...

>>
Since the two self-proclaimed masters of this newsgroup won't
reply to me,

I'm also a self-proclaimed master of this newsgroup and I'm
replying to you here. There is still hope

"I'm in charge, here."

"I'm the commander--see, I don't have to explain -- I don't need
to explain why I say things. That's the interesting thing about
being the President. Maybe somebody needs to explain to me why
they say something, but I don't feel like I owe anybody an
explanation." - George W. Bush, 2002-11-19

"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - GWB 2004-2-8

"If I knew then what I know today, I would still have invaded
Iraq. It was the right decision" - G.W. Bush, 2004-08-02

"This notion that the United States is getting ready to attack
Iran is simply ridiculous. And having said that, all options
are on the table." - George W. Bush, Brussels, 2005-02-22

Who's in charge?

Cheney.

Richard