[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gnubol: OFIN depth



    
I believe we are in agreement about the approximate largest valid depth for 
OFIN clause groups, of about 50/51.  Perhaps some of my posts did not clarify 
that I was thinking clause count where others were saying the token count. 

In my experiments I can project a hypothetically useful distinction between a 
reference modifeable data reference, and a non reference modifiable data 
reference.  I can code recurses, but once I generalize it to a recurse I can 
not stop it from potentially infinite recurse. I surely can count clauses or 
tokens (50/51 or 100/101/102). And I can sense the threshold transition. But 
I can not stop the deeper and deeper recursions unless I hack the 
manipulation that I expect the lexer or filter that supplies me with SYMT 
derived type specificity for tokens manifesting in this parse.

There is a need to halt the recurse, to prevent malicious code from being at 
compiler crash.

Some of that commentary is also meant to clarify for one who was kind enough 
to respond to
some of my earlier posts. I do not say we need 50 explicitly distinct rules 
to deal with OFIN agglutinations.  Any recursive tool works fine.  I can't 
easily see how to stop the thing from
diving needlessly far if it encounters bad code; but you know that is a 
problem for nested IFs as well, so surely we will discover a generalizable 
solution before long.

However, I do remain convinced that it would be good to distinguish reference 
modifiable, subscriptable, and function references by type in distinct 
tokens. And the discussion of 
valid depth should not be taken as an agreement about best maximum depth 
actually coded. I have that idea of an error manager as the primary design 
concept for the compiler. >::::::::


Best Wishes,
Bob Rayhawk
RKRayhawk@aol.com






--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.