Re: long_long and ulong_long deprecated

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> 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.

OK Marius, I think I agree with you.  Conflating long long and int64's
is probably a bad idea.

So it sounds like both you and Stefan might be satisfied by having
support for long long via scm_num2longlong, etc., and support for the
inttypes.h types like int64_t via scm_num2int64, etc.

If so, then that sounds like a cleaner solution to me as well, but it
only solves Stefan's problem if gcc/MSVC arranges for __int64 to be
typedefed to int64_t, or perhaps for inttypes.h to be available.

We *could* arrange for guile to do some of this detection/typedefing
itself, but that seems like the wrong place for the solution.  It
should go into gcc/MSVC's automake/autoconf support (presuming there
is any...)

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD