scanf (yes/no) - doesn't work + deprecation errors scanf, fopen etc. - Page 4

Keith Thompson wrote:

Prior to the ANSI standard, strdup() was commonly part of the C
library, right?
Not in the base <string.h>.
Why did the C89 standard include gets() but not strdup()?
Because gets() was in the legacy library and strdup() wasn't.

Some of us tried to get strdup() adopted for the standard,
but there was resistance primarily on the grounds that no other
standard function malloc()ed storage and the opposition didn't
want to start that as a design trend.
If gets() had been dropped from the standard back in 1989,
would that have been a bad thing; would you have (or did you) argue
for including it?

Actually I argued against including it in the first place,
but now that it is part of the standardized interface I see
no benefit and some harm in its removal.

Mar 3 '06 #152

On 2006-03-03, Douglas A. Gwyn <DA****@null.net> wrote:

Keith Thompson wrote:
Prior to the ANSI standard, strdup() was commonly part of the C
library, right?

Not in the base <string.h>.
Why did the C89 standard include gets() but not strdup()?

Because gets() was in the legacy library and strdup() wasn't.

Some of us tried to get strdup() adopted for the standard,
but there was resistance primarily on the grounds that no other
standard function malloc()ed storage and the opposition didn't
want to start that as a design trend.
If gets() had been dropped from the standard back in 1989,
would that have been a bad thing; would you have (or did you) argue
for including it?

Actually I argued against including it in the first place,
but now that it is part of the standardized interface I see
no benefit and some harm in its removal.

what harm?

Mar 3 '06 #153

John Devereux

"Douglas A. Gwyn" <DA****@null.net> writes:

Some of us tried to get strdup() adopted for the standard,
but there was resistance primarily on the grounds that no other
standard function malloc()ed storage and the opposition didn't
want to start that as a design trend.

Is it really true that no standard function malloc(s) storage?
--

John Devereux

Mar 3 '06 #154

Richard Bos wrote:

"Wojtek Lerch" <Wo******@yahoo.ca> wrote:
Well, exactly. It can be used safely, if you do control the input to stdin.

Sure. But this involves bondage gear, a single-user computer that has
never been connected to any kind of network, and deleting the executable
immediately after the single run.

Hardly. Gets() has been used in a zillion contexts where it has
not overflowed the allotted buffer, so it must not require all
of what you describe. You probably have in mind a usage model
that does *not* include controlling the input to stdin, which is
a different context.

Mar 3 '06 #155

Francis Glassborow wrote:

... I get tired of the
number of books for novices that still use gets(). As long as it is in
the Standard authors will just argue that they are using the standard
library.
If we removed it tomorrow, not a single program would fail but we could
condemn those that continue to teach its use and they would have
absolutely no defence.

First, you cannot "remove it tomorrow"; it's currently required
for standards conformance, and gets() will continue to be provided
in standard libraries for the indefinite future, even if it
eventually is no longer allowed for conformance for it to be
declared in <stdio.h> (which is a change that much legacy gets()-
using code wouldn't notice, due to explicitly declaring gets()
directly).

Also, if those books (taking your word for it since I'm not
familiar with them) use gets(), they should use the opportunity
to teach about the general buffer overrun issue, which is easy
for a novice to run afoul of. Indeed, a function similar to
gets() could easily be dreamed up as a nice way to encapsulate
reading a text line, and if the issue is not appreciated the odds
are that the programmer will just recreate the same problem.

Finally, if those books are claiming that gets() is good practice
for general contexts (unconstrained stdin), then they already
have no good defense; the "defense" that the interface can be
found in some (non-safety oriented) standards document is already
not justification for using any function inappropriately.

Pedagogically, gets() is a good example to have around.

Mar 3 '06 #156

Rod Pemberton wrote:

... People who do care about it use safer functions.

Indeed, and they generally use their own support library.
The converse point is important also: Please who don't
exert sufficient care about gets() usage aren't likely
to produce safe code regardless of whether gets() exists.

Mar 3 '06 #157

John Devereux <jd******@THISdevereux.me.uk> writes:

"Douglas A. Gwyn" <DA****@null.net> writes:
Some of us tried to get strdup() adopted for the standard,
but there was resistance primarily on the grounds that no other
standard function malloc()ed storage and the opposition didn't
want to start that as a design trend.

Is it really true that no standard function malloc(s) storage?

Well, obviously malloc() does, and calloc() and realloc() effectively
do. Other than that, fopen() and other functions *could* malloc
storage behind the scenes, but not in any manner that's visible to a
calling program.

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

Mar 3 '06 #158

