On 2/3/2024 10:41 PM, Bonita Montero wrote:
> Am 04.02.2024 um 06:30 schrieb Chris M. Thomasson:
>> On 2/3/2024 8:58 PM, Bonita Montero wrote:
>>> Am 03.02.2024 um 21:05 schrieb Chris M. Thomasson:
>>>
>>>> Hummm... You threw me for a loop here... What exactly do you mean?
>>>> Show me a condensed example. Those warnings are there for a
>>>> reason... You really need to model it in a race detector. Relacy is
>>>> a fun one.
>>>
>>> The code doesn't need any race detector, the synchronization part is
>>> trivial.
>>>
>>
>> What happens if you turn off all of those very important warnings?
>
> What a question ...
> I get incorrect warnings while compiling.

Why are they incorrect, according to you? Boil it down to a simple
example where these warnings are incorrect. That way I can reproduce it
on my side.

On 2/3/2024 10:41 PM, Bonita Montero wrote:
> Am 04.02.2024 um 06:30 schrieb Chris M. Thomasson:
>> On 2/3/2024 8:58 PM, Bonita Montero wrote:
>>> Am 03.02.2024 um 21:05 schrieb Chris M. Thomasson:
>>>
>>>> Hummm... You threw me for a loop here... What exactly do you mean?
>>>> Show me a condensed example. Those warnings are there for a
>>>> reason... You really need to model it in a race detector. Relacy is
>>>> a fun one.
>>>
>>> The code doesn't need any race detector, the synchronization part is
>>> trivial.
>>>
>>
>> What happens if you turn off all of those very important warnings?
>
> What a question ...
> I get incorrect warnings while compiling.

https://youtu.be/hAMQIvEtcJM

Am 04.02.2024 um 22:59 schrieb Chris M. Thomasson:

> Why are they incorrect, according to you? ...

No, according to what they should warn for.

On 2/5/2024 12:01 AM, Bonita Montero wrote:
> Am 04.02.2024 um 22:59 schrieb Chris M. Thomasson:
>
>> Why are they incorrect, according to you? ...
>
> No, according to what they should warn for.
>

Can you create a little self-contained example that shows these warnings?

Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:

> Can you create a little self-contained example that shows these warnings?

Make the pragmas commented and look what the IDE shows as warnings.

On 2/5/2024 10:12 PM, Bonita Montero wrote:
> Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:
>
>> Can you create a little self-contained example that shows these warnings?
>
> Make the pragmas commented and look what the IDE shows as warnings.
>

What is in:
______________________
#include <cassert>
#include "thread_pool.h"
#include "invoke_on_destruct.h"
______________________

?

On 2/5/2024 10:34 PM, Chris M. Thomasson wrote:
> On 2/5/2024 10:12 PM, Bonita Montero wrote:
>> Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:
>>
>>> Can you create a little self-contained example that shows these
>>> warnings?
>>
>> Make the pragmas commented and look what the IDE shows as warnings.
>>
>
> What is in:
> ______________________
> #include <cassert>
> #include "thread_pool.h"
> #include "invoke_on_destruct.h"
> ______________________
>
> ?

You have some issues here. These warnings are not for kicks and giggles,
so to speak. If these warnings are wrong, you need to file a bug report
to the MSVC team.

On 2/5/2024 10:12 PM, Bonita Montero wrote:
> Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:
>
>> Can you create a little self-contained example that shows these warnings?
>
> Make the pragmas commented and look what the IDE shows as warnings.
>

Think about getting a warning free compile. Think about what these
warnings actually mean. If you find a bug, report it to the MSVC team.

On 2/5/2024 10:34 PM, Chris M. Thomasson wrote:
> On 2/5/2024 10:12 PM, Bonita Montero wrote:
>> Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:
>>
>>> Can you create a little self-contained example that shows these
>>> warnings?
>>
>> Make the pragmas commented and look what the IDE shows as warnings.
>>
>
> What is in:
> ______________________
> #include <cassert>
> #include "thread_pool.h"

