Pushed to trunk.
-- >8 --
The name "_N" is listed as a reserved name on Solaris, so we shouldn't
use it as an example of our naming conventions.
libstdc++-v3/ChangeLog:
* doc/xml/manual/appendix_contributing.xml: Replace example that
uses a BADNAME.
* doc/html/manual/source_code_style.html: Regenerate.
---
libstdc++-v3/doc/html/manual/source_code_style.html | 4 ++--
libstdc++-v3/doc/xml/manual/appendix_contributing.xml | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libstdc++-v3/doc/xml/manual/appendix_contributing.xml
b/libstdc++-v3/doc/xml/manual/appendix_contributing.xml
index 197c7d9fb40..a9196493adc 100644
--- a/libstdc++-v3/doc/xml/manual/appendix_contributing.xml
+++ b/libstdc++-v3/doc/xml/manual/appendix_contributing.xml
@@ -887,7 +887,7 @@ indicate a place that may require attention for
multi-thread safety.
Type names and template formal-argument names:
<literal>_[A-Z][^_].*</literal>
- Examples: <code>_Helper _CharT _N</code>
+ Examples: <code>_Helper _CharT _Nm</code>
Member data and function names: <literal>_M_.*</literal>
@@ -899,7 +899,7 @@ indicate a place that may require attention for
multi-thread safety.
Don't use names in the same scope that differ only in the prefix,
e.g. _S_top and _M_top. See <link
linkend="coding_style.bad_identifiers">BADNAMES</link> for a list of forbidden
names.
- (The most tempting of these seem to be and "_T" and "__sz".)
+ (The most tempting of these seem to be and "_T" and "_N".)
Names must never have "__" internally; it would confuse name
unmanglers on some targets. Also, never use "__[0-9]", same reason.
--
2.41.0