On 2006-03-03, Douglas A. Gwyn <DA****@null.net> wrote:

Richard Bos wrote:
"Wojtek Lerch" <Wo******@yahoo.ca> wrote:
> Well, exactly. It can be used safely, if you do control the input to stdin.

Sure. But this involves bondage gear, a single-user computer that has
never been connected to any kind of network, and deleting the executable
immediately after the single run.

Hardly. Gets() has been used in a zillion contexts where it has
not overflowed the allotted buffer, so it must not require all
of what you describe. You probably have in mind a usage model
that does *not* include controlling the input to stdin, which is
a different context.

And how is the input controlled? Blind luck?

Mar 3 '06 #159

CBFalconer wrote:

Chris Torek wrote:
The function fpurge() erases any input or output buffered in the
given stream. For output streams this discards any unwritten
output. For input streams this discards any input read from the
underlying object but not yet obtained via getc(3); this
includes any text pushed back via ungetc.

Your version seems eminently useful, and offhand I see no reason
for it not to be implementable on all C systems. Not portably
implementable, however. Which, to me, is an excellent reason to
incorporate it in the standard.

It's not evident how useful it is in general, because details
of the buffering vary among platforms. For example, on some
systems multiple input or output lines might be buffered while
on others just one line at a time might be, depending on file
type etc. There are also multiple levels of buffering,
including kernel character queues, etc. and one needs to
specify whether or not unread/unwritten buffered data is
flushed at that level also. For a specific platform one can
handle all the details, but for general use it would be not
only a problem to specify adequately but also to use in a
portable manner.

Mar 3 '06 #160

Jordan Abel wrote:

And how is the input controlled? Blind luck?

No. How is an automobile's direction controlled? By blind luck?

Mar 3 '06 #161

John Devereux

Keith Thompson <ks***@mib.org> writes:

John Devereux <jd******@THISdevereux.me.uk> writes:
"Douglas A. Gwyn" <DA****@null.net> writes:
Some of us tried to get strdup() adopted for the standard,
but there was resistance primarily on the grounds that no other
standard function malloc()ed storage and the opposition didn't
want to start that as a design trend.

Is it really true that no standard function malloc(s) storage?

Well, obviously malloc() does, and calloc() and realloc() effectively
do. Other than that, fopen() and other functions *could* malloc
storage behind the scenes, but not in any manner that's visible to a
calling program.

I was thinking in particular about "big" functions like printf, and
embedded applications (where malloc / free use is often discouraged).

If it was guaranteed that standard functions did *not* use malloc
"behind the scenes", then this could be useful to know.

--

John Devereux

Mar 3 '06 #162

kuyper

Douglas A. Gwyn wrote:
....

Hardly. Gets() has been used in a zillion contexts where it has
not overflowed the allotted buffer, ...
That just means that the developers were unlucky enough to have a bad
design's flaws fail to surface. It doesn't mean that the design wasn't
flawed.
... so it must not require all
of what you describe. You probably have in mind a usage model
that does *not* include controlling the input to stdin, which is
a different context.

Since I don't know of any portable way for a C program to control it's
own standard input, yes, I am using such a model. It's bad design for
the ability of a program to avoid udefined behavior rely upon that
program being used correctly. When used incorrectly, it should fail
gracefully; it should not have undefined behavior. Obviously, you have
less strict standards for the behavior of incorrectly-used programs.

It's OK for a program that's not intended to be portable, to use
non-portable methods to control it's own standard input, but I don't
think the existence of such methods on some platforms should have any
influence over whether or not gets() remains in the standard library.

Mar 3 '06 #163

John Devereux <jd******@THISdevereux.me.uk> writes:

Keith Thompson <ks***@mib.org> writes:
John Devereux <jd******@THISdevereux.me.uk> writes:
"Douglas A. Gwyn" <DA****@null.net> writes:

Some of us tried to get strdup() adopted for the standard,
but there was resistance primarily on the grounds that no other
standard function malloc()ed storage and the opposition didn't
want to start that as a design trend.

Is it really true that no standard function malloc(s) storage?

Well, obviously malloc() does, and calloc() and realloc() effectively
do. Other than that, fopen() and other functions *could* malloc
storage behind the scenes, but not in any manner that's visible to a
calling program.

I was thinking in particular about "big" functions like printf, and
embedded applications (where malloc / free use is often discouraged).

If it was guaranteed that standard functions did *not* use malloc
"behind the scenes", then this could be useful to know.

