Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #27635

Re: Large number libraries/algorithms

Show all headers | View raw

On 10/24/2012 08:23 AM, David Brown wrote:
> On 24/10/2012 13:18, James Kuyper wrote:
>> On 10/24/2012 03:01 AM, David Brown wrote:
>> ...
>>> I noticed that (on gcc 4.5 on Linux-64).  There is also no int128_t or
>>> related types in <stdint.h>.  And there is no way to express an int128_t
>>> literal for targets that whose "long long" is smaller than 128 bits.  On
>>> x86-64, "long long" is 64-bit (with "long" being 32-bit on Windows,
>>> 64-bit on Linux), so until "long long long int" or "really long int" is
>>> added to C, the language is missing a bit of support for 128-bit integers.
>>
>> There's no need for that - that's what int128_t, int_least128_t and
>> int_fast128_t are reserved for. The language isn't missing anything,
>> it's just that particular implementation which has failed to implement
>> something which is already part of the language.
>>
> 
> Yes, these type names are suitable for that purpose (though I am not 
> sure they are reserved for it by C99)

If <stdint.h> is #included, C99 defines what those names mean for all N,
while only making the least and fast types mandatory for N = 8, 16, 32,
and 64. Conversely, the standard prohibits <stdint.h> from defining
those names for values of N for which the corresponding types are
unsupported.

Since those typedefs and macros do not have external linkage, but do
have file scope, the corresponding identifiers are reserved only if
<stdint.h> is #included; otherwise, they're in the name space reserved
for users, which means that an implementation is NOT free to give them
any other meaning.

> - and it is the implementation 
> here that has failed to include them in <stdint.h> (I am not sure 
> whether this is the responsibility of the compiler or the library).

The library can't do anything to make it work unless the compiler
supports a type of the right size; but the corresponding typedef must
not be defined unless and until the standard header is #included, so it
seems to me that they must both work together. Also, support for 128-bit
integers will probably affect [u]intmax_t, and therefore also the
corresponding functions from <stdint.h>, and the printf()/scanf() family.

> However, it is possible to express a 32-bit zero as "0", and a 64-bit 
> ("long long") zero as "0LL".  But there is no way to write a literal 
> 128-bit zero, without extending C to allow "0LLL".

That's what the INTN_C macros are for. They're clumsy, but they do the job:

#include <stdint.c>
#ifndef INT128_MAX
#error 128 bit types not supported
#endif

int128_t i128 = INT128_C(0);

Unless int128_t is a typedef for a standard type, INT128_C() will have
to do something implementation-specific to mark it as an int128_t value.
Keeping in mind that the result must be suitable for use in #if
preprocessing directives, it can't be something like ((int128_t)0),
because, for the purposes of such directives, that would parse as
((0)0), which is a syntax error. It might very well, as an
implementation-specific extension, expand to 0LLL. However, your code
doesn't have to know about that; all it needs to know is whether or not
INT128_MAX is #defined. If so, it can use INT128_C().

> The "int128_t" and related types are enough to do most 128-bit integer 
> work in C.  But there are unfortunately a number of places where the C 
> language and library specifications are tied to the poorly-defined 
> "int", "short", "long", "long long" types rather than size-specific 
> types.  This includes the suffixes on literals, and the format 
> specifiers in printf() (the "PRId32" style macros help enormously, but 
> they are not exactly elegant - and since they expand to specifiers for 
> short, int, long or long long, they can't support 128-bit integers).

There's no requirement that PRId128 expand into a specifier for short,
int, long, or long long. There is, on the other hand, a requirement that
if PRId128 is #defined, it must expand into a format specifier "suitable
for use ... when converting" int128_t. That specifier might be
implementation-specific, unless int128_t happens to be the same typedef
for a standard type, but it must exist.

> On the other hand, I don't see how this would limit practical 128-bit 
> usage much.  After all, how often do you need to write 128-bit literals, 
> or printf them out?

I'm sure that if I needed to work with 128-bit data, I would need to
write them and to printf() them out. Luckily, as explained above, that's
not a problem.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Large number libraries/algorithms boltar2003@boltar.world - 2012-10-22 09:11 +0000
  Re: Large number libraries/algorithms Mark Bluemel <mark_bluemel@pobox.com> - 2012-10-22 10:15 +0100
  Re: Large number libraries/algorithms Heikki Kallasjoki <fis+usenet@zem.fi> - 2012-10-22 09:19 +0000
    Re: Large number libraries/algorithms boltar2003@boltar.world - 2012-10-22 09:40 +0000
  Re: Large number libraries/algorithms Noob <root@127.0.0.1> - 2012-10-22 11:24 +0200
  Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-22 13:29 +0200
    Re: Large number libraries/algorithms boltar2003@boltar.world - 2012-10-22 11:53 +0000
      Re: Large number libraries/algorithms James Kuyper <jameskuyper@verizon.net> - 2012-10-22 08:01 -0400
        Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-22 14:41 +0200
          Re: Large number libraries/algorithms James Kuyper <jameskuyper@verizon.net> - 2012-10-22 09:36 -0400
            Re: Large number libraries/algorithms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 15:12 +0100
    Re: Large number libraries/algorithms Keith Thompson <kst-u@mib.org> - 2012-10-22 10:31 -0700
      Re: Large number libraries/algorithms Robert Wessel <robertwessel2@yahoo.com> - 2012-10-22 15:09 -0500
        Re: Large number libraries/algorithms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-23 00:01 +0100
          Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-23 09:38 +0200
            Re: Large number libraries/algorithms Steve Thompson <stevet810@gmail.com> - 2012-10-23 12:40 +0000
              Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-23 16:23 +0200
                Re: Large number libraries/algorithms Steve Thompson <stevet810@gmail.com> - 2012-10-23 14:38 +0000
            Re: Large number libraries/algorithms Keith Thompson <kst-u@mib.org> - 2012-10-23 12:58 -0700
              Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-24 09:01 +0200
                Re: Large number libraries/algorithms James Kuyper <jameskuyper@verizon.net> - 2012-10-24 07:18 -0400
                Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-24 14:23 +0200
                Re: Large number libraries/algorithms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-24 14:43 +0100
                Re: Large number libraries/algorithms Keith Thompson <kst-u@mib.org> - 2012-10-24 11:33 -0700
                Re: Large number libraries/algorithms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-24 19:53 +0100
                Re: Large number libraries/algorithms James Kuyper <jameskuyper@verizon.net> - 2012-10-24 10:50 -0400
                Re: Large number libraries/algorithms Noob <root@localhost> - 2012-10-24 15:16 +0200
                Re: Large number libraries/algorithms Noob <root@localhost> - 2012-10-24 18:57 +0200
                Re: Large number libraries/algorithms Keith Thompson <kst-u@mib.org> - 2012-10-24 11:43 -0700
                Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-25 09:05 +0200
  Re: Large number libraries/algorithms Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-22 08:23 -0400
    Re: Large number libraries/algorithms tom st denis <tom@iahu.ca> - 2012-10-22 11:40 -0700
      Re: Large number libraries/algorithms Keith Thompson <kst-u@mib.org> - 2012-10-22 17:05 -0700
        Re: Large number libraries/algorithms tom st denis <tom@iahu.ca> - 2012-10-23 07:10 -0700
  Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-22 14:42 +0200
    Re: Large number libraries/algorithms Chad <cdalten@gmail.com> - 2012-10-23 14:39 -0700
  Re: Large number libraries/algorithms pete <pfiland@mindspring.com> - 2012-10-24 03:27 -0400

csiph-web