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

Groups > comp.lang.c > #387630

Re: size_t best practice

Show all headers | View raw

On Sun, 18 Aug 2024 08:03:08 +0000
Mark Summerfield <mark@qtrac.eu> wrote:

> Many C std. lib. functions accept and/or return size_t values esp. for
> arrays incl. char* strings.
> 
> In view of this I'm using size_t throughout my code for array sizes
> and indexes.
> 
> However, this means I have to be very careful never to decrement a
> size_t of value 0, since, e.g., size_t size = 0; size--; results in
> size == 18446744073709551615.
> 
> So I need to guard against this. Here is an example I'm using
> (without the assert()s):
> 
> void vec_insert(vec* v, size_t index, void* value) {
>     if (v->_size == v->_cap) {
>         vec_grow(v);
>     }
>     for (size_t i = v->_size - 1; i >= index; --i) {
>         v->_values[i + 1] = v->_values[i];
>         if (!i) // if i == 0, --i will wrap!
>             break;
>     }
>     v->_values[index] = value;
>     v->_size++;
> }
> 
> I've also noticed that quite a few array-related algorithms _assume_
> that indexes are signed, so again I have to put in guards to avoid
> subtracting below zero when I use size_t when implementing them.
> 
> So is it considered best practice to use int, long, long long, or
> size_t, in situations like these?

My personal view is that in order to minimize a surprise factor one
should prefer signed array indices and signed loop control variables.
I.e. either int or ptrdiff_t.
I wouldn't use long or long long.
Some systems have ssize_t, but that's not part of standard C. Beyond, I
can't imagine a situation where ssize_t is better than ptrdiff_t.

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

Thread

size_t best practice Mark Summerfield <mark@qtrac.eu> - 2024-08-18 08:03 +0000
  Re: size_t best practice Ike Naar <ike@sdf.org> - 2024-08-18 08:38 +0000
    Re: size_t best practice Mark Summerfield <mark@qtrac.eu> - 2024-08-18 10:15 +0000
      Re: size_t best practice Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-08-20 07:38 -0700
  Re: size_t best practice Michael S <already5chosen@yahoo.com> - 2024-08-18 12:36 +0300
  Re: size_t best practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-18 04:32 -0700
  Re: size_t best practice Michael S <already5chosen@yahoo.com> - 2024-08-18 15:40 +0300
    Re: size_t best practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-18 15:23 -0700
      Re: size_t best practice Michael S <already5chosen@yahoo.com> - 2024-08-19 11:13 +0300
        Re: size_t best practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-19 09:43 -0700
  Re: size_t best practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-18 14:57 -0700
  Re: size_t best practice Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-08-20 06:53 -0700
    Re: size_t best practice Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-08-20 06:55 -0700
      Re: size_t best practice Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-08-20 06:56 -0700
        Re: size_t best practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-22 01:38 -0700
    Re: size_t best practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-22 01:31 -0700
      Re: size_t best practice Ike Naar <ike@sdf.org> - 2024-08-22 11:19 +0000
        Re: size_t best practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-22 06:12 -0700
  Re: size_t best practice Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-24 19:49 +0200
    Re: size_t best practice Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2024-08-25 06:30 +0200
      Re: size_t best practice Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-25 06:53 +0200
        Re: size_t best practice Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-26 21:39 +0100
  Re: size_t best practice Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-27 18:11 +0200

csiph-web