Hi, Guillem.
Thank you very much for taking the time to read the changelogs.
On Nov 17 2009, Guillem Jover wrote:
> The 90-workaround_strlcpy.patch, that just replaces strlcpy with
> strncpy is wrong, as it does not take care of NUL-terminating the
> string in case of truncation.
Yes, that was a quick'n'dirty solution instead of coding strlcpy of mine
(more below).
> There's also a strlcpy macro in 10-linux_specific_code.patch
> (include/missing.h).
Oops.
> 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.
Do you have any suggestions?
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).
Regards,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
