Thank you for the reminder, and accept my apologies for the delays. Jim and I have been been distracted by an intense effort to rewrite exception/declarative processing. There has also been a serious family health issue that caused us significant delays as well.
I finished a sub-project yesterday, and I will look into these four patches today. > -----Original Message----- > From: Rainer Orth <r...@cebitec.uni-bielefeld.de> > Sent: Wednesday, May 7, 2025 04:38 > To: gcc-patches@gcc.gnu.org > Cc: Robert Dubner <rdub...@symas.com>; James K. Lowden > <jklow...@cobolworx.com>; Jakub Jelinek <ja...@redhat.com>; Richard Biener > <rguent...@suse.de> > Subject: Unreviewed COBOL patches > > Four COBOL patches have remained unreviewed for a month. They are > required to get the cobol1 and libgcobol to build on Solaris: > > cobol: Don't require GLOB_BRACE etc. [PR119217] > https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680675.html > > cobol: Initialize regmatch_t portably [PR119217] > https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680676.html > > It's unclear how to proceed with this one: my simple patch or Jakub's > proposal. > > cobol: Allow for undefined NAME_MAX [PR119217] > https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680682.html > > This one is unclear, too: for one, it turned out that the use of > NAME_MAX isn't related to filenames at all (which suggests just > replacing the macro with it's Linux value, 255), but also Richi's > observation that cbl_funtion_t.name is never set all all (which suggests > removing it completely). > > libgcobol: Heed --enable-libgcobol > https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680684.html > > This allows --enable-libgcobol to enable building the runtime lib even > if the target isn't listed as supported in configure.tgt. > > Rainer > > -- > -------------------------------------------------------------------------- > --- > Rainer Orth, Center for Biotechnology, Bielefeld University
