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

[Yar Tikhiy]

On Mon, Jan 28, 2008 at 08:28:27AM -1000, Juli Mallett wrote:
> * 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:

Sorry, I'm tired to respond reasonably to the same things over and
over again.  Our basic notions are just different, so this discussion
is pointless because neither side can truly convince the other one.
I've already written to core@, so now it's up to them to make the
final decision, which I'll comply with.

But I'll try for the last time.

> 	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.

Please give me a reason why we should use int64_t when we can get
along equally well with a basic C type.

> 	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).

You just fail to see advantages from portable coding other than
being able to run the code in a crazy system.

> 	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.

I ran into a practical problem in fts(3).  fts(3) is available in
all the BSDs and has also been ported at least to Linux and Solaris.
It's more powerful than the POSIX nftw(3).  Need I give more reasons?

> 	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.)

See (3).  fts(3) is a rather probable candidate for porting to other
systems.

But, hey, have you seen the diffs in the first place?  You seem to
assume that my commit was only to kill the innocent int64_t.

-- 
Yar