> #include "invoke_on_destruct.h"
^^^^^^^^^^^^^^^^^^^^^^

What is that for?

> ______________________
>
> ?

Am 06.02.2024 um 07:34 schrieb Chris M. Thomasson:
> On 2/5/2024 10:12 PM, Bonita Montero wrote:
>> Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:
>>
>>> Can you create a little self-contained example that shows these
>>> warnings?
>>
>> Make the pragmas commented and look what the IDE shows as warnings.
>>
>
> What is in:
> ______________________
> #include <cassert>
> #include "thread_pool.h"

The header I posted.

> #include "invoke_on_destruct.h"

Sth. like experimental::scope_exit, this is my code:

#pragma once
#include <utility>

template<typename Fn>
requires requires( Fn fn ) { { fn() }; }
struct invoke_on_destruct
{ private:
Fn m_fn;
bool m_enabled;
public:
invoke_on_destruct( Fn &&fn ) :
m_fn( std::forward<Fn>( fn ) ),
m_enabled( true )
{
}
~invoke_on_destruct()
{
if( m_enabled )
m_fn();
}
void operator ()()
{
if( m_enabled )
m_enabled = false,
m_fn();
}
void disable()
{
m_enabled = false;
}
invoke_on_destruct &enable()
{
m_enabled = true;
return *this;
}
};

Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:

> Think about getting a warning free compile. Think about what these
> warnings actually mean. If you find a bug, report it to the MSVC team.

Where the compiler warns me there are no errors,
these are false warnings.

Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:
> On 2/5/2024 10:12 PM, Bonita Montero wrote:
>> Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:
>>
>>> Can you create a little self-contained example that shows these
>>> warnings?
>>
>> Make the pragmas commented and look what the IDE shows as warnings.
>>
>
> Think about getting a warning free compile. Think about what these
> warnings actually mean. If you find a bug, report it to the MSVC team.

Try this ...

void fn( unique_lock<mutex> &lock )
{ assert(lock);
lock.unlock();
}

.... and you'll get a warning.

On 2/6/2024 2:17 AM, Bonita Montero wrote:
> Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:
>
>> Think about getting a warning free compile. Think about what these
>> warnings actually mean. If you find a bug, report it to the MSVC team.
>
> Where the compiler warns me there are no errors,
> these are false warnings.

Well, that deserves a bug report?

On 2/6/2024 5:01 AM, Bonita Montero wrote:
> Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:
>> On 2/5/2024 10:12 PM, Bonita Montero wrote:
>>> Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:
>>>
>>>> Can you create a little self-contained example that shows these
>>>> warnings?
>>>
>>> Make the pragmas commented and look what the IDE shows as warnings.
>>>
>>
>> Think about getting a warning free compile. Think about what these
>> warnings actually mean. If you find a bug, report it to the MSVC team.
>
> Try this ...
>
> void fn( unique_lock<mutex> &lock )
> {
>     assert(lock);
>     lock.unlock();
> }
>
> ... and you'll get a warning.
>

Fwiw, I get no warning with:

{
std::unique_lock<std::mutex> lock(m_mutex);
assert(lock);
lock.unlock();
//lock.unlock(); // this throws an exception.
}

The interesting part is the code for std::unique_lock:

~unique_lock() noexcept {
if (_Owns) {
_Pmtx->unlock();
}
}

I was wondering why std::unique_lock did not try to unlock it twice in
the dtor. Well, the code for std::~unique_lock that MSVC is using
answers my question. Its that _Owns variable. Humm...

Am 06.02.2024 um 20:55 schrieb Chris M. Thomasson:
> On 2/6/2024 2:17 AM, Bonita Montero wrote:
>> Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:
>>
>>> Think about getting a warning free compile. Think about what these
>>> warnings actually mean. If you find a bug, report it to the MSVC team.
>>
>> Where the compiler warns me there are no errors,
>> these are false warnings.
>
> Well, that deserves a bug report?

