> On Mar 15, 2022, at 12:39 PM, Bill Gunshannon via cctalk
> <cctalk@classiccmp.org> wrote:
>
> On 3/15/22 09:12, Paul Koning wrote:
>>> On Mar 14, 2022, at 9:05 PM, Bill Gunshannon via cctalk
>>> <cctalk@classiccmp.org> wrote:
>>>
>>> On 3/14/22 20:53, Paul Koning via cctalk wrote:
>>>> Saw a note on the GCC list that I thought some here might find
>>>> interesting: it announces the existence (not quite done but getting there)
>>>> of a COBOL language front end for GCC. Interesting. For those who deal
>>>> in legacy COBOL applications that want a more modern platform, I wonder if
>>>> this might be a good way to get there. Run old COBOL dusty decks on
>>>> Linux, yeah...
>>>
>>> We already have GnuCOBOL which works just fine (most of the time).
>> Yes, although that one is apparently more limited.
>
> In what way?
I thought I saw a comment to that effect in the announcement; looking more
closely that isn't the case, other than the limitations you get from going
through C as an intermediate language. (Same sort of reason why the C++ to C
converter is no longer used.)
>> And GnuCOBOL is a COBOL to C converter. gcobol is a full front end.
>
> Is there some shortcoming in using C as an intermediate language?
Yes, debugging. It means the debugger sees a C program, and it's somewhere
between difficult and impossible to apply the original source semantics while
debugging.
>> One difference is that GDB will be able to do COBOL mode debugging.
>
> Never had a reason to try it but I thought GnuCOBOL allowed the use
> of GDB. FAQ seems to say it can be used.
Yes, but presumably in C language mode.
paul
