On Fri, 24 Sep 2010, Brad Jorsch wrote: > > completely agreed, however myy autohell-fu is hardly up for this task. > > Patch to follow shortly.
i like that approach, thank you! (ok, this sort of problem is new to me, so i'm turned easily, but still, i like it.) > > if system/libbsd provides them, we just #define wstrlcat strlcat? > > The drawback there is that in the libbsd case it would reqiure anyone > compiling against WINGs to have bsd/string.h available (e.g. in Debian, > they'd need libbsd-dev installed and not just libbsd0). i fail to see how is this a problem, but i guess this has to be decided by someone more interested in debian politics than i am. one either habitually unbundles (without understanding consequences is not uncommon, this witty remark is here to bad-mouth debian) components that are available in debian too *and* accepts the fact that this indeed might pull in other dependencies (this is what debian does), or doesn't unbundle and keeps vewy quiet (this isn't what debian does). i personally don't care and don't want to be involved. i came upon libbsd only by chance, and thought supporting it would be nice, but i accept the fact that the problem grew over me very fast, and now i would very much like to chicken out. > For the moment anyway, I provided implementations of wstrlcat and > wstrlcpy that just pass through to strlcat and strlcpy if available. i like this. thanks! -- [-] mkdir /nonexistent -- To unsubscribe, send mail to [email protected].
