[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH] proposed bugfix for #706
From: |
Christian Kellermann |
Subject: |
Re: [Chicken-hackers] [PATCH] proposed bugfix for #706 |
Date: |
Thu, 29 Sep 2011 11:15:22 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
* felix winkelmann <address@hidden> [110929 11:05]:
> From: Christian Kellermann <address@hidden>
> Subject: Re: [Chicken-hackers] [PATCH] proposed bugfix for #706
> Date: Thu, 29 Sep 2011 09:25:21 +0200
>
> > * felix winkelmann <address@hidden> [110929 03:18]:
> >> I would suggest simply to detect the error in C_file_info_2, and act
> >> accordingly (by calling whatever stupid POSIX API that has to be used
> >> for this, probably incompatible with the way stupid Windows does it,
> >> and all the stupid crap programmers have to put up with nowadays) and
> >> using a flonum for the size-slot in the file info vector.
> >
> > I am not quite sure I understand this correctly. Catch the error
> > and if it is an overflow, redo it with a flonum? I am not sure if
> > this is even possible since the internal check is against whether
> > you are a 32-bit application and your off_t datatype is large enough
> > to hold the size.
I see. I haven't found a different way of getting a filesize in my
Stephens yet.
>
> I meant: catch the error and do whatever necessary to obtain the file
> size using some other means (if that is possible - the manpage
> seems not to suggest what to do in case of EOVERFLOW) and store
> a flonum in the vector return by C_file_info_2. I'm probably missing
> something again. I just read up on this and it's just all a terrible
> mess.
>
> >
> > My manpage here suggests compiling with -D_FILE_OFFSET_BITS=64 in
> > this case to make this error go away. (Silly I know).
>
> Probably the only thing that helps, but needs to be tested for
> all platforms.
>
> > For all the other errors we still need to add checks IMHO. This
> > should also include a sane way to report them (have you seen the
> > bug #707?).
>
> What other errors do you mean specifically?
EACCES EBADF EFAULT ELOOP ENAMETOOLONG ENOMEM EOVERFLOW
In all these cases file-exists? would return #f, pretending nothing
happened. Each of these is unlikely to happen (more or less) but
will trick people into beleiving all is well and they may go ahead
and rewrite that file (as Sven did) all over again.
Not taking care of these, at least signalling them as an error,
will just lead to future misery. To be honest I have no idea whether
even these error codes work on all platforms. This really is a big
mess but just returning #f and hoping noone will notice is the wrong
thing.
--
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.