There's no such guarantee in the standard. Nothing other than
malloc(), calloc(), and realloc() returns a pointer that the program
should, or may, pass to free(), but other library functions are
allowed to use *alloc() and free() internally.

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

Mar 3 '06 #164

kuyper

Keith Thompson wrote:

John Devereux <jd******@THISdevereux.me.uk> writes:
"Douglas A. Gwyn" <DA****@null.net> writes:
Some of us tried to get strdup() adopted for the standard,
but there was resistance primarily on the grounds that no other
standard function malloc()ed storage and the opposition didn't
want to start that as a design trend.

Is it really true that no standard function malloc(s) storage?

Well, obviously malloc() does, and calloc() and realloc() effectively
do. Other than that, fopen() and other functions *could* malloc
storage behind the scenes, but not in any manner that's visible to a
calling program.

Many of the standard library functions contain wording that says that
other library functions must behave as-if they never call that
particular function. I can find no such wording for the malloc()
family.

On the other hand, I can't think of any portable method of detecting
whether or not malloc() was called by, for instance, printf().
Correspondingly, I can't think of any reason why it should matter.

Mar 3 '06 #165

Micah Cowan

John Devereux <jd******@THISdevereux.me.uk> writes:

Keith Thompson <ks***@mib.org> writes:
John Devereux <jd******@THISdevereux.me.uk> writes:
"Douglas A. Gwyn" <DA****@null.net> writes:

Some of us tried to get strdup() adopted for the standard,
but there was resistance primarily on the grounds that no other
standard function malloc()ed storage and the opposition didn't
want to start that as a design trend.

Is it really true that no standard function malloc(s) storage?

Well, obviously malloc() does, and calloc() and realloc() effectively
do. Other than that, fopen() and other functions *could* malloc
storage behind the scenes, but not in any manner that's visible to a
calling program.

I was thinking in particular about "big" functions like printf, and
embedded applications (where malloc / free use is often discouraged).

If it was guaranteed that standard functions did *not* use malloc
"behind the scenes", then this could be useful to know.

No such guarantee may be made. Doug's point, I think, was that none of
the other standard functions /require/ allocating storage.

But, as a quality-of-implementation issue, I'd be fairly miffed if
printf() did a buncha allocating, as it's clearly unnecessary. Also,
nothing specifically allows printf() to fail due to allocation
problems, and therefore it is not allowed (in that, it is not one of
the explicitly listed exceptions for the requirement that it behave as
described by the standard, every time).

Mar 3 '06 #166

On 2006-03-03, Douglas A. Gwyn <DA****@null.net> wrote:

Jordan Abel wrote:
And how is the input controlled? Blind luck?

No. How is an automobile's direction controlled? By blind luck?

"Steering an automobile into a concrete wall will cause a crash" is
acceptable and widely understood by drivers. I'd dispute both that
"entering more than _x_ characters at _y_ prompt will cause a crash (or
other undefined behavior)" is acceptable and that it's typically
documented.

Mar 3 '06 #167

ku****@wizard.net writes:

Keith Thompson wrote:
John Devereux <jd******@THISdevereux.me.uk> writes:
> "Douglas A. Gwyn" <DA****@null.net> writes:
>
>> Some of us tried to get strdup() adopted for the standard,
>> but there was resistance primarily on the grounds that no other
>> standard function malloc()ed storage and the opposition didn't
>> want to start that as a design trend.
>
> Is it really true that no standard function malloc(s) storage?

Well, obviously malloc() does, and calloc() and realloc() effectively
do. Other than that, fopen() and other functions *could* malloc
storage behind the scenes, but not in any manner that's visible to a
calling program.

Many of the standard library functions contain wording that says that
other library functions must behave as-if they never call that
particular function. I can find no such wording for the malloc()
family.

Even if there were such wording, an implementation could easily get
around it by providing a lower-level __malloc() function. malloc()
itself could just call __malloc(); other library functions couldn't
call malloc(), but they could call __malloc(). One could argue either
way on the question of whether this meets the "as-if" requirement.

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

Mar 3 '06 #168

On 2006-03-03, Keith Thompson <ks***@mib.org> wrote:

ku****@wizard.net writes:
Keith Thompson wrote:
John Devereux <jd******@THISdevereux.me.uk> writes:
> "Douglas A. Gwyn" <DA****@null.net> writes:
>
>> Some of us tried to get strdup() adopted for the standard,
>> but there was resistance primarily on the grounds that no other
>> standard function malloc()ed storage and the opposition didn't
>> want to start that as a design trend.
>
> Is it really true that no standard function malloc(s) storage?

