Overflow issue

[Daniel P]

Suppose we have a signed integral value, and wish to assign it to an unsigned
integral value as follows:

-value if value is negative,
value otherwise

Now consider

int64_t n = std::numeric_limits<int64_t>::min();

uint64_t u = n < 0 ? static_cast<uint64_t>(-n) :
static_cast<uint64_t>(n); // (*)

The problem is that negation of std::numeric_limits<int64_t>::min() cannot
be represented in type 'int64_t',

min: -9223372036854775808
max: 9223372036854775807

Which makes sanitizers unhappy.

So, how to express (*)?

Thanks,
Daniel

[Barry Schwarz]

There are specific rules for assigning a negative value to an unsigned
object. Your issue is trivially resolved with a simple
u = n;

--
Remove del for email

[James Kuyper]

On 5/4/20 11:39 PM, Barry Schwarz wrote:
> There are specific rules for assigning a negative value to an unsigned
> object. Your issue is trivially resolved with a simple
> u = n;
>
> On Mon, 4 May 2020 19:53:26 -0700 (PDT), Daniel P
> <daniel...@gmail.com> wrote:
>
>> Suppose we have a signed integral value, and wish to assign it to an unsigned
>> integral value as follows:
>>
>> -value if value is negative,
>> value otherwise

If the value of n is negative, then the statement

u = n;

Assigns a value to u of std::numeric_limits<uint64_t>::max()+1+n (see
6.3.1.3p2). Daniel Parker specified that it should have the value of -n.

[James Kuyper]

uint64_t u = n < 0 ? -static_cast<uint64_t>(n) :
static_cast<uint64_t>(n);

[Daniel P]

Tried that, but in vs2019, C++17, that gives

Error unary minus operator applied to unsigned type, result still unsigned

[Daniel P]

But this compiles:

uint64_t u = n < 0 ? uint64_t(0)-static_cast<uint64_t>(n) :
static_cast<uint64_t>(n);

[Keith Thompson]

Daniel P <daniel...@gmail.com> writes:
> On Tuesday, May 5, 2020 at 12:11:38 AM UTC-4, James Kuyper wrote:

[...]

>> uint64_t u = n < 0 ? -static_cast<uint64_t>(n) :
>> static_cast<uint64_t>(n);
>
> Tried that, but in vs2019, C++17, that gives
>
> Error unary minus operator applied to unsigned type, result still unsigned

Applying a unary minus operator to an unsigned type is not an error.
It has well defined semantics. That might be a reasonable warning,
but there should be a way to tell VS2019 to shut up about it.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Daniel P]

On Tuesday, May 5, 2020 at 12:32:30 AM UTC-4, Keith Thompson wrote:
>
> Applying a unary minus operator to an unsigned type is not an error.
> It has well defined semantics. That might be a reasonable warning,
> but there should be a way to tell VS2019 to shut up about it.
>

Doesn't seem to be, it's reported as an error, not a warning. Anyway,
"uint64_t()-static_cast<uint64_t>(n)" compiles.

Thanks for your help, appreciated.
Daniel

[Keith Thompson]

I'm using VS2015. I tried this as an experiment:
unsigned int n = 42;
n = -n;
and got this:
5>main.cpp(36): error C2220: warning treated as error - no 'object' file generated
5>main.cpp(36): warning C4146: unary minus operator applied to unsigned type, result still unsigned

After a quick web search, this worked around it:
unsigned int n = 42;
#pragma warning(push)
#pragma warning(disable: 4146)
n = -n;
#pragma warning(pop)

(Of course this is specific to Visual Studio.)

[Bonita Montero]

> Now consider
> int64_t n = std::numeric_limits<int64_t>::min();
> uint64_t u = n < 0 ? static_cast<uint64_t>(-n) :
> static_cast<uint64_t>(n); // (*)

Use:
uint64_t u = n < 0 ? ~n : n;
You won't get an exact result, but the result is
_________symmetrical_________ .
Hrhr. ;-)

[Juha Nieminen]

