No PL_get_uint64()?

General
1

Hi everybody,

I’m currently in the process of writing a prolog binding. In my C API, I have various functions that get or return a uint64_t. According to the swipl documentation, I can easily store a uint64_t into a prolog term with PL_unify_uint64(). However, there’s no corresponding PL_get_uint64(), although there is a signed version, PL_get_int64().

Is there any reason why this function is missing? And what should I be doing to get a proper uint64_t out of a prolog term?

Thanks,
Matthijs

2

It is surely there, but not very old. Which version do you run? Note that to actually use it for large unsigned values you need SWI-Prolog compiled with the GMP binding. Without, integers are internally int64_t, so it can never work.

3

I’m running latest stable (8.0.3), and it is not in the SWI-Prolog.h header file.

However, I just checked 8.1.12, and I can’t find it in that header file either. There’s unify functions, but no get and no put.

4

Sorry. I misread. There is an alternative that is used by the ffi package: PL_cvt_i_uint64(). The only difference with a potential PL_get_uint64() is that the cvt version raises a Prolog exception the case that the term is not an integer or outside the range of uint64_t, where a possible PL_get_uint64() would silently fail.

Is that good enough? It might be wise to add PL_get_uint64() anyway though.

5

Thanks - yeah, that’s acceptable for what I’m doing. I wasn’t aware of these functions. What does their naming (cvt, i) signify?

For consistency sake, I’m all in favor for adding PL_get_uint64() and PL_put_uint64() anyway.

6

convert in or out (o). They have been introduced long ago for implementing the Quintus/SICStus compatible foreign interface. They basically do get and unify, but with additional error checking that is traditionally not part of this interface.

1 Like
7

Pushed a patch that adds PL_put_uint64(). I’m not too sure about PL_get_uint64(). The _get interface seems a bit outdated. Most new code should use the _get_ex() interface, which is basically the same as the cvt_i interface. Needs some rethinking.

1 Like