[patch] [libcxx] cmakelists.txt patch to disable int to bool error warning for msvc

G M gmisocpp at gmail.com
Wed Oct 9 09:36:19 PDT 2013


I'd probably prefer to fix all the warnings of that bool type (there's only
about a dozen or so) rather than put all the push pop pragma's all over the
place. Because clang will than warn about unknown pragma's. So they'll have
to be #If _LIBCPP_MSVC etc.

It's just cleaner to change the code. Is that ok with you howard?


On Thu, Oct 10, 2013 at 5:14 AM, Reid Kleckner <rnk at google.com> wrote:

> Clang and gcc have a concept of "system" headers, for which they suppress
> all warnings.  It's assumed that the user doesn't care about unactionable
> warnings in code they don't own.
>
> I believe MSVC doesn't make this distinction, so I worry that some user
> might try to build with /W3, and warnings from libc++ headers.
>
> Both of your previous fixes were in headers, in which case we may actually
> want to commit them or use #pragma warning(push) #pragma warning(disable :
> 4800) ... #pragma warning pop().  Your original fix is probably less ugly
> than the pragma.
>
> Sorry for running you around!  :(  If the warning had been in source code,
> this fix would work.  This is still probably worth committing, since we
> don't care about these warnings at all in .cpp files.
>
>
> On Wed, Oct 9, 2013 at 7:30 AM, G M <gmisocpp at gmail.com> wrote:
>
>> Hi Everyone
>>
>> Here's a patch to disable implicit int to bool warnings for msvc libcxx
>> by changing the project file default to silence this warning.
>>
>> There are about a dozen or so instances of this warning in libcxx and I
>> am happy to make those changes manually if consensus forms to prefer that
>> but so far that isn't the case.
>>
>> It's simply changing things like bool b = x & m; to b = (x&m) != 0;
>>
>> In absence of consensus to me making these types of changes I've gone
>> with this change to the project file to disable the warnings instead. This
>> change only effects MSVC, other compilers already default to this it seems.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131010/1d0f6b2f/attachment.html>


More information about the cfe-commits mailing list