Well, obviously malloc() does, and calloc() and realloc() effectively
do. Other than that, fopen() and other functions *could* malloc
storage behind the scenes, but not in any manner that's visible to a
calling program.

Many of the standard library functions contain wording that says that
other library functions must behave as-if they never call that
particular function. I can find no such wording for the malloc()
family.

Even if there were such wording, an implementation could easily get
around it by providing a lower-level __malloc() function. malloc()
itself could just call __malloc(); other library functions couldn't
call malloc(), but they could call __malloc(). One could argue either
way on the question of whether this meets the "as-if" requirement.

Standard library functions _are_ forbidden from calling the rand()
function, and as far as I know the reason for this leads to the
conclusion that they're not permitted to do anything that messes with
rand()'s internal state. However, this can be easily detected in a
conforming program, whereas I'm at a loss to figure out how a conforming
program could detect memory allocation.

Mar 3 '06 #169

Richard Heathfield

Keith Thompson said:

John Devereux <jd******@THISdevereux.me.uk> writes:

Is it really true that no standard function malloc(s) storage?

Well, obviously malloc() does,

You mean malloc calls malloc? ;-)

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

Mar 3 '06 #170

Richard Heathfield <in*****@invalid.invalid> writes:

Keith Thompson said:
John Devereux <jd******@THISdevereux.me.uk> writes:
Is it really true that no standard function malloc(s) storage?

Well, obviously malloc() does,

You mean malloc calls malloc? ;-)

As a verb, "malloc()" means "whatever malloc does". malloc presumably
doesn't call malloc (though I suppose it could), but it does malloc().

That's my story, and I'm sticking to it.

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

Mar 3 '06 #171

Mark McIntyre

On 3 Mar 2006 22:00:38 GMT, in comp.lang.c , Jordan Abel
<ra*******@gmail.com> wrote:

On 2006-03-03, Douglas A. Gwyn <DA****@null.net> wrote:
Jordan Abel wrote:
And how is the input controlled? Blind luck?

No. How is an automobile's direction controlled? By blind luck?

"Steering an automobile into a concrete wall will cause a crash" is
acceptable and widely understood by drivers. I'd dispute both that
"entering more than _x_ characters at _y_ prompt will cause a crash (or
other undefined behavior)" is acceptable and that it's typically
documented.

Nowhere in my /automobile/ documentation does it say "do not steer
this vehicle into a wall". I was taught this when I learned to drive.
Nowhere in my /compiler/ documentation does it say "do not overflow
arrays". I was taught this when I learned to programme.

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

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Mar 3 '06 #172

On 2006-03-03, Mark McIntyre <ma**********@spamcop.net> wrote:

On 3 Mar 2006 22:00:38 GMT, in comp.lang.c , Jordan Abel
<ra*******@gmail.com> wrote:
On 2006-03-03, Douglas A. Gwyn <DA****@null.net> wrote:
Jordan Abel wrote:
And how is the input controlled? Blind luck?

No. How is an automobile's direction controlled? By blind luck?

"Steering an automobile into a concrete wall will cause a crash" is
acceptable and widely understood by drivers. I'd dispute both that
"entering more than _x_ characters at _y_ prompt will cause a crash (or
other undefined behavior)" is acceptable and that it's typically
documented.

Nowhere in my /automobile/ documentation does it say "do not steer
this vehicle into a wall". I was taught this when I learned to drive.
Nowhere in my /compiler/ documentation does it say "do not overflow
arrays". I was taught this when I learned to programme.

Exactly. And you shouldn't assume that your users, even if they do know
how to program, know there is an array overflow lurking. Even if you
tell them, that's not an acceptable "feature" for a program to have.

Mar 4 '06 #173

Brian Inglis

On Fri, 03 Mar 2006 18:34:08 +0000 in comp.std.c, John Devereux
<jd******@THISdevereux.me.uk> wrote:

"Douglas A. Gwyn" <DA****@null.net> writes:
Some of us tried to get strdup() adopted for the standard,
but there was resistance primarily on the grounds that no other
standard function malloc()ed storage and the opposition didn't
want to start that as a design trend.

Is it really true that no standard function malloc(s) storage?

Probably, "no standard function shall call {c,m,re}alloc or free".
OTOH fopen, fclose, setvbuf, and some others may dynamically
(de-)allocate memory.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Br**********@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply

Mar 4 '06 #174

CBFalconer

"Douglas A. Gwyn" wrote:

Jordan Abel wrote:
And how is the input controlled? Blind luck?

No. How is an automobile's direction controlled? By blind luck?

Yes, as is made supremely evident by observing traffic anywhere in
the world for significant length of time.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

