chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] proposed bugfix for #706


From: Felix
Subject: Re: [Chicken-hackers] [PATCH] proposed bugfix for #706
Date: Thu, 29 Sep 2011 05:05:14 -0400 (EDT)

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


cheers,
felix



reply via email to

[Prev in Thread] Current Thread [Next in Thread]