HDTenEightyP/NetNews huggingface dataset:
From: msb@sq.sq.com (Mark Brader)
Subject: char zoe[3] = "123";
Organization: SoftQuad Inc., Toronto, Canada
Date: Sat, 10 Oct 92 23:20:09 GMT


> > > I disagree that char zoe[3] = "123"; would be an erroneous initializer.
> > This *is* an erroneous initializer because you are initializing a three-
> > character array with four characters.
> Sorry, read the ANSI spec.  It's perfectly legitimate.

TWEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEET!

Thank you for your attention.  The quoted articles come from an incredibly
repetitive thread, from which I have deliberately separated this one in
this hopes of its being seen.  There have been many postings, including
some by C experts, stating that the construct is legal; and many others
stating that it is illegal.

BOTH assertions are right.

The initialization of a char array with a string literal containing
the same number of characters is -- now listen carefully -- LEGAL
in ANSI C, but ILLEGAL in old C.  The experts seem to be forgetting
on this occasion that this is not comp.std.c; pre-ANSI implementations
are relevant in this newsgroup!

(The ANSI committee did not invent this extension, by the way; they
copied it from "certain widely used implementations", according to
the Rationale.)

Why would you want to do it?  Well, just because char arrays are
usually used to contain strings doesn't mean they have to be.
For instance, there are also translate tables.  Now, wouldn't it
be silly to have a nice terse syntax for initializing the table
which only works if you have an extra unused element on the end
(containing a null)?  But that's the way it is in old C.

Why would you NOT want to do it?  Because it isn't in old C and
hence reduces your program's portability; and perhaps on the stylistic
grounds that "123" *looks* like a null-terminated string, because that's
what it would mean in any other context, and should only be so used.

Note that even in ANSI C, char zoet[] = "123"; declares a *4* element
array.  You get initialization without a trailing null character only
if you explicitly declare the size and it exactly matches the length
of the initializing string.
-- 
Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com
	"The conversation never became heated, which would have been difficult
	 in any argument where there is a built-in cooling-down period between
	 any remark and its answer."		-- Hal Clement, STAR LIGHT

This article is in the public domain.
From: fred@poly2.nist.gov (Frederick R. Phelan Jr.)
Newsgroups: comp.lang.c
Subject: MSDOS gcc (was: gcc (WHERE TO FIND MSDOS GCC))
Keywords: gcc djgpp msdos
Date: 16 Oct 92 23:51:25 GMT

In article <1992Oct13.152120.25783@pony.Ingres.COM> jonm@Ingres.COM (Go ahead... see if I care) writes:
>>>Where can I find gcc for both msdos and a sequent balance?
>> 
>>Someone posted this address recently for the MSDOS version:
>> 
>>	barancle.erc.clarkson.edu
>>	in /pub/msdos/djgpp
>> 
>
>I can't seem to ftp onto this.  Would you have an internet ID?
>
>			barancle.erc.clarkson.edu
>
>Jon M

I found gcc ok, but check out this from the readme:

  WARNING: This software comes with ABSOLUTELY NO WARRANTEE.  I can't even
  guarantee that this software won't wipe out your entire hard drive (it's
  happened to a few people before).  USE AT YOUR OWN RISK! It's always a
  good idea to make regular backups of your hard drives anyway. 

Well, my 486 is only two weeks old and I don't feel like trashing the
hard disk just yet!  Can anybody tell me if the use this and if they
have ever had any problems using this?  

Thanks.

Cheers,

Fred Phelan
---
Fred Phelan
fred@poly2.nist.gov
/*___________________________________________________
   ____ __  ___  __    ___       ___        ___ 
  /__  /_/ /__  / /   /__/ /__/ /__   /    /__/ /\  /  
 /    / ( /__  /_/   /    /  / /___  /___ /  / /  \/
___________________________________________________*/
From: tleck@mksol.dseg.ti.com (terrance l eck)
Newsgroups: comp.lang.c
Subject: VCR+Plus code
Date: 13 Oct 92 15:33:53 GMT
Organization: Texas Instruments

