cvs commit: src UPDATING src/include fts.h src/lib/libc/gen Makefile.inc Symbol.map fts-compat.c fts-compat.h fts.3 fts.c src/sys/sys param.h

[Juli Mallett]

* Yar Tikhiy <yar at comp.chem.msu.su> [ 2008-01-28 ]
	[ Re: cvs commit: src UPDATING src/include fts.h src/lib/libc/gen Makefile.inc Symbol.map fts-compat.c fts-compat.h fts.3 fts.c src/sys/sys param.h ]
> You are wrong, I haven't recieved a request for back-out yet, and
> I don't consider general criticism as such.  You are the first one
> to ask for back-out explicitly, but I don't think that your request
> has enough technical grounding.  Let's take this issue to core@
> then.

I think you should back it out because:

	1) The perceived gains do not exist:

	   Anybody porting code is going to have to do some legwork anyway and
	   defining a {u,}int{8,16,32,64}_t is probably one of the things they
	   will have to do, and isn't at all difficult.

	2) The actual gains do not exist:

	   Anybody running on so quirky a system as to have a "long long" but
	   no 64-bit type is going to have to do more than some legwork, like
	   annotating all the pointers to note which sort of memory they're in.
	   It is also unlikely that such a system has a need for fts(3).

	3) This is a damn strange place to start a crusade:

	   Why is your interest in fts(3) and limited to fts(3)?  The
	   portability of it borders of non-sequitur (and I suspect that your
	   commits to it were not because you were using fts(3) elsewhere,
	   though I suppose it is in the realm of possibility.)  As fts(3) is
	   unlikely to be used elsewhere by many people, portability isn't a
	   prime concern (though a little of it sure is nice.)  There is also
	   not a reason why it would be portable, as we are not taking it from
	   an externally-maintained source who wishes to keep it portable.  When
	   are you planning to sweep the tree for __FBSDID()?  I've run in to
	   that when using FreeBSD code elsewhere far more often than I've
	   ported FreeBSD code to a system that didn't have those C99 types.

	4) Other things in libc/gen use those C99 types or less portable
	   variations on the same theme:

	   There are 27 instances of 'int[1368]' in libc/gen -- one of them is
	   a manpage.  The manpage is for arc4random(3), which I would bet you
	   several dollars, a couple yuan and a handful of hrivnas has been
	   taken outside of FreeBSD by someone more times by an order of
	   magnitude than fts(3).  And it uses the even less portable old BSD
	   types 'u_int{8,16,32,64}', which have caused me pain in the past.
	   But I do not know many programmers who would start with FreeBSD libc
	   with the goal of porting many parts of it who do not know how to
	   define a type (some of them might use #define, or perl(1), but they
	   would all get the idea.)

Thanks,
Juli.