Daniel P <daniel...@gmail.com> wrote:
>> uint64_t u = n < 0 ? -static_cast<uint64_t>(n) :
>> static_cast<uint64_t>(n);
>
> Tried that, but in vs2019, C++17, that gives
>
> Error unary minus operator applied to unsigned type, result still unsigned

Note that in 2's complement representation negation is the same as inverting
all the bits and adding 1. (Inverting all the bits can be done by xorring with
a value with all the bits set.) All target systems you care about will use
2's complement representation.

Of course unless the compiler is quite clever with its optimizations (which
some compilers might well be, ie. they recognize the pattern), that's two
operations instead of one. Not that it matters in most practical situations.

[Alf P. Steinbach]

On 05.05.2020 08:13, Keith Thompson wrote:
> Daniel P <daniel...@gmail.com> writes:
>> On Tuesday, May 5, 2020 at 12:32:30 AM UTC-4, Keith Thompson wrote:
>>> Applying a unary minus operator to an unsigned type is not an error.
>>> It has well defined semantics. That might be a reasonable warning,
>>> but there should be a way to tell VS2019 to shut up about it.
>>>
>> Doesn't seem to be, it's reported as an error, not a warning. Anyway,
>> "uint64_t()-static_cast<uint64_t>(n)" compiles.
>
> I'm using VS2015. I tried this as an experiment:
> unsigned int n = 42;
> n = -n;
> and got this:
> 5>main.cpp(36): error C2220: warning treated as error - no 'object' file generated
> 5>main.cpp(36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
>
> After a quick web search, this worked around it:
> unsigned int n = 42;
> #pragma warning(push)
> #pragma warning(disable: 4146)
> n = -n;
> #pragma warning(pop)
>
> (Of course this is specific to Visual Studio.)

Now the Visual C++ compiler phones home, generates executables that also
phone Microsoft, and emits diagnostics like that that are only useful
for idiots, if any, and that for everybody else are counter-productive.

One possible explanation is that they have let loose their horde of
idiot "programmers", the same ones that sprinkle "void main" all over
the MS documentation, on the Visual C++ compiler.

Another possible explanation is that in usual Microsoft fashion they're
sabotaging a "technology" that they want to discontinue. That's a bit
scary, if it's what happened. No Microsoft C++ compiler...

However, at the same time the compiler has become faster and more
standard-conforming.

I don't know any resolution of that paradox other than possibly the MS
left hand doesn't know what the MS right hand is doing, and vice versa.


- Alf

[Alf P. Steinbach]

On 05.05.2020 04:53, Daniel P wrote:
> Suppose we have a signed integral value, and wish to assign it to an unsigned
> integral value as follows:
>
> -value if value is negative,
> value otherwise

Except for the problem you note below, that's the `std::abs` function.

In C++03 the integer argument overload was available via `<stdlib.h>`.

In C++11 and later it's also available via `<math.h>`.

> Now consider
>
> int64_t n = std::numeric_limits<int64_t>::min();
>
> uint64_t u = n < 0 ? static_cast<uint64_t>(-n) :
> static_cast<uint64_t>(n); // (*)
>
> The problem is that negation of std::numeric_limits<int64_t>::min() cannot
> be represented in type 'int64_t',
>
> min: -9223372036854775808
> max: 9223372036854775807
>
> Which makes sanitizers unhappy.
>
> So, how to express (*)?

Off the cuff,

const uint64_t u = (n < 0? 1 + ~uint64_t( n ) : n);

Which assumes two's complement form, which is guaranteed in C++20 and later.

However, you really should be able to just use negation. The standard
guarantees the result. E.g. in C++17 §8.3.1/8:

"The negative of an unsigned quantity is computed by subtracting its
value from 2^n , where n is the number of bits in the promoted operand."

No matter that the C++17 wording is incorrect: it should be number of
value representation bits. But the intent is clear.

The practical resolution of that sillywarning problem is to disable it,
and hopefully Visual C++ compiler option "/wd4146" will do the trick.


- Alf

[Öö Tiib]

To silence your sanitizers use something like:

uint64_t u = n < 0 ? static_cast<uint64_t>(1 - n) + 1 :
static_cast<uint64_t>(n);

The compiler will optimize those pointless additions away
anyway.

[Öö Tiib]

I wrote a typo ... what I meant was

uint64_t u = n < 0 ? static_cast<uint64_t>(-(n + 1)) + 1 :
static_cast<uint64_t>(n);

[jacobnavia]

Le 05/05/2020 à 08:35, Alf P. Steinbach a écrit :
> Now the Visual C++ compiler phones home, generates executables that also
> phone Microsoft,

WHAT?

Can you specify a little bit more? A reference? Some proof?

Thanks in advance

[Tim Rentsch]

I suggest

uint64_t u = n < 0 ? 0ULL - n : n;

[James Kuyper]

On 5/5/20 2:13 AM, Keith Thompson wrote:
> Daniel P <daniel...@gmail.com> writes:
>> On Tuesday, May 5, 2020 at 12:32:30 AM UTC-4, Keith Thompson wrote:
>>> Applying a unary minus operator to an unsigned type is not an error.
>>> It has well defined semantics. That might be a reasonable warning,
>>> but there should be a way to tell VS2019 to shut up about it.
>>>
>> Doesn't seem to be, it's reported as an error, not a warning. Anyway,
>> "uint64_t()-static_cast<uint64_t>(n)" compiles.
>
> I'm using VS2015. I tried this as an experiment:
> unsigned int n = 42;
> n = -n;
> and got this:
> 5>main.cpp(36): error C2220: warning treated as error - no 'object' file generated
> 5>main.cpp(36): warning C4146: unary minus operator applied to unsigned type, result still unsigned

This is a prime example of the stupid warnings that are the reason I
don't like the policy which says "Must compile without warnings", and
the corresponding compiler option of treating warnings as errors. My
coding style shouldn't be determined by the vagaries of implementor's
warnings.

[Jorgen Grahn]

On Tue, 2020-05-05, James Kuyper wrote:
> On 5/5/20 2:13 AM, Keith Thompson wrote:

...

>> 5>main.cpp(36): error C2220: warning treated as error - no 'object' file generated
>> 5>main.cpp(36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
>
> This is a prime example of the stupid warnings that are the reason I
> don't like the policy which says "Must compile without warnings", and
> the corresponding compiler option of treating warnings as errors. My
> coding style shouldn't be determined by the vagaries of implementor's
> warnings.

I feel the same way, but it's not a very fashionable attitude. You
can easily be lumped with those who let their code accumulate hundreds
of warnings.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Ian Collins]

Just disable those you consider stupid. Do this in your projects
makefile of whatever you use and include comments explaining why the
warnings are disabled.

--
Ian.

[James Kuyper]

A policy that says "Must compile without warnings" is rendered very
nearly meaningless if you're free to turn off any warnings you don't
like. A meaningless requirement like that is one I can live with, but I
still think it's wrong-headed. Bad warnings should be turned off, and
sensible warnings should be turned on - but they are warnings, not
errors, which means that sometimes they reflect a serious problem, and
sometimes they don't. Each warning should be considered on a case by
case basis, to decide whether or not the warning is justified.

[Ian Collins]

I'm not sure what you are arguing here, you say "Must compile without

warnings" is rendered very nearly meaningless if you're free to turn off

any warnings you don't like but then advocate turning bad warnings off!

In this case, the VS2019 warning is a bad warning.

--
Ian.

[Jorgen Grahn]

Surely he means (classes of) warnings which everyone in the project
agrees they are never interested in, in any context, are "bad".

> In this case, the VS2019 warning is a bad warning.

Hard to tell though; maybe C4146 is a lifesaver in 2% of the cases?

[James Kuyper]

On 5/6/20 2:57 AM, Ian Collins wrote:
> On 06/05/2020 16:00, James Kuyper wrote:

...

>> A policy that says "Must compile without warnings" is rendered very
>> nearly meaningless if you're free to turn off any warnings you don't
>> like. A meaningless requirement like that is one I can live with, but I
>> still think it's wrong-headed. Bad warnings should be turned off, and
>> sensible warnings should be turned on - but they are warnings, not
>> errors, which means that sometimes they reflect a serious problem, and
>> sometimes they don't. Each warning should be considered on a case by
>> case basis, to decide whether or not the warning is justified.
>
> I'm not sure what you are arguing here, you say "Must compile without
> warnings" is rendered very nearly meaningless if you're free to turn off
> any warnings you don't like but then advocate turning bad warnings off!

I thought it was clear that I don't approve of that policy - therefore,
rendering it meaningless would be an improvement from my point of view.

But my comments about turning off bad warnings was not in the context of
that policy, but of a different one. Instead of "Treat all warnings as
errors", my policy is to "Treat all warnings as warnings - don't ignore
them, but don't automatically change your code to avoid them. Use
judgement to decide whether or not to modify your code to avoid
triggering any particular warning." In that context, also using your
judgement to decide which warnings to turn on and off is simply part and
parcel of the same attitude. A warning is a good one if it frequently
brings real problems to your attention. A warning is a bad one if it
frequently brings non-problems to your attention. Real-life warnings are
always a mixture of the two.

[Keith Thompson]

Not disagreeing with anything you've said, but another viable approach
is to treat all warnings as errors and modify code as needed to avoid
any warnings. This relies on the good taste of the compiler writers.
It assumes that, even if some warnings (like Visual Studio's warning
about unary "-" on an unsigned type) might not be sensible, there are
ways to work around them without doing too much violence to the code.
If, for example, I can modify my code to avoid unary "-" on an unsigned
type *and* the resulting code is still reasonably clear, it might be
worth doing.

This can work if your development environment is reasonably stable over
time (as is the case for my current $DAYJOB). It's probably not viable
if you need to support multiple implementations, for example if you need
your code to build correctly on, say, Linux and Windows. It can be
simpler to follow a rule than to decide when it's ok to add exceptions.

[James Kuyper]

On 5/6/20 4:06 PM, Keith Thompson wrote:
> James Kuyper <james...@alumni.caltech.edu> writes:
...

>> But my comments about turning off bad warnings was not in the context of
>> that policy, but of a different one. Instead of "Treat all warnings as
>> errors", my policy is to "Treat all warnings as warnings - don't ignore
>> them, but don't automatically change your code to avoid them. Use
>> judgement to decide whether or not to modify your code to avoid
>> triggering any particular warning." In that context, also using your
>> judgement to decide which warnings to turn on and off is simply part and
>> parcel of the same attitude. A warning is a good one if it frequently
>> brings real problems to your attention. A warning is a bad one if it
>> frequently brings non-problems to your attention. Real-life warnings are
>> always a mixture of the two.
>
> Not disagreeing with anything you've said, but another viable approach
> is to treat all warnings as errors and modify code as needed to avoid
> any warnings. This relies on the good taste of the compiler writers.

That's the key point. I'm not willing to rely on that - and this thread
provides an example of why.

I've usually seen the policy of treating all warnings as errors promoted
as an essential best-practice, without any acknowledgment that the bad
taste of some compiler writers could make such a policy problematic.

[Ian Collins]

In our case, someone just pings the team with a "hey, I'm getting this
warning" message, we kick it around and decide to either change the code
or suppress the warning. Because we use VS, clang and gcc these
discussions can be entertaining!

--
Ian

[Juha Nieminen]

James Kuyper <james...@alumni.caltech.edu> wrote:
>> Just disable those you consider stupid. Do this in your projects
>> makefile of whatever you use and include comments explaining why the
>> warnings are disabled.
>
> A policy that says "Must compile without warnings" is rendered very
> nearly meaningless if you're free to turn off any warnings you don't
> like. A meaningless requirement like that is one I can live with, but I
> still think it's wrong-headed. Bad warnings should be turned off, and
> sensible warnings should be turned on - but they are warnings, not
> errors, which means that sometimes they reflect a serious problem, and
> sometimes they don't. Each warning should be considered on a case by
> case basis, to decide whether or not the warning is justified.

I once encountered a project where the author(s) had taken the "must
compile without warnings" way too seriously. Not only was the
compiler option -Werror used (obviously) in addition to your
standard -Wall -Wextra -pedantic, but the author(s) had gone the
extra mile of wading through gcc's documentation and turned on every
single warning flag that was not already turned on by those generic
options.

Problem was, when I tried to compile the project with whaver version of
gcc happened to be installed in my system at the time, those additional
super-pedantic warning flags (that are not turned on by -Wall nor
-Wextra) were causing warnings *from the standard library headers*.
Which of course stopped the project from compiling because of -Werror.

There are policies and there's taking policies too far.

[Alf P. Steinbach]

Modern compilers have ways to suppress warnings from system headers.

---

For (modern) g++ that's the default, and you have to explicitly enable
warnings from system headers if you're interested in them:

<url:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wsystem-headers>
«
-Wsystem-headers
Print warning messages for constructs found in system header files.
Warnings from system headers are normally suppressed, on the assumption
that they usually do not indicate real problems and would only make the
compiler output harder to read. Using this command-line option tells GCC
to emit warnings from system headers as if they occurred in user code.
However, note that using -Wall in conjunction with this option does not
warn about unknown pragmas in system headers—for that, -Wunknown-pragmas
must also be used.
»

To designate a directory as containing system headers,

<url:
https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#Directory-Options>
«
The -isystem and -idirafter options also mark the directory as a system
directory, so that it gets the same special treatment that is applied to
the standard system directories.
»

---

Visual C++ only recently gained the ability to let the user
differentiate between system headers and headers in general. As of
Visual C++ 2019 it's still an experimental feature. I.e., the details
may possibly still change.

In typical Microsoft fashion it's done via an excessively verbose COBOL
like syntax with no reasonable defaults, no doubt either designed to
look impressive to some non-technical MS manager, or designed by such.

[In the Windows Cmd interpreter:]
«
> cl /? 2>&1 | find /i "external"
/FC use full pathnames in diagnostics /H<num> max external name length
/external:I <path> - location of external headers
/external:env:<var> - environment variable with locations of
external headers
/external:anglebrackets - treat all headers included via <> as external
/external:W<n> - warning level for external headers
/external:templates[-] - evaluate warning level across template
instantiation chain
»

Some explanation and background: <url:
https://devblogs.microsoft.com/cppblog/broken-warnings-theory/>.

> There are policies and there's taking policies too far.

Yes, agreed. :)

