Re: [transcode-devel] checking the return value of fwrite

2006-12-16 Thread Francesco Romani
On Tue, 5 Dec 2006 22:52:25 -0800 "Scott Smith" <[EMAIL PROTECTED]> wrote: > Personally I've found that knowing about a partial write is useless. > If you only wrote part of it, there was probably an error that you > want to report anyways. That's the whole point of a wrapper like > pwrite which

Re: [transcode-devel] checking the return value of fwrite

2006-12-05 Thread Andrew Church
>> Well, the problem is how do you handle partial writes? Is there a >> case in which an error occurs but the caller would want to know how much >> data was successfully written? If not, you could just change the >> interface to return a boolean 1 (all data successfully written) or 0 >> (err

Re: [transcode-devel] checking the return value of fwrite

2006-12-05 Thread Scott Smith
On 12/5/06, Andrew Church <[EMAIL PROTECTED]> wrote: >Looks that the right thing to do is to make tc_pwrite (and family) to >return -1 if errno != EINTR happens. >(Andrew, any objections?) Well, the problem is how do you handle partial writes? Is there a case in which an error occurs but t

Re: [transcode-devel] checking the return value of fwrite

2006-12-05 Thread Andrew Church
>Looks that the right thing to do is to make tc_pwrite (and family) to >return -1 if errno != EINTR happens. >(Andrew, any objections?) Well, the problem is how do you handle partial writes? Is there a case in which an error occurs but the caller would want to know how much data was successf

Re: [transcode-devel] checking the return value of fwrite

2006-12-05 Thread Francesco Romani
On Tue, 5 Dec 2006 08:29:04 -0800 "Scott Smith" <[EMAIL PROTECTED]> wrote: [...] > Ok, but there's a bug in tc_pwrite, or in the way it's being used. > The return value of tc_pwrite is the number of bytes written. It is > never less than that; there is no special case to return a negative > numbe

Re: [transcode-devel] checking the return value of fwrite

2006-12-05 Thread Scott Smith
On 12/5/06, Francesco Romani <[EMAIL PROTECTED]> wrote: That makes think that we're talking about 1.0.x branch, am I right? oh, right. I noticed that some CVS modules used fwrite, but not that you switched to tc_pwrite. Ok, but there's a bug in tc_pwrite, or in the way it's being used. The re

Re: [transcode-devel] checking the return value of fwrite

2006-12-05 Thread Francesco Romani
On 12/5/06, Scott Smith <[EMAIL PROTECTED]> wrote: On 12/4/06, Andrew Church <[EMAIL PROTECTED]> wrote: > Personally, I've had my eye on getting rid of import_exit() > entirely, I fully agree with this. well a little more digging shows that apparently fwrite is not the preferred metho

Re: [transcode-devel] checking the return value of fwrite

2006-12-04 Thread Scott Smith
On 12/4/06, Andrew Church <[EMAIL PROTECTED]> wrote: Personally, I've had my eye on getting rid of import_exit() entirely, returning an error code from the decode/extract/etc. function instead. Seeing as that's not done yet, I suppose import_exit() is the only option, but I'd rather avoid a

Re: [transcode-devel] checking the return value of fwrite

2006-12-04 Thread Andrew Church
>I would like to clean up all the calls to fwrite in the >extracters/decoders. I was thinking of just writing 'import_write' >which would attempt the write, and call import_exit if it failed. >This is what extract_mp3 does, but there are other modules which >provide more verbose error messages. W

[transcode-devel] checking the return value of fwrite

2006-12-04 Thread Scott Smith
While chasing down a problem with transcode behaving different when run from bash vs python, I discovered that the return value of 'fwrite' is not consistently checked. Some extracters (mp3) check it, others (ac3) don't. This caused a problem where one process (tcdecode) exitted, leaving tcextra