Re: long_long and ulong_long deprecated

[Marius Vollmer]

stefan <address@hidden> writes:

> > 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.)
> 
> In my opinion the "scm_t_longlong" type would be just the same as the
> HAVE_LONG_LONGS before, but with the possibility to compile it with yet
> another compiler on a different platform.
> 
> Does the typedef itself harm any of your design goals ?

It doesn't conflict with a specific Guile design goal, it would just
be a bad design in general, in my book.  We should not introduce a
type that is just like long long, except it also works on compilers
that don't have long long.  That's a contradiction.  In Guile, long
long is _not_ a 64 bit type, it is a scalar type named "long long".
When the compiler does not have a type named "long long", we don't
need to work around that, we just disable the parts of Guile that
provide support for a type named "long long".

You might say that it is unfair that we do support long long but not
__int64.  That's true, and we can add support functions for __int64 no
problem.  I would prefer to add support for the new <stdint.h> types,
tho, and provide compatability definitions for _them_ on platforms
that lack them but have replacements.

> The correct replacement is the "__int64" type.

Is not. ;)