Project

General

Profile

Actions

Bug #16523

open

int8_t should explicitly be signed char

Added by Peter Tribble 25 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
headers
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

Description

We currently define int8_t as char in /usr/include/sys/int_types.h

#if defined(_CHAR_IS_SIGNED)
typedef char int8_t;
#else
typedef signed char int8_t;
#endif

The problem with this is that it leads to a build failure for C++ code that defines both foo(int8_t) and foo(char) as they end up as duplicate definitions. For a concrete example see Apache Arrow:

In file included from /export/home/ptribble/ud/apache-arrow-16.0.0-64bit/cpp/src/parquet/stream_reader.cc:18:
/export/home/ptribble/ud/apache-arrow-16.0.0-64bit/cpp/src/parquet/stream_reader.h:116:17: error: 'parquet::StreamReader& parquet::StreamReader::operator>>(char&)' cannot be overloaded with 'parquet::StreamReader& parquet::StreamReader::operator>>(int8_t&)'
116 | StreamReader& operator>>(char& v); | ^~~~~~
/export/home/ptribble/ud/apache-arrow-16.0.0-64bit/cpp/src/parquet/stream_reader.h:92:17: note: previous declaration 'parquet::StreamReader& parquet::StreamReader::operator>>(int8_t&)'
92 | StreamReader& operator>>(int8_t& v); | ^~~~~~

Explicitly using the signed char form fixes this and similar code. (In Tribblix, Apache Arrow and pyArrow are built successfully with int8_t = signed char and work fine.)

The downside is that the signature change will change the mangled symbol names, requiring a rebuild of any C++ library and all its consumers.

No data to display

Actions

Also available in: Atom PDF