On 05/05/16 12:26, Michal Privoznik wrote:
> On 05.05.2016 11:05, Erik Skultety wrote:
>> On 05/05/16 09:30, Michal Privoznik wrote:
>>> I've noticed this while trying to compile libvirt on my arm box.
>>>
>>> CC rpc/libvirt_net_rpc_server_la-virnetserverclient.lo
>>> rpc/virnetserverclient.c: In function 'virNetServerClientNewPostExecRestart':
>>> rpc/virnetserverclient.c:516:45: error: cast increases required alignment of target type [-Werror=cast-align]
>>> (long long *) ×tamp) < 0) {
>>> ^
>>> cc1: all warnings being treated as errors
>>>
>>> Problem is, @timestap is defined as time_t which is 32 bits long,
>>> and we are typecasting it to long long which is 64bits long.
>>> Solution is to make @timestamp type of long long. But that could
>>> overflow when passing the variable to
>>> virNetServerClientNewInternal(). Well, we can do this and hope to
>>> find a better solution for this till 19 January 2038 (yes, time_t
>>> on my arm box is signed long int).
>>>
>>
>> Hmm, why don't we then represent the timestamp as long long in the first
>> place, rather than having it as time_t. That way, no overflow as you
>> mention could happen and the only problem for your machine then would be
>> to cope with the 32bit timestamp time function returns, which will break
>> libvirt and anything else anyway, but at least in an expected manner.
>
> I don't know. It's not me who wrote the code :-P But sure, we could do
> that. It's going to be just a broadening of my patch anyway.
>
> Michal
>
I guess I wasn't explicit in my last reply, you have an ACK if you also
squash changes mentioned above into your patch.
Erik
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list