Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> 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.
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