Mar 4 '06 #175

CBFalconer

"Douglas A. Gwyn" wrote:

CBFalconer wrote:
Chris Torek wrote:

The function fpurge() erases any input or output buffered in the
given stream. For output streams this discards any unwritten
output. For input streams this discards any input read from the
underlying object but not yet obtained via getc(3); this
includes any text pushed back via ungetc.

Your version seems eminently useful, and offhand I see no reason
for it not to be implementable on all C systems. Not portably
implementable, however. Which, to me, is an excellent reason to
incorporate it in the standard.

It's not evident how useful it is in general, because details
of the buffering vary among platforms. For example, on some
systems multiple input or output lines might be buffered while
on others just one line at a time might be, depending on file
type etc. There are also multiple levels of buffering,
including kernel character queues, etc. and one needs to
specify whether or not unread/unwritten buffered data is
flushed at that level also. For a specific platform one can
handle all the details, but for general use it would be not
only a problem to specify adequately but also to use in a
portable manner.

But that is precisely the point. Only the system designer knows
how to make the function work on his system. I should think of it
as a means to guarantee that any future input occured after the
call to fpurge. It puts the input system in a known state and
avoids having to keep track of line ending absorption.

With it fgets would be useful. Just specify the min. length of
line you want to consider, and use fpurge to eliminate the rest.
If there is no rest, fpurge does nothing.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

Mar 4 '06 #176

Francis Glassborow

In article <44***************@null.net>, Douglas A. Gwyn
<DA****@null.net> writes

Some of us tried to get strdup() adopted for the standard,
but there was resistance primarily on the grounds that no other
standard function malloc()ed storage and the opposition didn't
want to start that as a design trend.

You mean like calloc and realloc:-) Of course those functions might be
implemented in a free standing way but conceptually they acquire memory
from the heap. The same applies to strdup (which might also be
implemented directly rather than by using malloc).

C has a family of functions that acquire memory from the heap and a
function free() that releases such memory. In what way does strdup() not
qualify to be a member? Indeed had it been we would not have the
resource leakage brought about by naive programmers who do not realise
that third party supplied functions such as strdup need a corresponding
call to free().
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

Mar 4 '06 #177

Francis Glassborow

In article <44***************@null.net>, Douglas A. Gwyn
<DA****@null.net> writes

Pedagogically, gets() is a good example to have around.

If the desired lesson is that using the Standard Library is dangerous:-)
When a student uses gets() it is much harder to persuade them that even
with, for example, the commonly used char buffer[BUFSIZE] when 19 out of
every 20 introductory books use it and it is in the Standard Library.
You know not to use it and so does everyone here yet it is in wide use
in the real world. The first step is to remove the endorsement of the C
Standard. And note that we could do so if we had the will because we do
have the power to issue a normative correction to the Standard even if
that would be very rare. Actually removing gets() would be one of the
few places that using such power could be justified and the resulting
exposure in the media might get the message home more effectively than
anything else we have available.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

Mar 4 '06 #178

Francis Glassborow

In article <sd********************************@4ax.com>, Mark McIntyre
<ma**********@spamcop.net> writes

Nowhere in my /automobile/ documentation does it say "do not steer
this vehicle into a wall". I was taught this when I learned to drive.
Nowhere in my /compiler/ documentation does it say "do not overflow
arrays". I was taught this when I learned to programme.

But the former is common sense (though with the litigious behaviour that
is common these days perhaps there should be a warning in the
documentation for vehicles :-) The latter is very far from obvious, has
to be taught and manifestly is usually (certainly considering the range
of academic authors who use it in their books) not taught.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

Mar 4 '06 #179

Mark McIntyre

On Sat, 4 Mar 2006 13:00:56 +0000, in comp.lang.c , Francis Glassborow
<fr*****@robinton.demon.co.uk> wrote:

In article <sd********************************@4ax.com>, Mark McIntyre
<ma**********@spamcop.net> writes
Nowhere in my /automobile/ documentation does it say "do not steer
this vehicle into a wall". I was taught this when I learned to drive.
Nowhere in my /compiler/ documentation does it say "do not overflow
arrays". I was taught this when I learned to programme.

But the former is common sense

Oh, did someone say that there was a requirement not to teach obvious
stuff? Hmm, that must have escaped most of the establishment.

Well then, pick your example - don't overfeed your fish, don't walk
through deep rivers, don't cross thin ice, etc. These are all things
you can learn either by instruction or experience. Documentation is
unlikely to be useful because hey, who reads the instructions on your
fishfood?

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

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Mar 4 '06 #180