returning error from main()

[junky_fellow]

Guys,

If main() calls some function func() and that function returns
the error (errno), then does it make sense to return that value
(errno) from main. (in case main can't proceed further) ?

eg.

int main(void)
{
int error;

if ((error = func()) 0) {
return(error); /* Is this Ok. ? */
}

return 0;
}

Otherwise, if this is not the right thing, what else should be done ?

[Al Balmer]

On Mon, 24 Sep 2007 11:02:47 -0700, Keith Thompson <ks***@mib.org>
wrote:

>Al Balmer <al******@att.netwrites:

>On Sat, 22 Sep 2007 15:29:37 +0100, "Malcolm McLean"
<re*******@btinternet.comwrote:

>>>The real answer is to implement safe pointers, which consist of three memory
addresses, the pointer itself and the bounds of the object it points to.
It means a slower language, but there just isn't another way I know of of
preventing buffer overruns.

I know another way - just don't write code that's susceptible to
buffer overruns :-)

How has that been working out so far?

Very well. Of course, I learned C before I had Microsoft to help out.

--
Al Balmer
Sun City, AZ

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

Mark McIntyre wrote:

>On Sun, 23 Sep 2007 22:19:25 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

[...]

>>This simple function is IMPOSSIBLE to write in
standard C today.

I agree its impossible to code a standard C function which can
absolutely tell you if a file exists. This is not because of lack of
error messages however - its because there is no way to do this
without some really very OS-specific code and without creating a
security loophole. Think about how many security probes begin by
looking for a named file with a known vulnerability.

Interesting. POSIX manages to do exactly that, but somehow
the C standard could not manage doing it.

POSIX specifies exactly the type of errors that can be thrown by
fopen!

POSIX doesn't let you write a function which can absolutely tell you
if a file exists.

Yes, POSIX requires fopen() to set errno on failure, and standard C
does not.

I agree that it would be better if the C standard required fopen() to
set errno to some meaningful value on failure. In most cases, this
doesn't help much in terms of the behavior of programs; it lets a
program display a meaningful error message, but the program's response
to a failure is likely to be the same whatever the cause of the error:
display or log an error message and move on.

I would even be nice if *all* standard functions that are able to
report failure were required to set errno to some meaningful value
when a failure occurs.

But keep in mind that most of us here in comp.lang.c are users, not
implementers or committee members. We're stuck with what the standard
specifies, or, at best, with what the implementations we use happen to
support. If you want the standard to require the setting of errno in
more contexts, then you should post a suggestion to comp.std.c. But
even if everyone agrees, nothing is likely to happen any time soon,
since there are no immediate plans for a new standard (and *please*
don't waste time complaining to us about 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Chris Torek]

[In yet more topic drift, this is now about "fopen() really should be
required to set errno; this seems like a smaller, yet more important,
thing than fixing reentrance problems in functions like strtok()".]

In article <DZ*********************@telenor.com>
Tor Rustad <to********@hotmail.comwrote:

>Agreed, as long as ISO C don't specify threads and the current (lack of)
signal definition exist, the "_r" functions is better left to POSIX.

Well, even without threads, strtok() remains an "accident waiting
to happen":

static const char ws[] = " \t\n"; /* or even " \t\b\f\v\r\n" */
char *tok;

/* do some work on the whitespace-separated keywords */
for (tok = strtok(str, ws); tok != NULL; tok = strtok(NULL, ws))
operate_on(tok);

If operate_on() is a function, and if operate_on() itself calls
strtok() with a non-NULL first parameter, the code breaks. The
POSIX strtok_r() fixes this, although that is the only silly part
of strtok() that it fixes. (The BSD strsep() fixes two "bad
behaviors", at the cost of making the caller merge adjacent separators
if that is desired. So I think adding strsep() would be better
than adding strtok_r(). Of course, I may be biased, since I wrote
the first implementation of strsep(), at least under that name, at
least as far as I know. :-) The actual interface was a collaboration
between myself and Keith Bostic: he wanted to use a function when
he rewrote the /etc/passwd and /etc/group parsing code. Since
strtok() merged adjacent delimiters, it was impossible to handle
"empty" colon-delimited fields correctly, even with the reentrancy
problem fixed.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

On Mon, 24 Sep 2007 18:34:28 +0000, Richard Harter wrote:

On Mon, 24 Sep 2007 16:47:25 +0000 (UTC),
=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0Fk?=
<tr*****@gmail.comwrote:

>>On Mon, 24 Sep 2007 16:34:06 +0000, Richard Harter wrote:

>>On Mon, 24 Sep 2007 10:48:00 -0400, Eric Sosman <Er*********@sun.com>
wrote:
What happens on a system where fopen() can fail for
reasons POSIX doesn't enumerate? I have used a system where a file
specification could (optionally) include an account name and password;
the attempt to open could fail because of bad credentials. You might,
with a stretch, translate this to POSIX' EACCESS, but that's really
not how EACCESS is described.

[snip litany of possible differences]

The obvious thing to do is have a general error code in addition to
the ones imported from posix. The general code would cover all errors
not otherwise classified. Do you have a problem with that?

I do. If fopen can fail for other reasons than specified by POSIX, the
implementation should define additional error codes properly. There's no
point in using something like EIDUNNO, which tells you nothing more than
fopen's NULL return value, when an implementation-specific EBADCRED
could be defined just as easily. It would then make sure a decent
message can get printed by strerror. (As an aside, I don't see the
problem with EACCES for this specific error, but I do agree with some of
the other snipped examples.)

I don't quite understand your objection. What we are talking about are
the error codes (that should be) required by the standard.

And you're suggesting requiring something like EIDUNNO, while I'm saying
this should not be required or even standardised at all.

Clearly the
standard cannot specify codes for all possible errors in all possible
implementations. What it can do is specify that there are codes for the
commonest errors.

Adding codes for all possible errors is up to the implementation.

That's what I would like to see required, and what I believe you stated
should not even be allowed: you stated "The general code would cover all
errors not otherwise classified." I took this to mean fopen would be
allowed to a) succeed, b) set errno to one of the imported error codes,
or c) set errno to a general error indicator. Missing is the possibility
to set errno to an implementation-defined error indicator, and with that
possibility, I personally don't see a use for a general error indicator.
If I misunderstood what you meant, then could you please clarify?

