Re: pull: hwclock 27 changes

[J William Piggott <elseifthen@gmx.com>]

On 01/25/2017 04:54 PM, Sami Kerola wrote:
> On Sun, 22 Jan 2017, J William Piggott wrote:
>> On 01/14/2017 05:51 PM, J William Piggott wrote:
>>> On 01/14/2017 04:34 AM, Sami Kerola wrote:
>>>> Preferably there should not be casts at all. But sometimes they are hard 
>>>> to avoid, and then one should do as few casts as possible to avoid cutting 
>>>> bits out.
>>>>
>>>> Think casting in terms of shape sorting toy. The more data is casted 
>>>> through none-matching types the more the original shape is modified to fit 
>>>> to storage where it is pushed.
>>>>
>>>> That is also the reason why casting to time_t in this case makes sense. 
>>>> While it might be that right now, on systems we happen to use, int and 
>>>> time_t are the same type there are no guarantees about other systems and 
>>>> future. In practical terms; casting exactly to matching storage type is 
>>>> the right way to avoid damaging data.
>>>
>>> What I'm trying to say is, assignment operators automatically convert
>>> the right operand to the type of the left operand; making your cast
>>> unnecessary. Try it, build hwclock with the cast. Now, remove the cast
>>> and build it. The resulting binaries are bit for bit identical.
>>>
>>> ISO C11:
>>> The type of an assignment expression is the type the left operand would have
>>> after lvalue conversion.
>>>
>>> In simple assignment (=), the value of the right operand is converted to
>>> the type of the assignment expression and replaces the value stored in
>>> the object designated by the left operand.
>>
>> It wasn't the intent of my previous message to be offensive in any way,
>> Sami. I was only trying to state my position using different language,
>> so as not to simply repeat myself.
>>
>> Also, I'm not continuing this topic to be argumentative. The reason is
>> for my own education. If my opinion is wrong, that is fine; I would like
>> to understand why, so as to improve my own coding.
>>
>> As I further read the ISO C standard, I'm more convinced of my belief.
>> It seems to me the compiler is required to use the type conversion
>> routine associated with assignment operators, because it must yield two
>> different results. A /qualified/ left operand type is stored, but the
>> evaluation of the assignment expression returns an /unqualified/ left
>> operand type. Since using the assignment operator's type conversion
>> routine is required (if I'm correct), the compiler would ignore any cast
>> on the results of the right hand operand for code optimization, yes?
>>
>> That seems to be true for my compiler, as the cast makes no difference
>> in the resulting binary.
>>
>> If anyone knows the correct answer to this, I am very interested in
>> learning it. Thank you in advance.
> 
> Hi William,
> 
> Sorry for late reply, I took a bit time off from reading / replying 
> emails.

No worries Sami. I thought you might have been angry at something I
wrote; it seem to unintentionally happen sometimes when talking across
cultural borders.

> 
> Correct the cast that is in place now is technically unnecessary. Value of 
> that cast is to remind return value type and storage type differ. Such 
> assignments can, at least in theory, cause bugs so being explicit about 
> them is a good thing. As a matter of fact anything that makes code easier 
> to understand is welcome.
> 
> That said now I doubt whether 'technically unnecessary' cast is really a 
> thing that clarifies, but confuses code reader. Comments would be nice, 
> meanwhile I will think about this.
> 

I understood the previous symbolism of the cast; to draw attention to
dropping the fractional part of a variable. I don't perceive any value
in using it on the floor(3) function.