Re: API/ABI rank of headers in /usr/include/isofs/cd9660

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   Date: Tue, 13 May 2014 22:01:20 +0200
   From: "Thomas Schmitt" <scdbackup%gmx.net@localhost>

   > grep on the source tree :-)

   Did not bring any more findings, except 9 directory loops.

   The open risk is that some application like makefs might rely
   on these headers ... /usr/src/usr.sbin/makefs says it does not.

Only struct iso_args and the associated bits are really public, I
believe.  The rest of the header files are installed for hysterical
raisins.  There are some that may be useful for userland applications
to grovel through the physical format, but anything involving struct
mount, struct vnode, &c., is a mistake to expose to userland.

   > > attach a new member
   > > (unsigned long int) to its end.
   > New types should probably be uint64_t, rather than long.

   The size of this variable is determined by ISO 9660 specs.
   Block addresses and counters are specified as unsigned 32 bit.

   I refrain from exposing uint32_t to the public, because this
   usually needs inclusion of some .h file, which might not yet
   be required by the cd9660 .h files. (unsigned long int) is
   sufficient and harmless. Even sbin/mount_cd9660.c is happy,
   because it can printf %lu iso_args.ssector without a cast.

Just include <sys/types.h> and use uint32_t.

unsigned long is not the same width everywhere, which means that using
it in a kernel/userland interface requires compat code to be written
in the kernel in order for 64-bit kernels to manage 32-bit userlands.
Since you need a fixed range anyway, better to just use uint32_t.