News for hackers. Stuff that matters.

A comment on A Special Kind of Hell: intmax_t in C and C++. Parent comment

Re:A Special Kind of Hell: intmax_t in C and C++ by MaulingMonkey on Sunday December 06, 2020 @10:39AM (#25324171)
It's absolutely insanity. A cruel question I came up with the other day, based on it - What is the result of:

    std::is_signed<decltype(1L * 2U)>()

?
[ Parent | on HN ]
Re:A Special Kind of Hell: intmax_t in C and C++ by folmar on Sunday December 06, 2020 @02:14PM (#25325818)
Why should it be cruel? Promotions are a part of life of an integer in C.
[ Parent | on HN ]
Re:A Special Kind of Hell: intmax_t in C and C++ by MaulingMonkey on Sunday December 06, 2020 @07:35PM (#25328107)
Even programmers who are roughly aware of integral promotion rules may not have connected all the dots to realize the answer is implementation dependent.

If sizeof(long) == sizeof(unsigned int), 1L * 2U results in an unsigned int, meaning the result is "false".

If sizeof(long) > sizeof(unsigned int), 1L * 2U result in a signed long, meaning the result is "true".

[ Parent | on HN ]
Re:A Special Kind of Hell: intmax_t in C and C++ by mehrdadn on Sunday December 06, 2020 @09:16PM (#25328733)
Wow that is cruel! Somehow I just assumed int would get promoted to long regardless of their size difference. That this isn't the case almost seems like a language defect!
[ Parent | on HN ]