- Alf

[Alf P. Steinbach]

Thread started in 2016:
<url:
https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_adding_telemetry_function_calls_to/>
«
Visual Studio adding telemetry function calls to binary?

[–]spongo2MSVC Dev Manager 86 points 3 years ago
hi everyone. This is Steve Carroll, the dev manager for the Visual C++ team.

Tl;dr: thanks folks for the feedback. Our team will be removing this
from our static libs in Update 3.

Our intent was benign – our desire was to build a framework that will
help investigate performance problems and
»


Thread started in 2018, about editor and IDE:

<url:
https://www.reddit.com/r/privacy/comments/80d8wu/just_realised_that_visual_studio_code_sends/>
«
Just realised that Visual Studio Code sends telemetry data do Microsoft
by default. Here how to disable it. (self.privacy)

submitted 2 years ago by misterolupo

As a reminder, if you are a programmer using VS Studio, you can disable
the telemetry by entering these entries in your user settings:

{
"telemetry.enableCrashReporter": false,
"telemetry.enableTelemetry": false
}
Using a FOSS alternative would be better, but I thought this might be
useful to somebody out there.

---

[–]slayerizer 10 points 2 years ago
The .NET core runtime also sends telemetry to Microsoft by default. If
you create a project with it, you need to disable that also.
»



