explicitly note that "file" refers to as it exists in the location of it being authored/modified.
this is to address any confusion about #including "bar.h" from foo.h based on whether bar.h is relative to foo.h at the time and location foo.h is being modified (e.g. under mylib/foo.h) versus at the time/location from which foo.h is installed to the system and included by the user (e.g. from /usr/include).
The current guidance on SF.12 can be over-applied and devolves into "always use <>" because all compilers support adding include directories to the <> search. In this case, even the current directory may be added and so it is always possible to use <> for every header. Applying the guidance then devolves into an undesirable state where <> is always used and include"" is never used.
Instead, the proposed guidance leverages and encourages the distinction between <> and "" to create an easy-to-understand rule that the original guidance hints at and that most developers already follow and understand: "" is for local headers and <> is for library and external headers.
* Actually detect negative sizes by following ES.106
And don't use senseless one letter names
* fix grammar
Co-Authored-By: Johel Ernesto Guerrero Peña <johelegp@gmail.com>
Co-authored-by: Johel Ernesto Guerrero Peña <johelegp@gmail.com>
* add SF.12
* add incscope to isocpp.dic to get the CI build to pass
* expand INCLUDES, update dictionary for the ci build to pass
* pr feedback
* in the same directory
* update based on feedback
* 3rd try
* PR feedback
* update lable
* Update CppCoreGuidelines.md
* Update CppCoreGuidelines.md
Changed the two anchors back (anchors need to stay stable and don't
display visibly anyway)
Switched "non-public" back to hyphernated (to use hyphenation
consistently)
* Casting away const isn't undefined behavior, but modifying a constant is
You can cast away `const` as much as you like, as long as you never write to variable.
* rewording for clarification