I'm not sure where to post this question so I'm trying here.
Does anyone know how to translate VCR+Plus code. I would like to write
a C program which will convert date, time, channel, and time length into
the numeric code used by VCR+Plus. 
Thanks,
Terry 
Newsgroups: comp.lang.c
From: byron@cc.gatech.edu (Byron A Jeff)
Subject: Finding 0 bytes in a 32 bit word.
Reply-To: byron@cc.gatech.edu (Byron A Jeff)
Organization: Georgia Institute of Technology
Date: Thu, 15 Oct 1992 15:06:40 GMT

Along the same lines for findings the number of 1's I'd like to know if
anyone has an efficient way of finding 0 bytes in a 32 bit word. The
situation is that I have a 68020 SBC with a 32 bit data path. It would
greatly improve my string operations (concatenate, length, copy) if I
could manipulate strings 4 bytes at a time. But to find the end of the
string requires finding a 0 byte within the 32 bit word. 

I know that I can simply AND the bytes of the word together and a 0 result
indicates a 0 within the word. But that'll take about the same amount of 
time as working with the individual bytes. Here's an example (for simplicity
assume the string is longword aligned):

strlen(s)
char *s;
{
   register unsigned long *lp;
   register int count;

   count = 0;
   lp = (unsigned long *) s;
   while(!have0(*lp)) {
      lp++;
      count += 4;
   }
   /* Additional code to take care of the leftover bytes */
   return count;
}

The 68020 in particular can not fetch and cache 4 bytes in the normal
case [ while (*s) ... ] would fetch 1 byte at a time. Hence wanting this
algorithm.

Any suggestions?

Any and all help greatly appreciated.

BAJ
---
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel!
Georgia Tech, Atlanta GA 30332   Internet: byron@cc.gatech.edu
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Determining variable type at run-time (followup q.)
Date: 8 Oct 92 18:21:06 GMT
Organization: negligable

In article <1992Oct2.205136.10070@netcom.com> sue@netcom.com (Sue Miller) writes:
>In article <369@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>>
>>   x.value = malloc(strlen(str)+1);
>>   strcpy(x.value, str);
>
>How about the fact that you didn't check to make sure that
>malloc actually returned the buffer you requested?

This is left as an excersize for the reader.

C'mon folks, it's only a code FRAGMENT in an article, it's 
not a production program!


		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I am just a figment of your imagination...
			...what does that say about *your* mental health?
Newsgroups: comp.lang.c
From: jth54363@uxa.cso.uiuc.edu (Zog)
Subject: Binary files.
Organization: University of Illinois at Urbana
Date: Thu, 15 Oct 1992 02:11:55 GMT

Hi All,
I'm in the process of learning C and C++. I go back and forth. Anyway...
How can I write to a binary file on the bit level? ie. just a 1 or 0?
I know there are two types of files but I guess I'm missing something.
Hope my question is clear enough for some kind soul to make sense out
of it and help me out.
Mail would be fine.
Thanks in advance,
Jason Herzog
j-herzog@uiuc.edu



-- 
Jason T. Herzog
j-herzog@uiuc.edu

Newsgroups: comp.lang.c
From: u8111091@cc.nctu.edu.tw ()
Subject: yus21bs12yus2112yuix12bx ipwyx1xb
Organization: National Chiao Tung University
X-Newsreader: TIN [version 1.1 PL6]
Date: Tue, 13 Oct 1992 01:33:46 GMT


Newsgroups: comp.lang.c
From: dat@thinkage.on.ca (David Adrien Tanguay)
Subject: Re: unsigned long version of time_t?
Organization: Thinkage, Ltd.
Date: Thu, 15 Oct 1992 17:47:39 GMT

per@front.se writes:
>What is the canonical way to extend the range of time_t? If my
>calculations are correct, end-of-time for a signed long is in 2038,
>but an unsigned long can reach 2106.