There was a recent (two or three months ago) thread about telemetry, or
at least the functions for telemetry, discovered in an executable
generated by Visual C++ 2019. Simple googling didn't find it now.


- Alf

[Manfred]

I honestly thought this was a joke.
It's scary indeed, thanks for sharing.

[David Brown]

I agree with this approach. Compilers vary significantly in how they
handle warnings, especially when left in defaults or general "-Wall"
settings. My preference is to be explicit about the warnings used -
usually as flags in a Makefile. But on occasions where I know some code
will trigger warnings that I normally prefer to have on, I use explicit
pragmas in the code. (The same applies to any specific optimisation
settings, such as if I am working with third-party code that does silly
things with pointer casts and needs "-fno-strict-alias" for gcc.)

Warnings are primarily of importance while developing code, rather than
for building it on different systems. So even for portable code it is
usually fine to have gcc-specific warning flags and pragmas if you are
using gcc as your main development compiler, and say that for building
on other tools you turn off warnings.

[David Brown]

You can't base "best practice" on whatever a compiler chooses by default
or in common flag groups (like "-Wall"). But you /can/ have it based on
your company or project specific choice of warnings. Static analysis
is, IMHO, an important part of any serious development practice. It
needs to be considered and used sensibly and appropriately, not as in a
shotgun "enable everything" way.

