Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #168355
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Why is glibc not extensive? |
| Date | 2022-11-26 09:07 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <867czh8x01.fsf@linuxsc.com> (permalink) |
| References | (3 earlier) <tl7fve$2tbg8$1@dont-email.me> <81589145-5348-439c-87d7-e34b85378ae6n@googlegroups.com> <tl7sm7$2uat7$1@dont-email.me> <c9a90f81-5fa8-4157-8901-e7510da1019cn@googlegroups.com> <a81ebdfc-4087-496a-9b21-3e321e37156an@googlegroups.com> |
Michael S <already5chosen@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.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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