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 > number if an error other than EINTR is encountered. That's an interesting point. I must admint that I've noticed this so far. Quick background explanation: some months ago tc_pwrite (as well as tc_pread and tc_preadwrite) was moved into libtc to replace multiple copies of p_write/p_read/p_readwrite scattered into codebase. It was no more than a copy/cut/search/replace process, so is definitively possible that some bugs are still in. Back on line: Looks that the right thing to do is to make tc_pwrite (and family) to return -1 if errno != EINTR happens. (Andrew, any objections?) > However, some modules (like decode_mp3) check if the return value is > negative, which is never is. Some modules do the right thing (like > extract_dv, extract_pcm), and some do a mixture (like extract_ac3). Well, a serious review will be undoubtfully a bless :) > Of course some don't bother checking it at all (parts of extract_ac3 > -- who wrote that?, decode_mov, etc) Legacy. Not so good legacy :( > So, uh, which way should I go? Change tc_pwrite to return negative on > error, or change users to check if result != num bytes requested? I'd to say: both of them :) The best is to improve tc_p*() behaviour AND review their usage on client code. :) Bests, -- Francesco Romani - Ikitt ['people always complain, no matther what you do'] IM contact : (email first, Antispam default deny!) icq://27-83-87-867 known bugs : http://www.transcoding.org/cgi-bin/transcode?Bug_Showcase tiny homepage : http://fromani.exit1.org (see IDEAS if you want send code!)
