Mail #10907

Back to main page of archive

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

From: Frank Heckenbach
Subject: Brief comments / additions to docs
Date: 6 Oct 2004, 10:06:44

Grant Jacobs wrote:

> 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. 

Did you also try this when, e.g., several implementions define a
private routine of the same name?

> 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. (!)

No, it isn't. Why do you think it should? `Exit' is BP compatible.
To stop the program use `Halt'.

> 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)

Well, what *I* (since you say "you" ;-) actually get (after filling
in the missing parts and fixing the obvious syntax error) is this:

  routine definition does not match previous declaration
  -> previous declaration

If you use `caseSensitive' within the body of `string_eq' (which you
didn't show in the `...') you might get that other message because
the second (wrong) redeclaration of the function is ignored, but the
first error message is the important one. If you don't get this,
please report with a full example (compilable code, compiler
version, etc., as usual).

> 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 -- 
> ?

Again, *I* don't. A testing example (see above) would really help.

> 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.

From the docs:

:    The last optional parameter determines the block size of the file.
: It is valid only for untyped files. Often 1 is a reasonable value here.
: However, the existence of this parameter is a BP compatibility feature,
: and in BP it defaults to 128 because of historic misdesign.  Therefore,
: GPC requires this parameter to be present. In `--borland-pascal' mode,
: it makes it optional (like BP does), but warns about the strange
: default if omitted.
> 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.

What do you suggest? Always a full path?

> 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.

For this purpose __FILE__ would seem more useful (think of include
files), I think.

> [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).

I plan to rewrite the preprocessor, and deal with macro facilities
in this course. For one thing, I'll surely not try hard to be C
compatible (e.g., I plan to replace that `##' stuff with something
more readable). I haven't had varargs macros on my list so far, but
I might consider them. Any other comments? If debugging writes are
the only use, I'm not sure they're justified well enough. (But I'd
also have to see how hard it is to implement them.)

Frank

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

In reply to

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).