On Tue, Jan 05, 2010 at 09:39:45AM +0100, Martin Costabel wrote:
> Daniel Macks wrote:
> []
> > main/archives.c:tarobject() uses a static buffer to store a filename
> > during installation. Wanna guess the size of fnamebuf[]? Try bumping
> > it to something "much larger". Latest dpkg upstream still has this
> > same hardcoded size.
>
> This may even be legal, seeing that /usr/include/sys/syslimits.h has
>
> #define NAME_MAX 255 /* max bytes in a file name */
>
> I don't know if this number includes the path component or only the
> basename, though. The basename itself, even extended by "-dpkg-new", is
> only 244 characters.
The open(2) manpage says:
[ENAMETOOLONG] A component of a pathname exceeded {NAME_MAX} charac-
ters, or an entire path name exceeded {PATH_MAX} char-
acters.
> As buffer overflows do not always lead to crashes, this would explain
> the sort of non-deterministic behavior of the package.
>
> Anayway, I guess this should be treated as a bug in sbcl. It doesn't
> really need that outrageously named file, which only contains a URL
> redirection, anyway, and does not seem to be linked to by any of the
> other documentation files.
Sounds good to me.
dan
--
Daniel Macks
[email protected]
http://www.netspace.org/~dmacks
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Fink-devel mailing list
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
