Re: xtime.h's xtime_nsec: s/int/long int/? (resend)

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> Jim Meyering <address@hidden> writes:
>
>> [I sent this message a few weeks ago, but it was
>>  mistakenly MIME-format=flowed, so not very readable]
>
> Odd, I sent a reply (only to bug-gnulib), but I see it's not archived
> so I guess it didn't get through the spam filters.  Here it is again.
>
> =====
>
> POSIX originally made tv_nsec 'long int' because 'int' might have been
> 16 bits.  Nowadays, though, 'int' is guaranteed to be at least 32 bits
> (both by POSIX and by the GNU coding standards), so it's OK nowadays
> to use 'int' to store a tv_nsec number.
>
> I thought it a bit nicer to celebrate the fact that we don't have to
> worry about 16-bit hosts, and to use plain 'int' here.  It's not a big
> deal either way, though, and if there's a problem with using 'int' we
> can change it to 'long int'.

I'm not worried about the absolute width of `int' -- just about
its width compared to that of the timespec.tv_nsec member.
Since that member has type long,

  struct timespec
  {
    time_t tv_sec;
    long tv_nsec;
  };

the corresponding xtime.h parameters/functions should, too.

This came up when I tried to print an xtime_nsec value with the
same format (%ld) that I'd use to print timespec.tv_nsec member.
But that gives a warning about the potential mismatch.