August 1997 - Gpc

bison and flex with GPC
by Tom Dye 05 Aug '97

05 Aug '97

Hello, Please excuse a newbie request for help. I'm interested in using a lexer prepared with flex in a GPC program. I gather from the documentation that this is possible, but I'm not enough of a C programmer to figure out how it might be done. Has anyone had experience with this? Can someone provide me with an example of how it might be done? Many thanks in advance. Tom Thomas S. Dye, Ph.D. Home: 813 16th Avenue, Honolulu, Hawaii 96816. Voice (808) 734-2087. Work: International Archaeological Research Institute, Inc., 949 McCully St., Suite 5, Honolulu, Hawaii 96826. Voice (808) 946-2548; Fax 943-0716.

1 0

Re: gpi-hash.c segfaults
by Peter Gerwinski 04 Aug '97

04 Aug '97

According to Bill Currie: > On 31 Jul 97 at 15:08, Jukka Virtanen wrote: > > I suggest that this problem is fixed by casting > > the result of the pointer subtraction to > > (unsigned ptrdiff_t) which is always large enough, > > something like: > > One slight problem: I couldn't find a `ptrdiff_t' in djgpp. However, > it could always be created. Not a slight, but a big problem: (i) See `../cccp.c', line 51; (ii) `ptrdiff_t', even if it exists, is a signed type, and GCC doesn't accept `unsigned ptrdiff_t'. :-( To work around, what about the following? It only must produce a more-or-less unique number ... /* We must avoid negative values. Naturally, we would cast this to * `unsigned ptrdiff_t', but since we cannot be sure that the platform * we compile GPC on will support this, we use `abs' instead. */ #define HASH_FUNC(NODE) ((abs ((NODE) - (tree) 0) >> 2) % MAX_HASH_TABLE) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Pending bugs?
by Peter Gerwinski 04 Aug '97

04 Aug '97

Hi! I have only one thing to fix up before the next beta: The run-time system must learn how to read/write `LongInt's and such. `write[ln]' already works. (Thanks, Frank!) Anything else? Bernhard, did you succeed to reproduce that OOP-related bug? Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: GetFile builtin function
by Peter Gerwinski 04 Aug '97

04 Aug '97

Hi, Bill! Hi, everybody! According to Bill Currie: > > Isn't. That is: the function is provided in rts-file.c (_p_getfile), > but it's not supported by the compiler. You can write `Function GetFile: Pointer; AsmName `_p_getfile';' into your program and just use it, but I see, you want more than this. :-) > How do I go about adding > this (or others) function? I'ld rather get instructions on how to do > it myself rather than a patch (though I can study the patch) so I can > learn how do to it to add more functions later on (such as Lo, Hi > etc). That would be great! Here is a recipe how to introduce a new built-in function into GPC. If it looks like French for you, feel free to ask me - I can speak French (more or less). * Edit `util.c', go into the `KItable[]' and add this identifier with the appropriate flags (`GNU_PASCAL' since it is not part of any other standard). (Perhaps after `DefineSize' is a nice place?) (First Letter Capitalized.) * Edit `parse.y' and add `gpc_GETFILE' (my suggested name for it) to the list of tokens (= constant definitions), perhaps after `p_DEFINESIZE'. * In `parse.y', look how something similar is implemented (e.g., again, `p_DEFINESIZE') and do it similarly. This means: - Give it a return type: "%type <ttype> gpc_GETFILE". - Add it to `new_identifier_1', so the name remains redefinable. - Add it to `rts_fun_onepar', so the parser will take it into account. In case you are not familiar with Bison (I was not when I found GPC): This language essentially is a machine-readable form of syntax diagrams. The `bison' program translates this into a C file not intened to be read by humans. The C stuff indented with two tabs is the "action" to be taken if the pascal parser reads this syntax. * Again in `util.c', function `build_rts_call', write a handler for `gpc_GETFILE'. This is where the real work is done; all the above is administrative stuff. But in this case, it's quite simple: Do the same as `case p_DEFINESIZE' does, i.e. warn about ISO violation, check for errors (hmm ... these functions don't count their arguments ... looks like a bug in GPC ... we should check it ...), and pass the argument to the other parts of `build_rts_call' which will do the work. * Don't forget to follow the GNU coding style guidelines. * Don't forget to send me a patch, so I can study it. ;-) * What about doing the same for `ParamCount' and `ParamStr'? The RTL functions do *almost* the same as their BP equivalents do. Perhaps we should make them truly compatible and built-in? (One problem: `ParamStr' must return a String of unknown length. Where to allocate it?) Welcome to the GNU Pascal development team! Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

GetFile builtin function
by Bill Currie 03 Aug '97

03 Aug '97

Isn't. That is: the function is provided in rts-file.c (_p_getfile), but it's not supported by the compiler. How do I go about adding this (or others) function? I'ld rather get instructions on how to do it myself rather than a patch (though I can study the patch) so I can learn how do to it to add more functions later on (such as Lo, Hi etc). TIA Bill -- Leave others their otherness.

1 0

VB: EFLIB
by Johan Larsson 01 Aug '97

01 Aug '97

Hi, I have written a program for Borland Pascal. I am currently looking for porters for the GNU Pascal environment. It will be released under a modified GNU Library GPL license. Check EFLIB at http://www.ts.umu.se/EFLIB/. Best Regards, Johan Larsson jola(a)ts.umu.se Also, REMEMBER to check out http://www.ts.umu.se/EFLIB/ for a free application framework - SIMPLY SOPHISTICATED.

1 0

Re: pointer-compatibile integers
by Peter Gerwinski 01 Aug '97

01 Aug '97

According to Frank Heckenbach: > > Can there be any problems with signedness, or is it guaranteed that > ptrdiff_t is always signed and of the same size as a pointer? (I should > think so, but after all I've heard in the last time about such things, > I'm getting very careful...) If this is portable, there's no need to > predefine this type. Of course, this is *not* guaranteed. > What about size_t? > [...] > So perhaps only one more integer type (for now)... :-) GNU C has two special types here: SIZE_TYPE and PTR_DIFF_TYPE. Both are machine-dependent. To be compatible, maybe we must provide both? Following the notations for required identifiers in the Extended Pascal standard, we should not use underscores for predefined types. So what about `SizeType' and `PtrDiffType'? Since both are *not* guaranteed to have the same size as a pointer, the other thing, `Ptr[Int|Card|Word]', would be useful, too. This means five more integer types. More suggestions? Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: pointer-compatibile integers (was: gpi-hash.c segfaults)
by Frank Heckenbach 01 Aug '97

01 Aug '97

Peter Gerwinski wrote: > According to Frank Heckenbach: > > > > While we're at it: would it be possible to have predefined Pascal types > > as size_t and ptrdiff_t (and maybe other types?) so that such > > calculations can be done in Pascal? > > Not enough integer types yet? ;-) :-) (But, fortunately, they're not really new types, just the same types with different names...) > This can be be implemented with > > Type > PtrInt = Integer ( BitSizeOf ( Pointer ) ); > > Is this sufficient? Can there be any problems with signedness, or is it guaranteed that ptrdiff_t is always signed and of the same size as a pointer? (I should think so, but after all I've heard in the last time about such things, I'm getting very careful...) If this is portable, there's no need to predefine this type. What about size_t? In BP, I've always used "Word" for memory sizes, and at least for DJGPP and Linux, this would work in gpc, too. But also on other machines (Alpha)? If not, I don't see a way to define size_t in Pascal, so it might have to be predefined... So perhaps only one more integer type (for now)... :-) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0