mridoni / gixsql

GixSQL is an ESQL preprocessor and a series of runtime libraries to enable GnuCOBOL to access PostgreSQL, ODBC, MySQL, Oracle and SQLite databases.
GNU General Public License v3.0
16 stars 8 forks source link

Unexpected WORD on simple program #130

Open processor286 opened 2 years ago

processor286 commented 2 years ago

Attempting to preprocess simple program for testing, this one doesn't have any SQL in it yet.

I was actually trying to test anonymous 01 levels as I have a lot of these in the codebase, and a more complex test program failed SIGSEGV on an anonymous 01 level, so I thought to provide a simple test program:

        identification division.
        program-id. t1.
        data division.
        working-storage section.
        01 block1.
                03 mypic1 pic x(10).
        01.
                03 mypic2 pic x(10).

        procedure division.
        a-main section.
                display 'hello world'.
                stop run.

This will compile and run with cobc:

cobc -x t1.cob && ./t1
hello world

But attempting to preprocess it:

gixpp -v -d -C -e -i t1.cob -o t1.cbl
ESQL: Input file: t1.cob
ESQL: Output file: t1.cbl
ESQL: Copy extension: .
ESQL: Copy extension: .CPY
ESQL: Copy extension: .cpy
ESQL: Option [consolidated_map] : [true]
ESQL: Option [emit_cobol85] : [true]
ESQL: Option [emit_debug_info] : [false]
ESQL: Option [emit_map_file] : [false]
ESQL: Option [emit_static_calls] : [false]
ESQL: Option [params_style] : [d]
ESQL: Option [picx_as_varchar] : [false]
ESQL: Option [preprocess_copy_files] : [false]
00002 :         identification division.
00002 :         program-id. t1.
00003 :         data division.
00004 :         working-storage section.
t1.cob:4: error: syntax error, unexpected WORD

versions in use:

gixpp --version
gixpp - the ESQL preprocessor for Gix-IDE/GixSQL
Version: 1.0.18a
libgixpp version: 1.0.18a

And:

cobc --version
cobc (GnuCOBOL) 3.1.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built     Nov 13 2022 19:21:19
Packaged  Dec 23 2020 12:04:58 UTC
C version "11.2.0"
mridoni commented 2 years ago

Thanks, I will look into it.

mridoni commented 2 years ago

One thing: the parser is - in many points - currently geared towards uppercase-only source. I know this is a limitation (a major one for some existing code bases) and it will be addressed in the future, as well as (probably not at the same time) the lack of support for free-format source. In the meantime I just wanted to point this out because it's probably not totally clear from the docs.

processor286 commented 2 years ago

I find it is sensitive to the location of some lines even within area A, e.g. this works ( I shfted working-storage section to begin in column 8 instead of 9):

00002 :         identification division.
00002 :         program-id. t1.
00003 :         data division.
00004 :        working-storage section.
00005 :         01 block1.
00006 :                 03 mypic1 pic x(10).
00007 :         01.
00008 :                 03 mypic2 pic x(10).
00009 : 
00010 :         procedure division.
00011 :         a-main section.
00012 :                 display 'hello world'.
00013 :                 stop run.

I lazily use TAB - 8 spaces when I'm writing short COBOL programs, as one TAB puts you in area A at column 9 , then two puts you in area B at column 17. Good enough for short snippets mostly.

But apparently working-storage section. needs to be in column 8.

I don't know what the standard says about this, but in my old head I was sure that 'anywhere in area A' was acceptable for division and section headers even before free form source.

mridoni commented 2 years ago

I performed some tests, most of this is definitely linked to the parser (actually the lexer) being case-sensitive and geared towards uppercase. This behavior must obviously be changed but it is not going to be a quick fix