However that is necessarily non-portable.

They can be portably used with strerror, and that's enough to make them
useful. Would they cause any problems that you can see?

[Mark McIntyre]

On Mon, 24 Sep 2007 18:29:08 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Eric Sosman wrote:

>where a file specification could (optionally) include an
account name and password; the attempt to open could fail
because of bad credentials. You might, with a stretch,
translate this to POSIX' EACCESS, but that's really not
how EACCESS is described.

Why not?
It is an access error.

Which of the several dozen possible "access denied" conditions was it?
I thought the idea was to have useful errors...

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

[Keith Thompson]

Al Balmer <al******@att.netwrites:

On Mon, 24 Sep 2007 11:02:47 -0700, Keith Thompson <ks***@mib.org>
wrote:

>>Al Balmer <al******@att.netwrites:

>>On Sat, 22 Sep 2007 15:29:37 +0100, "Malcolm McLean"
<re*******@btinternet.comwrote:
The real answer is to implement safe pointers, which consist of
three memory addresses, the pointer itself and the bounds of the
object it points to. It means a slower language, but there just
isn't another way I know of of preventing buffer overruns.

I know another way - just don't write code that's susceptible to
buffer overruns :-)

How has that been working out so far?

Very well. Of course, I learned C before I had Microsoft to help out.

I'm glad it's working out *for you*, but that's not what I asked (or
at least not what I meant to ask).

In any case, Microsoft certainly isn't the only source of buffer
overruns.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Mark McIntyre]

On Mon, 24 Sep 2007 10:48:00 -0400, in comp.lang.c , Eric Sosman
<Er*********@sun.comwrote:

If you try to enumerate all the possible reasons fopen()
could fail on all possible systems,

>you will find yourself
writing a very large number of #define's ... Also, the
resulting set will probably contain ambiguities.

I'm always amused by winerror.h and its nested chums. I think it comes
close to using every bit of a long, and a great many of the
possibilities are very very similar.
--
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

[Mark McIntyre]

On Mon, 24 Sep 2007 20:42:03 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>The terrible situation now, i.e. developing code for EACH
combination of OS + compiler is so difficult to implement that
it makes portable error analysis IMPOSSIBLE!!!

I think that you're letting your enthusiasm for your favoured solution
lead you into hyperbole and over-exaggeration.

