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

Groups > comp.lang.c > #168460

Re: Why is glibc not extensive?

Show key headers only | View raw

Michael S <already5chosen@yahoo.com> writes:

> On Saturday, November 26, 2022 at 7:08:15 PM UTC+2, Tim Rentsch wrote:
>
>> Michael S <already...@yahoo.com> writes:
>>
>>> On Friday, November 18, 2022 at 2:47:42 PM UTC+2, A wrote:
>>>
>>>> On Friday, 18 November 2022 at 17:39:58 UTC+5:30, David Brown wrote:
>>
>> [...]
>>
>>>>> a) Use size_t like the rest of the world.
>>>>
>>>> This is a problem.  If I am not convinced then why should I follow
>>>> the world?  The world can use size_t but I will use long and if the
>>>> world says that I should be using size_t then I will ignore that.
>>>
>>> So, you don't want to use size_t because it is unsigned.  Well.
>>> Then use signed type ptrdiff_t.  When you want to hold size of
>>> arbitrary objects ptrdiff_t is more portable than 'long'.
>>> In corner case of size of object that occupies more than half
>>> of address space both ptrdiff_t and 'long' are not good enough,
>>> but at least ptrdiff_t works in all other cases.  The same can't
>>> be said about 'long' which does not work in pretty common case
>>> of size of big objects (>= 2GB) on Win64.
>>
>> IMO it's a mistake to hard-wire either 'long' or 'ptrdiff_t' to
>> be the name of a (signed) size type.  Whatever type is chosen
>> should allow as wide a range of values as needed, and neither of
>> those types will necessarily do that.  Furthermore the type name
>> used should reflect the purpose rather than the representation.
>> Assuming the name 's_size' is considered appropriate and
>> acceptable, a suitable typedef can be chosen using a scheme
>> along these lines:
>>
>> #include <limits.h>
>> #include <stdint.h>
>>
>> #if INT_MAX >= SIZE_MAX
>> typedef int s_size;
>> #elif LONG_MAX >= SIZE_MAX
>> typedef long s_size;
>> #elif defined LLONG_MAX && LLONG_MAX >= SIZE_MAX
>> typedef long long s_size;
>> #else
>> typedef intmax_t s_size;
>> #endif
>>
>> after which any interfaces desired should use 's_size' for values
>> of a signed size type.
>
> Your solution is theoretically pure but I don't find it practical.
> For example, I don't want 64-bit s_size on my Cortex-M that
> in practice will never ever have objects  bigger than 2**31-1.

I think you are focusing on the less important part of what I'm
saying.  The key point is to define a new type name, and give
that type name a suitable choice of representation.  If you want
to impose a 31-bit limit on object sizes in a particular program
environment, even though SIZE_MAX is much larger, it's easy to
adapt the chain of #if's accordingly, as for example,

  #if   defined MAXIMUM_OBJECT_SIZE &&   INT_MAX >= MAXIMUM_OBJECT_SIZE
  typedef int s_size;
  #elif defined MAXIMUM_OBJECT_SIZE &&  LONG_MAX >= MAXIMUM_OBJECT_SIZE
  typedef long s_size;
  #elif defined MAXIMUM_OBJECT_SIZE && LLONG_MAX >= MAXIMUM_OBJECT_SIZE
  typedef long long s_size;
  #elif INT_MAX >= SIZE_MAX
    ...
  #endif

and use -DMAXIMUM_OBJECT_SIZE=2147483647 as a compilation flag.

> Also, hopefully before I am retired, intmax_t on common 64-bit
> platforms (x86-64, ARM64, POWER) will become 128-bit.
> In my personal opinion, it's long overdue.
> If current rate of Moore Law is not improved then even with
> all conservatism of standard bodies it will happen several
> decades before the first individual object reaches 2**63-1.
> Or, much more likely,  on 64-bit architectures, size of
> individual objects will never be as big as  2**63-1.  If it at all
> happens, it would be long after migration to wider addresses.
> So, if we follow your suggestion, we'll use 128-bit s_size
> on 64-bit platforms for sole benefit of compatibility with very
> unlikely corner case in very remote future.

Same response.  The chain of #if's in the earlier posting is only
an example.  Of course it can and should be adapted to whatever
particular circumstances are relevant for the environment in
question.  The essential property is to decouple the name of the
type being used, so it can tied to whatever underlying type (and
width, etc) is appropriate to the environment(s) being used.

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

Thread

Why is glibc not extensive? Amit <amitchoudhary0523@gmail.com> - 2022-11-16 22:31 -0800
  Re: Why is glibc not extensive? Bart <bc@freeuk.com> - 2022-11-17 13:05 +0000
    Re: Why is glibc not extensive? A <amit234234234234@gmail.com> - 2022-11-17 05:18 -0800
      Re: Why is glibc not extensive? A <amit234234234234@gmail.com> - 2022-11-17 05:24 -0800
      Re: Why is glibc not extensive? Bart <bc@freeuk.com> - 2022-11-17 13:57 +0000
      Re: Why is glibc not extensive? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-17 17:04 +0000
      Re: Why is glibc not extensive? David Brown <david.brown@hesbynett.no> - 2022-11-18 09:32 +0100
        Re: Why is glibc not extensive? A <amit234234234234@gmail.com> - 2022-11-18 02:32 -0800
          Re: Why is glibc not extensive? David Brown <david.brown@hesbynett.no> - 2022-11-18 13:09 +0100
            Re: Why is glibc not extensive? A <amit234234234234@gmail.com> - 2022-11-18 04:47 -0800
              Re: Why is glibc not extensive? David Brown <david.brown@hesbynett.no> - 2022-11-18 13:59 +0100
                Re: Why is glibc not extensive? A <amit234234234234@gmail.com> - 2022-11-18 05:27 -0800
              Re: Why is glibc not extensive? Bart <bc@freeuk.com> - 2022-11-18 17:04 +0000
                Re: Why is glibc not extensive? David Brown <david.brown@hesbynett.no> - 2022-11-21 08:50 +0100
                Bart (Was: Why is glibc not extensive?) gazelle@shell.xmission.com (Kenny McCormack) - 2022-11-21 14:14 +0000
              Re: Why is glibc not extensive? Michael S <already5chosen@yahoo.com> - 2022-11-21 08:10 -0800
                Re: Why is glibc not extensive? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-26 09:07 -0800
                Re: Why is glibc not extensive? Michael S <already5chosen@yahoo.com> - 2022-11-26 16:11 -0800
                Re: Why is glibc not extensive? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-27 13:05 +0000
                Re: Why is glibc not extensive? scott@slp53.sl.home (Scott Lurndal) - 2022-11-27 16:30 +0000
                Re: Why is glibc not extensive? BGB <cr88192@gmail.com> - 2022-11-27 12:20 -0600
                Re: Why is glibc not extensive? Bart <bc@freeuk.com> - 2022-11-27 21:13 +0000
                Re: Why is glibc not extensive? BGB <cr88192@gmail.com> - 2022-11-27 21:53 -0600
                Re: Why is glibc not extensive? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-03 01:17 -0800
        Re: Why is glibc not extensive? BGB <cr88192@gmail.com> - 2022-11-23 15:11 -0600
  Re: Why is glibc not extensive? Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-17 19:05 +0100
    Re: Why is glibc not extensive? gazelle@shell.xmission.com (Kenny McCormack) - 2022-11-18 08:09 +0000
      Re: Why is glibc not extensive? BGB <cr88192@gmail.com> - 2022-11-23 13:55 -0600

csiph-web