On Sat, Oct 08, 2011 at 09:43:17PM +0200, Christian Kellermann wrote: > * Alan Post <alanp...@sunflowerriver.org> [111008 21:37]: > > > > Here is my new proposal: > > > > Do not check for ENAMETOOLONG (I withdraw that proposal) and wait > > for a user to encounter a problem in real life for which adding > > an ENAMETOOLONG check would help. If thata never happens, it's clearly > > not a problem. > > > > As such, I think the patch as written is fine. > > Maybe this is a misunderstanding: Are you aware that an error is > raised in case of an ENAMETOOLONG in the patch as it is? >
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. I believe that the patch Felix submitted at the top of this thread, when it receives an ENAMETOOLONG errno, will throw an error in Chicken that the user will experience or handle. 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. 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. -Alan -- .i ma'a lo bradi cu penmi gi'e du _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers