Skip to content

GH Actions: add macOS 14 #77

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Mar 30, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 27 additions & 0 deletions .github/workflows/build.yml
Original file line number Diff line number Diff line change
Expand Up @@ -39,6 +39,33 @@ jobs:
-DCMAKE_CXX_INCLUDE_WHAT_YOU_USE='include-what-you-use;-Xiwyu;--verbose=3'
- name: Run tests
run: .build/run-unittest --valgrind
macos:
runs-on: macos-14
strategy:
fail-fast: false
matrix:
cpp-standard:
- '98'
- '11'
- '20'
steps:
- uses: actions/checkout@v4
- name: Install GoogleTest
env:
CPP_STANDARD: ${{ matrix.cpp-standard }}
run: .build/install-gtest "$CPP_STANDARD"
- name: Build
env:
CPP_STANDARD: ${{ matrix.cpp-standard }}
# This tells the C++ compiler to produce debugging info that Valgrind needs to report line numbers.
# See also https://valgrind.org/docs/manual/manual-core.html#manual-core.started
CMAKE_BUILD_TYPE: Debug
run: |
.build/build \
-DCMAKE_BUILD_TYPE="$CMAKE_BUILD_TYPE" \
-DCMAKE_CXX_STANDARD="$CPP_STANDARD" -DCMAKE_CXX_STANDARD_REQUIRED=ON -DCMAKE_CXX_EXTENSIONS=OFF
- name: Run tests
run: .build/run-unittest

