HDTenEightyP/NetNews huggingface dataset:
From: steve@taumet.com (Steve Clamage)
Subject: Re: Where are literals stored?
Organization: TauMetric Corporation
Date: Thu, 19 Nov 1992 19:12:59 GMT

richard@crowded-house.den.mmc.com (Richard Armstrong) writes:

|Are literals always stored in the same location in memory? (IBM-PC,Borland)

|For instance, is the string a stored in the same place in the following
|two declarations?:

|static char a[]="ABC"
|funca()
|{
|}

|funca()
|{
|char a[]="ABC";
|}


Nothing in the C language specifies where string literals are stored,
whether they are always stored in the same address space, or whether
identical string literals may share storage.  You have to read the
manual for your compiler.  Some compilers have directives for
controlling where literals are stored.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c
From: root@ufps9.unifr.ch (Operator)
Subject: Re: Virtual memory Management Systems
Organization: University of Fribourg - CH
Date: Wed, 18 Nov 1992 07:26:34 GMT

Hi,
In article <1992Nov17.143327@gese.ge14.mdadv.gv.at>, sca@gese.ge14.mdadv.gv.at (Petzi Schweda) writes:
|> 
|> In article <1992Nov17.103746.20006@di.unipi.it>, Nico Tranquilli <ntranqu@caticsuf.cati.csufresno.edu> writes:
|> |> Could anyone please tell me how to call the Hardware/Software needed
|> |> to manage virtual memory ?
|> |> --
|> |> nico.
|> 
|> Huh ?
|> 
|> UNIX: don't know more then malloc/calloc ...
|> VMS: see lib$get_vm in your RTL-doc's
|> PC/WINDOWS: GlobalAlloc/GlobalLock 
|> WINDOWS NT: VirtualAlloc
|> 
|> Is it that you wanted to know ?
|> 
|> regards, Petzi
|> -- 
|> Petzi Schweda (sca@gese.ge14.mdadv.gv.at)
|> MD-ADV, Municipality of the City of Vienna, Austria

