Commits on Jan 5, 2018
  1. Merge pull request #372 from luzpaz/misc-typo

    jepler committed Jan 5, 2018
    Misc. typo
Commits on Jan 4, 2018
  1. Misc. typo

    luzpaz committed Jan 4, 2018
Commits on Dec 27, 2017
  1. Merge pull request #371 from luzpaz/moar-misc-typos

    mpictor committed Dec 27, 2017
    More Misc. typos
Commits on Dec 23, 2017
  1. More Misc. typos

    luzpaz committed Dec 23, 2017
Commits on Nov 30, 2017
  1. Merge pull request #370 from luzpaz/misc-typos

    jepler committed Nov 30, 2017
    Misc. typos
Commits on Nov 27, 2017
  1. Misc. typos

    luzpaz committed Nov 27, 2017
Commits on Oct 25, 2017
  1. Merge pull request #367 from luzpaz/comment-typo

    jepler committed Oct 25, 2017
    data/ap238/ap238-aim-long.exp comment typo
Commits on Oct 9, 2017
  1. data/ap238/ap238-aim-long.exp comment typo

    luzpaz committed Oct 9, 2017
Commits on Oct 4, 2017
  1. Merge pull request #366 from luzpaz/more-misc-typos

    jepler committed Oct 4, 2017
    More typos
Commits on Oct 3, 2017
  1. More typos

    luzpaz committed Oct 3, 2017
Commits on Sep 18, 2017
  1. Merge pull request #365 from luzpaz/misc_typos

    mpictor committed Sep 18, 2017
    Misc. typos
Commits on Sep 15, 2017
  1. Misc. typos

    luzpaz committed Sep 15, 2017
    A few user-facing and the rest just code comments
Commits on Aug 28, 2017
  1. Merge pull request #364 from jepler/enable-additional-tests

    jepler committed Aug 28, 2017
    Enable additional tests
  2. appveyor: don't skip test on Windows

    jepler committed Aug 28, 2017
    The test failure has been fixed since 8447292
Commits on Aug 23, 2017
  1. travis: no longer allow osx failures

    jepler committed Aug 23, 2017
    .. the known failure was fixed at 0b6cd90
Commits on Aug 22, 2017
  1. Merge pull request #358 from jepler/sanitize

    mpictor committed Aug 22, 2017
    Fix problems detected by "-fsanitize=address"
  2. Merge pull request #363 from jepler/inverse_attr3_windows

    mpictor committed Aug 22, 2017
    fix test_inverse_attr3 failures on appveyor (windows)
  3. Merge pull request #362 from jepler/mac-inverse-attr3-failure

    mpictor committed Aug 22, 2017
    Fix test_inverse_attr3 failure on macos
  4. Merge pull request #360 from jepler/test-parallelism-failures

    mpictor committed Aug 22, 2017
    Fix test parallelism failures
Commits on Aug 21, 2017
  1. Don't open part 21 files as text files

    jepler committed Aug 16, 2017
    On Windows, when a file is opened in "text" mode, but it actually
    contains Unix-style line endings, the behavior of tellg() is
    Consider this program which puts the (binary) contents "a\nb\n" in a
    file, then opens it in text mode for reading.  It prints each
    character read, along with the value returned by tellg():
        #include <iostream>
        #include <fstream>
        int main()
                std::ofstream f("myfile.txt", std::ios::binary);
                f << "a\nb\n";
            std::ifstream f("myfile.txt");
            for (char c=0; f.get(c);)
                std::cout << f.tellg() << ' ' << int(c) << '\n';
    On a UNIX platform which does not have a distinction between "text"
    and "binary" files, the output will read
        1 97
        2 10
        3 98
        4 10
    because the file position simply advances one position after each
    byte is read.
    On Windows with the Visual Studio C and C++ runtime, the result is
        -1 97
        1 10
        2 98
        4 10
    While it is impossible to say exactly what the Windows runtime is
    doing here, it appears that it is trying to adjust for the mismatch
    between "number of bytes read in byte oriented mode and "number of
    bytes read in text mode".
    Since "part21" files don't necessarily contain CRLF line endings
    when viewed in binary mode, open the file in binary mode.  This
    fixes the test failure seen on appveyor ci running the
    "test_inverse_attr3" test.
  2. Correctly append a single character to a std::string

    jepler committed Aug 15, 2017
    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/
        #2 0x7fb905b677c3 in ErrorDescriptor::AppendToDetailMsg(char) /home/jepler/src/stepcode/src/clutils/
    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/
      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
  3. express/error.c: Ensure the error buffer does not overflow

    jepler committed Aug 15, 2017
    On Debian Stretch, when configuring stepcode like so:
        ASAN_OPTIONS="detect_leaks=false" CXX="clang++" CXXFLAGS="-fsanitize=address" cmake ..
    a fatal error would be detected:
      ==29661==ERROR: AddressSanitizer: heap-buffer-overflow on address
      0x62100001dca0 at pc 0x0000004435e3 bp 0x7ffed6d9cae0 sp 0x7ffed6d9c290
      READ of size 4001 at 0x62100001dca0 thread T0
          #0 0x4435e2 in __interceptor_strlen.part.45 (/home/jepler/src/stepcode/build/bin/schema_scanner+0x4435e2)
          #1 0x501d7b in ERRORreport_with_symbol /home/jepler/src/stepcode/src/express/error.c:413
      0x62100001dca0 is located 0 bytes to the right of 4000-byte region
      allocated by thread T0 here:
          #0 0x4c3ae8 in __interceptor_malloc (/home/jepler/src/stepcode/build/bin/schema_scanner+0x4c3ae8)
          #1 0x5011fc in ERRORinitialize /home/jepler/src/stepcode/src/express/error.c:129
    Operations on ERROR_string were unsafe, because they did not guard
    against accesses beyond the end of the allocatd region.
    This patch ensures that all accesses via *printf functions do respect
    the end of the buffer; and encapsulates the routine for pointing
    ERROR_string at the space for the next error text to start, if space is
    Finally, because it was found with search and replace, a stray manipulation
    of ERROR_string within the print-to-file branch of the code is removed.
    This stray line would have had the effect of moving ERROR_string one byte
    further along at every warning-to-file, which could also have been a
    cause of the problem here.
  4. sc_version_string: Use temporary names resilient against parallel builds

    jepler committed Aug 16, 2017
    In #359 I identify a race condition between multiple parallel invocations
    of cmake, which can arise naturally during ctests.  Now that the file
    contents will not change without an intervening git commit, it is
    sufficient to ensure that the parallel invocations use distinct temporary
    file names with high probability.
  5. sc_version_string: omit the date and time when testing

    jepler committed Aug 16, 2017
    As analyzed in #359, if the header contains the current time, it will
    be updated while running the testsuite; this, in turn, causes multiple
    cmake processes to attempt to update targets like lib/
    at the same time, causing test failures.
