Re: CVS commit: src/sbin/fdisk

[Alan Barrett <apb%cequrux.com@localhost>]

On Tue, 04 Sep 2007, Valeriy E. Ushakov wrote:
> > If we want to work around issues like this,
> > src/tools/compat/compat_defs.h seems to be a much better place to do it.
> 
> I guess I'm to blame for setting the precedent, b/c I've added PRId64
> there some time ago (for FreeBSD 4 host too).

Does FreeBSD-4 have int64_t but not PRId64, or does it have neither,
or does it have both but needs special header files to be included (in
addition to <inttypes.h>)?

> However in this specific case I wonder
> 
> . if using PRI macro is necessary at all and if just using int
>   wouldn't be enough (I don't think we support hosts with ints
>   narrower than 32-bit anyway).

Yes, we could use int or long or "long long" for all the printf stuff,
but perhaps not for the calculations involving int64_t variables.  But
I'd find it easier to continue using the PRI* macros and just supply
suitable compat definitions.

> . why compat macro is defined as a "long" format?

I'll eventually fix this by defining the compat macro as "d", "ld" or
"lld", depending on INT_MAX, LONG_MAX, etc.

> . why an unsigned value is printed using a signed format?  (which has
>   nothing to do with the discussed change, but while we are here...)

Good question.  I suppose nobody has seen a disk larger than 2^63
sectors (2^42 gigabytes, assuming 512-byte sectors), so the unsigned
value hasn't ever appeared to be negatove.

--apb (Alan Barrett)