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:17:47PM +1100, Peter Jeremy wrote:
> 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.

The range of intmax_t guaranteed by C99 is not greater than that
of long long.  Intmax_t is there not to store astronomical numbers,
but to be able to keep a value from any non-basic integer type,
e.g., when one needs to printf(3) an off_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.

I'd put it the other way around: porting code often is so painful
because many people care only about their favourite systems and
platforms.

-- 
Yar