BudVVeezer

The title is incorrect, it's WG23, not WG32.

> __they don't want these things next to where they live__.

Which is the precise definition of Not In My Back Yard...

It's consistent with for (init; condition;) {} and solves a problem like:

if (std::vector<int> v = f(); !v.empty()) { // Use v }

without requiring an extra compound statement to limit the scope and lifetime of v.

Not quite.

It was submitted for PDTS (proposed draft technical standard), which means it goes out for balloting to ISO national bodies. That balloting either succeeds (at which point you have a Techincal Specification) or it comes back to the committee with comments that the committee then has to respond to (and then another round of balloting happens). Once it's accepted as a Technical Specification, it's still not part of the C++ International Standard. That's a decision the committee comes to at their own pace, much like what happened at this meeting where the Concepts TS was accepted (as amended) into the IS.

Think of a TS somewhat like a beta. There's no assurance that the contents of the TS will go into the IS at all or in the exact form it was originally specified in, but that's certainly the hope when the TS is published.

The clang-tidy tool has some C++ Core Guideline checks under the cppcoreguidelines module.

Some of these rules are currently in clang-tidy, but the coverage is by no means comprehensive. Patches always welcome. :-)

What's considered critical or difficult to discover is a bit subjective, but:

It's easy to forget that alignment is important on some architectures (other than for performance reasons), so be careful when using placement new: https://www.securecoding.cert.org/confluence/display/cpluspl...

This may seem obvious, but even the C++ committee got this one wrong when they created auto_ptr (which has since been removed from the standard): https://www.securecoding.cert.org/confluence/display/cpluspl...

This one is totally obvious but has a stunning number of ways you can fail to adhere to it, some of which look reasonable at first blush: https://www.securecoding.cert.org/confluence/display/cpluspl...

Yes and no. Many compilers support #pragma once, but whether your build environment handles it is another matter. Having your headers on network drives, or having symlinks to your headers, etc can cause issues with #pragma once handling (depending on the implementation) that can often be hard to track down, especially if building with multiple compilers. Include header guards do not have these issues.

Is it the /d1reportSingleClassLayoutXXX flag, described here?

https://blogs.msdn.microsoft.com/vcblog/2007/05/17/diagnosin...

You are forgetting attributes, which can be empty and are grammatical sequences (so you can add them infinitely).

[[]][[]][]()[[]][[]]{}();

Ah, that's right, ranges was a new work item planned for TS (but still not planned for IS in C++17).

The author may be a bit confused as to what C++17 will be. Modules will be in a TS, most likely. Transactional memory, concepts, ranges, and filesystem are already in published TSes (not planned for the IS in this round). Out of the list presented, only fold expressions and __has_include are actually already voted in for C++17 itself. The rest are in various stages of standardization (mostly TSes) and are not guaranteed to ever become part of the IS (though hopefully many will).

Boost is a very large project with varying degrees of API quality, and so when you say it depends on boost, I wonder "the good parts (any, variant, stuff that usually gets looked at for standardization)" or "the bad parts (Spirit, etc)". Also, as others have said, it's a huge dependency that generally raise a red flag (for performance and compile time).

I would highly recommend looking at the CERT C Coding Standards, which are available for free: https://www.securecoding.cert.org/confluence/display/c/SEI+C...

One thing to note, they split them into recommendations and rules. Recommendations are more stylistic and open to debate, whereas violations of rules generally result in definite security concerns.

Yes, the most vexing parse.

https://en.wikipedia.org/wiki/Most_vexing_parse

I think this is a good step in the right direction, but still falls short. For instance, it's heavily gender binary, and has odd cultural mismatches such as "man with turban" but no "woman with hijab." However, major kudos to the Unicode consortium for their work on this -- it's a very challenging set of subjects to get into!

It's something we're discussing and exploring. The general thought is that Clang could do this for everything but sized deallocations (and it's unclear how much of an issue those would pose).

I apologize for being imprecise. We're aware it's more than just ADL or constexpr, but we had insufficient time to address it at this meeting. It's definitely on our radar, we flagged it as a high priority item.

This topic was discussed in Lenexa at last week's C++ standards meeting, and the direction the core working group was thinking was that this should be ill-formed, but is currently under specified. I would not rely on this ADL constexpr trick working for long (at least until CWG has had the chance to really pick apart the issue and change the wording to explicitly allow it).

One of the two values (a or b) gets evaluated twice. Eg)

  min(a++, b++);

a or b would really be incremented twice.

If you are investigating the CERT coding standards, I would recommend focusing on the rules more than the recommendations. The rules are normative and give excellent advice on how to write secure code. The recommendations are generally more about code quality than likely security defects.

More information on the distinction can be found at: https://www.securecoding.cert.org/confluence/display/seccode...

It can, and it is. One of the outcomes of the CERT C secure coding standard was the publication of TS 17961, which is an ISO document on C analyzability, which also went hand in hand with the Annex L (normative) section of the C standard.

Basically, the CERT rules all must be analyzable (though some require dynamic analysis instead of static analysis).

I just tried the following simple example:

  #include <string.h>

  struct S {
    int i;
    char c;
    int j;
  };

  void f(void) {
    struct S s1 = { 0, 0, 0 }, s2 = { 0, 0, 0 };
    memcpy(&s1, &s2, 9);
  }

  int main(void) {
    f();
    return 0;
  }

MSVC, Clang, and PC-Lint are all silent on the code (which is reasonable behavior since it's impossible to glean programmer intent from that snippet -- maybe the programmer really only wants the first nine bytes!). (Btw, yes, I am using the analyzer features for MSVC and Clang, not just relying on high warning levels.)

It's shocking to see how often people write code like: memcpy(somePtr, &myStructObj, 12);

So while that warning can certainly be useless information, it does definitely catch bugs. Unfortunately, the people who write code like the above are also more likely to be people who ignore warnings. ;-)

Try it with -stdlib=libc++, since that's what will control the behavior of std::string.

Except that it was a collaborative effort that involved far more than just Microsoft, such as CERT, and the WG14 committee as a whole...

When I tried to change my password to a twenty character pass phrase, I wasn't allowed because it was "too weak". Adding a single digit made it "strong." I am not particularly comforted by this.

We tested most of the major ones at work on the faulty code, and only PC-Lint caught the issue.

Odd that there's no mention of Annex K support under the "Security/hardening comparison" heading. While it's optional to implement, it certainly applies.

I'll ignore your ad hominem and simply point out that Tim (the person who commit the AArch64 backend from the post I linked) is an Apple employee...