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 Sun, Jan 27, 2008 at 01:46:53AM -0800, David O'Brien wrote:
> On Sun, Jan 27, 2008 at 08:38:13AM +0300, Yar Tikhiy wrote:
> > On Sat, Jan 26, 2008 at 08:33:34PM -0800, David O'Brien wrote:
> > > On Sat, Jan 26, 2008 at 05:09:41PM +0000, Yar Tikhiy wrote:
> > > >   o For things that should be at least 64 bits wide, use long long
> > > >     and not int64_t, as the latter is an optional type.
> > > 
> > > I don't follow - int64_t is an ISO-C99 type, and we have it in FreeBSD.
> > > Is this code expected to be taken from FreeBSD and used in some pre-C99
> > > system?
> > 
> > C99 explicitly says that any intN_t is an optional type[0].  E.g.,
> > a 96-bit system may choose not to provide int64_t if none of its
> > basic C types is 64 bits wide.
> 
> I think this is a quite silly argument.
>
>     $ 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.

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.

> > fts(3) is a purely userland library which need not depend on a
> > particular platform[1], so I did my best to avoid any assumptions like,
> > `There will never be a 96-bit system around.'
> 
> This is FreeBSD - not a magazine on C programming, in which examples

It doesn't mean that we shouldn't learn from a good magazine on C
programming. :-)

> should be usable on all platforms.  Given the use of intN_t in the
> kernel, we already cannot boot on this future platform

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.

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.

> Please don't un-C99 the system that folks have worked to update us to.

And I've been convinced that I'm making a part of our system more
compliant to C99.  We must be reading different C99 standards. :-)

-- 
Yar