Activity for Robert Dubner
-
Robert Dubner posted a comment on ticket #991
INSPECT works by sweeping through the "EFABDBCGABEFGG" text one position at a time. At each position, it checks each of the "FOR" conditions. When a condition is satisfied, it increments the counter for that condition, the remaining conditions are skipped for that position, and the position pointer is advanced by the length of the match. So, in the present case: Position 1 is "EF..", so we have a match for LEADING "EF". COUNT-2 is incremented to 1, and the pointer updated to position 3. Position...
-
INSPECT example from ISO: bad COUNT-4; corrupt REPLACING
-
INSPECT example from ISO calculates incorrect COUNT-4
-
EVALUATE [...] WHEN - ]...] crashes GC3.2
-
Simon, and @vcoen, I have found this discussion to be extremely useful, and I appreciate it very much. I believe that the GC documentation surrounding DEPENDING ON should be expanded. It basically covers rule 7). The behavior covered by 8a) and 8b) needs to be covered. I would hope that the expansion would be written in language plain enough -- maybe even with examples -- in an effort to be understandable the first time through, rather than the third or fifth time. I have just tested these three...
-
Simon, and @vcoen, I have found this discussion to be extremely useful, and I appreciate it very much. I believe that the GC documentation surrounding DEPENDING ON should be expanded. It basically covers rule 7). The behavior covered by 8a) and 8b) needs to be covered. I would hope that the expansion would be written in language plain enough -- maybe even with examples -- in an effort to be understandable the first time through, rather than the third or fifth time. I have just tested these three...
-
A light begins to dawn. Unfortunately, so far it is just illuminating my confusion. In the example I posted, the data structure is 01 PLINE. 03 PLINE-LEN PIC S9(4) COMP-5. 03 PLINE-TEXT. 04 FILLER PIC X(1) OCCURS 1 TO 80 DEPENDING ON PLINE-LEN. The instructions are MOVE 5 TO PLINE-LEN MOVE 'the first part in' TO PLINE-TEXT Just so I am sure: When MOVEing something to PLINE-TEXT, the DEPENDING ON variable is PLINE-LEN, which is not subordinate to PLINE-TEXT, so rule 8a) applies, and the MOVE is limited...
-
A light begins to dawn. Unfortunately, so far it is just illuminating my confusion. In the example I posted, the data structure is 01 PLINE. 03 PLINE-LEN PIC S9(4) COMP-5. 03 PLINE-TEXT. 04 FILLER PIC X(1) OCCURS 1 TO 80 DEPENDING ON PLINE-LEN. The instructions are MOVE 5 TO PLINE-LEN MOVE 'the first part in' TO PLINE-TEXT Just so I am sure: When MOVEing something to PLINE-TEXT, the DEPENDING ON variable is PLINE-LEN, which is not subordinate to PLINE-TEXT, so rule 8a) applies, and the MOVE is limited...
-
I am aware that the 25-December-2021 version of the GnuCOBOL Programmer's Guide has this, and as far as I can tell, only this, to say about that: The optional DEPENDING ON clause can be added to an OCCURS to create a variable length table. In such cases, the value of integer-1 specifies what the minimum number of entries in the table will be while integer-2 specifies the maximum. Such tables will be allocated out to the maximum size specified as integer-2. At execution time the value of identifier-1...
-
This is a program derived from one of the GnuCOBOL tests. IDENTIFICATION DIVISION. PROGRAM-ID. prog. DATA DIVISION. WORKING-STORAGE SECTION. 01 PLINE. 03 PLINE-LEN PIC S9(4) COMP-5. 03 PLINE-TEXT. 04 FILLER PIC X(1) OCCURS 1 TO 80 DEPENDING ON PLINE-LEN. procedure division. a-main section. MOVE 5 TO PLINE-LEN MOVE 'the first part in' TO PLINE-TEXT MOVE 30 TO PLINE-LEN DISPLAY PLINE-TEXT MOVE 'the first part in' TO PLINE-TEXT DISPLAY PLINE-TEXT STOP RUN. Compiled with cobc (GnuCOBOL) 3.2-dev.0 it...
-
READ AT END should be an error for ACCESS RANDOM file
-
Maybe. I have test code that uses COPY to bring in variables and code, and it's working properly, last I checked, on both Windows and Linux. It concerns me that COBC, in the reported scenario, is generating .C code that is subsequently confusing the following C compilation. I always get confused when there are escaped backslashes, but it seems to me that the filename in the generated line: #line 9 "d:/bspgui41/cpy\\CY020D.CBL" is somehow being interpreted as d:/bspgui41/cpy\CY020D.CBL which leads...
-
It is page 216 in the US Letter format. In the 2021-Apr-12 A4 version, it's page 198. The section is "6.9.49. USAGE"
-
I just deleted and recreated my build directory, and redid the ../configure. I still see #define COB_CONFIG_DIR "${prefix}/share/gnucobol/config"
-
I did not use the CI-generated tarball. On my Ubuntu system I effectively did svn update && make && make checkall && make dist and sent him the resulting tarball.
-
Incorrect config.h entries for COB_CONFIG_DIR and COB_COPY_DIR
-
Removing the COBCD branch, which is no longer needed
-
Fixed some inconsequential typos in dump code generation
-
Merged and deconflicted with 3.x r3921
-
Merged in gnucobol-3.x through r3907
-
Merged in gnucobol-3.x through r3900
-
Merged in gnucobol-3.x through r3894
-
Merged in gnucobol-3.x through r3877
-
Merge in 3.x through r3868
-
Merged in 3.x through r3856; modified configure.ac to eliminate '-Wp,-DFORTIFY_SOURCE'
-
Merged in gnucobol-3.x through r3850
-
Merged in gnucobol-3.x through r3845
-
Merged in gnucobol-3.x through r3842
-
Merged in gnucobol3.x through r3840
-
Merged in gnucobol-3.x through r3838
-
Output doubled backslashes in output_c_info routine
-
Implement -fgen-c-comment-fdump switch
-
Merged gnucobol-3.x through Revision 3826 into cobcd
-
Simon, the conflict occurs because of the meaning of the "-c" switch. It means "Compile and assemble [and produce a .o object file]". But two source files together can't form a single .o object file output. That's why you aren't accepting the -o switch. Remove the -o clause, and the command cobc -c -g rtest.s rtest.sym.c properly produces an rtest.o file and an rtest.sym.o file. In short, this isn't a bug. It's operator error, and the compiler is responding appropriately.
-
Simon, the conflict occurs because of the meaning of the "-c" switch. It means "Compile and assemble [and produce a .o object file]". But two source files together can't form a single .o object file output. That's why you aren't accepting the -o switch. Remove the -o clause, and the command cobc -c -g rtest.s rtest.sym.c properly produces a rtest.o file and an rtest.sym.o file. In short, this isn't a bug. It's operator error, and the compiler is responding appropriately.
-
-fdump=ALL with LOCAL-STORAGE and REDEFINES comments for cbl-gdb
-
Forked 3.x to support COBOLworx cbl-gdb Version 4
-
I'm the person who authored the COBOLworx .vsix file. I just updated https://cobolworx.com/pages/downloads.html to point to the 3.2.1 version. As Simon has pointed out, there are a number of developments to the debugger that will become available shortly after the release of 3.1-rc2
-
I have looked into failure of 'make check' #0333, and here is what happens on a MacBook Pro running Catalina. The problem is in the cobc compiler. I reduced the 0333 test program down to this code. ~~~ IDENTIFICATION DIVISION. PROGRAM-ID. tutorial. PROCEDURE DIVISION. move low-values to 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'- 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'- 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'- 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'- 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'- 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'-...
-
Brian, if it's not already clear, those debugging extensions are my baby. I've seen that business of the COBOL intermixed with the C, and it doesn't have to be there. It depends on how cobc was compiled. Were you using one of my versions of cobc, or one that you created? And if it was mine, please let me know which one.
-
< grin > And I couldn't be more delighted. I just wanted to emphasize that there is no real need to see that nastiness. Your best bet is not to use the "start" command. GDB thinks it's debugging a C program, so the start command sets a breakpoint at the symbol "main". Which does exist, but it's nowhere near any of the places in the binary for which #line directives were issued. So gdb does the best it can, which is nice, but the messages are a bit frightening. I recommend that you instead issue a...
-
< grin > And I couldn't be more delighted. I just wanted to emphasize that there is no real need to see that nastiness. Your best bet is not to use the "start" command. GDB thinks it's debugging a C program, so the start command sets a breakpoint at the symbol "main". Which does exist, but it's nowhere near any of the places in the binary for which #line directives were issued. So gdb does the best it can, which is nice, but the messages are a bit frightening. I recommend that you instead issue a...
-
<grin> And I couldn't be more delighted. </grin> I just wanted to emphasize that there is no real need to see that nastiness. Your best bet is not to use the "start" command. GDB thinks it's debugging a C program, so the start command sets a breakpoint at the symbol "main". Which does exist, but it's nowhere near any of the places in the binary for which #line directives were issued. So gdb does the best it can, which is nice, but the messages are a bit frightening. I recommend that you instead issue...
-
Brian, if it's not already clear, those debugging extensions are my baby. I've seen that business of the COBOL intermixed with the C, and it doesn't have to be there. It depends on how cobc was compiled. Were you using one of my versions of cobc, or one that you created? And it it was mine, please let me know which one.
1