At 10:23 09/01/2003, Frank Heckenbach wrote:

As you probably know, GPC currently converts all identifiers to first letter upper-case/rest lower-case. Since this is often not nice, I plan to change this. This would affect at least the following things:

What is your new rule? (A) -- all lowercase? (B) -- using case in declaration? Here you will face a problem that we (Free Pascal developpers) already faced with our 'cdecl' modifier'. For forward'ed function, which case should be used? - the case used in the first declaration (with forward) or the case in the second true declaration of the function.

(C) - other??

• error messages

• the file name chosen with `--transparent-file-names' (makes a

difference only on case-sensitive file systems, i.e. not Dos/Windows); is this ok (to those who use this option)?

• the file name prompt with external files without binding

While I'm at it, it might be easy to add a warning if an identifier is used with varying case (something like `var Foo: Integer; [...] WriteLn (FOO)').

• Any ideas for the name of the option? (`-Widentifier-case'?)

• Default? (I suppose off, though I think I myself would prefer on.)

• Should it work across units/modules? Or should it be a tri-state

option (never/current file/global)?

-Debugging.... The first char up and the other down is a default combination that I added in the p-exp.y file of GDB sources to get better case-insensitiveness in GDB behavior. (Remember, I am the official pascal language maintainer for GDB).

-Interaction with C sources.... Most standard C sources use names with all chars downcase, so if you choose the same behavior you will have overlaps between C and GPC identifiers. This seems to be a very dangerous change, because some GPC specific functions might become the standard function after this.

Let me explain this a little more in detail, the potential problems are not exactly the same depending on the answer to the question above.

(A) if all identifiers are lowercase, then a function declared a printf in pascal code, which has currently an internal assembly identifier of Printf or _Printf depending on platform will now become printf or _printf. So if some C code is included and the C lib is also linked in, the C lib very of (_)printf will not be loaded anymore, because the pascal version will be used.... This might be VERY dangerous, because the failure might depend on the extent to which the pascal version is compatible with the C one....

(B) that could lead to similar, problems but only on places where all lowercase names are used in declaration.

Another point is that, in Free Pascal, we use uppercased names for normal pascal variables and functions and lower case variables for internal functions (like for operator overloading) so we would get into trouble if we would do the same change. But I don't know the GPC internal and can not tell if this problem could also appear inside GPC.

In short, doing this case is completely against the 'Case-insensitiveness' feature of pascal and potentially can lead to hard to detect problems.

Of course, this is only a personal opinion, furthermore issued by someone that in mainly working on Free Pascal... But I hope that you are convinced that my arguments are not partial and that I only issue them for the global benefit of the pascal community.

In article 200301090923.KAA06096@goedel.fjf.gnu.de, Frank Heckenbach frank@g-n-u.de writes

• Default? (I suppose off, though I think I myself would prefer on.)

Definitely off as default.

On Tue, May 20, 2003 at 12:24:23PM +0200, Maurice Lombardi wrote:

I have tried for the first time to use dwarf-2 debugging with the last gpc version (20030507 / gcc 3.2.2) and DJGPP (it is the default now). I use either gdb 5.3 (last djgpp distribution) or rhide 1.5.0.1 (last snapshot, said to incorporate the same gdb version). In any case when I try to set a breakpoint, I obtain an error message:

internal error - unimplemented function unk_lang_create_fundamental_type called.

Any other experience on other systems / version ?

Everything is correct with stabs debugging, and also when debugging C programs.

I've tried it on Linux recently, with no success. I've downloaded the latest gdb source distribution, and it seems that Pascal+dwarf is not supported by gdb. The trouble is that dwarf reading routines do not understand Pascal specific types, so "set language c" doesn't help either.

Emil