A time_t could be a double. On some systems, the mantissa part of a double
is longer than an unsigned long, and can be used to store an exact integer.
-- 
David Tanguay       dat@Thinkage.on.ca  dat@Thinkage.com  uunet!thinkage!dat
Thinkage, Ltd.           Kitchener, Ontario, Canada          [43.40N 80.47W]
Newsgroups: comp.lang.c
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Re: multidimensional arrays as parameters
Organization: Sequoia Peripherals, Inc.
Date: Wed, 14 Oct 92 19:49:45 GMT

In article <behrenss.719056199@hphalle6> behrenss@Informatik.TU-Muenchen.DE (Soenke Behrens) writes:
>bill@chaos.phys.ualberta.ca (Bill Burris) writes:
>
>>I was wondering how to pass a multidimensional array as a parameter.
>
>Serious suggestion first: Buy a book on C.

And make sure it isn't the book that Soenke learned from. 

>>Now for a 2D array if I do the following:
>>void fun2d( int * );
>>int array2d[10][20];
>
>And how do you think that would work? You tell the compiler that fun2d
>expects 'int *', and then you pass it 'int **'. You could declare

No, he's not passing it an 'int **'.

The name "array2d" used as an argument to func2d follows The 
Rule (TM): an array name used in an expression context is converted 
to a pointer to its first element. And that's all that happens to
it.

Now "array2d" is an array of 10 elements, each of which is of type
<array 20 of int>. So in an expression context, "array2d" is converted
to a pointer to the array's first element, this element being of type
<array 20 of int>. So "array2d" (and the formal parameter of fun2d) must
be a pointer to an array of 20 ints. Recognizing that the C grammar makes
array indexing bind more tightly than pointer dereferencing, this is
written as:

   void fun2d (int (*)[20]);


   main ()
   {
      int array2d[10][20];

      fun2d (array2d);
   }

   void fun2d (int (*dptr)[20])
   {
      .....
   }

See this newsgroup's FAQ list for another (and presumably better)
explanation. 


-- 
Dave Eisen    dkeisen@leland.Stanford.EDU   Sequoia Peripherals: (415) 967-5644
      Incompetent amateurs have given prostitution a bad name.
        --- Camille Paglia in "Madonna II: Venus of the Radio Waves"
From: magiera@syr.ge.com (Larry Magiera X7453)
Newsgroups: comp.lang.c
Subject: Kalman Filter code/library
Date: 14 Oct 92 21:40:18 GMT
Article-I.D.: crd.1992Oct14.214018.4454
Reply-To: magiera@syr.ge.com
Organization: General Electric Co. - Syracuse, NY

Does anyone out here know of a library of functions involving
kalman filters??

thanx

---
--
Larry Magiera
ECMS Software
magiera@e7sc10.ecms.syr.ge.com
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Realloc failure when downsizing (was Re: Probably a simple realloc() question)
Date: 12 Oct 92 19:21:52 GMT
Organization: negligable

In article <1992Oct9.083836.15851@klaava.Helsinki.FI> wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
>Richard Hartman wants to discuss further why realloc should or shouldn't
>return NULL when it fails to make a block smaller.
>
>1. You cannot change the specification of realloc (until around the year
>   2000 or so).  Under the current specification, realloc can fail when
>   downsizing, which means that you _have_ to check it (ergo, no savings
>   in simpler code with no error checking is possible).

Actually checking the manual page I found that when realloc fails
(at least on my system) it does NOT dispose of the original memory
block, so my main objection (the library losing your data for you)
disappears.

It also, however, does say that the pointer returned may not be
unchanged, so my suggestion on the implemntation still seems valid.
(Bear in mind that the thing that touched this off was someone's 
comment that the library implementation was stupid).

