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