I won't file it.

Am 06.02.2024 um 21:07 schrieb Chris M. Thomasson:
> On 2/6/2024 5:01 AM, Bonita Montero wrote:
>> Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:
>>> On 2/5/2024 10:12 PM, Bonita Montero wrote:
>>>> Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:
>>>>
>>>>> Can you create a little self-contained example that shows these
>>>>> warnings?
>>>>
>>>> Make the pragmas commented and look what the IDE shows as warnings.
>>>>
>>>
>>> Think about getting a warning free compile. Think about what these
>>> warnings actually mean. If you find a bug, report it to the MSVC team.
>>
>> Try this ...
>>
>> void fn( unique_lock<mutex> &lock )
>> {
>>      assert(lock);
>>      lock.unlock();
>> }
>>
>> ... and you'll get a warning.
>>
>
> Fwiw, I get no warning with:
>
> {
>     std::unique_lock<std::mutex> lock(m_mutex);
>     assert(lock);
>     lock.unlock();
>     //lock.unlock(); // this throws an exception.
> }

That's sth. totally different. My function has the pre-condition
that it inherits the lock of the calling function and sometimes
it unlocks it.

> The interesting part is the code for std::unique_lock:
>
> ~unique_lock() noexcept {
>     if (_Owns) {
>         _Pmtx->unlock();
>     }
> }
>
>
> I was wondering why std::unique_lock did not try to unlock it twice in
> the dtor. Well, the code for std::~unique_lock that MSVC is using
> answers my question. Its that _Owns variable. Humm...

On 2/7/2024 8:15 AM, Bonita Montero wrote:
> Am 06.02.2024 um 21:07 schrieb Chris M. Thomasson:
>> On 2/6/2024 5:01 AM, Bonita Montero wrote:
>>> Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:
>>>> On 2/5/2024 10:12 PM, Bonita Montero wrote:
>>>>> Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:
>>>>>
>>>>>> Can you create a little self-contained example that shows these
>>>>>> warnings?
>>>>>
>>>>> Make the pragmas commented and look what the IDE shows as warnings.
>>>>>
>>>>
>>>> Think about getting a warning free compile. Think about what these
>>>> warnings actually mean. If you find a bug, report it to the MSVC team.
>>>
>>> Try this ...
>>>
>>> void fn( unique_lock<mutex> &lock )
>>> {
>>>      assert(lock);
>>>      lock.unlock();
>>> }
>>>
>>> ... and you'll get a warning.
>>>
>>
>> Fwiw, I get no warning with:
>>
>> {
>>      std::unique_lock<std::mutex> lock(m_mutex);
>>      assert(lock);
>>      lock.unlock();
>>      //lock.unlock(); // this throws an exception.
>> }
>
> That's sth. totally different. My function has the pre-condition
> that it inherits the lock of the calling function and sometimes
> it unlocks it.

Ahhh. I got them with:
__________________________________
namespace ct
{ struct mutex_test
{
std::mutex m_mutex;

void
bar(std::unique_lock<std::mutex>& lock)
{
assert(lock); // better be locked!
lock.unlock();
}

void
foo()
{
std::unique_lock<std::mutex> lock(m_mutex);
bar(lock); // beware. unlocks the damn thing!
lock.lock(); // okay...
}
};
} __________________________________

Give the warnings:
__________________________________
Severity Code Description Project File Line Suppression State Details
Warning C26115 Failing to release lock 'this->m_mutex' in function
'ct::mutex_test::foo'. ct_threads
D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp 26

Warning C26111 Caller failing to release lock 'this->m_mutex' before
calling function 'std::unique_lock<std::mutex>::lock'. ct_threads
D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp 26
Warning C26110 Caller failing to hold lock 'lock' before calling
function 'std::unique_lock<std::mutex>::unlock'. ct_threads
D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp 18
__________________________________

You just have to be very careful with this type of logic. These warnings
elude to that.

[...]

