Re: [Chicken-hackers] [PATCH] handle EOVERFLOW and ENOTDIR gracefully in file/directory-exists?

[Christian Kellermann]

Hi Alan!

* Alan Post <address@hidden> [111008 22:23]:
> I'm sorry that I don't seem to be communicating well today: I'm only
> in and out at my computer trying to do other things and it seems to
> be affecting my ability to be articulate.

Thanks for bearing with me, I think I have understood your point
now.

> As such, we will not convert ENAMETOOLONG to an #f, which would
> signal that the file does not exist.  We will instead tell the user
> that the resource they asked for an existence test for isn't a valid
> path by way of signalling an error.
> 
> I was trying to say above that until we see this behavior in the
> wild, (that is, an errno==ENAMETOOLONG that someone complains about)
> I was ok with the behavior as it is in the original patch, which does
> not treat ENAMETOOLONG in any non-default way.

Now I get it, so this basically means we mitigate the error situation
from here further down the programmer's path when he actually wants
to do something with the thing referenced by an invalid path.

I personally prefer to get yelled at when I provide nonsense input
to a function but that may be irrellevant if everyone else would
expect to get different things.

John, how do other schemes handle this situation?

I would say go with the flow then to not surprise everyone else...

> I'm still not clear on what the EOVERFLOW case is doing, and how
> that differs from handling ENAMETOOLONG.  I have assumed you did
> know the difference and consider it significant enough to handle
> EOVERFLOW and not handle ENAMETOOLONG.

EOVERFLOW means that the type we have in the stat structure's field
for the file size overflows, so the size cannot be represented
properly. This happens on linux systems that run 32 bit applications
on 64 bit Systems. The usual workaround seems to recompile the
application (here the chicken runtime) with -D_FILE_OFFSET_BITS=64
(see also the comments for bug #706).

On OpenBSD the type of off_t is (at least on i386) long long which
is 64 bit there.

So while EOVERFLOW signals an error in the fstat call it still gives
a positive answer to the question whether the file exists.

This has been discovered by Sven Hartrumpf in Bug #706.

Does that make the intention clearer?

Thanks for this discussion, I am learning something new every mail
:)

Kind regards,

Christian

-- 
Who can (make) the muddy water (clear)? Let it be still, and it will
gradually become clear. Who can secure the condition of rest? Let
movement go on, and the condition of rest will gradually arise.
 -- Lao Tse.