[sane-devel] Re: dell1600n_net.c in sane-backends-1.0.18

m. allan noah anoah at pfeiffer.edu
Sun Jul 30 17:00:11 UTC 2006


can you be assured that L_tmpnam will exist on all platforms sane builds 
on? it would seem that PATH_MAX might be a better define to use...

allan

On Sun, 30 Jul 2006, Jon Chambers wrote:

>
> Hi Scott,
>
> Oops!  Well spotted: I will amend this for the next release!
>
> By the way, do you have a Dell 1600n and if so does the driver work ok for 
> you (aside from its monstrous size!)?
>
> cheers,
> Jon
>
> ====================== Jon Chambers =====================
> http://www.jon.demon.co.uk, 020 8575 7097, 07931 961669
> =========================================================
>
>
> On Sat, 29 Jul 2006, Scott S. Bertilson wrote:
>
>>  At line 1765 the code allocate a char array:
>> 	char tempFilename[TMP_MAX] = "scan.dat";
>> I just tried to build it on FreeBSD-6.1 and noticed that
>> while installing it took a _very_ long time to strip
>> the shared object for dell1600n_net.  Out of curiousity,
>> I looked at the size of the shared object and found that
>> it was about 300 MB (yes, megabytes).  After poking around,
>> I narrowed it down to the line referenced above.  After
>> a little more looking around, I found out that
>> 	TMP_MAX
>> is the maximum number of unique _names_ generated by
>> the algorithm used whereas "L_tmpnam" is the symbol
>> defined to specify the maximum _length_ of the string
>> generated.  This is documented on both FreeBSD-6.1
>> and Gentoo Linux.  I get a very reasonable 24.5 KB
>> object file after changing this.
>>  I'm guessing that there must be something interesting
>> about the gcc-3.4.4 compiler on my FreeBSD-6.1 machine
>> because I don't get a preposterously large object file
>> on Gentoo with gcc-3.3.6.
>> 				Regards, Scott
>> 
>
>

-- 
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera



More information about the sane-devel mailing list