gcobol
Paul Koning
paulkoning at comcast.net
Tue Mar 15 11:57:30 CDT 2022
> On Mar 15, 2022, at 12:39 PM, Bill Gunshannon via cctalk <cctalk at 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 at 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
More information about the cctech
mailing list