In my view there essentially isn't a need for a fully portable error
analysis environment. In the real world a given developer team are
going to be working on a small number of platforms, probably two or
three at most. I've previously had to support Solaris. Win32 and
RedHat, or Solaris, VMS and Win32 but never all of them at once though
I concede some people may have more.

Developing useful error handling for such a set is a one-off job,
probably heavily obtainable from existing sources. In my experience,
most shops already have all this built, organically migrating it to
new platforms / environments as and when they need to.

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

[Keith Thompson]

Harald van D©¦k <tr*****@gmail.comwrites:

On Mon, 24 Sep 2007 18:34:28 +0000, Richard Harter wrote:

[...]

>Clearly the standard cannot specify codes for all possible errors
in all possible implementations. What it can do is specify that
there are codes for the commonest errors.

Adding codes for all possible errors is up to the implementation.

That's what I would like to see required, and what I believe you stated
should not even be allowed: you stated "The general code would cover all
errors not otherwise classified." I took this to mean fopen would be
allowed to a) succeed, b) set errno to one of the imported error codes,
or c) set errno to a general error indicator. Missing is the possibility
to set errno to an implementation-defined error indicator, and with that
possibility, I personally don't see a use for a general error indicator.
If I misunderstood what you meant, then could you please clarify?

>However that is necessarily non-portable.

They can be portably used with strerror, and that's enough to make them
useful. Would they cause any problems that you can see?

What I'd like to see is a requirement that fopen() sets errno to some
non-zero value on error, and that that value is a valid argument to
strerror() or perror().

I don't want to require that the value must indicate something more
specific than "Something went wrong", because there might be
implementations that are unable to provide that information in some
cases.

I think it might make sense for the standard to provide a catch-all
EMISC or EUNKNOWN error code, but I could live without 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Al Balmer]

On Mon, 24 Sep 2007 13:29:54 -0700, Keith Thompson <ks***@mib.org>
wrote:

>Al Balmer <al******@att.netwrites:

>On Mon, 24 Sep 2007 11:02:47 -0700, Keith Thompson <ks***@mib.org>
wrote:

>>>Al Balmer <al******@att.netwrites:
On Sat, 22 Sep 2007 15:29:37 +0100, "Malcolm McLean"
<re*******@btinternet.comwrote:
>The real answer is to implement safe pointers, which consist of
>three memory addresses, the pointer itself and the bounds of the
>object it points to. It means a slower language, but there just
>isn't another way I know of of preventing buffer overruns.

I know another way - just don't write code that's susceptible to
buffer overruns :-)

How has that been working out so far?

Very well. Of course, I learned C before I had Microsoft to help out.

I'm glad it's working out *for you*, but that's not what I asked (or
at least not what I meant to ask).

I'm not really qualified to say. I know that there are programs which
have such problems, but I suspect there are many programs that don't -
even some I didn't write. <gI also suspect that programmers will
continue to write bad programs, even if MS outlaws strcpy()
altogether.

Without outlawing it completely, I have to wonder how effective the
new library functions are. I recently had to port an old program,
which I wrote years ago, to the current version of Visual Studio. I
got a bunch of annoying warnings, and was advised by one of the C++
programmers from the Windows product group to define
_CRT_SECURE_NO_WARNINGS. It seems they always use it.

>
In any case, Microsoft certainly isn't the only source of buffer
overruns.

Of course not, but I got the impression that they were the source of
the "safe string" library that was mentioned.

In any case, Malcolm's notion that buffer overruns cannot be prevented
without his notion of safe pointers is incorrect.

--
Al Balmer
Sun City, AZ

[Eric Sosman]

Al Balmer wrote On 09/24/07 17:30,:

[...]
In any case, Malcolm's notion that buffer overruns cannot be prevented
without his notion of safe pointers is incorrect.

The notion that they *can* be prevented by pointers-
with-bounds is also incorrect.

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

[CBFalconer]

$)CHarald van D)&k wrote:

Richard Harter wrote:

>>
[snip litany of possible differences]

The obvious thing to do is have a general error code in addition
to the ones imported from posix. The general code would cover all
errors not otherwise classified. Do you have a problem with that?

