kopia lustrzana https://gitlab.com/sane-project/website
124 wiersze
5.0 KiB
HTML
124 wiersze
5.0 KiB
HTML
<!-- received="Tue Dec 8 14:44:10 1998 PST" -->
|
|
<!-- sent="Wed, 9 Dec 1998 01:30:03 +0100 (MET)" -->
|
|
<!-- name="becka@rz.uni-duesseldorf.de" -->
|
|
<!-- email="becka@rz.uni-duesseldorf.de" -->
|
|
<!-- subject="Re: Bit of a rant, bug in PNM" -->
|
|
<!-- id="m0znXVz-000CHLC@hades.beck-sw.de" -->
|
|
<!-- inreplyto="Pine.LNX.3.96.981208195305.16262A-100000@chef.ecs.soton.ac.uk" -->
|
|
<title>sane-devel: Re: Bit of a rant, bug in PNM</title>
|
|
<h1>Re: Bit of a rant, bug in PNM</h1>
|
|
<a href="mailto:becka@rz.uni-duesseldorf.de"><i>becka@rz.uni-duesseldorf.de</i></a><br>
|
|
<i>Wed, 9 Dec 1998 01:30:03 +0100 (MET)</i>
|
|
<p>
|
|
<ul>
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#115">[ date ]</a><a href="index.html#115">[ thread ]</a><a href="subject.html#115">[ subject ]</a><a href="author.html#115">[ author ]</a>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0116.html">David Fox: "Re: Bit of a rant, bug in PNM"</a>
|
|
<li> <b>Previous message:</b> <a href="0114.html">Wolfgang Kaess: "Internet Message Header"</a>
|
|
<!-- nextthread="start" -->
|
|
<li> <b>Next in thread:</b> <a href="0129.html">Nick Lamb: "PNM bugfix doesn't help"</a>
|
|
<li> <b>Reply:</b> <a href="0129.html">Nick Lamb: "PNM bugfix doesn't help"</a>
|
|
<!-- reply="end" -->
|
|
</ul>
|
|
<!-- body="start" -->
|
|
Hi !<br>
|
|
<p>
|
|
<i>> 2. The PNM backend seems to be a quick hack, </i><br>
|
|
<p>
|
|
Well - it was kind of the "reference implementation", that was used in the<br>
|
|
early days to have something to talk about.<br>
|
|
<p>
|
|
If it is broken, it is probably largely my fault.<br>
|
|
<p>
|
|
<i>> I hoped to use it to test my install of SANE, </i><br>
|
|
<p>
|
|
That's actually what it was meant for. Testing and reference implementation.<br>
|
|
<p>
|
|
<i>> but instead I have spent a good hour finding that the</i><br>
|
|
<i>> problem initially thought to be the result of my mistakes is a BUG</i><br>
|
|
<i>> in the PNM backend!</i><br>
|
|
<p>
|
|
Ouch. So we got to squish it.<br>
|
|
<p>
|
|
<i>> The major bug in the PNM device is that it seems to think the</i><br>
|
|
<i>> maximum length parameter to read_sane() is just a suggestion! </i><br>
|
|
<p>
|
|
Oh - WHAT ?<br>
|
|
<p>
|
|
In what branch does that happen ?<br>
|
|
<p>
|
|
The sane-read request branches, if the "modifying" options are set.<br>
|
|
If neither grayify nor three-pass-emulation are set, all should be well:<br>
|
|
<p>
|
|
else<br>
|
|
/* Suck in as much of the file as possible, since it's already in the<br>
|
|
correct format. */<br>
|
|
len = fread (data, 1, max_length, infile);<br>
|
|
<p>
|
|
Now let's have a look at the other branch ...<br>
|
|
<p>
|
|
Ah - I see it. There is a buffer allocated and blindly filled with data<br>
|
|
which is the given out again. However due to the dynamic sizing of the<br>
|
|
buffer, this can overflow the frontend buffers, in case the frontend<br>
|
|
uses different sized read requests.<br>
|
|
<p>
|
|
O.K. - nice someone has found that finally, and even nicer, that I am sure<br>
|
|
I didn't write that code. So who's the culprit ? David ? ;-)<br>
|
|
<p>
|
|
O.K. - how to fix that ...<br>
|
|
<p>
|
|
as a quickfix, I assume replacing the ;p < rgbend; in the for loops with <br>
|
|
;p < rgbend && max_length--; looks tempting, but we would have to take <br>
|
|
care for a _biiig_ overflow buffer.<br>
|
|
<p>
|
|
Another (a bit better) one would be to disable the if (rgbbuf == 0 || <br>
|
|
rgblength < 3 * max_length) condition, or the yet best I see is to do<br>
|
|
<p>
|
|
- len = fread (q, 1, rgblength - rgbleftover[0], infile);<br>
|
|
+ len = fread (q, 1, 3*max_length - rgbleftover[0], infile);<br>
|
|
<p>
|
|
Yeah - that should fix it.<br>
|
|
<p>
|
|
Could you test/confirm that ? Otherwise we'd need to look for a "real" fix.<br>
|
|
<p>
|
|
<i>> If the PNM device has more data to send, it just writes past the end</i><br>
|
|
<i>> of the buffer, </i><br>
|
|
<p>
|
|
Hey - it's not that bad. Just some overly clever code, which misbehaves<br>
|
|
when used in a somewhat unusual way. Who didn't make such a mistake once<br>
|
|
upon a time ?<br>
|
|
<p>
|
|
<i>> I can't tell if this bug exists for any other SANE devices.</i><br>
|
|
<p>
|
|
It shouldn't. It looks like it has been introduced with the test festures.<br>
|
|
<p>
|
|
Can you confirm, that my suspicion is correct ?<br>
|
|
<p>
|
|
I.e. it only happens, when either grayify or 3-pass-emulation is on, and the<br>
|
|
frontend uses varying sizes for the read()s - right ?<br>
|
|
<p>
|
|
Does my suggested fix kill the bug ?<br>
|
|
<p>
|
|
CU, ANdy<br>
|
|
<p>
|
|
<pre>
|
|
--
|
|
= Andreas Beck | Email : <<a href="mailto:andreas.beck@ggi-project.org">andreas.beck@ggi-project.org</a>> =
|
|
<p>
|
|
<pre>
|
|
--
|
|
Source code, list archive, and docs: <a href="http://www.mostang.com/sane/">http://www.mostang.com/sane/</a>
|
|
To unsubscribe: echo unsubscribe sane-devel | mail <a href="mailto:majordomo@mostang.com">majordomo@mostang.com</a>
|
|
</pre>
|
|
<!-- body="end" -->
|
|
<p>
|
|
<ul>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0116.html">David Fox: "Re: Bit of a rant, bug in PNM"</a>
|
|
<li> <b>Previous message:</b> <a href="0114.html">Wolfgang Kaess: "Internet Message Header"</a>
|
|
<!-- nextthread="start" -->
|
|
<li> <b>Next in thread:</b> <a href="0129.html">Nick Lamb: "PNM bugfix doesn't help"</a>
|
|
<li> <b>Reply:</b> <a href="0129.html">Nick Lamb: "PNM bugfix doesn't help"</a>
|
|
<!-- reply="end" -->
|
|
</ul>
|