[sane-devel] debug logs not output ...toupper() call related issue in sanei_init_debug()
viresh_shirol at yahoo.co.uk
Tue Aug 6 16:55:29 UTC 2013
On Sunday 04 August 2013 01:02 PM, Stef wrote:
> On 02/08/2013 19:39, viresh wrote:
>> On Wednesday 17 July 2013 07:17 AM, m. allan noah wrote:
>>> I can confirm your findings- i think this is a bug in
>>> On Tue, Jul 16, 2013 at 8:46 PM, Bureau <viresh_shirol at yahoo.co.uk>
>>>> Hi all,
>>>> During my backend testing efforts with tstbackend.c frontend that
>>>> is available in the distribution ,I observed an issue in the
>>>> sanei_constrain_value function.
>>>> The details are as below.
>>>> 1)I believe the specifications for SANE_Range are simple enough and
>>>> there are no further rules on the values for min,max and quant
>>>> 2)assuming #1 above is correct, my observation is that the
>>>> constrain_value function returns values that are greater than the
>>>> max specified for the range.
>>>> 3)I am assuming that #2 item is either unknown or known but not
>>>> fixed/valid scenario.
>>>> 4)the issue
>>>> the issue happens for constraint type RANGE when following
>>>> condition is satisfied
>>>> (max-min)%quant >=(quant/2)
>>>> value to be set >=max
>>>> Cause:Due to rounding done using quant/2 value,the final value put
>>>> in array[i] overshoots the max value by at the max quant/2 units.
>>>> 5>Why this is an issue for me
>>>> for few reasons
>>>> a)I blindly believed the value returned by constrain_value is
>>>> actually constrained to the max. By this assumption,I did not have
>>>> to check the values everywhere for their constraint-wise-correctness.
>>>> b)the machine that I am writing the backend for seems to take tl br
>>>> values in mm and seems to do some kind of validation using which it
>>>> decides the actual scan size.So offset of value/s for tl br options
>>>> would lead to heavy offsets when large resolution scan is done.
>>>> c)the issue is very dominant,I believe,when the range type is
>>>> SANE_Fixed. Note that in this case the quant value is sufficiently
>>>> large leading to larger offsets.
>>>> 6)Solutions possible
>>>> a)temporary fix can just check whether the adjusted value is larger
>>>> than Max for the range and set it to either max or one quant level
>>>> Also,I can temporarily fix it in a local function.
>>>> b)not very sure but If the rounding via quant/2 is removed we can
>>>> safely say that the value is always safe. I think it's a subjective
>>>> item and can not discuss further but I think flooring isn't that bad.
>>>> 7)My test values(sorry to put them at the end)
>>>> max=SANE_FIX(431.8);//ledger width
>>>> quant=SANE_FIX(0.01);//tried .1,1.0 too
>>>> value to be set (actually the issue was found when testing with
>>>> tstbkend.c fronted) is 431.8. (or more ...as constrain value
>>>> reduces it to max in that case)
>>>> Query:how do I proceed with this?My main question is "am I doing
>>>> something wrong??"
>>>> this is my first post.I wanna thank you all and especially the ones
>>>> who have authored the tstbackend frontend.Also,please note that I
>>>> may ve wrong in using fractional quant values etc but i think there
>>>> was no limitation w.r.t. in the spec. I apologize in advance if
>>>> anyone feels any sentence in this post seems to show impoliteness
>>>> in any way. ...I am newbie/noob u knw!!!!
>>>> Thanks and regards,
>>>> Sent from my iPhone
>>>> sane-devel mailing list: sane-devel at lists.alioth.debian.org
>>>> Unsubscribe: Send mail with subject "unsubscribe your_password"
>>>> to sane-devel-request at lists.alioth.debian.org
>> Hi Allan,
>> Thanks for the quick response that day. And I am sorry for the late
>> reply from my side.
>> I am attaching the updated code based on the temporary solutions that
>> I had mentioned in my original mail.
>> I am not sure if this is the correct procedure to send the updated
>> code but I am new to git as well.
>> Also I believe newbies like me can not update the code tree directly
>> Could you please review and include the changes in the next release?
>> Please note that the changes in my backend code were external to
>> i.e. though the logic was same as the attached file, the patch was
>> external to constrain_value function.
>> Apart from this, I would like to know if I could help the efforts in
>> any way. I dont have any hardware to test any backends etc but I
>> have some experience with opencv-v4l configuration which I think can
>> be helpful in improving the v4l backend. (At least the man page says
>> it is not so stable)
>> Also as a plus point w.r.t scanners ,I have some 3+ years of
>> experience on multi functional peripherals controller development(for
>> one of the brands which do not have a sane backend of their own yet)
>> which included work on UI to middleware.
>> Let me know if I can be of any help in any way.
>> Viresh M.Shirol
>> P.S: rather large comment for 1 if block addition in the code but I
>> think it explains why the changes were done clearly.
> I have commit the fix in git tree. I have also added test cases in
> sanei_constrain_test.c which detected the problem before fix, and are
> now 'passing' with the fix.
> I don't think there is a better way to change this. Since sane
> 'fixed' values are float values multiplied by 65536, there will be
> always rounding issues. For instance the SANE_Range you used resolved
> to min=0, max=28298444 and quant=655, so min+k*quant will always be
> different from max.
Thanks for the commit.
A new issue report follows...
While testing our backend code for Pardus Linux Turkish version, we
observed another issue.
Though I would like to think that it is not a serious bug but the
efforts put in to pinpoint the issue root cause were sufficient enough
to mention it here for your opinions.
The details of the issue are as below.
Problem statement: Debug logs were not output even though the
SANE_DEBUG_XXX env variable was set to non-zero value.
1>XSane front end supports internationalization via ,probably,
setlocale() call. (i think it's bindtotextdomain() or something but I am
not sure of the actual func. call)
2>When setlocale (most likely LC_ALL category) is done by xsane , the
case conversion is affected.
3>When sane_init_debug() call is made by the backend the flow is as below,
a> set buf="SANE_DEBUG_"
b> get the backend name
c>convert the backend name to all UPPER CASE using toupper() call.
d>append the converted backend name to buf
d>get the user set env variable value using getenv(buf)
e>if the env is set and valid convert it to int and set
DEBUG_LEVEL. else return.
4>THE ISSUE point
toupper() call usage is probably not good. When character 'i' (HEX
49) is passed to toupper() after xsane has set the LC_CTYPE is changed
to turkish ,its upper case character is still "i".
i.e. uppercase('i') ='i' ----i.e. not 'I'
(btw, i had no clue such things existed....a learning point you know..at
least dint expect it for ASCII chars)
now if my backend name is xixi then the uppercase counterpart would be
"XiXi" ,for turkish locale ,which is completely different from the
expected XIXI value.
5>As the sanei_init_debug() was searching for SANE_DEBUG_XiXi ,the
export SANE_DEBUG_XIXI=100 done by us was never recognized. And thus no
logs output by the backend.
1>The debug log issue applies to all the backends which have character
'i' in their name.
-->The issue specific to character 'i' is only for Turkish.
However the manpage for toupper clearly mentions that for some
scripts there are no uppercase counterparts for some letters. (for ex.
the sharp s in german)
2>The toupper logic seems to be present in libsane-dll.so too as we
could see SANE_**_CONFig_PATH too being queried incorrectly due to
which the default path /usr/local/lib/ was being searched for the so files.
-->As I am not sure about where all and how all the toupper() call
is made, I think we need to check this part to avoid unnecessary debugging.
For ex. Even thouhgh the configure path was /usr/lib ,due to
incorrect env variable name creation the dll.so would try to search for
the installed drivers in /usr/local/* which it won't find.
We are not sure about where all the changes may be required but I think
the following might work.
before toupper() call, set the local to en_US.en_US and after toupper
call restore the original locale.
But will this transient change have any side effect on the frontend
(especially the graphical frot end such as xsane) any effect on its text
conversions is not clear.
Note: I am not sure if backend names have any limitations/specifications
,w.r.t characters that they can have ,in the standard1.0.
Though it's not a major item as far as debug log output is concerned
,but I think if there are any other such instances in the source files
which I am not aware of yet, they could lead to few other problems too
probably relatively major ones when we target different langauges.
Backends which would not output debug logs in Turkish OS would be as below,
(reference:supported backends page
etc. which all have character 'i' in their name.
NOTE: This is only regarding Turkish OS and I am not aware of other
languages where toupper() would return the same char for alpha chars.
Not aware means not knowledgeable enough.
Pardus Linux Turkish 32bit OS
XSane 0.998 package in the installed os
probably 1.0.23(22?) sane backends package.
Thanks and regards,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sane-devel