I am using GNU 3.2 , We are migrating source from MF to GNU . We have cases like call subprogram with less no. of arguments , Sometimes length of the linkage variable is mismatch ( however the missing linkage area not used during that call), Some times these calls are getting Segment fault SIGSEGV in GNU . Not always linkage mismatch giving SIGSEGV error , ** Some observations like calling same subprogram multiple time with different arguments / linkage size,** call subprogram1 have mismatch in linkage but SIGSEGV it getting call subprogram2 which has correct call parameters.
Is there any runtime or compile time parameter GNU can treat mismatch in arguments treat as optional ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A SIGSEGV can have too much reasons, very often then are the result of a problem that happened much earlier than the actual SIGSEGV, so your diagnostic "not used when there is a SIGSEGV" may be correct (because its a follow-up problem of an earlier invocation).
Of course: the best option would be to change the LINKAGE and PROCEDURE DIVISION USING to be "standard conforming", for programs like this that means using ANY LENGTH and OPTIONAL plus a one-time check before using the optional arguments with IF LINK-ARG NOT OMITTED - but you may not have the option to do so.
If you compile with cobc --debug then nearly all SIGSEGV get replaced by a nice abort, specifying what the problem is at the time where it happens.
As this is not what you want for "argument with different size" and "not optional argument not passe but unused", I'd use the same option but explicit disable those two checks: cobc --debug -fno-ec=program-arg-mismatch -fno-ec=program-arg-omitted.
Ideally compile all programs that way, then rerun the test and very likey see the error, or at least get an error message before/after CALL when the internal codespace is broken.
In most cases there is an error in the code "since years" - you just get a different problem when switching to another compiler because of a different memory layout outside of 01/77 vars and/or different "internal" storage that you trash.
Last edit: Simon Sobisch 2023-12-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using GNU 3.2 , We are migrating source from MF to GNU . We have cases like call subprogram with less no. of arguments , Sometimes length of the linkage variable is mismatch ( however the missing linkage area not used during that call), Some times these calls are getting Segment fault SIGSEGV in GNU . Not always linkage mismatch giving SIGSEGV error , ** Some observations like calling same subprogram multiple time with different arguments / linkage size,** call subprogram1 have mismatch in linkage but SIGSEGV it getting call subprogram2 which has correct call parameters.
Is there any runtime or compile time parameter GNU can treat mismatch in arguments treat as optional ?
A SIGSEGV can have too much reasons, very often then are the result of a problem that happened much earlier than the actual SIGSEGV, so your diagnostic "not used when there is a SIGSEGV" may be correct (because its a follow-up problem of an earlier invocation).
Of course: the best option would be to change the
LINKAGEandPROCEDURE DIVISION USINGto be "standard conforming", for programs like this that means usingANY LENGTHandOPTIONALplus a one-time check before using the optional arguments withIF LINK-ARG NOT OMITTED- but you may not have the option to do so.If you compile with
cobc --debugthen nearly all SIGSEGV get replaced by a nice abort, specifying what the problem is at the time where it happens.As this is not what you want for "argument with different size" and "not optional argument not passe but unused", I'd use the same option but explicit disable those two checks:
cobc --debug -fno-ec=program-arg-mismatch -fno-ec=program-arg-omitted.Ideally compile all programs that way, then rerun the test and very likey see the error, or at least get an error message before/after
CALLwhen the internal codespace is broken.In most cases there is an error in the code "since years" - you just get a different problem when switching to another compiler because of a different memory layout outside of 01/77 vars and/or different "internal" storage that you trash.
Last edit: Simon Sobisch 2023-12-05