leads to Quote:
I've compiled this program using OC 1.0 without any warning. What's the problem about this line?

human

Good find human.

This has to do, afaik, with changes made to support PROGRAM-ID CaseSensitiveName.

And it uncovers another issue. Draft 20xx specs that WRITE FROM should handle FUNCTION (with category limitations) and the current parser.y doesn't account for that, along with missing the figurative constants you have discovered. Long live pre-releases and extended soak-time.

I have a trial patch, but it'll be not quite right, and in compiler speak that is the same as wrong, so I'm not posting it this time. ;)

Cheers,
Brian

Brian, could you please submit (and if possible explain) your trial patch? What is wrong about it? Maybe we can fix this as a community?
I'd like to have that bug source fixed for Roger being able to just take this into the next tarball.

human

Bumping up this one for a patch in OpenCOBOL-CE.
@brian: here you go

human

Will do human.

I got parser.y and friends to all write from figuratives, but changes to the parse tree need very special care and attention. Changes are relatively easy ... but.

A change to the scan rules can have weird effects on completely unrelated usage of the reserved words (complex backtracking yadayada, stuff I don't feel comfortable pretending that I can internally visualize all at once).

Last time I tried to run a VCG (a visual representation of the compiler graph) it ran out of resources (OpenCOBOL is likely one of the most complex scanner.l and parser.y pairs in existence). Before I fling code on the world, I'd like to get a vcgview or similar tool working to verify deltas after the changes.

found a script that looks like it reads gcc -fdump-tree-vcg and outputs Graphviz .dot files, need to test and maybe tweak

Cheers,
Brian

An addition as I've read this in the 20xx draft today:
WRITE FROM SPACES/SPACE should insert ONE space into the record (depends on additional clauses and FD, of course - in line sequential files you will have either a simple additional line break or many spaces (if COB_LS_FIXED is used)).

@Brian: just add it to the parser and place some test progs into the suite, we'll find errors later on, if they're in. And if you find good tools for visualizing, please use them when we have changes to parser/lexer stuff.

human

Just to be clear(er)

Write Rec-Name from Spaces

doesn't "exactly" insert one (space) character. Rather it is more accurate to say that it MOVEs "one space chacter" (eg " ") to the 01-record name and then writes that record.

This means that ALL normal rules for "padding" and writing apply, i.e. it is EXACTLY equivalent to

Move " " to Rec-Name
Write Rec-Name

(and if Rec-Name is a NATIONAL item, the space is a national space)

This may be what Human, meant, but I did want to make cerain that it was "clear".