On 24 Mar 2005 at 14:59, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
On 18 Mar 2005 at 14:02, Frank Heckenbach wrote:
Grmpf. We'd always assumed our `_p_' prefixes should be good enough to avoid such conflicts. Apparently not.
No, not in this case :(
BTW: it also has "_p_terminate" in case we ever consider using that name ...
I don't currently (we have `_p_finalize' instead).
To avoid this particular conflict, we could just upper-case the letter after `_p_'. But this may turn out too short-sighted in the future again ...
Indeed ...
But some prefixes will remain, e.g. for C library interfaces. We could discuss changing our prefix to something even less likely con conflict (`_gpc_'? -- though we once had a problem with a libgpc in another package, so even that might not be unique enough) ... Any suggestions?
How about: _gpc_<unitname>_foo { for units } _gpc_rts_foo { for RTS stuff } _gpc_<programname>_foo { for programs }
I don't really mind, but I don't want to have to rename them again sometime later. So we should be sure the new names are "unique enough" if we rename them now.
Agreed. That is why I proposed names prefixed with "_gpc_" and including the name of the unit/program + the name of the symbol. This also avoids symbol duplication between units, although that is no longer a problem as we now have qualified identifiers. There is a theoretical risk of someone else hijacking the prefix "_gpc_", but I dobut that this is a realistic risk. If we think it is a realistic risk, then perhaps "_gnu_pascal_" would be a better prefix? (I think that is too long-winded).
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/