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

[Christoph Mallon]

Erik Trulsson wrote:
> On Mon, Jan 28, 2008 at 11:55:29AM +0100, Dag-Erling Smørgrav wrote:
>> Yar Tikhiy <yar at comp.chem.msu.su> writes:
>>> Excuse me, but did you notice that fts(3) is not a part of sys?  It's
>>> generic userland code, albeit it's contaminated by system-dependent
>>> parts for performance or whatever.
>> Irrelevant.
>>
>>> But let intN_t be mostly confined in the kernel and system-dependent
>>> userland code.  E.g., system-dependent include files can use them
>>> to define more portable types such as ino_t, nlink_t, or whatever.
>> C99 doesn't define those either.
>>
>>> Userland code should be portable and useful to other systems in the
>>> chosen domain of compatibility, e.g., C99 or POSIX, unless there
>>> are substantial reasons for it not to.  That's how different projects
>>> can benefit from each other's work.
>> Both C99 and POSIX *require* int64_t and uint64_t on all platforms that
>> have 64-bit integer types.
>>
>> FreeBSD has never run on any platform that doesn't.  I don't think
>> NetBSD or OpenBSD has either, nor Solaris, nor Linux to my knowledge.
> 
> Those are all good reasons for why using 'int64_t' would be OK.
> None of it is a reason for why using 'long long' would not be OK when you
> want at least 64 bits, but do not require exactly 64 bits.

How about int_least64_t? It's a required type of at least 64bits.
I'd like my bikeshed green with yellow dots, please.

Regards
	Christoph