Commits on Aug 19, 2017
  1. Merge pull request #361 from jepler/appveyor-single-thread-test

    mpictor committed Aug 19, 2017
    appveyor build: don't use ctest parallelism
  2. Merge pull request #357 from jepler/nullptr-bool

    mpictor committed Aug 19, 2017
    Fix build error with g++ 6.3 (Debian Stretch)
Commits on Aug 16, 2017
  1. Fix test_inverse_attr3 failure

    jepler committed Aug 16, 2017
    This fixes the failure in test_inverse_attr3 seen on travis ci's osx
    Actually, only the change to sectionReader::getRealInstance is
    needed to fix the test, but as the reason that 'unget' can fail is
    unclear, I changed all instances of 'unget' to use the 'seekg' +
    arithmetic method instead.
    I failed to find a reason why 'unget' could fail in this way, or
    reports of macos-specific failures in 'unget', but I was not
    I do not know whether test_inverse_attr3 would *consistently* hang
    on Appveyor, but after this change (and modifying .appveyor.yml
    to not skip test_inverse_attr3) it did succeed on the first try.
  2. appveyor build: don't use ctest parallelism

    jepler committed Aug 16, 2017
    On Windows, concurrent access to files is severely restricted
    compared to standard operating systems.  When ctest is invoking
    cmake, this causes it to write simultaneously to the same files in
    each concurrent cmake invocation, leading to spurious test failures
      error MSB3491: Could not write lines to file "...".  The process
      cannot access the file '...' because it is being used by another
    Explicitly ask for no parallelism with "-j1", even though it is
    probably the default.
Commits on Aug 15, 2017
  1. Fix build error with g++ 6.3 (Debian Stretch)

    jepler committed Aug 12, 2017
    On this platform, TEST_NULLPTR fails, even though nullptr and
    nullptr_t are supported:
        error: converting to 'bool' from 'std::nullptr_t'
        requires direct-initialization [-fpermissive]
     int main() {return !!f();}
    Subsequent to this failure, the workaround definitions in sc_nullptr.h
    prevent standard C++ headers (which must refer to real nullptr) to fail.
    The failure occurs because the C++ standard apparently does not state
    that operator! may be used on nullptr.  Despite this, some compilers
    have historically allowed it.  g++ 6.3's behavior appears to be aligned
    with the standard.
    As requested by @brlcad, ensure that the function 'f' is used from main,
    to avoid a clever (but not nullptr-supporting) compiler from somehow
    skipping 'f' altogether, creating a false positive for nullptr support.
Commits on Aug 14, 2017
  1. Merge pull request #351 from stepcode/review/327

    mpictor committed Aug 14, 2017
Commits on Mar 5, 2017
  1. Merge pull request #356 from luzpaz/ascii-typos

    tpaviot committed Mar 5, 2017
    Fixed typos showing up as ascii chars
Commits on Mar 4, 2017
  1. Fixed typos showing up as ascii chars

    luzpaz committed Mar 4, 2017
Commits on Aug 6, 2016
  1. Revert "Get latest version of ap242 from http://stepmod.cvs.sourcefor…

    starseeker committed Aug 6, 2016
  2. Add an option to completely bypass the git management of the version …

    starseeker committed Aug 6, 2016