At 12:36 +0200 1/7/05, Frank Heckenbach wrote:
Peter N Lewis wrote:
At first glance, it seems to be different. AFAIUI, the Mac Pascal version requires the same size for the parameter. This page says:
: univ is most often used for passing arrays, where you can call a : procedure or function with different array sizes. In that case, : you generally would pass another parameter that gives the actual : size of the array, as follows:
So what do you really need? I think defining a sane subset might be the only way out of this long-standing dilemma.
I would be perfectly happy with univ working only for pointer or scalar types, and requiring the size of the parameter to match. I would be reasonably happy with only working with pointer types and integers with the same size as pointer. I would be acceptably happy with only working with pointer types.
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. At least it is easy to define in one place a system-specific integer size that matches the size of pointers on that system.
On the Mac, it is typical for libraries to use a userdata field which is 4 bytes, often an SInt32 or Ptr=^UInt8, and it is useful to be able to store a UInt32 or Pointer when storing such data, and so univ SInt32 would be useful to accept both.
I definitely agree, any univ implementation should at a minimum require the sizes to match.
OTOH, all pointer types (in GPC) always have the same size, so converting between pointers would be less risky, and more meaningful. Is this sufficient? What kinds of parameters are required, only value, or also var paremeters?
value and var is required. The typical cases would be such as:
procedure MyCFRelease( var cf: CFTypePtr ); procedure CFShow( cf: CFTypePtr ); procedure SetUserData( obj: Whatever; userdata: unit SInt32 ); procedure GetUserData( obj: Whatever; var userdata: unit SInt32 );
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.
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?
Given GPC does has -Wunused-parameters, {$unused()} becomes even more useful.
Thanks, Peter.