I want to describe what's arriving this fall for the COBOL front end,
and check the plan with the august body here assembled. Or, are we
compiled?
Features pending or planned in 2025:
1. "National" support. COBOL programs define the runtime encoding and
collation of each string (sometimes implicitly). COBOL defines two
encodings: "alphanumeric" and "national". Every alphanumeric (and
national) variable and literal has a defined runtime encoding that is
distinct from the compile-time and runtime locale, and from the
encoding of the source code. This means
MOVE 'foo' TO FOO.
may involve iconv(3) and
IF 'foo' = FOO
is defined as true/false depending on the *characters* represented, not
their encoding. That 'foo' could be CP1140 (single-byte EBCDIC) and
FOO could be UTF-16.
Cauldron Alert: Who was I talking to? Unicode equality and inequality
require library support. Some wise person in Porto agreed that 1) GCC
was unlikely to want to add ICU as a dependency and 2) a limited amount
of Unicode evaluation is available in (IIRC) gnulib, which might be
adapted to libiberty, and might serve the purpose. Problem is, I don't
remember and didn't take notes. If that conversation sounds familiar,
please ping me.
Conversion is a solved problem. Comparison is not. And, no, afaik the
C and C++ libraries are insufficient. Anything that relies on the
environment is begging for trouble.
National support will arrive piecemeal. This month we will have support
for initialization, assignment, and display of arbitrary single-byte
encodings. That gets us some distance down the road. Next up is
probably UTF-16, then comparison. What exactly makes it into GCC 16
depends on what the user needs and how fast we work.
2. Messages and warnings. I will revamp how messages are defined to
the compiler driver, so that they can be elevated to error and defeated
with -fno-. I will do the same with "dialect" options for non-ISO
syntax, so that each extension is individually manipulable. That looks
like November from here.
3. XML parsing. This an extension elegantly defined by IBM, a COBOL
wrapper on the libxml2 SAX parser. Definitely the saxiest option. This
implies a new dependency which of course will be documented. Probably
1/2 implemented at present.
4. POSIX and runtime-library compatibility. COBOL vendors all supply
externally defined functions to interact with the OS. For example,
CBL_CREATE_FILE, from MicroFocus, does what it says, albeit in a
totally non-POSIX way.
To emulate these functions requires new directories both in the source
tree and in the install tree. Our two-level design implements
a) gcc/cobol/posix/udf: COBOL wrappers for POSIX functions
with the same parameters and return types that POSIX defines. There are
several subdirectories.
b) gcc/cobol/compat/gnu: functions such as CBL_CREATE_FILE that
are defined by a vendor. These are written in 100% COBOL and use the
POSIX wrappers in (a). They never call an OS function directly.
Both of these directories hold code that is not meant to be separately
compiled. They are what we might call header libraries, in the STL
spirit. They are included into the COBOL source via the COPY
directive. For that to work, they need to be installed. I think the
installation directories should be
PREFIX/include/gcobol/posix/udf
PREFIX/include/gcobol/posix/cpy ("include" files for data)
PREFIX/include/gcobol/compat/gnu
the last so named because GnuCOBOL also implements these functions and
it is their implementation we claim to emulate.
The POSIX wrapper functions need runtime support, which we intend to
supply via libgcobol. Some require C "shim" helper functions, and
most need access to errno.
For example stat(2) uses a struct with defined members but no standard
layout. COBOL cannot define its own buffer to pass to stat(2) and has
no way to parse the one defined by sys/stat.h. Instead we define our
own struct for the COBOL<->wrapper interface. The wrapper calls the
shim, which calls stat(2).
So, a typical call stack might be
<application>
CBL_CHECK_FILE_EXIST
posix-stat.cbl (stat(2) as COBOL function)
posix_stat.c (populates gcobol struct stat)
stat(2)
To hold the shim functions I want to add libgcobol/posix and to build
libgcobol/posix/posix-shim.a. That static library will not be
installed; rather it will be linked into libgcobol.so. That way, any
runtime support required by our POSIX and vendor compatibility layers is
automatically supplied by the library every gcobol-produced executable
already uses.
The goal for gcobol 16 is 10 compatibility functions supported by as
many POSIX user-defined functions as needed, perhaps 2 dozen. As of
now that work has just begun. The proof of that pudding will be in the
eating: existing user code requires that they work.
Thank you for your kind attention. This message is in no way
exhaustive. Various problem reports are also on my TODO list, and we
also want to make sure gcobol is perfected on all the designated
primary architectures for GCC 16. Safe to say, 2026 holds yet more to
do.
--jkl
