Hi,

while fiddling with some C'isms I've stumbled over a function in a library expecting an array of integers *or* a NULL pointer.

How can I hand over any NIL or 0 or something equal to NULL in C that is accepted by fpc?

Using NIL or 0 does not work certainly...

In code:

hsize_t = qword;

(*
hid_t H5Screate_simple(int rank, const hsize_t * dims, const hsize_t * maxdims )

--> h2pas -->

*)

function H5Screate_simple(rank:longint; dims:array of hsize_t;
maxdims:array of hsize_t):hid_t;cdecl;external;

{ calling is done this way: }
(*
dataspace = H5Screate_simple(RANK, dimsf, NULL);
-->
*)

dimsf			: array[0..1] of hsize_t;
dataspace := H5Screate_simple(RANK, dimsf, ???);

TIA,
Marc

I remember that on c a null pointer has value 0, but in ansi pascal it has value 23. Don't know if it's still true or if fpc uses the c value, or both.

HTH

Add an overloaded literal translation if you want to be able to pass nil:

type
   phsize_t = ^hsize_t;
function H5Screate_simple(rank:longint; dims: phsize_t;
maxdims:phsize_t):hid_t;cdecl;external;

When passing arrays, pass the address of the first element of the array.

Jonas

?

Okay, I'll try that, but I would at least expect it to have a value of
42. ;)

Thank you anyways,
Marc

Eduardo wrote

I remember that on c a null pointer has value 0, but in ansi pascal it has value 23.

The value of nil is not defined in the ISO Ansi Pascal standard. In FPC, nil = pointer(0) on all currently supported platforms, but in principle it could be anything.

Jonas

By using a pointer to the array instead of an array. Was that too obvious?

>> Using NIL or 0 does not work certainly... > I remember that on c a null pointer has value 0, but in ansi pascal > it has value 23. Don't know if it's still true or if fpc uses the c > value, or both.

This is nonsense. At least for the C version and I doubt that any Pascal standard ever stated a value of "23" for NIL.

? Okay, I'll try that,

DON'T! The "right" way to do such nasty thing would be to dereference a NIL pointer constant and then cast it to the according array type. Well, I don't know if compiler checks already kick in at that point.

So you're better off with providing an overloaded version which accepts a pointer instead of the array type.

Vinzent.

Neither it is in any official C standard.

In FPC, nil = pointer(0) on all currently supported platforms, but in principle it could be anything.

I'm making enemies now, but:

If the NIL pointer is represented by another value (like 0xFFFFF780 or such) on a given target platform, the integer conversion from a _compile-time_ constant 0 literal should still lead to a NIL representation.

Basically that would be the same behaviour as what the C-standard guarantees.

Note that this leads to a subtle difference on such platforms between integer literals whether they're known at compile .

Where?

I don't see why, except for compatibility with code built on wrong assumptions. However, for exactly that same reason nil is unlikely to ever become something different from pointer(0) in FPC.

Basically that would be the same behaviour as what the C-standard guarantees.

Does it guarantee that (void*)(0) == NULL?

Jonas

For C language interfacing, I'd say.

> Basically that would be the same behaviour as what the C-standard > guarantees. Does it guarantee that (void*)(0) == NULL?

Yes. It's about the only guarantee it gives regarding the "null pointer constant":

--- 8< ---

ISO/IEC 9899:1999 (E) - 6.3.2.3 Pointers

[...]
3 An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant[55] If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.
4 Conversion of a null pointer to another pointer type yields a null pointer of that type.
Any two null pointers shall compare equal.
5 An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.
[...]

[55] The macro NULL is defined in <stddef.h> (and other headers) as a null pointer constant; see 7.17.

--- 8< ---

Vinzent.

Sorry then for the confusion... i had read it somewhere else, i'll try to look for it.

Thanks

Yes, this does actually work. :)

When passing arrays, pass the address of the first element of the array.

Still thinking about that, I don't want to change calling syntax very much ...

Many thanks,
Marc

Well, you can create different overloaded versions for all possible uses of course:

function H5Screate_simple(rank:longint; dims: array of hsize_t;
maxdims: array of hsize_t):hid_t;cdecl;external;
function H5Screate_simple(rank:longint; dims: array of hsize_t;
maxdims: phsize_t):hid_t;cdecl;external;
function H5Screate_simple(rank:longint; dims: phsize_t; maxdims:
array of hsize_t):hid_t;cdecl;external;
function H5Screate_simple(rank:longint; dims: phsize_t; maxdims:
array of hsize_t):hid_t;cdecl;external;

(possibly leaving some out which don't make sense)

Jonas

Yes, great! I've tried in the meantime and found that I can have both or all of them, that's nice. :)

Thanks again,
Marc