Date: Sun, 20 Jun 2004 13:40:28 -0400 From: Chuck Swiger <cswiger@mac.com> To: Daniel Roethlisberger <daniel@roe.ch> Cc: ports@FreeBSD.org Subject: Re: Testing ports/patches on non-i386 (such as amd64) Message-ID: <40D5CC0C.8050908@mac.com> In-Reply-To: <20040620044647.GA24274@dragon.roe.ch> References: <20040620044647.GA24274@dragon.roe.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Roethlisberger wrote: > What's the best way to handle such a situation as port maintainer? > Should I file a PR asking for a committer to test my patches? Or should > I find someone able and willing to do some testing for me through other > means, such as posting patches to this list? Or should I just go ahead > and have the untested patches committed, and wait for the bento logs to > tell me about success or failure? (I don't particularly like this one). > Any other options? If you want to make sure your port works properly on the SPARC or Alpha, for example, having access to a machine of that type is very helpful. You might ask on the appropriate freebsd-sparc, freebsd-alpha, etc mailing list whether someone will test your port or give you a login so you can do the testing yourself. If noone responds, it's likely that you can not worry about that platform until someone does run your port and does run into a problem. :-) In the meantime, you can make changes to the software in a fashion that are platform-independent using C99 concepts; use portable datatypes such as intXX_t's rather than depending on sizeof(short) = 2 and sizeof(int) = 4, etc, particularly in struct's which are persisted in data files or sent over the network; you can avoid depending on fancy platform-specific analysis like GNU autoconf [1]; compile using -Wall and fix any warnings, pay attention to implicit conversions and casting when dereferencing pointers, etc. While you're there, one can also herd the code towards using snprintf() rather than sprintf() to try to avoid buffer overflows, using malloc() and [*gasp*] actually checking it's return value, rather than using automaticly allocated arrays on the stack, and so forth. None of this is rocket science. There's a lot of sloppy code of there, though... -- -Chuck [1]: The notion of conditional code which depends on actual tests of the local platforms capabilities is fine, to the extent that doing so is actually useful. However, autoconf has long since passed the point of being the tail wagging the dog in that it often takes longer to run ./configure than it does to actually build the program itself, when every ./configure run contains hundreds of lines of the same tests as every other, when the program code contains a maze of twisty little #ifdefs, all alike, when testing for sizeof(int) and the like encourages people to write code which depends on these conditionals rather than simply using a portable approach from the start, testing the maximum size of the argument list (and wasting lots of CPU time doing so) and hardcoding that value into the executable when that "maximum size" may well change if someone switches which shell they use or recompile the kernel, etc. [ I guess I pressed one of my own buttons here. :-) ]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40D5CC0C.8050908>