GNU Pascal Homepage - gpc - gpc-announce - gpc-de - gpc-doc
Diese Seite auf deutsch

Mail #10919

Back to main page of archive

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

From: Grant Jacobs
Subject: Brief comments / additions to docs
Date: 6 Oct 2004, 20:06:46

Here are a few random things I've spotted from a recent round of 
programming in GPC. (BTW - I know macros aren't part of Pascal, but 
they are useful, especially if you are porting code to/from C). 
Excuse me if any of these overlap with things previously covered - I 
haven't been following the list as I'm too busy of late.


Debugging:

If your source code is in multiple source files as units (or modules? 
- I've only tested for units), there is no need to specify the source 
filename as the GDB man pages suggest (e.g. break is defined as 
'break [file:]function'). Just give the function/procedure name. 
Don't forget to make the first letter of the procedure/function 
identifier in uppercase - gpc adopts this (odd!) convention to avoid 
name-space conflicts with C and system libraries.

Might be worth adding this to the docs - ?



In my hands Exit doesn't seem to so much terminate the program as the 
proc/fn or the unit. Haven't tested this - I just gave up using it - 
but it certainly isn't stopping the program. (!)



It would be good to see a more sensible error message generated when 
the compiler detects a missing parameter in the interface vs. 
implementation definitions of a proc/fn, e.g.

if you have:

interface

	function string_eq( str1, str2    : string; ) : boolean ;

implementation

	function string_eq( str1, str2    : string;
	                    caseSensitive : boolean ): boolean ;
         begin
           ...
         end ;

You get

    undeclared identifier `caseSensitive' (first use in this routine)

rather than some sort of interface/implementation definition 
mis-match error. Its *very* confusing if you're down in the body of 
the unit looking at the source code for the function itself as its 
certainly present there and there is nothing to clue you into looking 
at the interface definition.



If you do a rewrite() or reset(), do nothing with the file, but 
forget to close the file(s) before ending the program, malloc 
complains about a "deallocation of a pointer not yet allocated". I 
presume the post-execution mop-up doesn't handle unused files well -- 
?



Reset() and rewrite() insist on the buffer size parameter rather than 
defaulting if an untyped file is used. OK, you can just set it to 1, 
but its not consistent with the definition of the procedures in the 
docs which indicate [to me!] that this is optional.



Macro expansion of __FILE__ seems to be inconsistent. In cases it 
expands to a full path and in others to just the local filename. It 
seems to be that if the file is in the local directory compared to 
the main program being compiled, just the filename is returned; if 
the source file is in another directory, a full path is returned.



While there is a CurrentRoutineName there is no CurrentUnitName. It'd 
be useful to have this for debugging writes, to indicate which source 
file to look for a routine in.



[Fussy one] Macros can't do C99's
   #define many_arg_fn(...) some_fn( __VA_ARGS__ )
trick. The GNU C compiler does support this & its very useful for 
debugging writes (which, in turn, are useful for test-driven 
development).



Just keeping you on your toes ;-)

Grant

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  


Back to main page of archive


Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.

Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.


This page was created by Crystal 0.999 (Linux 2.4.27/i686).