On 2/7/2024 8:13 AM, Bonita Montero wrote:
> Am 06.02.2024 um 20:55 schrieb Chris M. Thomasson:
>> On 2/6/2024 2:17 AM, Bonita Montero wrote:
>>> Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:
>>>
>>>> Think about getting a warning free compile. Think about what these
>>>> warnings actually mean. If you find a bug, report it to the MSVC team.
>>>
>>> Where the compiler warns me there are no errors,
>>> these are false warnings.
>>
>> Well, that deserves a bug report?
>
> I won't file it.
>

Maybe you should. However, the warnings do flag some "sketchy" things
are going on.

Am 07.02.2024 um 21:38 schrieb Chris M. Thomasson:
> On 2/7/2024 8:15 AM, Bonita Montero wrote:
>> Am 06.02.2024 um 21:07 schrieb Chris M. Thomasson:
>>> On 2/6/2024 5:01 AM, Bonita Montero wrote:
>>>> Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:
>>>>> On 2/5/2024 10:12 PM, Bonita Montero wrote:
>>>>>> Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:
>>>>>>
>>>>>>> Can you create a little self-contained example that shows these
>>>>>>> warnings?
>>>>>>
>>>>>> Make the pragmas commented and look what the IDE shows as warnings.
>>>>>>
>>>>>
>>>>> Think about getting a warning free compile. Think about what these
>>>>> warnings actually mean. If you find a bug, report it to the MSVC team.
>>>>
>>>> Try this ...
>>>>
>>>> void fn( unique_lock<mutex> &lock )
>>>> {
>>>>      assert(lock);
>>>>      lock.unlock();
>>>> }
>>>>
>>>> ... and you'll get a warning.
>>>>
>>>
>>> Fwiw, I get no warning with:
>>>
>>> {
>>>      std::unique_lock<std::mutex> lock(m_mutex);
>>>      assert(lock);
>>>      lock.unlock();
>>>      //lock.unlock(); // this throws an exception.
>>> }
>>
>> That's sth. totally different. My function has the pre-condition
>> that it inherits the lock of the calling function and sometimes
>> it unlocks it.
>
> Ahhh. I got them with:
> __________________________________
> namespace ct
> {
>     struct mutex_test
>     {
>         std::mutex m_mutex;
>
>         void
>         bar(std::unique_lock<std::mutex>& lock)
>         {
>             assert(lock); // better be locked!
>             lock.unlock();
>         }
>
>         void
>         foo()
>         {
>             std::unique_lock<std::mutex> lock(m_mutex);
>             bar(lock); // beware. unlocks the damn thing!
>             lock.lock(); // okay...
>         }
>     };
> }
> __________________________________
>
> Give the warnings:
> __________________________________
> Severity    Code    Description    Project    File    Line
> Suppression State    Details
> Warning    C26115    Failing to release lock 'this->m_mutex' in function
> 'ct::mutex_test::foo'.    ct_threads
> D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp    26
>
> Warning    C26111    Caller failing to release lock 'this->m_mutex'
> before calling function 'std::unique_lock<std::mutex>::lock'.
> ct_threads D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp    26
>
> Warning    C26110    Caller failing to hold lock 'lock' before calling
> function 'std::unique_lock<std::mutex>::unlock'.    ct_threads
> D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp    18
> __________________________________
>
>
> You just have to be very careful with this type of logic. These warnings
> elude to that.

Can't you read my code ?
That's still sth. completely different than what I did.

