Hi Przemek,
It would be better IMO too, to not impose artificial limits
just to present a bit more meaningful error message, since
these problems don't normally occur in user code.
I think - if we can - we should just fix the problems
causing it (those you describe), preferably using the
current strict PP feature set, again, if possible. (I
feel these fixes to be too complicated for me to do though)
As for the concatenation feature of PP, if enabled, what
kind of incompatibilities can it cause for legacy Clipper
code?
As an alternate solution, we might simply say that HB_C52_STRICT
is not a working codepath, and the sole purpose is to document
Clipper/Harbour differences in proper detail.
Brgds,
Viktor
On 2008.01.09., at 10:37, Przemyslaw Czerpak wrote:
On Tue, 08 Jan 2008, Szakáts Viktor wrote:
I understand, thanks for the tip. I've just committed this
modification.
Thank you.
Something's still not right though. When compiling checkbox.prg
(the first OO code in the build process), lots of syntax errors
appear, then - after a slight pause - comes a memory allocation
error:
harbour checkbox.prg /p /n /w /i..\include
Harbour devel build 1.1-1 Intl.
Copyright (c) 1999-2008, http://www.harbour-project.org/
Compiling 'checkbox.prg' and generating preprocessed output to
'checkbox.ppo'...
checkbox.prg(69) Error E0030 Syntax error: "syntax error at '.'"
In strict C52 mode we do not have support for functions with variable
number of parameters and ... operator. This can be easy resolved.
checkbox.prg(81) Error E0030 Syntax error: "syntax error at
'BITMAPS'"
checkbox.prg(82) Error E0030 Syntax error: "syntax error at
'BUFFER'"
checkbox.prg(83) Error E0030 Syntax error: "syntax error at
'CAPCOL'"
checkbox.prg(84) Error E0030 Syntax error: "syntax error at
'CAPROW'"
checkbox.prg(85) Error E0030 Syntax error: "syntax error at
'CAPTION'"
checkbox.prg(86) Error E0030 Syntax error: "syntax error at 'COL'"
[...]
For SETGET methods we also need identifier concatenation too add "_"
prefix. This cannot be easy resolved because Clipper's PP does allow
to concatenate any identifiers. For this we will have to use stringify
and RT function which will convert strings to symbols.
Unrecoverable error 9006: hb_xgrab can't allocate memory
Side effect of possible recursions which can appear in strict C52 mode
because Clipper always preporcess nested directive in result pattern.
To eliminate it we will have to make some deeper modifications in our
hbclass.ch or use trick with #include like in class(y).ch
You can also easy disable strict compatibility here by modification
in hbpp.h, look at:
#ifdef HB_C52_STRICT
# define HB_PP_TOKEN_ISEOS(t) HB_PP_TOKEN_ISEOL(t)
# define HB_PP_TOKEN_ISEOP(t,l) HB_PP_TOKEN_ISEOL(t)
#else
/* End Of Subst - define how many tokens in line should be
translated,
Clipper translate whole line */
and change it to:
#ifdef HB_C52_STRICT_INFO
# define HB_PP_TOKEN_ISEOS(t) HB_PP_TOKEN_ISEOL(t)
# define HB_PP_TOKEN_ISEOP(t,l) HB_PP_TOKEN_ISEOL(t)
#else
/* End Of Subst - define how many tokens in line should be
translated,
Clipper translate whole line */
Memory allocation error is not good results of such recursive
substitution
but also in Clipper it's possible to create rules which will give the
same results.
Unfortunately it's one of situations which cannot be easy trap and
reported without introducing some fixed limits which may reduce
functionality. The translation counter does not help because I can
easy create rule which will double tokens in translated line, f.e.:
#command CMD <*x*> => CMD <x>, <x>
CMD 1
and as you can easy calculate the memory allocation will be geometric
(2^N) to number of iterations. In such simple example it's possible
to easy detect cycle so this can be resolved but it's also possible
to create other examples where in practice it cannot be done. The only
one possible solution to avoid memory allocation errors seems to be
hardcoding some fixed limit for total allocate memory or number of
allocated tokens and report error like 'expression to complex' when
such limit is reached. So far I haven't added it intentionally to not
reduce functionality but I'll add such limit in the future for
programs
which uses PP at RT.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
