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. -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
