Build failed on Linux about size_t

[sksat]

Overview

Build failed on some Linux environment because of lack of include cstddef.

Details

Description

Some files use size_t type without include cstdef.

• src/Interface/SpacecraftInOut/Ports/I2CPort.h

Conditions of occurrence

• Build on my Arch Linux(GCC 11.2.0, clang version 13.0.1)
• Build on ubuntu:latest(Docker Image)
  • packages: build-essential, git, cmake, gcc-11-multilib, g++-11-multilib
  • GCC 11.2.0-19ubuntu1

Additional information

Build log

[ 60%] Building CXX object src/Interface/SpacecraftInOut/CMakeFiles/SC_IO.dir/Ports/I2CPort.cpp.o
In file included from /s2e-core/src/Interface/SpacecraftInOut/Ports/I2CPort.cpp:1:
/s2e-core/src/Interface/SpacecraftInOut/Ports/I2CPort.h:22:3: error: 'size_t' does not name a type
   22 |   size_t WriteCommand(const unsigned char i2c_addr, const unsigned char* tx_data, const size_t length);
      |   ^~~~~~
/s2e-core/src/Interface/SpacecraftInOut/Ports/I2CPort.h:3:1: note: 'size_t' is defined in header '<cstddef>'; did you forget to '#include <cstddef>'?
    2 | #include <map>
  +++ |+#include <cstddef>
    3 | 
/s2e-core/src/Interface/SpacecraftInOut/Ports/I2CPort.h:23:3: error: 'size_t' does not name a type
   23 |   size_t ReadCommand(const unsigned char i2c_addr, unsigned char* rx_data, const size_t length);
      |   ^~~~~~
/s2e-core/src/Interface/SpacecraftInOut/Ports/I2CPort.h:23:3: note: 'size_t' is defined in header '<cstddef>'; did you forget to '#include <cstddef>'?
/s2e-core/src/Interface/SpacecraftInOut/Ports/I2CPort.cpp: In member function 'int I2CPort::WriteRegister(unsigned char, unsigned char)':
/s2e-core/src/Interface/SpacecraftInOut/Ports/I2CPort.cpp:16:48: warning: unused parameter 'i2c_addr' [-Wunused-parameter]
   16 | int I2CPort::WriteRegister(const unsigned char i2c_addr, const unsigned char reg_addr) {
      |                            ~~~~~~~~~~~~~~~~~~~~^~~~~~~~
/s2e-core/src/Interface/SpacecraftInOut/Ports/I2CPort.cpp: At global scope:
/s2e-core/src/Interface/SpacecraftInOut/Ports/I2CPort.cpp:58:1: error: 'size_t' does not name a type
   58 | size_t I2CPort::WriteCommand(const unsigned char i2c_addr, const unsigned char* tx_data, const size_t length) {
      | ^~~~~~
/s2e-core/src/Interface/SpacecraftInOut/Ports/I2CPort.cpp:2:1: note: 'size_t' is defined in header '<cstddef>'; did you forget to '#include <cstddef>'?
    1 | #include "I2CPort.h"
  +++ |+#include <cstddef>
    2 | 
/s2e-core/src/Interface/SpacecraftInOut/Ports/I2CPort.cpp:79:1: error: 'size_t' does not name a type
   79 | size_t I2CPort::ReadCommand(const unsigned char i2c_addr, unsigned char* rx_data, const size_t length) {
      | ^~~~~~
/s2e-core/src/Interface/SpacecraftInOut/Ports/I2CPort.cpp:79:1: note: 'size_t' is defined in header '<cstddef>'; did you forget to '#include <cstddef>'?

Task

• [x] Fix Linux build CI
• [x] Add include cstddef

Scope of influence

Some Linux environment.

Supplement

Write additional comments if you need.

Note

• If there are related Projects, tie them together.
• Set priority label if possible.
• Assignees should be set if possible.
• Write a conclusion when closing the issue.

[sksat]

状況からして，たぶんCIが通ってしまっているのがおかしい

[sksat]

今めっちゃ疑っているのはgcc(というかlibc++か)のバージョン差異です

[sksat]

ubuntu:focalだとExtLibrariesのビルドにコケまくるが，これはCMakeのバージョンによるものか...？(3.16.3)

[sksat]

ubuntu:focalで，(ExtLibrariesがコケたところは手動でどうにかしたけど)同じ操作でビルド成功(ビルドCIの再現ができた)． ということで，問題は

• CMake 3.16.3でExtLibrariesのビルドがコケる(3.22.1, 3.23.1では大丈夫)
  • nrlmsise00/tmpに.c/.hが入ってない
• GCC 9.4.0ではビルドが通ってしまう(このビルドは通ってしまうべきではない)
  • これがビルドCI
  • <map>から紆余曲折あってなぜか<cstddef>が読まれてる？(or GCC拡張？)
  • GCC 11系でもclangでもビルドは落ちる
  • GitHub Actionsのubuntu-latestはまだfocalなのでGCC 9系が入る

の2つ

[sksat]

なので，やるべきこととしては

• ExtLibrariesのCMakeのminimum required versionを上げる
• ビルドCIでGCC 11系を使う
  • 別に古いやつを明示的にサポートする必要はないし(どうせ動きはする・ワーニングなども性能がいい方を使うべき)
• LinuxでのビルドCIにclangを追加
  • 必ずしも追加する必要は無いが，複数のコンパイラでビルドできる，ということは大事
  • どうせreviewdogする時(#102)にclang-tidy使う
• <cstddef>を適切にincludeするようにする

[sksat]

あとCIで諸々の使ってるやつのバージョン表示する，とかもかな

[sksat]

あっActionsのCMakeはWinもUbuntuも3.23.0なのか

[200km]

@sksat こちら、v5.0.0更新前に修正したほうが良いと思っていますが、私ができる範囲であればやるので遠慮なく申し付けてください。私の環境ではビルドエラーは出ていませんが、GCCのバージョンを更新したほうが良いですよね？

[sksat]

あ，そうですね．やるだけなのでやります．

[sksat]

focalだと素直にはgcc-10までしかないか．まあ試してみよう．

[sksat]

結局gcc-11になりました．とりあえず実用上は #111 で問題ないです．

[sksat]

clangとCMakeの話はここで出たというだけで別問題なので別Issueとします．

[200km]

ありがとうございます。こちらは次のような理解で良いのでしょうか？

• CIとしては、gcc-11で通るかチェックする
• ユーザーはgcc-11より前のgccで使うようにする(documentのどこかにそういうことを書いておく？)
• 開発者はCI通すためにgcc-11で開発することを推奨する

[sksat]

いや，コンパイラ(正確には標準ライブラリ)の実装が適当でないことによって適当でないコードのコンパイルが通っていた，ということが問題なので，ユーザ・開発者がgccのバージョンを意識する必要はあまりないです．

[200km]

今回のように手元でエラー出ていなくても、CIがエラー出すからその時に気づいて修正すれば良いって感じですかね。

[sksat]

そういうことです．基本的にCIが最大限エラー・ワーニングを出せればよい(その意味で最新のコンパイラを使うとワーニングが増えていたりしてよいがち)，という考えです． 準拠すべきなのは各々のコンパイラやバージョンによる差異ではなくC++の規格(のバージョン)であって，複数のコンパイラ実装でビルドCIを組むことでその差異に気付けるようにしたい，というかんじです．なので，コンパイラのバージョンを気にするとしてもCI側で複数バージョンのコンパイラでビルドするようにしたいですかね(が，これははあまり必要ないと思います)．

[200km]

わかりました。ありがとうございます。