On Tue, Mar 25, 2025 at 11:41:09PM -0500, Robert Dubner wrote:
> I'll take a look at this tomorrow. Conditional compilation is one
> possibility. Another is to bust that .h file into two; one that goes into
> libgcobol and is accessed by gcc/cobol and libgcobol, and a second that is
> accessed solely by libgcobol. I'll want to look at the magnitude of the
> problem before deciding which.
That would work fine too.
Another question for later is if any of those APIs with __int128 are
actually ever called from compiled COBOL code, or if after this change
and your header split __int128 will be just a type internal to the library,
with compiled COBOL code only storing stuff into memory as 16-byte values.
In that case, we could easily get rid of the __int128 dependency and enable
COBOL support e.g. on many 32-bit architectures, by doing
#ifdef __SIZEOF_INT128__
typedef __int128 int128;
#else
class int128 {
...
};
#endif
where the class would have overloaded operators such that it would work
fully or mostly the same as native __int128 type. The library is written
in C++ so let's take some advantage of it. Guess it depends on
what exactly is __int128 used for in the library and e.g. what C library
functions are used with it if any.
Jakub
