Peter N Lewis wrote:
Types that happen to have the same size on a given platform, e.g. a pointer and some integer type, seem too fragile, and I can't easily imagine a good use for such conversions.
One option is to define IntegerPtr or such which is an integer the same size as pointer.
We have this type already, it's called PtrInt. That's not the problem. But with such a rule, the parameter would also allow, say, CInteger, if it happened to have the same size as a pointer which may or may not be the case.
And if we could restrict it to pointers, do I get it right that the routine externally behaves as if the parameter were an untyped pointer (i.e., `Pointer' in BP and GPC), and internally the pointer is converted to the given type before the routine starts?
Pretty much, although it would certainly be helpful to allow compatible sized integers as well as pointers. Generally there should be no need to "convert" the data since it should be size and binary compatible and just type changed.
This is what converting means (in Pascal, not assembler).
Lack of {$unused( param )} directive - needs to be commended out with ifdef __GPC__ for each one (and then I don't understand why GPC is not itself warning about the unused parameters...)
Nomally it does with -Wunused-parameters (or -Wall which includes it). Did you use this option? If so, can you provide an example?
I have -Wall, but I haven't seen them, perhaps it is the -O0 as Adriaan suggests?
Ah, sorry, it requires -Wall -W (both).
Given GPC does has -Wunused-parameters, {$unused()} becomes even more useful.
I think we've discussed compiler directives vs. attributes or statements (Discard) before. Restarting an old discussion without new points really only wastes time of all of us. (Discard is there, attributes could be possible, would add new syntax which hopefully won't conflict, but would have to check, compiler directives would be quite contrary to the existing principle of compiler directives which don't directly refer to particular Pascal code elements, but rather influence the general behaviour of the compiler.)
Frank