Agree: Require ANSI C for development [Was: libwww ]

In message <9407131826.AA10464@hook.spyglass.com>, Eric W. Sink writes:
>
>Can we get rid of all those ARGS3 K&R compatibility macros?
>This is purely a style thing.  The only real difficulty they
>cause is that editors which parse C syntax in looking for functions
>can't grok the funky macros.  But how important is it REALLY that
>libwww support non-ANSI C compilers?

Amen and Halleluia!

Look at it this way: we've got different classes of consumers for
libWWW:

	* lib developers: folks like ourselves who can contribute to the
	  library. I think it's safe to assume that
	  anybody in this class has an ANSI C development environment.

	* builders: folks who just want to compile the library and apps
	  based on it on various platforms and provide binary
	  distributions of the library. These folks need an ANSI C
	  compiler. (And PGP or RIPEM to sign the binary distribution
	  so we can prevent viruses...)

	* app developers: folks who just want to use the library to
	  build specialized apps. These folks shouldn't be required
	  to have an ANSI C compiler. If they can get a binary library
	  distribuition, the public header files should work
	  even on broken compilers.

	* administrators: folks that support users by installing apps
	  and documentation, answering questions, etc.
	  These folks shouldn't need a compiler at all.

	* users: folks that want to surf and post. These folks don't
	  know what a compiler is.

The explosion in user base for the web is a result of the fact that
you don't have to be able to play the typical net-software game
of:
	* download the source
	* edit the makefiles
	* fix the dirent/direct BSD/SYSV stuff for your platform
	* build it
	* find a few bugs
	* fix them
	* install it in ~/bin

just to use the dang thing. For a given "product", there's a hierarchy:
zillions of users, supported by thousands of administrators who get
software from hundreds of sites, and that software is contributed by ten or
twenty developers.

Not only should we require an ANSI C compiler for development, but we
should write squeaky-clean ANSI C code, except for modules that need
POSIX features, in which case we should write squeaky-clean POSIX code.

For the non-standard interfaces (networking, etc.) we should use function
pointers and allow folks to substitute work-alikes WITHOUT RECOMPILING
THE LIBRARY!

I spent a weekend cleaning up the 2.15 header files, and isolated all
the platform specific stuff. It wasn't that hard. We just need to
synchronize that sort of thing because it touches all the files,
practically.

For cases where the platform doesn't directly support ANSI C semantics,
we supplement the runtime for that platform with something that does
what the spec says. For example, in the case of malloc() causing memory
leaks in MS Windows, we provide a malloc() that, for example registers an
at_exit() function and free()s everything when the program exits.

>Glad to get that off my chest.  If you agree to this, I'll be
>back asking to re-indent the code with 4-space tabs! :-)

I'm in favor of this too, by the way!

Dan

Received on Wednesday, 13 July 1994 20:56:45 UTC