Re: size_t vs long.

[Alejandro Colomar via Libc-alpha <libc-alpha@sourceware.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3207 bytes --]

Hello,

On 11/17/22 08:02, A via Libc-alpha wrote:
> Hi,
> 
> I prefer long over size_t.

'long'?  really?  'ptrdiff_t' could make sense, but 'long' is a very bad choice, 
IMO.  I whish it had never been invented.  What does 'long' mean, in a (ISO C) 
portable way?  Nothing.

'long' is just a type on which typedefs can be made, but it has no use on its 
own, except for a few places in libc where it's used because noone stopped to 
create a better typedef for the variable (e.g., timespec.tv_nsec, which would 
have been better with a typedef called nseconds_t).

> 
> This is because, in case the user passes a negative number by mistake
> then I will be able to check it if the type is long and return
> immediately.

signed types have their own issues.  In the end, if you pass a negative value to 
malloc(3), which will be converted to a huge value, sooner or later you will 
probably realize.

> 
> But if size_t is used, then most probably, it will result in a crash -

And I love that.  Crashing is the best thing you can do.  That tells me 
immediately that I wrote a bug.  Isn't that what we wanted in the first place?

> like malloc(-1) will crash the program because unsigned -1 is
> 0xFFFFFFFF and this much memory is not available on today's computers
> and probably may not be available at all in future also (RAM size of
> 2^64 bits is really really huge).

We're not so lucky with malloc(3), since it's virtual memory, and you won't get 
it all at once.  But yes, sooner or later, if you passed -1 to malloc(3), you'll 
see a crash, which is a Good Thing (tm).

> 
> Another thing is that if size_t is used an array index then array[-1]
> will result in wrong behavior or program crash. But with long, the
> developer can check whether the index is negative, thus avoiding
> program crash.

And what do you plan to do when you detect -1 in your code?  Set errno to 
EPROGRAMMERNOTSMARTENOUGH and return -1 from your function?

BTW, just for fun, would anyone please add that errno code to glibc?  It would 
be a nice easter egg  :P

If you weren't smart enough to avoid a bug in your code (and of course nobody is 
smart enough to write 0 bugs), can you yourself write code that is smart enough 
to handle it?  It makes little sense.  What if you write another bug in your 
code handling the bug?

> 
> So, in my opinion, long should be used instead of size_t.

I'd like to change your opinion.  Please read this excellent article by Jens 
Gustedt (member of WG14, the group that develops the ISO C standard) which 
explains why size_t is better:

<https://gustedt.wordpress.com/2013/07/15/a-praise-of-size_t-and-other-unsigned-types/>

> 
> I know that original glibc authors had chosen size_t, so there must be
> some reason for that, however that reason is not clear to me.

The reason why it was chosen is not documented, AFAIK, and could possibly be 
attributed to a historical accident.  However, I'd say it's a great accident if 
it was that way.

But in the article above you may find readons to keep using it for your own code.

> 
> Amit

Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]