I do. If fopen can fail for other reasons than specified by POSIX,
the implementation should define additional error codes properly.
There's no point in using something like EIDUNNO, which tells you
nothing more than fopen's NULL return value, when an implementation-
specific EBADCRED could be defined just as easily. It would then
make sure a decent message can get printed by strerror. (As an
aside, I don't see the problem with EACCES for this specific error,
but I do agree with some of the other snipped examples.)

I can remember a horror set of sessions with a Windows program. It
returned the blazingly informative "parameter error" for a call to
a system routine with roughly one-dozen parameters. I went nuts
finding the problem (which wasn't a parameter error, IIRC).
Finding it involved a priviledged debugger following the call deep
into the system. KISS.

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

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

user923005 <dc*****@connx.comwrites:

On Sep 24, 3:39 pm, Keith Thompson <[e-mail]:

[...]

>Personally, I'd like to see an exception mechanism in C. Probably
something similar to what C++ has, but with some restrictions, would
have the best chance of being accepted. But before we can seriously
consider adding features to C, we have to deal with the current lack
of support for the current C standard; until C99 is supported, there's
not much point in adding major features to C200X or C201Y.

The try/catch mechanism is not compatible with setjmp/longjmp so I
think it would probably be very difficult to implement in the C
language without breaking tons of pre-existing code.

[...]

Really? C++ has C's setjmp() and longjmp(), via the header <csetjmp>
(which corresponds to C's <setjmp.h>). But I haven't looked into the
possible interactions.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Mark McIntyre wrote:

jacob navia <ja***@jacob.remcomp.frwrote:

>Mark McIntyre wrote:

>>I agree its impossible to code a standard C function which can
absolutely tell you if a file exists.

Interesting. POSIX manages to do exactly that,

I suspect not - what does a posix-compliant fopen return if the
user had absolutely no rights to scan the directory? I'd suspect
the answer is "not permitted". That tells you nothing about the
existence or otherwise of the file.

Devils advocate here. In that case the file does not exist, as far
as that user is concerned. With proper settings of attributes that
user would not be allowed to even create such a file, whether or
not it preexisted.

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

--
Posted via a free Usenet account from http://www.teranews.com

[Stephen Sprunk]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

user923005 <dc*****@connx.comwrites:

>The try/catch mechanism is not compatible with setjmp/longjmp
so I think it would probably be very difficult to implement in the C
language without breaking tons of pre-existing code.

Really? C++ has C's setjmp() and longjmp(), via the header
<csetjmp(which corresponds to C's <setjmp.h>). But I haven't
looked into the possible interactions.

C++ also has C's malloc() and free(), but it's unwise to mix them with new
and delete. It seems the same would apply to mixing setjmp() and longjmp()
with try and catch.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

[user923005]

On Sep 24, 6:12 pm, Keith Thompson <[e-mail]:

user923005 <[e-mail]:

On Sep 24, 3:39 pm, Keith Thompson <[e-mail]:

[...]

Personally, I'd like to see an exception mechanism in C. Probably
something similar to what C++ has, but with some restrictions, would
have the best chance of being accepted. But before we can seriously
consider adding features to C, we have to deal with the current lack
of support for the current C standard; until C99 is supported, there's
not much point in adding major features to C200X or C201Y.

The try/catch mechanism is not compatible with setjmp/longjmp so I
think it would probably be very difficult to implement in the C
language without breaking tons of pre-existing code.

[...]

Really? C++ has C's setjmp() and longjmp(), via the header <csetjmp>
(which corresponds to C's <setjmp.h>). But I haven't looked into the
possible interactions.

I'm not sure what the standard says about it, but I know of several
implementations where the destructors do not fire properly as the
stack unwinds if you use setjmp/longjmp.

The new/delete operators also cannot be mixed with the malloc()/free()
functions.

[Keith Thompson]

user923005 <dc*****@connx.comwrites:

On Sep 24, 6:12 pm, Keith Thompson <[e-mail]:

>user923005 <[e-mail]:

On Sep 24, 3:39 pm, Keith Thompson <[e-mail]:

[...]

>Personally, I'd like to see an exception mechanism in C. Probably
something similar to what C++ has, but with some restrictions, would
have the best chance of being accepted. But before we can seriously
consider adding features to C, we have to deal with the current lack
of support for the current C standard; until C99 is supported, there's
not much point in adding major features to C200X or C201Y.

The try/catch mechanism is not compatible with setjmp/longjmp so I
think it would probably be very difficult to implement in the C
language without breaking tons of pre-existing code.

[...]

Really? C++ has C's setjmp() and longjmp(), via the header <csetjmp>
(which corresponds to C's <setjmp.h>). But I haven't looked into the
possible interactions.

I'm not sure what the standard says about it, but I know of several
implementations where the destructors do not fire properly as the
stack unwinds if you use setjmp/longjmp.

The new/delete operators also cannot be mixed with the malloc()/free()
functions.

If C were to adopt an exception handling mechanism similar to C++'s,
it wouldn't be a great tragedy if it couldn't be mixed with setjmp and
longjmp. The restrictions on setjmp and longjmp are already fairly
tight.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[user923005]

On Sep 24, 9:45 pm, Keith Thompson <[e-mail]:

user923005 <[e-mail]:

On Sep 24, 6:12 pm, Keith Thompson <[e-mail]:

user923005 <[e-mail]:
On Sep 24, 3:39 pm, Keith Thompson <[e-mail]:
[...]
Personally, I'd like to see an exception mechanism in C. Probably
something similar to what C++ has, but with some restrictions, would
have the best chance of being accepted. But before we can seriously
consider adding features to C, we have to deal with the current lack
of support for the current C standard; until C99 is supported, there's
not much point in adding major features to C200X or C201Y.

The try/catch mechanism is not compatible with setjmp/longjmp so I
think it would probably be very difficult to implement in the C
language without breaking tons of pre-existing code.

[...]

Really? C++ has C's setjmp() and longjmp(), via the header <csetjmp>
(which corresponds to C's <setjmp.h>). But I haven't looked into the
possible interactions.

I'm not sure what the standard says about it, but I know of several
implementations where the destructors do not fire properly as the
stack unwinds if you use setjmp/longjmp.

The new/delete operators also cannot be mixed with the malloc()/free()
functions.

If C were to adopt an exception handling mechanism similar to C++'s,
it wouldn't be a great tragedy if it couldn't be mixed with setjmp and
longjmp. The restrictions on setjmp and longjmp are already fairly
tight.

Here's the bit from the C++ standard that prohibits it:

© ISO/IEC ISO/IEC 14882:1998(E) page 347:

"18 Language support library 18.7 Other runtime support

4 The function signature longjmp(jmp_buf jbuf, int val) has more
restricted behavior in this International Standard. If any automatic
objects would be destroyed by a thrown exception transferring control
to another (destination) point in the program, then a call to
longjmp(jbuf, val) at the throw point that transfers control to the
same (destination) point has undefined behavior.
SEE ALSO: ISO C subclause 7.10.4, 7.8, 7.6, 7.12."

[Richard Bos]

Mark McIntyre <ma**********@spamcop.netwrote:

On Mon, 24 Sep 2007 10:48:00 -0400, in comp.lang.c , Eric Sosman
<Er*********@sun.comwrote:

If you try to enumerate all the possible reasons fopen()
could fail on all possible systems,

you will find yourself
writing a very large number of #define's ... Also, the
resulting set will probably contain ambiguities.

I'm always amused by winerror.h and its nested chums. I think it comes
close to using every bit of a long, and a great many of the
possibilities are very very similar.

And how many of them do you see regularly? And how many of those serve
as a mostly useless catch-all? It is indeed a great example of how not
to set up an error reporting system.

Richard

[Mark McIntyre]

On Mon, 24 Sep 2007 20:15:56 -0400, in comp.lang.c , CBFalconer
<cb********@yahoo.comwrote:

>Mark McIntyre wrote:

> what does a posix-compliant fopen return if the
user had absolutely no rights to scan the directory?

Devils advocate here. In that case the file does not exist, as far
as that user is concerned.

thats kinda my point - the concept "exist" doesn't even have a good
definition....
--
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

[Mark McIntyre]

On Tue, 25 Sep 2007 08:23:03 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Peter J. Holzer wrote:

>On 2007-09-24 10:39, jacob navia <ja***@jacob.remcomp.frwrote:

>>POSIX specifies exactly the type of errors that can be thrown by
fopen!

No, it doesn't:

http://www.opengroup.org/onlinepubs/...html#tag_02_03

Thas is nothing but the usual Standard Disclaimer

Hang on - someone posts a reference to the Standard you're claiming is
'better', and your response is to disparage it?
--
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