Re: long_long and ulong_long deprecated

[Marius Vollmer]

Martin Grabmueller <address@hidden> writes:

> Hello list.
> 
> I plan to do what is necessary for this change.  That includes:
> 
> * Defining the types scm_t_longlong and scm_t_ulonglong as `long
>   long'/`unsigned long long' or `__int64/__uint64', depending on the
>   compiler (gcc/MSVC).  This should go into __scm.h, I suppose.
> 
> * Changing all uses in libguile core and the srfis of `long
>   long'/`unsigned long long' to using these typedefs.
> 
> Any comments, thoughts or criticism?

I think this:

| The idea is that libguile itself does not need a "long long" type,
| but provides support for it (in the form of conversion functions,
| say) when it is available.

has not been addressed adequately yet.

What would the description of "scm_t_longlong" be?  "The type
`scm_t_longlong' is equivalent to `long long' when `long long' exists
on your system, else it is equivalent to `__int64'.  If neither `long
long' nor `__int64' exists on your system, Guile does not compile."

The above would be a weak reason for introducing scm_t_longlong.
Better would be: "The type `scm_t_longlong' is a integer type that can
hold signed 64 bit quantities.  If no such type exists on your system,
Guile does not compile."

That would be a better reason, but the part about "Guile does not
compile" does not sound very nice, especially when Guile can very well
live on systems without 64 bit numbers.

So we should probably have: "The type `scm_t_longlong' is a integer
type that can hold signed 64 bit quantities.  If no such type exists
on your system, scm_t_longlong and the functions that use it in their
argument list (like scm_num2longlong) do not exist either."

But if are at this point, we might as well just say: "If there is a
`long long' type on your system, Guile provides some functions like
`scm_num2longlong' for converting SCM values to and from it."

The same can be said for any number of additional standard,
quasi-standard and soon-to-be-standard type names, like int64_t,
int_fast32_t, etc.  it is good for Guile to support them by providing
functions that can work with them directly without having to make the
user guess whether `scm_num2long' is appropriate for `int64_t' or
`scm_num2longlong', or whether there is an appropriate function at
all.

I never really understood the reason behind

    typedef int gint;

either.  I think they (the Gtk folks) later "got it", by defining
`gint32', etc, which makes sense for a foundation library like glib,
but libguile is not such a foundation library.  It is not our job to
provide yet another name for a 64 bit type.  We should cater to the
type names that exist, but not make the mess worse.


To summarize, the reasons given by Stefan for adding something
`scm_t_longlong' are not strong enough.  There might be reasons, but
we haven't found them yet.  (And I would prefer it if we wouldn't find
any.)