>2. If realloc returns NULL when failing to downsize, you may be able to 
>   learn useful things from it.  For example, that memory is tight, and
>   that the size of the block was not changed (you might want to be able
>   to use the memory instead of wasting it).  This information is not
>   available if realloc returns the original pointer.

Again, my man page says that the orig block was not changed.  Some
of the posts here were saying (paraphrased) "free it regardless".
That was my prime objection.

>5. Also, from a pure common sense point of view, since realloc may fail
>   for other reasons than lack of memory, and since no programmer is
>   perfect, realloc just might be signalling an error on your part. 
>   (Are you _sure_ that the pointer is valid?)  It is simply good
>   engineering to program defensively and to include checks for things
>   that "can't happen".

Now HERE'S one I could agree with from the start!  I wasn't saying
you shouldn't check the results, just that there was not a good
reason for the library implementation to be failing on a downsizing.
This is NOT an excuse for failing to check the results.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Blasting, bursting, billowing forth with	|
the power of ten billion butterfly sneezes,	|	-Richard Hartman	
Man, with his flaming fire,			|	hartman@uLogic.COM
has conquered the wayword breezes.		|
Newsgroups: comp.lang.c
From: hjv@phil.ruu.nl (Hendrik Jan Veenstra)
Subject: Re: struct/union
Keywords: struct
Organization: Department of Philosophy, University of Utrecht, The Netherlands
Date: Wed, 14 Oct 1992 16:16:37 GMT

cs310as@ux1.cso.uiuc.edu (Tonya Yu) writes:

>Hi...
>I have a problem using pointer within in struct or at least i think that is 
>what the problem is.
>Is the following sturct declaration valid?

>      typedef struct { int x;
>                       int y;
>                       FOO *junk_pointer; } FOO;

>I am getting an error message telling me to use union?
>The C book I have does not fully explain this matter.
>Any input will be greatly appreciated.

Try this instead:

	typedef struct foo_struct
		{ int x;
		  int y;
		  foo_struct *junk_pointer;
		} FOO;

At the moment the FOO* is encountered in your code, the type FOO is not
know yet, but the 'struct foo_struct' *is*.

--
Hendrik Jan Veenstra  |  hjv@phil.ruu.nl  |   You look for your dreams in
Dept. of Philosophy   |                   |   heaven, but what the hell are
University of Utrecht |                   |   you supposed to do when they
The Netherlands       |                   |   come true...?
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: Life, stderr, and everything (was Re: malloc() as a user...)
Date: 14 Oct 92 11:06:45 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <1992Oct12.172346.14127@organpipe.uug.arizona.edu>, dave@cs.arizona.edu (Dave Schaumann) writes:
> In article <15040@goanna.cs.rmit.oz.au>, ok@goanna (Richard A. O'Keefe) writes:
> >(1) Standard output might be routed to a file.
> >    Use stderr, which is there precisely for you to write error messages.

> Perhaps so.  But particularly when I'm debugging, I want my error
> messages in *exact* sync with the rest of my program's output.

Even more than that, I want my error messages to _appear_.
In UNIX the default is that stdout is _buffered_ and stderr is not.
If I write an error message to stderr, it will come out at once.
If I write it to stdout, I may never see it.

So if someone routes error messages to stdout, it may be a good idea to
	setbuf(stdout, NULL);
early on in main().

> I'm not particularly fond of either of the error messages presented
> here.  "Malloc error." is clearly lacking in specificity, and "Unable
> to allocate enough memory" is too vague on the details for me.  I'd
> greatly prefer a simple and accurate
> 
> 	FATAL ERROR: malloc() returns NULL
> 
Well, "malloc() returns NULL" isn't any more specific than "malloc error";
there is after all only one way that malloc() _can_ report an error, and
someone who doesn't understand that won't understand what malloc() is
either.  I greatly prefer error messages that do not require the user
to be fluent in C.  The best thing to do would be to make a macro like
assert, perhaps call it "fatal", so that
	#define fatal(message) do {				    \
	    fprintf(stderr, "\nFatal error at line %d in %s: %s\n", \
		__LINE__, __FILE__, message);			    \
	    exit(EXIT_FAILURE);					    \
	} while (0)

