1d01b831aa
The idiom
char c = ...;
_userMsg.append( &c );
is not correct C++, because it treats the address of 'c' as a NUL-
terminated C string. However, this is not guaranteed.
When building and testing on Debian Stretch with AddressSanitizer:
ASAN_OPTIONS="detect_leaks=false" CXX="clang++" CC=clang CXXFLAGS="-fsanitize=address" LDFLAGS="-fsanitize=address" cmake .. -DSC_ENABLE_TESTING=ON -DSC_BUILD_SCHEMAS="ifc2x3;ap214e3;ap209"
ASAN_OPTIONS="detect_leaks=false" make
ASAN_OPTIONS="detect_leaks=false" ctest . --output-on-failure
an error like the following is encountered:
==15739==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffeb2ca7621 at pc 0x00000043c943 bp 0x7ffeb2ca75d0 sp 0x7ffeb2ca6d80
READ of size 33 at 0x7ffeb2ca7621 thread T0
#0 0x43c942 in __interceptor_strlen.part.45 (/home/jepler/src/stepcode/build/bin/lazy_sdai_ap214e3+0x43c942)
#1 0x7fb9056e6143 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::append(char const*) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x11f143)
#2 0x7fb905b677c3 in ErrorDescriptor::AppendToDetailMsg(char) /home/jepler/src/stepcode/src/clutils/errordesc.cc:150:5
Address 0x7ffeb2ca7621 is located in stack of thread T0 at offset 33 in frame
#0 0x7fb905b676af in ErrorDescriptor::AppendToDetailMsg(char) /home/jepler/src/stepcode/src/clutils/errordesc.cc:149
This frame has 1 object(s):
[32, 33) '' <== Memory access at offset 33 overflows this variable
A similar problem with AppendToUserMsg is found by inspection.
After this change, all 200 tests pass under the AddressSanitizer
configuration
|
||
|---|---|---|
| cmake | ||
| data | ||
| doc | ||
| example/ap203min | ||
| include | ||
| misc | ||
| src | ||
| test | ||
| .appveyor.yml | ||
| .gitignore | ||
| .travis.yml | ||
| AUTHORS | ||
| ChangeLog | ||
| CMakeLists.txt | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| ctest_matrix.cmake | ||
| CTestConfig.cmake | ||
| INSTALL | ||
| lcov.cmake | ||
| NEWS | ||
| README.md | ||
| run_ctest.cmake | ||
| SC_VERSION.txt | ||
| Travis-CI | AppVeyor CI |
|---|---|
| Linux, OSX (LLVM) | Windows (MSVC) |
 |
STEPcode v0.8 -- stepcode.org, github.com/stepcode/stepcode
-
What is STEPcode? SC reads ISO10303-11 EXPRESS schemas and generates C++ source code that can read and write Part 21 files conforming to that schema. In addition to C++, SC includes experimental support for Python.
-
Renamed in April/May 2012: SC was formerly known as STEP Class Libraries, SCL for short. It was renamed because the name wasn't accurate: the class libraries make up only a part of the code.
-
Much of the work to update SC has been done by the developers of BRL-CAD, and SC (then STEP Class Library) was originally created at NIST in the 90's.
-
For information on changes version-by-version, see the NEWS file
-
Building and testing SCL - see the INSTALL file
-
For more details on the libraries and executables, see the wiki: http://github.com/stepcode/stepcode/wiki/About-STEPcode
-
For license details, see the COPYING file. Summary: 3-clause BSD.
CODING STANDARDS
SC's source has been reformatted with astyle. When making changes, try to match the current formatting. The main points are:
- compact (java-style) brackets:
if( a == 3 ) {
c = 5;
function( a, b );
} else {
somefunc( );
}
- indents are 4 spaces
- no tab characters
- line endings are LF (linux), not CRLF (windows)
- brackets around single-line conditionals
- spaces inside parentheses and around operators
- return type on the same line as the function name, unless that's too long
- doxygen-style comments (see http://www.stack.nl/~dimitri/doxygen/docblocks.html)
If in doubt about a large patch, run astyle with the config file misc/astyle.cfg. Download astyle from http://sourceforge.net/projects/astyle/files/astyle/
For more info, see the wiki.