On 2/8/2024 4:07 AM, Bonita Montero wrote:
> Am 07.02.2024 um 21:38 schrieb Chris M. Thomasson:
>> On 2/7/2024 8:15 AM, Bonita Montero wrote:
>>> Am 06.02.2024 um 21:07 schrieb Chris M. Thomasson:
>>>> On 2/6/2024 5:01 AM, Bonita Montero wrote:
>>>>> Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:
>>>>>> On 2/5/2024 10:12 PM, Bonita Montero wrote:
>>>>>>> Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:
>>>>>>>
>>>>>>>> Can you create a little self-contained example that shows these
>>>>>>>> warnings?
>>>>>>>
>>>>>>> Make the pragmas commented and look what the IDE shows as warnings.
>>>>>>>
>>>>>>
>>>>>> Think about getting a warning free compile. Think about what these
>>>>>> warnings actually mean. If you find a bug, report it to the MSVC
>>>>>> team.
>>>>>
>>>>> Try this ...
>>>>>
>>>>> void fn( unique_lock<mutex> &lock )
>>>>> {
>>>>>      assert(lock);
>>>>>      lock.unlock();
>>>>> }
>>>>>
>>>>> ... and you'll get a warning.
>>>>>
>>>>
>>>> Fwiw, I get no warning with:
>>>>
>>>> {
>>>>      std::unique_lock<std::mutex> lock(m_mutex);
>>>>      assert(lock);
>>>>      lock.unlock();
>>>>      //lock.unlock(); // this throws an exception.
>>>> }
>>>
>>> That's sth. totally different. My function has the pre-condition
>>> that it inherits the lock of the calling function and sometimes
>>> it unlocks it.
>>
>> Ahhh. I got them with:
>> __________________________________
>> namespace ct
>> {
>>      struct mutex_test
>>      {
>>          std::mutex m_mutex;
>>
>>          void
>>          bar(std::unique_lock<std::mutex>& lock)
>>          {
>>              assert(lock); // better be locked!
>>              lock.unlock();
>>          }
>>
>>          void
>>          foo()
>>          {
>>              std::unique_lock<std::mutex> lock(m_mutex);
>>              bar(lock); // beware. unlocks the damn thing!
>>              lock.lock(); // okay...
>>          }
>>      };
>> }
>> __________________________________
>>
>> Give the warnings:
>> __________________________________
>> Severity    Code    Description    Project    File    Line Suppression
>> State    Details
>> Warning    C26115    Failing to release lock 'this->m_mutex' in
>> function 'ct::mutex_test::foo'.    ct_threads
>> D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp    26
>>
>> Warning    C26111    Caller failing to release lock 'this->m_mutex'
>> before calling function 'std::unique_lock<std::mutex>::lock'.
>> ct_threads D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp    26
>>
>> Warning    C26110    Caller failing to hold lock 'lock' before calling
>> function 'std::unique_lock<std::mutex>::unlock'.    ct_threads
>> D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp    18
>> __________________________________
>>
>>
>> You just have to be very careful with this type of logic. These
>> warnings elude to that.
>
> Can't you read my code ?

Yes.

> That's still sth. completely different than what I did.
>

I just wanted to get MSVC to pop out those "false" warnings. Mission
accomplished.