[Keith Thompson]

David Brown <david...@hesbynett.no> writes:
> On 06/05/2020 22:06, Keith Thompson wrote:

[...]

>> Not disagreeing with anything you've said, but another viable approach
>> is to treat all warnings as errors and modify code as needed to avoid
>> any warnings. This relies on the good taste of the compiler writers.
>> It assumes that, even if some warnings (like Visual Studio's warning
>> about unary "-" on an unsigned type) might not be sensible, there are
>> ways to work around them without doing too much violence to the code.
>> If, for example, I can modify my code to avoid unary "-" on an unsigned
>> type *and* the resulting code is still reasonably clear, it might be
>> worth doing.
>>
>> This can work if your development environment is reasonably stable over
>> time (as is the case for my current $DAYJOB). It's probably not viable
>> if you need to support multiple implementations, for example if you need
>> your code to build correctly on, say, Linux and Windows. It can be
>> simpler to follow a rule than to decide when it's ok to add exceptions.
>
> I agree with this approach. Compilers vary significantly in how they
> handle warnings, especially when left in defaults or general "-Wall"
> settings. My preference is to be explicit about the warnings used -
> usually as flags in a Makefile. But on occasions where I know some
> code will trigger warnings that I normally prefer to have on, I use
> explicit pragmas in the code. (The same applies to any specific
> optimisation settings, such as if I am working with third-party code
> that does silly things with pointer casts and needs
> "-fno-strict-alias" for gcc.)

