Is a godot_uint (not) needed ?

[touilleMan]

PR #36163 has made godot_int an alias to int64_t, this pretty good for GDnative (before that calling methods returning uint64_t/int64_t could lead to segfault, see #34254)

However I wonder from a documentation point of view this is not perfect given the methods returning uint64_t are presented to GDnative users as returning godot_int (hence 64bits signed number)

I see currently three usecases for those signed values:

1. uint64_t GDAPI godot_color_to_abgr64(const godot_color *p_self) (see Fix return type for GDNative's godot_color_to_XXX64 #35795)
2. uint64_t OS::get_static_memory_usage() const;
3. uint64_t OS::get_unix_time () const & uint64_t OS::get_system_time_msecs()

In case 1 here we return an array of 4 a/b/g/r bytes, so it's meaningless to use the return value as a number. Hence there is no trouble ;-)

In case 2&3 we are actually providing a number (and a negative value is meaningless in those contexts). However we will hit a trouble if the returned value is bigger than 2⁶³ - 1.. which is really huge ! (get_system_time_msecs will start to have issue in year 29227899, get_static_memory_usage needs more than 8 Exaoctet of used RAM...)

So my guess is we don't need a godot_uint type (it would add complexity for a small documentation benefit), but I think it's good to have this choice documented (at least by this issue ^^).

[aaronfranke]

In case 3, a negative value is not necessarily meaningless. Negative values represent times before the year 1970. While negative values may not be returned by these specific methods, int64_t (or one day int128_t) should be used to store time in case you need to store times before 1970.