So that
	fatal("Out of memory");
might produce
	Fatal error at line 123 of foobar.c: Out of memory.
which contains information for the user who is not a C programmer,
and provides far more explicit information for the maintainer than
a vague statement that some malloc() somewhere returned NULL.
From: jutta@opal.cs.tu-berlin.de (Jutta Degener)
Newsgroups: comp.lang.c
Subject: Re: static/external <=> storage/linkage
Date: 13 Oct 92 13:09:35 GMT
Organization: Techn. University of Berlin, Germany

choup@bionette.cgrb.orst.edu (Ping Chou) writes:
> extern int global_1;  /* external storage, external linkage */
>        int global_2;  /* static storage, external linkage */
> static int global_3;  /* static storage, static linkage */

There is no such animal as "external storage".  The storage class,
or duration, of a variable defines how long it lives, not where
it is visible.

C only recognizes two durations -- either a variable is there
all the time, this is called "static" or "global", or a new copy
is created for each invocation of the enclosing scope, then it's
called "automatic".

Variables defined outside of a function have static duration.
So have variables you define using the `static' keyword, no matter
where you define them.  Everything else has automatic duration.

--Jutta
Newsgroups: comp.lang.c
From: d9502001@ccms (Jih-Chung Lee)
Subject: Does Watcom C9.0/386 support 387 coprocessor ?
Organization: National Taiwan University Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Tue, 29 Sep 1992 10:30:25 GMT

Hi,
  Does anyone know whether Watcom C9.0/386 C compiler support 387 math
coprocessor ?
  Direct mail will be prefered.
Thanks.

Jih-Chueng Lee
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Lookup table location
Date: 15 Oct 92 20:59:19 GMT
Organization: negligable

In article <1bf19uINNb2t@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>You can declare the variable with "static const char *days[] = ...", and
>prototype the function "const char *dayname(int day)".  The caller will be
>forced to use a "const char *" variable to hold the result (unless he
>explicitly casts the result to a non-const).

1) is there anything wrong with this?  I've always thought it was bad
   practice to "cast away" const-ness, it could cause trouble later
   on if you try to change the data....  what is wrong w/

    const char *answer = dayname(3);	

and how would:

    char *answer = (char *) dayname(3);

be any more helpful/useful(/safer(?!??!))

2) there *is* another way:

	char answer[DAYNAMESIZE];

	strcpy(answer, dayname(3));


note: in the above, '3' plays the part of any int expression (it doesn't
even have to be in the range 0..6 if dayname() was written w/ protection ;)
Let's give '3' a nice round of applause!


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Between the silence of the mountains	|
and the crashing of the sea 		|	-Richard Hartman	
there lies a land I once lived in	|	hartman@uLogic.COM
and she's waiting there for me.		|
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Strings and integer sizes
Date: 8 Oct 92 18:32:07 GMT
Organization: negligable

In article <1992Oct8.032607.16951@athena.mit.edu> scs@adam.mit.edu (Steve Summit) writes:
>
>strncpy, on the other hand, is (annoyingly) not guaranteed to
>0-terminate the destination, so a stratagem like the above might
>be necessary.  (My own idiom runs along the lines of
>
>	strncpy(dest, src, n);
>	dest[n] = '\0';		/* ensure \0-termination */


I have this in a central include file as:
	strncpyz(d,s,n) { strcpy(d,s,n); d[n] = '\0'; }

and then use strncpyz() throughout my code.  The 'z' convention
on the name is one I picked up somewhere as referring to "zero-terminated"
arrays as opposed to "raw" arrays.  I think there's a memcpyz() to go
w/ memcpy(), but I'm not sure....



		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Never speak in absolutes.  It will always lead to trouble.

Newsgroups: comp.lang.c
From: rehak@breeze.rap.ucar.edu (Nancy Rehak)
Subject: Re: Strings and integer sizes
Organization: NCAR / RAP
Date: Wed, 7 Oct 1992 13:46:13 GMT

In article <718167097snx@grendel.demon.co.uk> jes@grendel.demon.co.uk (Jim Segrave) writes:
>
>In article <9227705.8771@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>
>> 
>> >Multiple choice question:
>> >
>> >A string is stored
>> >	a. in an array of characters
>> >	b. in an array of characters terminated with 0
>> >	c. in an array of characters terminated with '\0'
>> 
>> Well, the answer is:
>> 	d. all of the above
>
>What about:
>
>char zoe[3] = "123";
>
>neither b. nor c. applies here.
> 
> 
>--
>Jim Segrave (Segrave Software Services)     jes@grendel.demon.co.uk
>


Actually, b. and c. both apply here as the string "123" is actually "123\0" and
the \0 is stored in the byte following the end of the array zoe.  Big problem!

If you said:

char zoe[3];

zoe[0] = '1';
zoe[1] = '2';
zoe[2] = '3';

then you would not have the trailing \0, but I would contend that you don't have
a string -- you have an array of characters.

Nancy Rehak
From: "hans friedrich steffani" <GM08@DKAUNI2.BITNET>
Subject: Re: Are pointer just addresses???
Organization: University of Karlsruhe, Germany
Date: Wed, 14 Oct 1992 08:42:19 GMT



> Hello!!! I have a question about C that I would
> like to know the answer. The question is:
>
>   "Are pointers just addresses of memory?"
>
> Thank you for your attention!!!
>
normally they are but i am shure that some experts
can explain us that pointers are slight different
from addresses of memory. e.g. on intel86-machines
in some memory-models you have pointers only being
the offset as the segment doesnt change. but a offset
isnt a full memoryaddress.

hans friedrich steffani
uni karlsruhe

Newsgroups: comp.lang.c
From: tone@leland.stanford.edu (Tony Lin)
Subject: Intercepting hangup/logout signals...?
Keywords: signals, unix, processes
Organization: DSG, Stanford University
Date: Mon, 12 Oct 92 05:46:41 GMT

Hi everyone!
  I'm new at UNIX systems programming, and I was just wondering if any of you
could help me.  I'm writing a small program that I'm planning to run in
the background.  When I hangup, this program normally would continue to
run if I don't explicitly kill it.  I would like to know if there is some
kind of signal that I can intercept that would tell me that the user has
pressed CTRL-D and is about to log off, so that my program can terminate
itself immediately.  I've tried to write a handler that intercepts
SIGHUP, SIGQUIT, and SIGTERM, but it doesn't work.  Maybe I'm just doing
it wrong.  If you know anything about this, could you sent me some sample
code explaining what I should do?   Any suggestions would be greatly
appreciated.
  Thanks.

						Tony Lin
						tone@leland.Stanford.EDU

Newsgroups: comp.lang.c
From: woody@gergu2.tamu.edu (Woody Lee)
Subject: Help!  Function not returning float values.
Reply-To: woody@gergu2.tamu.edu
Organization: Texas A&M University -- GERG
Date: Fri, 16 Oct 1992 22:06:19 GMT



Could someone out there please tell me why I can't get a function to
return a floating point value??!!  If I declare the function as
anything other than an int it returns nothing at all.  It returns the 
sppropriate value as an integer, but that's not what I need.


I'm running on a DEC 5000, Ultrix4.2a.  Nothing else special.

Thanks.

--
Woody Lee    -=-=-   woody@gergu2.tamu.edu   -=-=-   (409) 862-2321 
GERG - Latex/A Data Office   |"That's the whole problem with science.
Texas A&M University	     | You've got a bunch of empiricists trying 
Department of Oceanography   | to describe things of unimaginable wonder."
College Station, TX 77845    |                - Calvin (& Hobbes)