arity: short, int, or size_t

[mgondan]

I encountered a runtime warning from a sanitizer for undefined behavior when I registered a foreign c function, complaining about a wrong type for the arity of my function. This seems to be inconsistent in the code (?)

pl-vmi.c, 4477: VMH_GOTO_AS_VMI(I_FEXITDET, (*f)(h0, DEF->functor->arity, &FNDET_CONTEXT));
pl-wrap.c, 258: size_t
pl-termhash.c, 525: int
foreign.doc: short

What is the correct type, size_t?

[JanWielemaker]

Historically, arity was int. At some time it was converted to size_t. The pl-termhash.c is wrong (but rather benign; it is only a hash, now computed from arity modulo 2^32). the definition in foreign.doc is fine, as predicates are limited to 1024 arguments. Of course, there may be some dubious conversion somewhere ...

[mgondan]

I see. Would you mind a few PRs? I see many warnings if I compile with -Wconversion. I guess 90% are easily solved using e.g. size_t, but a few of them may need auditing.

[JanWielemaker]

I see. Would you mind a few PRs?

I wouldn't mind getting all this in sync. Be careful though, size_t is unsigned, where int is signed. This can break some code if you just change the type. There are probably also structs where we can safely assume the represented number of arguments to fit in a smaller type and use this to reduce the size.

If I recall well, I did a lot of these. Do them in small chunks, commit and run ctest frequently. That should capture most issues.

... actually, I'm keener getting bool being used consistently throughout 😄 Mostly because it helps a lot examining the code if you know a function is bool or int and (thus) has more than two possible result states.

[mgondan]

I see your point. Many warnings arise indeed from return values of different types.