Date: Sat, 16 Feb 2002 03:00:33 +0000 From: "J. Mallett" <jmallett@NewGold.NET> To: freebsd-arch@freebsd.org Subject: Generalisation of Base64 function prototypes. Message-ID: <20020216030032.A12929@NewGold.NET>
next in thread | raw e-mail | index | archive | help
Hello, I've been working on base64 ala MIME support for uudecode(1) and uuencode(1), as part of standards conformance projects. Rather than re-implement base64 stuff inline, I looked high and low for base64 functions in libc. Eventually Mike Barcroft came to my aid with b64_pton and b64_ntop, undocumented interfaces implemented in lib/libc/net/ and prototyped and wrapped in <resolv.h>. Rather than include networking types and functionality in uuencode and uudecode (silly) I put the prototypes and namespace wrappers in the code inline, and my current patch represents this, and I would probably end up getting it into the tree like this, I suppose, as there is no equally or less evil method of doing the right thing here. Except of course, what I proposed above the prototypes and preprocessor definitions I so hastily inserted, and that is moving b64_* stuff from <resolv.h> to <stdlib.h>. The interfaces are very generalised and as is obvious by the fact I have working base64 uu*code, they can be applied to things other than networking, and certainly more than just stuff that makes use of resolver code. Existing users of b64_* may need changed to include <stdlib.h> as well as <resolv.h>, however I would _guess_ that very few consumers of said prototypes do not already get <stdlib.h> included. I won't go into the issue of whether the namespace is too similar to networking functions and should be changed, nor whether the implementations should be repocopied to a non-networking location in libc, as while I have opinions of such things, I can't speak for how useful or purposeful such may be. I can only say that very soon, hopefully, uuencode(1) and uudecode(1) will have base64 functionality, as almost everyone else (aside the other BSDs) tends to be using this in addition to UUENCODE format, and that I think we should not duplicate the code, and that unless prototypes and namespace wrappers are placed into <stdlib.h>, or somewhere else independant of needing tons of networking headers, the code will have to have extremely out of place prototypes in itself. Just an idea, anyway. Insight is greatly appriciated, as well as discussion of such a change to decide whether it would be practical. Thanks for your time and attention. -- J. Mallett <jmallett@NewGold.NET> Need a modular BSD solution? http://www.xMach.org/ jmallett@{xMach.org,tasam.com,e-u-a.net} deepthroat@bsdconspiracy.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020216030032.A12929>