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

[Bruce Evans]

On Mon, 28 Jan 2008, Yar Tikhiy wrote:

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

Please don't back it out.  I think some of the type changes aren't best,
but mostly for the opposite reasons to people who ask for a back out
(since they aren't as portable as possible).

While the existence of long long is a bug, using int64_t just because you
want a 64-bit type is worse.  fts might need to use fixed-width types to
nail doesn its ABI.  Otherwise, it shouldn't use fixed-width types.

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

1) To prevent the ABI changing when the size of the basic C type changes.
    I don't know if this matters for fts.
2) To prevent space wastage if the basic C type is larger than the fixed-
    width type or becomes larger.  In this case, the basic C type doesn't
    work equally well, but ignore that for the moment.  (long long
    should have size 256 bits on 64-bit machines and 512 bits on 128-bit
    machines.  Sizes should be long = twice as long as a machine register;
    long long = twice as long as long.  Except long long shouldn't exist).

>> ...
>> 	3) This is a damn strange place to start a crusade:
>>
>> 	   Why is your interest in fts(3) and limited to fts(3)?  The
>>...
>
> 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?

fts shows what happens when types are poorly chosen.  The types become
part of the API and ABI, and if they are really poorly chosen then they
eventually become too small.  When fixing this, it would be stupid to
repeat the mistake.

I would probably use intmax_t more, provided its size doubling every
few years is not a problem.  Old kernel headers and one place in old
fts used `long' for the same reason back when `long' meant intmax_t,
but old fts is apparently concerned about space wastage and uses shorts
and ints a lot.  I don't know if space is a problem for struct fts.

Bruce