On 2/8/2024 4:07 AM, Bonita Montero wrote:
> Am 07.02.2024 um 21:38 schrieb Chris M. Thomasson:
>> On 2/7/2024 8:15 AM, Bonita Montero wrote:
>>> Am 06.02.2024 um 21:07 schrieb Chris M. Thomasson:
>>>> On 2/6/2024 5:01 AM, Bonita Montero wrote:
>>>>> Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:
>>>>>> On 2/5/2024 10:12 PM, Bonita Montero wrote:
>>>>>>> Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:
>>>>>>>
>>>>>>>> Can you create a little self-contained example that shows these
>>>>>>>> warnings?
>>>>>>>
>>>>>>> Make the pragmas commented and look what the IDE shows as warnings.
>>>>>>>
>>>>>>
>>>>>> Think about getting a warning free compile. Think about what these
>>>>>> warnings actually mean. If you find a bug, report it to the MSVC
>>>>>> team.
>>>>>
>>>>> Try this ...
>>>>>
>>>>> void fn( unique_lock<mutex> &lock )
>>>>> {
>>>>>      assert(lock);
>>>>>      lock.unlock();
>>>>> }
>>>>>
>>>>> ... and you'll get a warning.
>>>>>
>>>>
>>>> Fwiw, I get no warning with:
>>>>
>>>> {
>>>>      std::unique_lock<std::mutex> lock(m_mutex);
>>>>      assert(lock);
>>>>      lock.unlock();
>>>>      //lock.unlock(); // this throws an exception.
>>>> }
>>>
>>> That's sth. totally different. My function has the pre-condition
>>> that it inherits the lock of the calling function and sometimes
>>> it unlocks it.
>>
>> Ahhh. I got them with:
>> __________________________________
>> namespace ct
>> {
>>      struct mutex_test
>>      {
>>          std::mutex m_mutex;
>>
>>          void
>>          bar(std::unique_lock<std::mutex>& lock)
>>          {
>>              assert(lock); // better be locked!
>>              lock.unlock();
>>          }
>>
>>          void
>>          foo()
>>          {
>>              std::unique_lock<std::mutex> lock(m_mutex);
>>              bar(lock); // beware. unlocks the damn thing!
>>              lock.lock(); // okay...
>>          }
>>      };
>> }
>> __________________________________
>>
>> Give the warnings:
>> __________________________________
>> Severity    Code    Description    Project    File    Line Suppression
>> State    Details
>> Warning    C26115    Failing to release lock 'this->m_mutex' in
>> function 'ct::mutex_test::foo'.    ct_threads
>> D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp    26
>>
>> Warning    C26111    Caller failing to release lock 'this->m_mutex'
>> before calling function 'std::unique_lock<std::mutex>::lock'.
>> ct_threads D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp    26
>>
>> Warning    C26110    Caller failing to hold lock 'lock' before calling
>> function 'std::unique_lock<std::mutex>::unlock'.    ct_threads
>> D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp    18
>> __________________________________
>>
>>
>> You just have to be very careful with this type of logic. These
>> warnings elude to that.
>
> Can't you read my code ?
> That's still sth. completely different than what I did.
>

Keep in mind that your code disables those warnings. So, be sure to turn
them back on for any and all user code!

Am 08.02.2024 um 22:28 schrieb Chris M. Thomasson:

> Keep in mind that your code disables those warnings. So, be sure to turn
> them back on for any and all user code!

Locking and unlocking mutexes is trivial and I don't need any addtional
aid for that. And MSVC runtime gives me a debug message if I try to
unlock a non-locked mutex; that's sufficient for me. And the shown
code is never trapped in that way.

On 2/9/2024 4:16 AM, Bonita Montero wrote:
> Am 08.02.2024 um 22:28 schrieb Chris M. Thomasson:
>
>> Keep in mind that your code disables those warnings. So, be sure to
>> turn them back on for any and all user code!
>
> Locking and unlocking mutexes is trivial and I don't need any addtional
> aid for that. And MSVC runtime gives me a debug message if I try to
> unlock a non-locked mutex; that's sufficient for me. And the shown
> code is never trapped in that way.
>

I am saying that a user of your code might not want those warnings
disabled at all. So, you should turn them back on.

Am 09.02.2024 um 20:43 schrieb Chris M. Thomasson:

> I am saying that a user of your code might not want those
> warnings disabled at all. So, you should turn them back on.

In my own translation units I don't re-enable those warnings.
In headers I disable certain warnings at the beginning of the
header and re-enable them at the end, so that these headers
won't disable those warnings for translation units of others
using my code.

On 2/9/2024 9:11 PM, Bonita Montero wrote:
> Am 09.02.2024 um 20:43 schrieb Chris M. Thomasson:
>
>> I am saying that a user of your code might not want those
>> warnings disabled at all. So, you should turn them back on.
>
> In my own translation units I don't re-enable those warnings.
> In headers I disable certain warnings at the beginning of the
> header and re-enable them at the end, so that these headers
> won't disable those warnings for translation units of others
> using my code.
>

Yup. I think that would be the prudent thing to do. :^)

Okay.