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

[Peter Jeremy]

On Mon, Jan 28, 2008 at 08:35:15AM +0300, Yar Tikhiy wrote:
>On Sun, Jan 27, 2008 at 01:46:53AM -0800, David O'Brien wrote:
>>     $ find /usr/src/sys -name \*.[ch] -a -type f \
>>         | xargs grep int[0-9][0-9]_t | wc -l
>>     37026
>> 
>> I think that shows we can depend on int64_t existing and usable.

My count (using ports/devel/id-utils) says there are 627 references to
int64_t in the tree - half of them in sys.  If you extend this to
tokens matching /int[0-9]+_t$/ then those numbers go up to 62958 and
48559 respectively.

A more suitable type might be intmax_t - which is also used more
commonly in userland than int64_t.

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

I would prefer to see the primary driver for FreeBSD code be FreeBSD,
not what other projects may or may not choose to copy from it.  In
general, porting code to other systems is going to require more than
a copy-and-paste.  Requiring the target system to provide a single,
fairly well-defined standard type does not seem overly onerous.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20080128/08f088a7/attachment.pgp