Hi! On Tue, 2009-11-17 at 02:30:05 -0200, Rogério Brito wrote: > Thank you very much for taking the time to read the changelogs.
No problem. :) > On Nov 17 2009, Guillem Jover wrote: > > Ideally all those would be replaced by just linking against libbsd and > > using strlcpy from there. > > OK, now we reach the real problem: the code is not 64-bit safe and, > therefore, I'm compiling with -m32 on amd64 and kfreebsd-amd64 and > leaving other 64-bit arches aside. :-( (You probably can tell that I am > unhappy about that). > > Unfortunately, compiling with -m32 doesn't seem to work with libbsd the > last time I tried, since the code being linked would be 64-bit (libbsd > would already be compiled with 64 bits when being linked) and this is > the reason why I just chose the fasttrack of substituting strlcpy with > strncpy. Yeah, I realized the gcc-multilib problem after having sent the report. > Do you have any suggestions? What happened to the patch from Goswin? I've reviewed it and it seems ok, built and tested it and seems to work fine. Did some brief review of the fsck code and there does not seems to be any other suspsicious cast, and the remaining warnings from the build are not related to 64 bit pointer issues. > I am on the verge of writing strlcpy myself, but I really, really want > to avoid that, for many reasons (the first one being not knowing of > security bugs inside the code, if my own version happens to be > vulnerable). One of the reasons for creating libbsd, was especifically to avoid this kind of situation, to try to reduce code duplication and embedded copies. So please, let's avoid that! I'd recommend building natively for 64-bit, linking against libbsd, and if there's any other portability problem in the future, fixing it. regards, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
