Re: Fifth draft of the Y2038 design document

[Deepa Dinamani <deepa dot kernel at gmail dot com>]

>> There is a small error in the way SO_TIMESTAMPING is described below:
>>
>> SO_TIMESTAMPING uses an integer bitfield which is not sensitive to
>> time bit-size.
>>
>> SO_TIMESTAMPING uses the below struct as its cmsg data:
>> struct scm_timestamping {
>>      struct timespec ts[3];
>>  };
>
> I think we're talking about two different things: the integer bitfield
> I am talking about is the argument to setsockopt, described as such in
> Documentation/networking/timestamping.txt; the struct scm_timestamping
> you're talking about is the ancillary data read through recvmsg() when
> some SO_TIMESTAMPING options were set.

According to your draft:

SO_TIMESTAMP uses a struct timeval as its cmsg data;

SO_TIMESTAMPNS uses a struct timespec as its cmsg data;

SO_TIMESTAMPING uses an integer bitfield which is not sensitive to
time bit-size.

Here you point out that the OOB data format for both SO_TIMESTAMP and
SO_TIMESTAMPNS.
But, you are using setsockopt options for SO_TIMESTAMPING.
I was just pointing out this discrepancy.

> As far as recvmsg / sendmsg / cmsg are concerned, I /think/ there are
> no dependencies per se on time_t size; it only comes into play when/if
> CMSG_DATA() is type-cast to (a pointer to) a type which involves time_t,
> and such casts are done at application, not GLIBC, level.

I was pointing to the discussion from last time here: that we could
use a flag in recvmsg/ sendmsg to indicate time_t size. And, we
decided to not rely on this.

-Deepa