# Builds and runs tests on Ubuntu 7.10.
# It ships with:
Expand Down
7 changes: 7 additions & 0 deletions Common.cmake
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,13 @@ target_compile_options(${PROJECT_NAME} PRIVATE
$<$<CXX_COMPILER_ID:MSVC>:/W4 /WX>
$<$<NOT:$<CXX_COMPILER_ID:MSVC>>:
-Wall -Wextra -Wpedantic -Werror

# We're using the `long long` type intentionally. Although it's not part of C++98, in
# practice it is usually supported even by ancient compilers with very limited C++11
# support. And we already unconditionally require `uint64_t`, so it would be strange if
# the compiler supported `uint64_t` and not `long long`.
-Wno-error=long-long

# See <https://gcc.gnu.org/onlinedocs/gcc-13.3.0/gcc/Warning-Options.html#index-Wstrict-aliasing_003dn>:
#
# > Level 1: (...) it has very few false negatives. However, it has many false positives.
Expand Down
6 changes: 6 additions & 0 deletions gcc4.mk
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,12 @@ OBJS := \

CXXFLAGS := -std=c++98 -Wall -Wextra -pedantic

# `-pedantic` enables `-Wlong-long`, which for some reason turns into
# `error: ISO C++ does not support 'long long'`, even though we don't use `-Werror`. Since
# we're using `long long` intentionally, we suppress this error using `-Wno-long-long`
# (see https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Warning-Options.html#index-Wlong_002dlong-305).
CXXFLAGS += -Wno-long-long

# NOTE: the meaning of `<n>` values in `-Wstrict-aliasing=<n>` is different in GCC 4.1.2
# than in recent versions of GCC. According to
# https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Warning-Options.html#index-Wstrict_002daliasing-246,
Expand Down
15 changes: 11 additions & 4 deletions kaitai/kaitaistream.h
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,7 @@

#include <ios> // std::streamsize, forward declaration of std::istream // IWYU pragma: keep
#include <cstddef> // std::size_t
#include <climits> // LLONG_MAX, ULLONG_MAX
#include <sstream> // std::istringstream // IWYU pragma: keep
#include <string> // std::string

Expand Down Expand Up @@ -252,8 +253,11 @@ class kstream {
return to_string_signed(val);
}

// The `long long` type is only available since C++11, so we use it only in C++11 mode.
#ifdef KAITAI_STREAM_H_CPP11_SUPPORT
// The `long long` type is technically available only since C++11. It is usually
// supported even by ancient compilers that have very limited C++11 support, but we can
// still check if the `LLONG_MAX` macro is defined (it seems very unlikely that it is not,
// though).
#ifdef LLONG_MAX
/**
* Converts given integer `val` to a decimal string representation.
* Should be used in place of `std::to_string(long long)` (which is available only
Expand Down Expand Up @@ -282,8 +286,11 @@ class kstream {
return to_string_unsigned(val);
}

// The `unsigned long long` type is only available since C++11, so we use it only in C++11 mode.
#ifdef KAITAI_STREAM_H_CPP11_SUPPORT
// The `unsigned long long` type is technically available only since C++11. It is usually
// supported even by ancient compilers that have very limited C++11 support, but we can
// still check if the `LLONG_MAX` macro is defined (it seems very unlikely that it is not,
// though).
#ifdef ULLONG_MAX
/**
* Converts given integer `val` to a decimal string representation.
* Should be used in place of `std::to_string(unsigned long long)` (which is available only
Expand Down
26 changes: 6 additions & 20 deletions tests/unittest.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -154,8 +154,6 @@ TEST(KaitaiStreamTest, to_string_long)
#pragma warning(pop)
#endif

// The `long long` type is only available since C++11, so we use it only in C++11 mode.
#ifdef KAITAI_STREAM_H_CPP11_SUPPORT
TEST(KaitaiStreamTest, to_string_unsigned_long_long)
{
EXPECT_EQ(kaitai::kstream::to_string(std::numeric_limits<unsigned long long>::min()), "0");
Expand All @@ -167,20 +165,6 @@ TEST(KaitaiStreamTest, to_string_long_long)
EXPECT_EQ(kaitai::kstream::to_string(std::numeric_limits<long long>::min()), "-9223372036854775808");
EXPECT_EQ(kaitai::kstream::to_string(std::numeric_limits<long long>::max()), "9223372036854775807");
}
#else
// Make sure we still support 64-bit integers.
TEST(KaitaiStreamTest, to_string_uint64)
{
EXPECT_EQ(kaitai::kstream::to_string(std::numeric_limits<uint64_t>::min()), "0");
EXPECT_EQ(kaitai::kstream::to_string(std::numeric_limits<uint64_t>::max()), "18446744073709551615");
}

TEST(KaitaiStreamTest, to_string_int64)
{
EXPECT_EQ(kaitai::kstream::to_string(std::numeric_limits<int64_t>::min()), "-9223372036854775808");
EXPECT_EQ(kaitai::kstream::to_string(std::numeric_limits<int64_t>::max()), "9223372036854775807");
}
#endif

TEST(KaitaiStreamTest, string_to_int)
{
Expand Down Expand Up @@ -578,15 +562,17 @@ TEST(KaitaiStreamTest, bytes_to_str_invalid_seq_gb2312_too_short)
}
}

#if defined(__FreeBSD__) || defined(__NetBSD__)
#if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__APPLE__)
TEST(KaitaiStreamTest, DISABLED_bytes_to_str_invalid_seq_gb2312_two_bytes)
#else
TEST(KaitaiStreamTest, bytes_to_str_invalid_seq_gb2312_two_bytes)
#endif
{
// 0xB0 0x30 is illegal sequence in GB2312: 0xB0 must be followed by [0xA1..0xFE].
// However, some iconv engines, namely CITRUS integrated with modern FreeBSD (10+) and NetBSD,
// are not considering this as error and thus not returning EILSEQ.
// 0xB0 0x30 is illegal sequence in GB2312: 0xB0 must be followed by [0xA1..0xFE]. However,
// some iconv engines, namely CITRUS integrated with modern FreeBSD (10+) and NetBSD, are
// not considering this an error and thus not returning EILSEQ. Iconv preinstalled in the
// GitHub Actions `macos-14` runner image does not consider this an error either.
//
try {
std::string res = kaitai::kstream::bytes_to_str("\xb0\x30", "GB2312");
FAIL() << "Expected illegal_seq_in_encoding exception";
Expand Down