From 906ae347f3b147ba77a2b92e5e90dc825cba4634 Mon Sep 17 00:00:00 2001 From: Sergey Zubkov Date: Sun, 4 Jun 2017 10:47:46 -0400 Subject: [PATCH] travis CI fixes --- CppCoreGuidelines.md | 33 +++++++++++++++++---------------- scripts/hunspell/isocpp.dic | 2 ++ 2 files changed, 19 insertions(+), 16 deletions(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index dce634e..67f7027 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -1,6 +1,6 @@ # C++ Core Guidelines -JUne 3, 2017 +June 3, 2017 Editors: @@ -12225,7 +12225,7 @@ See also * Use [RAII](#Rr-raii) to avoid lifetime problems. * Use [unique_ptr](#Rf-unique_ptr) to avoid lifetime problems. * Use [shared_ptr](#Rf-shared_ptr) to avoid lifetime problems. -* Use [references](#Rf-ptr-ref) when `nulllptr` isn't a possibility. +* Use [references](#Rf-ptr-ref) when `nullptr` isn't a possibility. * Use [not_null](#Rf-not_null) to catch unexpected `nullptr` early. * Use the [bounds profile](#SS-bounds) to avoid range errors. @@ -12276,7 +12276,7 @@ There are many approaches to dealing with this potential problem: void f1(int* p) // deal with nullptr { - if (p==nullptr) { + if (p == nullptr) { // deal with nullptr (allocate, return, throw, make p point to something, whatever } int x = *p; @@ -12288,17 +12288,18 @@ There are two potential problems with testing for `nullptr`: * the test can be redundant and/or relatively expensive * it is not obvious if the test is to protect against a violation or part of the required logic. + void f2(int* p) // state that p is not supposed to be nullptr { - Assert(p!=nullptr); + assert(p != nullptr); int x = *p; } -This would carry a cost only when the assertion checking was ensbled and would give a compiler/analyser useful information. +This would carry a cost only when the assertion checking was enabled and would give a compiler/analyzer useful information. This would work even better if/when C++ gets direct support for contracts: void f3(int* p) // state that p is not supposed to be nullptr - [[expects: p!=nullptr]] + [[expects: p != nullptr]] { int x = *p; } @@ -12310,7 +12311,7 @@ Alternatively, we could use `gsl::not_null` to ensure that `p` is not the `nullp int x = *p; } -There remedies take care of `nullptr` only. +These remedies take care of `nullptr` only. Remember that there are other ways of getting an invalid pointer. ##### Example @@ -12332,17 +12333,17 @@ Remember that there are other ways of getting an invalid pointer. void f() { vector v(10); - int* p = v(5); - v.pushback(99); // could rellocate v's elements + int* p = &v[5]; + v.push_back(99); // could reallocate v's elements int x = *p; // BAD: dereferences potentially invalid pointer } ##### Enforcement -This rule is part ot the [lifetime profile](#Pro.lifetime) +This rule is part of the [lifetime profile](#Pro.lifetime) * Flag a dereference of a pointer that points to an object that has gone out of scope -* Flag a dereference of a pointer that may have beed invalidated by assigning a `nullptr` +* Flag a dereference of a pointer that may have been invalidated by assigning a `nullptr` * Flag a dereference of a pointer that may have been invalidated by a `delete` * Flag a dereference to a pointer to a container element that may have been invalidated by dereference @@ -19600,7 +19601,7 @@ and "mysterious values." Accessing through a pointer that doesn't point to anything is a major source of errors, and very hard to avoid in many traditional C or C++ styles of programming. -For example, a pointer my be uninitialized, the `nullptr`, point beyond the range of an array, or to a deleted object. +For example, a pointer may be uninitialized, the `nullptr`, point beyond the range of an array, or to a deleted object. See /docs folder for the initial design. The detailed formal rules are in progress (as of May 2017). @@ -19611,13 +19612,13 @@ Lifetime safety profile summary: ##### Impact -Once completely enforced through a combilnation of style rules, static analysis, and library support, this profile +Once completely enforced through a combination of style rules, static analysis, and library support, this profile * eliminates one of the major sources of nasty errors in C++ * eliminates a major source of potential security violations * improves performance by eliminating redundant "paranoia" checks * increases confidence in correctness of code -* avoids undefined behavior by enforcinga key C++ language rule +* avoids undefined behavior by enforcing a key C++ language rule # GSL: Guideline support library @@ -21289,8 +21290,8 @@ Alternatively, we will decide that no change is needed and delete the entry. * \[Stroustrup14]: B. Stroustrup. [A Tour of C++](http://www.stroustrup.com/Tour.html). Addison Wesley 2014. -* + \[Stroustrup15]: B. Stroustrup, Herb Sutter, and G. Dos Reis: [A brief introduction to C++'s model for type- and resource-safety](https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Introduction%20to%20type%20and%20resource%20safety.pdf). * \[SuttHysl04b]: H. Sutter and J. Hyslop. "Collecting Shared Objects" (C/C++ Users Journal, 22(8), August 2004). * diff --git a/scripts/hunspell/isocpp.dic b/scripts/hunspell/isocpp.dic index 6d0b901..7f83d2f 100644 --- a/scripts/hunspell/isocpp.dic +++ b/scripts/hunspell/isocpp.dic @@ -494,6 +494,7 @@ Stroustrup00 Stroustrup05 Stroustrup13 Stroustrup14 +Stroustrup15 Stroustrup94 Stroustrup's struct @@ -554,6 +555,7 @@ use1 users' UTF util +v's v1 va ValueType