Merge pull request #77 from kaitai-io/gh-actions-macos

GH Actions: add macOS 14

Author: generalmimon

.github/workflows/build.yml

@@ -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:

Common.cmake

@@ -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.

gcc4.mk

@@ -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,

kaitai/kaitaistream.h

@@ -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
 
@@ -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
@@ -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

tests/unittest.cpp

@@ -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");
@@ -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)
 {
@@ -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";