[KPhotoAlbum] Patch to speed up scanning for new images

[Robert L Krawitz]

   From: Shawn Willden <shawn-kimdaba at willden.org>
   Date: Thu, 10 May 2007 22:33:31 -0600

   On Thursday 10 May 2007 07:13:23 pm Robert L Krawitz wrote:
   > You win some and you lose some.  I understand the problem, but it
   > doesn't sound like there's really a safe way around it, since
   > KPhotoAlbum is threaded.

   I don't think it's a such a large concern in this case.  As long as
   the system-defined MAXNAMLEN really is the maximum filename length
   on the system, it's safe, no overflow is possible.  And, actually,
   it's even safer than that since you allocated sizeof(struct dirent)
   + MAXNAMLEN + 1 bytes, and struct dirent already allocates 256
   bytes for the name.  So, on my system, your code allocates 512
   bytes, where no more than 256 should ever be needed.  As the
   security advisory Jan linked to says, some systems have a small
   dirent structure, but the code should be safe even on those, as
   long as MAXNAMLEN is correct.

   For a little extra insurance, it might be a good idea to allocate
   the data from the heap rather than the stack.

I'll make the change to allocate it on the heap, but quite frankly
this whole thing seems a bit silly.  If MAXNAMLEN isn't correct, a lot
more things that readdir_r() will break.  In fact, I think this whole
union thing is pointless, and I don't even remember why I did it in
the first place.

Yes, the binary will theoretically have portability problems, but
it's the same with any binary that was compiled on a system and used
on a system with different constants.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton