> Charles Hannum:
> > ANSI does not require such a special case, and I really
> > don't like the idea of masking bugs in applications by kluging up the
> > C library.
> 
> In this case, Andrew, I'm pretty sure an application would only
> call fclose() with NULL if it had lost track of that stream pointer.
> As Charles does, I would certainly consider this an error in
> the program, not in the C library.  I considered advocating checking
> for NULL in fclose, but it occured to me I would actually rather
> that my program dump core, as a warning to me that I was closing
> a file twice, closing a file that was never open, or somehow not
> handling a file correctly in some other way, rather than blindly
> continue on.  I would consider that segmentation fault to be a
> debugging aid.

Yes, that is solid reasoning.  I do wish the man pages for fclose(),
flush(), and close() were not so confusing.  fflush accepts NULL,
if the fp is invalid it shoudl return EOF with errno set to EBADF,
etc.. Nothing about dumping core!

The actual code looked like this:
fp = fopen(path, "r");
if (!fp) {
	fclose(fp);
	...
	return(-1);
	}

I guess that's a bug... :-)

So, now that I'm bothering you gurus... why does *this* fail?

#include <stdio.h>

main()
{
char    buf[512 * 1024];
}

Is this some kernel size limitation?  This same code (mSQL)
is trying to use a 'buf[512 * 1024' and this is causing a
segmentation fault.
Is there anyway to fix this? (i.e. config file option)

Thanks!

-Andrew


------------------------------------------------------------------------------