Activity for Edward Hart
-
Edward Hart modified ticket #156
MF LINE and COL screen clauses
-
INPUT not reserved word in DEBUGGING MODE
-
Fixed in [r4355]. The issue is due to DEBUG-NAME and INPUT having the same hash. DEBUG-NAME is saved first into the reserved word table (with key 38). INPUT is saved after (with key 39, since 38 is taken by DEBUG-NAME). When DEBUG-NAME was removed after parsing DEBUGGING MODE, 38 is now a valid key for INPUT. However, the reserved word info for INPUT was still at 39 and had not been adjusted. The fix was to check all entries (up to the next NULL) following a deleted entry and move them, if needed,...
-
Fixed bug #764 "INPUT not reserved word in DEBUGGING MODE".
-
INPUT not reserved word in DEBUGGING MODE
-
#include <parser.h> broken in Windows 10
-
ftruncate undefined in Visual C++
-
ssize_t undefined in Visual C++
-
Fixed failing tests in manual screen test.
-
Exciting. The patch should be based on trunk. Could you share the patch you already have? I'd be interested to look through it, even if it can't yet be applied to trunk.
-
No, feel free to unassign me.
-
I've included the version because it indicates what branch I'm basing the manual on, which is trunk, i.e. 4.0-early-dev. Admittedly, the grammar does also include 3.1.1-dev only changes, but this is a hopefully a temporary situation because most of those changes should eventually get merged up to 4.0.
-
Attached is the Grammar updated to [r3967] and with the error in ADD (and also in DIVIDE) fixed.
-
"rounded-phrase" in Format 1 od ADD statement
-
Fixed in [r3968], along with other issues with ADD and DIVIDE.
-
Grammar: updated to [r3967].
-
I tried compiling an application that I have running using Microfocus Object Cobol on SCO using GNUcobol on Linux, using the -std=mf option. The program compiled cleanly, but when executing it, the values returned by function keys are different. In MF,. Function keys 1 thru 10 return 02 thru 11. In Gnucobol, Function keys 1 thru 10 return 01 thru 10. IDENTIFICATION DIVISION. PROGRAM-ID. FKEY. ENVIRONMENT DIVISION. INPUT-OUTPUT SECTION. DATA DIVISION. WORKING-STORAGE SECTION. 01 CBL-LENGTH PIC X(4)...
-
Thanks for the report, Mauirizio. I've reproduced the behaviour and found the bug in: GnuCOBOL replaces every space with an underscore because it sees that every field in S-RESET can be used for input. However, it doesn't see that that shouldn't be done in a DISPLAY. I'll commit the fix shortly. (If you need a temporary workaround, replacing USING with FROM makes the DISPLAY appear correctly.) EDIT: I've created a bug ticket [bugs:#665].
-
Space replaced with underscore in DISPLAY of USING screen field
-
Fixed in branches/gnucobol-3.x in [r3737]. Marked as pending, to be closed when a manual screen section testsuite entry is added.
-
Fixed bug #665 "Space replaced with underscore in DISPLAY of USING screen field".
-
Space replaced with underscore in DISPLAY of USING screen field
-
Thanks for the report, Mauirizio. I've reproduced the behaviour and found the bug in: GnuCOBOL replaces every space with an underscore because it sees that every field in S-RESET can be used for input. However, it doesn't see that that shouldn't be done in a DISPLAY. I'll commit the fix shortly. (If you need a temporary workaround, replacing USING with FROM makes the DISPLAY appear correctly.)
-
I presume "dynamic" implies both forms from above ? fassign-clause=mf,dynamic Correc t ? -fassign-clause=mf and -fassign-clause=dynamic are synonyms. An assign clause like ASSIGN sysut1 is interpreted as ASSIGN DYNAMIC sysut1. This means sysut1 is taken to be the name of a variable and you can do MOVE "/my/file/path" TO sysut1. Similarly, -fassign-clause=external is a syonym for -fassign-clause=ibm and ASSIGN sysut1 is interpreted as ASSIGN EXTERNAL sysut1. The new synonyms provide Micro Focus nomenclature....
-
I presume "dynamic" implies both forms from above ? fassign-clause=mf,dynamic Correc t ? -fassign-clause=mf and -fassign-clause=dynamic are synonyms. An assign clause like ASSIGN sysut1 is interpreted as ASSIGN DYNAMIC sysut1. This means sysut1 is taken to be the name of a variable and you can do MOVE "/my/file/path" TO sysut1. Similarly, -fassign-clause=external is a syonym for -fassign-clause=ibm and ASSIGN sysut1 is interpreted as ASSIGN EXTERNAL sysut1. The synonym synonyms provide Micro Focus...
-
Merged [r3735] from trunk.
-
As part of improving the ASSIGN clause syntax checks, new configuration options were added to control what extensions are allowed. The new config options all begin with assign-, which is why the abbreviated compiler flag -fassign is now ambiguous. IBM/EXTERNAL format is still suppoted - -fassign-clause=ibm will work as expected. I have clarified the help text in [r3735].
-
Added possible values for assign-clause and screen-section-rules help text.
-
Improved numeric screen ACCEPT: initial cursor position and beep on end of field
-
Removed obsolete comment.
-
r3715 broke build
-
Thanks for this! Fix committed in [r3730].
-
Corrected [r3721] ([bugs:#664]).
-
Incorrect "Value size exceeds data size" warning with floating-insertion
-
Reproduced in [r3729] of trunk.
-
Partially done in [r3729]. Remains to add tests, maybe runtime configuration options and code to make cursor jump to appropriate digit on entering a numeric field.
-
Partially done in [r3279]. Remains to add tests, maybe runtime configuration options and code to make cursor jump to appropriate digit on entering a numeric field.
-
Add ACCEPT of decimal fields to screen section testsuite
-
Improved numeric screen ACCEPT behaviour.
-
Added expected-failing test with >>TURN and GO TO.
-
Added tests and fixed issue with >>TURN and recursion.
-
Fixed dpc-in-data tests failing when no JSON handler is present.
-
JSON-C support added to trunk in [r3721]. I've not included the changes to configure: I followed the example of the INDEXED libraries in having --with-json=<library> and --with-<json-library>. I think for consistency the JSON and INDEXED libraries should have the same kinds of configure flags. I copied cJSON in having a json-c-local option. I didn't look into whether it made sense, so feel free to delete it.
-
Added JSON-C as a JSON handler (see [patches:#45]).
-
Attached is an update to [r3716]. It covers all changes to be found in 3.1-RC, as well a few that aren't: these extra changes will either be in the final release of 3.1 or in 4.0. Complete details are found in the Changelog.
-
Grammar: improved MF directives syntax.
-
Grammar: again correct DELETE FILE syntax.
-
Grammar: correct DELETE FILE syntax.
-
Grammar: updated to [r3716].
-
I've re-checked the JSON-C API and found a workaround. The function json_object_new_double_s allows a double to be serialized as a user-specified string. So, we can tell JSON-C every number is 0.0 and give a string with the actual value. Attached is the updated patch.
-
Sorry about the word list and conf file; they're in this updated patch.
-
COBOL 202X support
-
The error suggests you have out-of-control recursive PERFORM statements. If you're sure you're program is working correctly, you can work around the error by: Increasing the stack size: add the cobc option -fstack-size=<large-number-here>. Disabling stack overflow checks: add the cobc option -fno-stack-check. (Stack overflow checks are disabled by default, but are enabled if you're compiling with the parameters -debug or -g.)
-
Patch version 4: cobcrun support added, with a new parameter --param. This is some ugliness: The options for PARM-style linkage depends on the endianness of COMP, which must be indicated by --param=parm-big-endian or --param=parm-native. I chose a random number of 1024 for the maximum size of the parameter. This could be too small or could lead to spurious "OCCURS DEPENDING ON out of bounds" errors. (I'm open to ideas for a better constant.) Maybe add a compiler warning if a program has a PARM-like...
-
Patch version 4: cobcrun support added, with a new parameter --param. This is some ugliness: The options for PARM-style linkage depends on the endianness of COMP, which must be indicated by --param=parm-big-endian or --param=parm-native. I chose a random number of 1024 for the maximum size of the parameter. This could be too small or could lead to spurious "OCCURS DEPENDING ON out of bounds" errors. (I'm open to ideas for a better constant.) Maybe add a compiler warning if a program has a PARM-like...
-
Thank you for the report. Some of the inconsistencies are problems with the compiler and some are just idiosyncracies of COBOL. QUOTE and '""'. This is a bug, using QUOTE should give a warning. ZERO and 0. This is a bug; since 0 is accepted with a warning, so should ZERO. Inconsistent display with invalid numeric data. This is a valid instance of undefined behaviour. By default, the option pretty-display is enabled and this clearly leads to odd results with invalid data. Compiling with -fno-pretty-display...
-
Compiler error messages inconsistencies
-
IF conditions weird behaviour
-
Fixed in [r3713] and merged to gnucobol-3.x in [r3714].
-
Merged [r3713] from trunk.
-
Fixed bug #663 "IF conditions weird behaviour".
-
IF conditions weird behaviour
-
Thank for the report, Nikos! I can reproduce both issues.
-
Added dpc-in-data config option and directive.
-
Harden compilation by default
-
Harden compilation by default
-
Harden compilation by default
-
Harden compilation by default
-
I don't think JSON-C will work. It is mostly fine, but there are issues with decimal number output, which break the "JSON GENERATE trimming" test. This is due to having to cast decimal numbers to double, which I feel is not acceptable and risks incompatibility with MF's and IBM's JSON handlers. This problem does not occur with cJSON, since we can format numbers as we want by inserting raw strings into the JSON. A quick patch for JSON-C support is attached.
-
I'll have a look into this now.
-
Fixed clang warnings.
-
I've looked into this and can't see much to move. I've attached a patch which removes 400 lines (out of 18000) from parser.y. There are two main problems: While it is possible to move all the static functions, they use a lot of global variables. Moving these functions will be error-prone (and make the remaining code uglier). Most code in yyparse is quite minimal - around 3-5 lines per block. It's possible to remove this - we could have a strict "all validating/emitting in typeck.c/field.c" policy...
-
Generate initial exception tables for files and reviewed use of cob_set_exception.
-
I think I've basically done [feature-requests:#358] now, so I would like to commit the patch as-is. As for what to do next: posix should be very quick to do unix should also be relatively easy chaining syntax checks will also be easy chaining implementation might take a while and would probably be best done with the (MF/AcuCOBOL) CHAIN or (RM/COBOL) CALL PROGRAM statements mapping might be quite hard - I think it will have to be implemented in cobc/codegen.c, instead of a wrapper in libcob/call....
-
I think I've basically done [feature-requests:#358] now, so I would like to commit the patch as-is. As for what to do next: posix should be very quick to do unix should also be relatively easy chaining syntax checks will also be easy chaining implementation might take a while and would probably be best done with the CHAIN or CALL PROGRAM statements mapping might be quite hard - I think it will have to be implemented in cobc/codegen.c, instead of a wrapper in libcob/call.c
-
Patch version 3: parm shim moved to call.c, -fmain-linkage=mapping added as pending (along with testsuite entry above). The actual handling of the parm value and the CMDLINELINKAGE directive is noted in [feature-requests:#358] - mapping is very different from this as this maps possibly multiple entries directly Thanks for this! I hadn't seen the difference between #357 and #358 before you mentioned this. Well, I'll keep posting patches here for consistency's sake. ... acu.conf it seems it should...
-
Segfault with reserved word in SELECT
-
Merged in [r3707].
-
No checks on UNSTRING COUNT items
-
Merged in [r3707].
-
Merged revisions 3677, 3684 and 3700 from trunk.
-
compiler divide-by-zero crasher
-
compiler divide-by-zero crasher
-
Fixed in branches/gnucobol-3.x in [r3706].
-
Fixed bug #659 "compiler divide-by-zero crasher".
-
compiler divide-by-zero crasher
-
What an interesting bug! Thank you for investigating and solving this. I can confirm the patch works. I'll commit it shortly, along with a testsuite entry.
-
Attached is a quick update. Added main-linkage option as above, but with "mapping" renamed to "parm" - I think the IBM terminology will be more familiar to users. Added the COMMANDLINELINKAGE directive. It remains to extract all the new codegen code to a new function in libcob/call.c.
-
Return I-O exceptions to exception.def.
-
Added support for runtime exception checking setting.
-
Added CHECKREFMOD directive.
-
Merged all eligible revisions from /branches/gnucobol-3.x between r3664 and r3695.
-
Fixed minor memory leaks.
-
Hacking GnuCOBOL
-
Hacking GnuCOBOL
-
Hacking GnuCOBOL
-
Added vsam-status config option.
-
Incorrect test of array index with -x
-
Incorrect test of array index with -x
1 >