GnuCOBOL uses various facilities to determine the COBOL dialect to be used.
So setting std=85, I presume, causes the compiler to produce code in accordance with the COBOL 85 standard without any extensions.
Setting std=mf-strict, I presume, causes compilation strictly in accordance with Micro Focus rules which will be a COBOL 85 standard plus Micro Focus's proprietary extensions.
So what additional facilities does std=mf provide over and above the mf-strict directive? And what does GnuCOBOL not implement when using mf-strict?
I know these are very basic questions and I have been usiing GnuCOBOL for several years without properly understanding the differences. I would welcome clarification.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The GnuCOBOL compiler tries to limit both the feature-set and reserved words to the specified compiler when the "strict" dialects are used.
COBOL sources compiled with these dialects are therefore likely to compile with the specified compiler and vice versa: sources that were compiled on the specified compiler should compile without any issues with GnuCOBOL.
With the "non-strict" dialects GnuCOBOL will activate the complete feature-set where it doesn't directly conflict with the specified dialect, including reserved words and GnuCOBOL specific extensions. COBOL sources compiled with these dialects therefore may work only with GnuCOBOL. COBOL sources may need a change because of rich feature-set and reserved words in GnuCOBOL, otherwise offending words may be removed by -fno-reserved=word.
COBOL-85, X/Open COBOL, COBOL 2002 and COBOL 2014 are always "strict".
The functions that are actually available as intrinsic functions depend on the -std used. Function names that aren't marked as intrinsic functions by the current -std can be used freely as user defined words or even as user defined functions.
That, I guess should answer most of the questions, I also guess something similar can be found in the Programmer's Guide.
So what additional facilities does std=mf provide over and above the mf-strict directive? And what does GnuCOBOL not implement when using mf-strict?
Short answer: GnuCOBOL adds all that -std-default provides with the "lax" std dialects.
This brings in several intrinsic functions that are not supported by that dialect originally and removes some restrictions (like word/literal/... length). Similar you get COBOL support (for example you get END-DISPLAY and ALLOCATE as well as BINARY-INT and a lot of others in -std=mvs-strict - with the "cost" that "old" code may not be able to compile because of the huge increased number of reserved words (which you may un-reserve), and if coding against the lax syntax it may not compile on the "original" system (developing with the strict then only syntax-check against the lax dialect can help to write more portable code).
My personal Rule of thumb:
don't specify -std if there's no explicit reason
specify a strict standard when you target the dialect's environment (you want to compile the programs on the other environment later) - depending on the version of the target you may need to unreserve some words (if they were added in a later version, a good example may be -fnot-reserved=JSON,XML)
specify a strict dialect when you know the source is matching this dialect and it doesn't seem to compile/work correctly
You may have a look at the details by inspecting the "config" directory and comparing the word lists + dialect configurations.
Last edit: Simon Sobisch 2023-03-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
GnuCOBOL uses various facilities to determine the COBOL dialect to be used.
So setting std=85, I presume, causes the compiler to produce code in accordance with the COBOL 85 standard without any extensions.
Setting std=mf-strict, I presume, causes compilation strictly in accordance with Micro Focus rules which will be a COBOL 85 standard plus Micro Focus's proprietary extensions.
So what additional facilities does std=mf provide over and above the mf-strict directive? And what does GnuCOBOL not implement when using mf-strict?
I know these are very basic questions and I have been usiing GnuCOBOL for several years without properly understanding the differences. I would welcome clarification.
Thanks
From the NEWS file:
New
-stdoptions-stdvaluecobol2014xopenmf-strictibm-strictibm-strictacuacu-strictbs2000bs2000-strictrmrm-strictgcosgcos-strictNote:
The GnuCOBOL compiler tries to limit both the feature-set and reserved words to the specified compiler when the "strict" dialects are used.
COBOL sources compiled with these dialects are therefore likely to compile with the specified compiler and vice versa: sources that were compiled on the specified compiler should compile without any issues with GnuCOBOL.
With the "non-strict" dialects GnuCOBOL will activate the complete feature-set where it doesn't directly conflict with the specified dialect, including reserved words and GnuCOBOL specific extensions. COBOL sources compiled with these dialects therefore may work only with GnuCOBOL. COBOL sources may need a change because of rich feature-set and reserved words in GnuCOBOL, otherwise offending words may be removed by
-fno-reserved=word.COBOL-85, X/Open COBOL, COBOL 2002 and COBOL 2014 are always "strict".
The functions that are actually available as intrinsic functions depend on the -std used. Function names that aren't marked as intrinsic functions by the current -std can be used freely as user defined words or even as user defined functions.
That, I guess should answer most of the questions, I also guess something similar can be found in the Programmer's Guide.
Short answer: GnuCOBOL adds all that
-std-defaultprovides with the "lax" std dialects.This brings in several intrinsic functions that are not supported by that dialect originally and removes some restrictions (like word/literal/... length). Similar you get COBOL support (for example you get
END-DISPLAYandALLOCATEas well asBINARY-INTand a lot of others in-std=mvs-strict- with the "cost" that "old" code may not be able to compile because of the huge increased number of reserved words (which you may un-reserve), and if coding against the lax syntax it may not compile on the "original" system (developing with the strict then only syntax-check against the lax dialect can help to write more portable code).My personal Rule of thumb:
-stdif there's no explicit reason-fnot-reserved=JSON,XML)You may have a look at the details by inspecting the "config" directory and comparing the word lists + dialect configurations.
Last edit: Simon Sobisch 2023-03-06