Sure, but I was thinking primarily about writing the code so it
doesn't trigger the warning in the first place rather than using
a compiler-specific pragma. For example, if this:
unsigned x = 42;
x = -x;
triggers a warning because I used unary "-" on an unsigned type, I might
change it to:
x = UINT_MAX-x+1;
(Depending on the context, that might even be clearer.)

> Warnings are primarily of importance while developing code, rather
> than for building it on different systems. So even for portable code
> it is usually fine to have gcc-specific warning flags and pragmas if
> you are using gcc as your main development compiler, and say that for
> building on other tools you turn off warnings.

The most common case where I've run into this at work is when I've
added a temporary function while debugging and then commented out a
call to it, causing a (fatal) warning that the function is unused.
It's easy enough to comment out the function definition and rebuild.

[David Brown]

I'd say write the code in the clearest way. I am a big fan of warnings
in compilers, and use them a lot - but if a warning means you have to
write code in an awkward way, then this must be balanced carefully
against the warnings use in preventing accidental mistakes. If you
think you are likely to make mistakes that are caught by this warning,
then it is worth enabling it even if it means occasionally writing
awkward looking code (or warning disables) for the rare occasions when
you need it. If you don't see it as a likely cause of mistakes and
regularly want to negate unsigned types, then disable the warning
completely.

>
>> Warnings are primarily of importance while developing code, rather
>> than for building it on different systems. So even for portable code
>> it is usually fine to have gcc-specific warning flags and pragmas if
>> you are using gcc as your main development compiler, and say that for
>> building on other tools you turn off warnings.
>
> The most common case where I've run into this at work is when I've
> added a temporary function while debugging and then commented out a
> call to it, causing a (fatal) warning that the function is unused.
> It's easy enough to comment out the function definition and rebuild.
>

Yes. Or add "__attribute__((unused))" to the function (for gcc - other
compilers are likely to have their own methods).