From owner-freebsd-arch Fri Feb 15 19:21:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from sunny.newgold.net (durham-ar1-174-172.durham.dsl.gtei.net [4.40.174.172]) by hub.freebsd.org (Postfix) with ESMTP id BD48D37B404 for ; Fri, 15 Feb 2002 19:21:48 -0800 (PST) Received: from sunny.newgold.net (jmallett@localhost [IPv6:::1]) by sunny.newgold.net (8.12.1/8.12.1) with ESMTP id g1G30YDF026805 for ; Sat, 16 Feb 2002 03:00:35 GMT Received: (from jmallett@localhost) by sunny.newgold.net (8.12.1/8.12.1/Submit) id g1G30XEV016470 for freebsd-arch@freebsd.org; Sat, 16 Feb 2002 03:00:33 GMT Date: Sat, 16 Feb 2002 03:00:33 +0000 From: "J. Mallett" To: freebsd-arch@freebsd.org Subject: Generalisation of Base64 function prototypes. Message-ID: <20020216030032.A12929@NewGold.NET> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.21i Organisation: New Gold Technology Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 . 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 to . 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 as well as , however I would _guess_ that very few consumers of said prototypes do not already get 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 , 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 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