Pls advise if there is a way to make GPC accept a field name in a RECORD or variable name and that field name or variable name is a reserved or key word in GPC. I am porting software from SPARC SunOS (using SUN PASCAL compiler) to INTEL Solaris 7 (using GPC). For example :
EXAMPLE A:
PROCEDURE Blkkut;
VAR Trow, Tline_nbr, Tcnt :INTEGER; Tptr :Parm_ptr; Tmp_erlin :Er_typ; View :BOOLEAN; Repos :INTEGER;
BEGIN (* Blkkut *) IF Slct_flg THEN BEGIN View := FALSE; Blkcopy(View); <<< this is line 349; View is a GPC reserved word. IF NOT Spare_buffer_used THEN
I get the following errors during compile: Shared_tpl/Mprocsrc/blockcmd.p: In procedure `Blkkut': Shared_tpl/Mprocsrc/blockcmd.p:349: parse error before `View' Shared_tpl/Mprocsrc/blockcmd.p:349: missing `)' Shared_tpl/Mprocsrc/blockcmd.p:349: too few arguments to function `Blkcopy' Shared_tpl/Mprocsrc/blockcmd.p:349: parse error before `)'
EXAMPLE B:
Sortmask_rec = PACKED RECORD Bin_nbr :Int8; Class :Class_typ; <<< line 226 Class is a GPC reserve word. Any :BOOLEAN; Display_ch :Displ_char; Socket_quality_delta :INT16; Test_Sum :INT16; Test_List :PACKED ARRAY[1..Maximum_tests] of INT16; END;
Error messages during compile. In file included from Shared_tpl/Inc/tplmain.typ:38, from Shared_tpl/Mprocsrc/blockcmd.p:67: Dependent/Inc/misc.typ:226: parse error before `Class' Dependent/Inc/misc.typ:226: extra semicolon
I am using gpc version 20010623, based on 2.95.2 19991024 (release) and I use only -O and --no-mixed-comments options when calling gpc.
Thanks in advance for any assistance.
Jing Gloria Texas Instruments
"Gloria, Jing" wrote:
Pls advise if there is a way to make GPC accept a field name in a RECORD or variable name and that field name or variable name is a reserved or key word in GPC. I am porting software from SPARC SunOS (using SUN PASCAL compiler) to INTEL Solaris 7 (using GPC). For example :
EXAMPLE A:
PROCEDURE Blkkut;
VAR Trow, Tline_nbr, Tcnt :INTEGER; Tptr :Parm_ptr; Tmp_erlin :Er_typ; View :BOOLEAN; Repos :INTEGER;
BEGIN (* Blkkut *) IF Slct_flg THEN BEGIN View := FALSE; Blkcopy(View); <<< this is line 349; View is a GPC reserved word. IF NOT Spare_buffer_used THEN
I get the following errors during compile: Shared_tpl/Mprocsrc/blockcmd.p: In procedure `Blkkut': Shared_tpl/Mprocsrc/blockcmd.p:349: parse error before `View' Shared_tpl/Mprocsrc/blockcmd.p:349: missing `)' Shared_tpl/Mprocsrc/blockcmd.p:349: too few arguments to function `Blkcopy' Shared_tpl/Mprocsrc/blockcmd.p:349: parse error before `)'
EXAMPLE B:
Sortmask_rec = PACKED RECORD Bin_nbr :Int8; Class :Class_typ;<<< line 226 Class is a GPC reserve word. Any :BOOLEAN; Display_ch :Displ_char; Socket_quality_delta :INT16; Test_Sum :INT16; Test_List :PACKED ARRAY[1..Maximum_tests] of INT16; END;
Error messages during compile. In file included from Shared_tpl/Inc/tplmain.typ:38, from Shared_tpl/Mprocsrc/blockcmd.p:67: Dependent/Inc/misc.typ:226: parse error before `Class' Dependent/Inc/misc.typ:226: extra semicolon
I am using gpc version 20010623, based on 2.95.2 19991024 (release) and I use only -O and --no-mixed-comments options when calling gpc.
I think if you use --extended-pascal or --standard-pascal that will go away. Info gpc should lead you straight to the applicable documentation.
CBFalconer wrote:
"Gloria, Jing" wrote:
<<< line 226 Class is a GPC reserve word.
I think if you use --extended-pascal or --standard-pascal that will go away. Info gpc should lead you straight to the applicable documentation.
Indeed.
Also, in the particular case of `view', I've disabled it as a reserved word in general contexts, so if you use the most current GPC, it should also work without these options.
Frank
Frank Heckenbach wrote:
CBFalconer wrote:
"Gloria, Jing" wrote:
<<< line 226 Class is a GPC reserve word.
I think if you use --extended-pascal or --standard-pascal that will go away. Info gpc should lead you straight to the applicable documentation.
Indeed.
Also, in the particular case of `view', I've disabled it as a reserved word in general contexts, so if you use the most current GPC, it should also work without these options.
Which brings me to the subject of defaults. In PascalP, after much discussion with myself, I concluded that the proper default was pure standard syntax, with access to extension standard procedures. Such source, if compiled elsewhere, could always be satisfied by providing the missing procedures/functions. If any extended syntax was desired it was necessary to specifically enable them.
Maybe the appropriate default for GPC is --extended-pascal. Then either compile time options or pseudo-comments could further refine it. The user could always select a --gpc-pascal option (which has no standard).
CBFalconer wrote:
Frank Heckenbach wrote:
CBFalconer wrote:
"Gloria, Jing" wrote:
<<< line 226 Class is a GPC reserve word.
I think if you use --extended-pascal or --standard-pascal that will go away. Info gpc should lead you straight to the applicable documentation.
Indeed.
Also, in the particular case of `view', I've disabled it as a reserved word in general contexts, so if you use the most current GPC, it should also work without these options.
Which brings me to the subject of defaults. In PascalP, after much discussion with myself, I concluded that the proper default was pure standard syntax, with access to extension standard procedures. Such source, if compiled elsewhere, could always be satisfied by providing the missing procedures/functions. If any extended syntax was desired it was necessary to specifically enable them.
Maybe the appropriate default for GPC is --extended-pascal. Then either compile time options or pseudo-comments could further refine it. The user could always select a --gpc-pascal option (which has no standard).
No, sorry. This has been discussed and decided long time ago. The default is `--gnu-pascal' (which also exists as an option and compiler directive to reset any previous settings) which means all features allowed (only some evil Borland features warned about).
If you like pure EP, use `--extended-pascal' as your default option, fine. I (and others) have come to the conclusion that EP is not fully sufficient for our needs -- you've probably seen the recent discussion in c.l.p.a-i where I stated some opinions. (And even where it is, I might prefer other alternatives; e.g., I prefer UCSD/Borland style units over EP style modules in most cases.)
Frank
In article CB8F4D9EA060D31188730008C79143C406F8C101@dlee11.itg.ti.com, "Gloria, Jing" j-gloria@ti.com writes
Pls advise if there is a way to make GPC accept a field name in a RECORD or variable name and that field name or variable name is a reserved or key word in GPC. I am porting software from SPARC SunOS (using SUN PASCAL compiler) to INTEL Solaris 7 (using GPC). For example :
EXAMPLE B:
Sortmask_rec = PACKED RECORD Bin_nbr :Int8; Class :Class_typ; <<< line226 Class is a GPC reserve word. Any :BOOLEAN; Display_ch :Displ_char; Socket_quality_delta :INT16; Test_Sum :INT16; Test_List :PACKED ARRAY[1..Maximum_tests] of INT16; END;
You can certainly work around this by adding a {$define class thing} directive to the start of the program/unit. We had exactly the same problem when Class became a reserved word.
Martin Liddle wrote:
In article CB8F4D9EA060D31188730008C79143C406F8C101@dlee11.itg.ti.com, "Gloria, Jing" j-gloria@ti.com writes
Class :Class_typ; <<< line226 Class is a GPC reserve word.
You can certainly work around this by adding a {$define class thing} directive to the start of the program/unit. We had exactly the same problem when Class became a reserved word.
This only has the problem that defines don't work across units.
I'd missed `class' in the original mail (again, please include complete test programs, possibly as MIME attachments, so I can run them directly).
I'll disable `class' as a keyword for now, since it's not been implemented yet, anyway. By the time it will be implemented, there's (hopefully) a feature to disable certain keywords explicitly.
Frank
-
CBFalconer -
Frank Heckenbach -
Gloria, Jing -
Martin Liddle