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:
- 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)?
Frank
Frank Heckenbach wrote:
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'?)
Sounds good to me.
- Default? (I suppose off, though I think I myself would prefer on.)
Me too, I'd prefer "on". Does someone insist on "off" due to traditional Pascal behaviour?
(If "on" is the default, the option should IMO get another name. E.g. `-Wignore-identifier-case'.)
- Should it work across units/modules? Or should it be a tri-state option (never/current file/global)?
Tri-state, I suppose. If you yourself care for identifier cases, but use units by someone who doesn't, it would be good to disable the warnings for that units.
One question: What convention will GPC use instead of the old one? Will the asmnames be verbatim as defined? (E.g. if I write "type myFoo", the asmname of that type will be 'myFoo'?)
Yours,
Markus
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.
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.
Maurice
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
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.
Appearently gdb cannot recognise Pascal when using Dwarf-2. The following _very experimental_ patch make gdb treat unknown language as C -- it allows to debug at least some Pascal programs
diff -ru gdb-5.2.1.orig/gdb/language.c gdb-5.2.1/gdb/language.c --- gdb-5.2.1.orig/gdb/language.c Wed Feb 13 19:49:30 2002 +++ gdb-5.2.1/gdb/language.c Wed Dec 4 20:38:12 2002 @@ -99,7 +99,7 @@ static int unk_lang_value_print (struct value *, struct ui_file *, int, enum val_prettyprint);
/* Forward declaration */ -extern const struct language_defn unknown_language_defn; +extern struct language_defn unknown_language_defn;
/* The current (default at startup) state of type and range checking. (If the modes are set to "auto", though, these are changed based @@ -1453,6 +1453,10 @@ {NULL, OP_NULL, PREC_NULL, 0} };
+#if 1 +extern const struct language_defn asm_language_defn; +struct language_defn unknown_language_defn; +#else const struct language_defn unknown_language_defn = { "unknown", @@ -1481,6 +1485,7 @@ &builtin_type_char, /* Type of string elements */ LANG_MAGIC }; +#endif
/* These two structs define fake entries for the "local" and "auto" options. */ const struct language_defn auto_language_defn = @@ -1594,7 +1599,10 @@ show = add_show_from_set (set, &showlist); set_cmd_cfunc (set, set_case_command); set_cmd_cfunc (show, show_case_command); - + + unknown_language_defn = asm_language_defn; + unknown_language_defn.la_name = "unknown"; + unknown_language_defn.la_language = language_unknown; add_language (&unknown_language_defn); add_language (&local_language_defn); add_language (&auto_language_defn);
Waldek Hebisch a écrit:
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.
Appearently gdb cannot recognise Pascal when using Dwarf-2. The following _very experimental_ patch make gdb treat unknown language as C -- it allows to debug at least some Pascal programs
diff -ru gdb-5.2.1.orig/gdb/language.c gdb-5.2.1/gdb/language.c --- gdb-5.2.1.orig/gdb/language.c Wed Feb 13 19:49:30 2002 +++ gdb-5.2.1/gdb/language.c Wed Dec 4 20:38:12 2002 @@ -99,7 +99,7 @@ static int unk_lang_value_print (struct value *, struct ui_file *, int, enum val_prettyprint);
/* Forward declaration */ -extern const struct language_defn unknown_language_defn; +extern struct language_defn unknown_language_defn;
/* The current (default at startup) state of type and range checking. (If the modes are set to "auto", though, these are changed based @@ -1453,6 +1453,10 @@ {NULL, OP_NULL, PREC_NULL, 0} };
+#if 1 +extern const struct language_defn asm_language_defn; +struct language_defn unknown_language_defn; +#else const struct language_defn unknown_language_defn = { "unknown", @@ -1481,6 +1485,7 @@ &builtin_type_char, /* Type of string elements */ LANG_MAGIC }; +#endif
/* These two structs define fake entries for the "local" and "auto" options. */ const struct language_defn auto_language_defn = @@ -1594,7 +1599,10 @@ show = add_show_from_set (set, &showlist); set_cmd_cfunc (set, set_case_command); set_cmd_cfunc (show, show_case_command);
- unknown_language_defn = asm_language_defn;
- unknown_language_defn.la_name = "unknown";
- unknown_language_defn.la_language = language_unknown; add_language (&unknown_language_defn); add_language (&local_language_defn); add_language (&auto_language_defn);
Works approximately indeed. Pascal is recognized:
(gdb) show language The current source language is "auto; currently pascal".
but casing of identifiers is no more correct: when you ask to print some identifier, it was tested in turn casing as typed in gdb First Letter only capitalized, ALL LETTERS capitalized This was quite handy and is broken: casing as typed gives the correct answer First Letter capitalized gives 0 ALL LETTERS capitalized gived an error message: no symbol "LETTERS" in current context.
Better to still use stabs debugging, for which all this works, until we hear from Pierre Muller, the gdb / pascal maintainer
Maurice
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:
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)').
I assume the reason for the existing convention is to allow linkage with case sensitive linkers in the first place. The penalty being that it requires things such as asmname to allow linkage to existing C routines, libraries, etc. and that the object of the change is to eliminate the asmname.
At any point there appear to be several options: Use the original name, as entered. Convert it to canonical form (1st upper, etc). Convert it to monocase, either upper or lower. Convert it to something arbitrary, via asmname. Do any of the above and add a prefix or suffix.
I vaguely recall having similar problems long ago with the PascalP system. The problem doesn't arise until the link stage. At that time I was free to modify the link system as I wished, and I think my kluge solution was a translation module that was searched only when names remained unresolved. This module said effectively: If nameone is unresolved, satisfy any references with nametwo and forget nameone (IIRC). A kluge.
I actually think that your existing convention (1st upper, rest lower) is an excellent way to resolve most things. I am quite sure I don't have a grasp of the conflicting systematic requirements involved. It might be helpful to enumerate them.
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.
-
CBFalconer -
Emil Jerabek -
Frank Heckenbach -
Markus Gerwinski -
Martin Liddle -
Maurice Lombardi -
Pierre Muller -
Waldek Hebisch