This has been a pet peeve of mine. The copy messes up my indentations and formatting of working storage copies when you have a rename.
I just quit looking at the copied parts of listings from my compiles. I know it is hard to do, but copy replacing is so VERY powerful it deserves ATTENTION. Considering what cobc is capable of digesting, I think copy replacing should be brought up to the same standard. (EXCELLENT).
I'm still getting my monies worth out of GnuCobol.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the source I have:
COPY "GNU.CPY" REPLACING ==(GNU)== BY ==GNU==.This is the copybook:
The compilation goes fine, and the program does what it is supposed to do. But the listing says:
Is there an compilation option that would give GNU-record etc. ?
Cool, that's an error in the listing code (cobc.c only). Cool because that should be quite easy to find and fix.
Just an update - it is as I've thought, a general issue in the listings replace handling, so also seen here:
which compiles and executes fine (displaying 42, then 44), but has a bad listing:
So next is inspecting the actual code in cobc.c.
This has been a pet peeve of mine. The copy messes up my indentations and formatting of working storage copies when you have a rename.
I just quit looking at the copied parts of listings from my compiles. I know it is hard to do, but copy replacing is so VERY powerful it deserves ATTENTION. Considering what cobc is capable of digesting, I think copy replacing should be brought up to the same standard. (EXCELLENT).
I'm still getting my monies worth out of GnuCobol.