For theorical stuff, look at the books written by Andrew Tannenbaum, Silberschatz or
Hoare about operating systems.
Particularly, I remember something is written in Silberschatz - Operating System Concept
(excuse me I don't have this book in my hand now and am not sure the title is correct).
The UNIX aspect of memory management is discuss.

For the application of tools given by the operating system, I'm afraid the only
a technical reference or programmer guide especially for your machine could help you.

Mail me if you want more. Bye.

							Laurent Schmutz
							schmutz@CFrUni52.bitnet
							University of Fribourg, Switzerland.

Newsgroups: comp.lang.c
From: sca@gese.ge14.mdadv.gv.at (Petzi Schweda)
Subject: Re: The Correct Way To Write C if-Statements
Originator: sca@gese0n.ge14.mdadv.gv.at
Organization: MD-ADV, Vienna, Austria
Date: Mon, 16 Nov 1992 08:48:33 GMT


In article <604@ulogic.UUCP>, hartman@ulogic.UUCP (Richard M. Hartman) writes:
> >
|> >>	if ( OpenCode ) ...
|> >
|> >Is anyone else as repelled as I am by the practice of leaving the
|> >parentheses surrounded by whitespace on both sides?  Not only does
|> 
|> I am! I am!
|> 

Me too !
So we finally agree to
     if (cond statements)
right ?

!> I finally convinced 'em of the futility of this one though.  But they
|> still insist on:
|> 
|> 	if (x == y)
|> 		flag = TRUE;
|> 	else
|> 		flag = FALSE;
|> 
|> instead of believing that:
|> 
|> 	flag = (x == y);
|> 
|> actually works.   What do you have to say about that one?
|> 
Fine !
Generally I would tend to use the "if"-way if what's happening upon the 
condition has a major influence on the behavior or structure of the program,
and the "=(==)"-style when "flag" isn't so important at all ...

By the way, I think that the whole discussion isn't one of "personal taste" 
or something like that - much more it's about how someone can get a 
feeling what some code written by somebody else does.
If your'e working in an ivory tower whatever makes you work happy is perfectly
right - but when working as a group (wer'e here 6) you have to establish
conventions to avoid misunderstandings and save time and money ...

Furthermore the usabiltiy of PD- or shareware-code would be enhanced if
the guys writing it would have a little eye on gettin' over the ether HOW
their keen stuff works (I'm far off talking about inline-doc's)... 

regards, Petzi

-- 
Petzi Schweda (sca@gese.ge14.mdadv.gv.at)
MD-ADV, Municipality of the City of Vienna, Austria


-- 
Petzi Schweda (sca@gese.ge14.mdadv.gv.at)
MD-ADV, Municipality of the City of Vienna, Austria
Newsgroups: comp.lang.c
From: carl@montebello.ecom.unimelb.EDU.AU (Carl Brewer)
Subject: strange things with gcc
Organization: Computer Science, University of Melbourne, Australia
Date: Mon, 16 Nov 1992 14:51:29 GMT

I've ahd some funny problems with gcc on SunOS 4.1.2 of late, it doesn't
seem to handle fflush(stdin) very well (ie not at all).

either that, or I'm not using it correctly ?

calling it as gcc -o filename part1.c part2.c etc

do I need to send it a -ansi flag?  I thought it defaulted to ansi
anyway, as all my programmes are ansi, and I've not needed to do anything 
special before

my code works fine compiled under acc (SunOS 4.1.2), and microsoft QuickC
on a 386 PC.  The relevant function is even straight from a book ...

(ie a demonstatration programme from an ANSI C book ...)

hmmmm

oh well ....


-- 
 Annal  Natrach, Usthvah Spethed,         carl@ecr.mu.oz.au (IRC: Bleve)
 Dochoel Dienve                           carl@munagin.ee.mu.oz.au
					  carl@montebello.ecom.unimelb.EDU.AU
 Merlin, where are you?  Call your dragon, to weave a mist...
From: fischer@iesd.auc.dk (Lars Peter Fischer)
Newsgroups: comp.lang.c
Subject: Re: The Correct Way To Write C if-Statements
Date: 17 Nov 92 03:48:13 GMT
	<605@ulogic.UUCP>
Organization: Mathematics and Computer Science, Aalborg University


>>>>> "Richard" == Richard M. Hartman (hartman@ulogic.UUCP)

Richard> 	if (!condition)
Richard> 		do_something;

Richard> should obviously be written as:

Richard> 	if ( condition )
Richard> 		{
Richard> 		}
Richard> 	else
Richard> 		{
Richard> 		do_something;
Richard> 		}

Nice if you're being paid per line of code.

/Lars
--
Lars Fischer, fischer@iesd.auc.dk | It takes an uncommon mind to think of
CS Dept., Aalborg Univ., DENMARK. | these things.  -- Calvin
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: qucik, merge, shell and bubble sort
Date: 17 Nov 92 09:04:30 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

I thought I had better back up this posting with some numbers:
> In article <1e1cnvINNt2t@usenet.INS.CWRU.Edu>, cc015@cleveland.Freenet.Edu (Vito T. Kwan) writes:
> Costs:
> 	Quick sort is O(N**2) in the worst case.  It is complicated and
> 	unstable.  Its _average_ cost is O(N.lgN).  The only known reason
> 	for using quicksort is if you are DESPERATELY short of memory; it
> 	was invented for use on a computer with 256 words of main memory.
> 	(Read Hoare's paper in Computer Journal 1961.)  At the time it was
> 	invented, it was known to be inferior to merge sort by every metric
> 	except space, and if you are sorting a list it doesn't save any
> 	space either.
> 
> 	Merge sort is O(N.lgN) in the worst cast.  If the comparisons are
> 	not trivial (i.e. if the compiler does not know at compile time that
> 	they are machine integer comparisons) then the *worst* case of
> 	merge sort is better than the *best* case of quick sort.
> 
> Of the four methods, the only one that can be recommended for general use
> is merge sort.

The following numbers were obtained on an Encore Multimax running their
port of System V Release 3.2, using Encore's C compiler (-q optimize=time)
and runtime library.  File 1 was 25000 words in random order (taken from
/usr/dict/words on another Encore box running BSD).  File 2 was the same
25000 words replicated 4 times and scrambled again.  All times are accurate
to about +/- 1 second.

				File 1		File 2

merge sort (array based)	4 seconds	20 seconds
qsort				6 seconds	24 seconds
heap sort (array based)		6 seconds	29 seconds
dummy (read, no sort, write)	2 seconds	 8 seconds

From these figures, the actual sorting times were

merge sort (array based)	2 seconds	12 seconds
qsort				4 seconds	16 seconds
heap sort (array based)		4 seconds	21 seconds

This is not entirely fair to qsort, but on the other hand, I didn't pick
my fastest version of merge sort either.
Newsgroups: comp.lang.c
From: chaplin@keinstr.uucp (Roger Chaplin)
Subject: Re: The Correct Way To Write C if-Statements
Organization: Keithley Instruments, Cleveland, Ohio
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 19 Nov 1992 17:04:21 GMT

Richard M. Hartman (hartman@ulogic.UUCP) wrote:

: 	if (!condition)
: 		do_something;
: 
: should obviously be written as:
: 
: 	if ( condition )
: 		{
: 		}
: 	else
: 		{
: 		do_something;
: 		}
: 
: so as to avoid the "!" operator.  

Why avoid the `!' operator?  Obviously the intention of this code is
"If not condition then do something."  Writing it as "If condition then
don't do anything, otherwise do something" obfuscates it.  I quickly
grep'ed through the 1992 winning Obfuscated C contest files, and didn't
find `Hartman' anywhere B-)

In my experience (disclaimer B-) the compiled code will execute equally
fast (or slowly) whether it is branching on zero or branching on
not-zero.  Maybe I've just been lucky in never having had to work with
bizarre processors.

-- 
Roger Chaplin / Instruments Division Engineering / "This land is your land,
chaplin@keinstr.uucp / CI$: 76307,3506          / This land is my land,
#include <disclaimer.h>                        / One of us has a bogus deed
#include "disclaimer.h" /* cover all bases */ / to this land."  - George Carlin
From: roy%cybrspc@cs.umn.edu (Roy M. Silvernail)
Newsgroups: comp.lang.c
Subject: Re: The Correct Way To Write C if-Statements
Date: Sat, 21 Nov 92 02:59:11 CST
Organization: Villa CyberSpace, Minneapolis, MN

sca@gese.ge14.mdadv.gv.at (Petzi Schweda) writes:

> think you'll end up a little bit messy when using this one inside blocks:
> 
> for (...)
>     {
>     if  (cond)
>     {
>         state;
>     }
>     else
>     {
>         state2;
>     }
>     }
> 
> too much paranthesis in this column, for my taste ...

Yuk!  OK, the original article notwithstanding, what's wrong with this?

for (...) {
    if (cond) {
        state;
    } else {
        state2;
    }
}

I've also been known to do this...

for (...) {
    if (cond) {
        state;
    } else
    if (other_cond) {
        state2;
    } else
    if (yet_another_cond) {
        state3;
    }
}

This makes it easy to add (yet_one_more_last_minute_condition) without
having to decode brace placement.
--
Roy M. Silvernail --    [my machine ] "Sometimes, you're the windshield....
roy%cybrspc@cs.umn.edu  [my opinions]            sometimes, you're the bug!"
cybrspc!roy@cs.umn.edu  [my $0.0275 ]                      --Mark Knopfler
From: maurer@nova.stanford.edu (Michael Maurer)
Newsgroups: comp.lang.c
Subject: Re: the abs() function in C
Date: 20 Nov 92 08:04:09 GMT
Organization: STAR Lab, Stanford University, California USA
Distribution: world
NNTP-Posting-Host: magellan.stanford.edu

In <pebi.722223424@zephyr.aem.umn.edu> pebi@aem.umn.edu (Peter A. Bidian) writes:


>Isn't abs(-2)=2 in C?
>I always get 0.

>Confused!

>Peter

you probably want to say abs(-2.0), if the abs() function expects a
floating point argument.  or abs((double)-2).
--
______________________________________________________________________
Michael Maurer          maurer@nova.stanford.edu        (415) 723-1024
From: kdq@quest.UUCP (Kevin D. Quitt)
Newsgroups: comp.lang.c
Subject: Is this ANSI?
Date: Wed, 18 Nov 92 18:00:19 PST
Reply-To: srhqla!quest!kdq
Organization: Job quest  (805) 251-8210,  So Cal: (800) 400-8210

    I'm working on an HP9000, in UNIX, using the native C compiler
which claims to be ANSI compliant.  It appears to be, in most things,
even though you've got to jump through hoops to really get it into ANSI
mode with the correct ANSI includes.

    Here is (a simplified version of) the struct that the compiler
calls an error:

struct FM
{
	short	data_len;
	char	data[];        /*  This line is the kicker  */
};

    As I recall, ANSI says this is legal, with sizeof( struct FM) is 2 
bytes, and offsetof( struct FM, data) is 2.

    I note that the FAQ does not address this issue directly.  It
states (in question 9.6) that the ANSI C standard allows:

struct name
{
	int namelen;
	char name[1];
};

    only implicitly.  

    So, I have two questions: Is the original structure legal ANSI
code?  And if so, what does it take to make HP's cc be ANSI compliant
(-Aa ain't enough) (or have I really found a bug?).  BTW, all my other
compilers have no complaints - the HP compiler does just issue a
warning, it craps out.

    Thanks in advance.  (P.S. email preferred unless you think it's of
general interest)


 _
Kevin D. Quitt      96.37% of all statistics are made up.     srhqla!quest!kdq
Xref: sparky comp.lang.c:16971 comp.os.vms:18309
From: 873clifton@gw.wmich.edu
Newsgroups: comp.lang.c,comp.os.vms
Subject: Re: Looking for "C" Source Line Counter
Date: 21 Nov 92 18:47:41 EST
Organization: Western Michigan University

In article <2B097095.1911@deneva.sdd.trw.com>, flower@donald.etdesg.trw.com (Rick Flower) writes:
> Hi...
> 
> 	I'm looking for a code line counter for "C".. I'm guessing that there
> is one out there somewhere!  Ideally, I'm looking for one that runs on a 
> VAX/VMS system, but if the code is for Unix, I'd be more than willing to port
> it to the VAX environment (not the first or last time!)..  If you know of one
> floating around somewhere, please e-mail me what the name is or where I can
> find it, etc..  Any help is appreciated!
> 
> -- Rick

If you used a Unix machine then use wc (word count - counts words, characters
and lines in a text file). Fortunately both BSD and GNU versions are available
for anonymous ftp. The GNU version will be in the textutils package and the
BSD version will be usally in the /usr/bin directory of any ftp site with a
bsd_source directory. Try ftp.uu.net, you'll find both GNU and BSD there.

/D
--
Douglas Clifton [99clifto@lab.cc.wmich.edu]
From: goudreau@robin.rtp.dg.com (Bob Goudreau)
Newsgroups: comp.lang.c
Subject: Re: The Correct Way To Write C if-Statements
Date: 16 Nov 92 17:47:03 GMT
Organization: Data General Corporation, RTP, NC.

In article <craigh.721691551@cserver> craigh@cserver.plexus.com (Craig Heilman) writes:
>goudreau@batman.rtp.dg.com (Bob Goudreau) writes:
>
>[...]
>>Anway, if I were posting in Swedish, then perhaps I'd put only one
>>space after each period.  But in English, two following spaces *IS*
>>the standard (look it up).
>
>Two spaces after a sentence is a throwback to the typewriter days when
>everything was "monospaced" ...

>Two spaces looks better with such fonts (note how these net messages are
>monospaced - at least on my machine).

Exactly!  That's why I use two spaces in my articles!  We ain't
exactly typsetting books here on Usenet.


----------------------------------------------------------------------
Bob Goudreau			Data General Corporation
goudreau@dg-rtp.dg.com		62 Alexander Drive	
+1 919 248 6231			Research Triangle Park, NC  27709, USA
Newsgroups: comp.lang.c,comp.lang.c++,comp.misc
From: aa@rexago8.uucp (Adam Andrews)
Subject: Re: Confused
Organization: Summit Information Systems
Date: Mon, 23 Nov 1992 14:23:20 GMT

fhi0055@hq.dla.mil (Marc Poole) writes:

[some code deleted]
>printf ("Enter you number: ____\b\b\b\b");
>scanf ("%d",&fact); 

>while 
>{
>    while (fact > 0)
>       {
>       count = count * fact--;
>       }
>answr = count;
>printf ("%e", answr);
>printf ("\n");
>printf ("Enter another number or 0 to quit: ___\b\b\b");

I hope you have another scanf here; otherwise you will always have an infinite
loop unless 0 is the first number they enter (assuming you implement the 
solutions in the previous posts).

>}


>printf ("\n");
>}

-- 
Adam Andrews                "When the going gets weird, we get even weirder."
uunet!rexago8!aa or aa@rexago8.UUCP       e-mail only to aa@summitis.com
Newsgroups: comp.lang.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: struct hack (was: Is this ANSI?)
Summary: Clarification
Organization: SoftQuad Inc., Toronto, Canada
Date: Mon, 23 Nov 92 08:51:12 GMT

I wrote:

> [3] 3.1.2.5 says that a pointer contains a reference to an object and
>     says nothing to allow it to possibly containing other information.
>     Therefore fmptr->data is equivalent to p+offsetof(struct FM,data) ...

Here and farther down in the article, by fmptr->data, I meant of
course the pointer to which this array-valued expression decays when
its value is taken as an operand to + or [], as specified in 3.2.2.1.
Sorry about that.
-- 
Mark Brader			"A clarification is not to make oneself clear.
SoftQuad Inc., Toronto		 It is to PUT oneself IN the clear."
utzoo!sq!msb, msb@sq.com		-- Lynn & Jay, "Yes, Prime Minister"

This article is in the public domain.
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: & of array - what does ANSI specify for resulting value?
Date: 21 Nov 92 06:25:55 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article 1901@ils.nwu.edu, engber@ils.nwu.edu (Mike Engber) asked:
? int foo[3];
? I know ANSI specifies the type of &foo will be an int**, how about
? the value? Is it unspecified - or - &foo[0].

In article <1992Nov13.204451.26101@eagercon.com>,
eager@eagercon.com (Michael J. Eager) replied:
> No, ANSI specifies that &foo is illegal.

Wrong.  &foo is legal and has type pointer-to-array-3-of-int.

> foo is converted to a value
> which is the address of the first element of the array.

Only in a value context.  & and sizeof are not value contexts
and array->pointer decay does not happen.
From: jlothian@castle.ed.ac.uk (J Lothian)
Newsgroups: comp.lang.c
Subject: Re: What is meant by: double A[n,m]?
Date: 18 Nov 92 20:13:41 GMT
Organization: Edinburgh University Computing Service

In article <TORSTEIN.92Nov18125146@itekiris.kjemi.unit.no>, torstein@itekiris.kjemi.unit.no (torstein hansen) writes:
|> As a newcomer to C, previously programming in Pascal, I used the
|> following declaration in one of my programs:
|> 
|> double A[n,m];
[...]

|> Has it something to do with the comma operator, discarding the first
|> value inside the braces?

I suspect that's exactly what's happening. The comma operator
evaluates both its arguments, returning the value of the right-
hand expression and throwing away the value of the left-hand one.
Presumably your C compiler is quite happy to do this evaluation
at compile-time, though I'm a little surprised that it didn't flag
this as an error, given that in this context the construction is
bound to be meaningless. 

James

-- 

-------------------------------------------------------
James Lothian        |      "It's life, Jim, 
james@uk.ac.ed.caad  |   but not as we know it"
Newsgroups: comp.lang.c
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Re: Multiple &'s in an if statement
Organization: Sequoia Peripherals, Inc.
Distribution: comp.lang.c
Date: Tue, 24 Nov 92 03:28:12 GMT

It was pointed out in email that my post was misleading because I
elided too much of the original poster's article.

In article <1992Nov23.212924.7733@leland.Stanford.EDU> dkeisen@leland.Stanford.EDU (Dave Eisen) writes:
>>In C, a zero is false and anything else is true.  There is no specification
>
>False. 
>
>All of the boolean operators (==, &&, and ||) are guaranteed to
>return 0 for false and 1 for true. There are obfuscated C contest
>entries that depend upon this behavior so the ANSI committee couldn't
>change that.

Of course the quoted part is *not* false. It is quite true. It
also wasn't really what I was replying to.

Here is a little more of the article I was responding to.

>In C, a zero is false and anything else is true.  There is no specification
>for what (x == y) returns other than zero or not zero.  

And this is in fact false. As I said, x == y must return either
0 or 1. I apologize for any confusion.




-- 
Dave Eisen                               Sequoia Peripherals: (415) 967-5644
dkeisen@leland.Stanford.EDU              Home:                (415) 321-5154
       There's something in my library to offend everybody. 
          --- Washington Coalition Against Censorship
Newsgroups: comp.lang.c,comp.software-eng
From: ofut@gmuvax2.gmu.edu (A. Jeff Offutt)
Subject: Why are some programmers more productive?
Organization: ISSE Department, George Mason University
Date: Mon, 23 Nov 1992 01:33:43 GMT

In article <BxMuBK.ArM@inews.Intel.COM> nsridharan@faois.intel.com (Sridharan) writes:

>Try a hypothesis:  What if .. just what if .. the famous 80-20 rules works.
>Examples: 80 percent of the function comes from 20 percent of the code
>	80 percent of the value comes from 20 percent of the effort
>	80 percent of the result comes from 20 percent of the people (in a large
>project)
   ...
>get 80% of the most valuable work done in 20% of the effort; and  
>if a "gifted" programmer is one who can apply the 80-20 rule twice over - and
>can get
>64% of the value with only 4% of the effort
>- Would this account for the variability in productivity?

I had an interesting experience in one of my classes last year that explains a
lot about "programmer productivity", especially the "super programmer" notion
(that some people produce 10 times, 100 times, whatever, more than others).

This is a software engineering team project course -- they go through
the whole process, from requirements to integration.  A kid who thought
he was a very good programmer (he'd done very well in previous classes)
came up with a design for his team's subsystem that, while very clever,
was very inefficient.  During the design review, they pointed out that
they were halfway through coding -- had already written 1000 lines of
code.  But I pointed out a severe flaw, and a way to reduce the size of
the subsystem coonsiderably.  This did not make them happy, until I
pointed out that they were now planning on writing about 1000 more
lines of code, and the new design would only require a couple of
hundred, so the new design was _still_ a net savings.

The point is, if you can write code much faster than I can, _and_ you
come up with a better design, the advantage is multiplied because you
start with less code to write.  This is what Brooks meant in his Silver
Bullet paper about fostering "great designers" ... a great design will
make everybody great programmers.


Jeff Offutt
Department of ISSE, George Mason University, Fairfax VA
email: ofut@gmuvax2.gmu.edu
phone: (703) 993-1654 (messages: 993-1640)
-- 
Jeff Offutt
Department of ISSE, George Mason University, Fairfax VA
email: ofut@gmuvax2.gmu.edu
phone: (703) 993-1654 (messages: 993-1640)
Newsgroups: comp.lang.c
From: msb@sq.sq.com (Mark Brader)
Subject: The Correct Way To Space English (was: The Correct Way To Write...)
Followup-To: poster
Organization: SoftQuad Inc., Toronto, Canada
Date: Mon, 16 Nov 92 00:02:57 GMT

> > "In typewritten material, two spaces follow a period that ends a
> > sentence. ... In typeset material, only one space follows this
> > period."
> 
> In typeset material, spaces don't occur in nice integer units, so "one
> space" versus "two spaces" makes no sense.  (Unless it's being typeset
> monospaced, of course.)  The space after a period (or more precisely,
> at the end of a sentence - not all periods end sentences) *is*
> generally wider than the space between words in that sentence, though.

No, not generally.  This style, which I happen to like, is mostly
seen in:

	1. Books some decades old
	2. Text typeset with troff
	3. Text typeset with TeX

For people reading this newsgroup, it's much more likely than it is
for people in general that text they read will fall in one of the
last two categories.  This is way off topic for the newsgroup, anyway;
followups are directed to email, or you might start a new thread in
comp.text, or maybe sci.lang or alt.usage.english.

I agree that two spaces are usual and preferable in monospaced text.
-- 
Mark Brader		   "I don't care HOW you format   char c; while ((c =
SoftQuad Inc., Toronto	    getchar()) != EOF) putchar(c);   ... this code is a
utzoo!sq!msb, msb@sq.com    bug waiting to happen from the outset." --Doug Gwyn

This article is in the public domain.
Newsgroups: comp.lang.c