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

Groups > comp.lang.c > #169278

Re: FAQ list update: Q1.1: choosing types

Show all headers | View raw

John Dill <jadill33@gmail.com> writes:
> On Tuesday, February 14, 2023 at 3:34:52 PM UTC-5, Keith Thompson wrote:
>> John Dill <jadi...@gmail.com> writes: 
>> [...]
>> > I fall into the size_t camp (instead of 'int') for common looping of unsigned 
>> > sequences. For size_t values where a -1 is needed for semantics, we use 
>> > a preprocessor sequence to generate a signed version of size_t called 
>> > ssize_t.
>> [...] 
>> 
>> POSIX defines a type ssize_t, a signed type that may or may not be the 
>> signed type corresponding to size_t. It's defined in <sys/types.h> and 
>> other headers. If there's any chance of your code being compiled under 
>> POSIX, you might consider checking whether SSIZE_T is defined, and if so 
>> just use the POSIX ssize_t (and be aware that it might not be the signed 
>> type corresponding to size_t). Or pick a different name for your type. 
>
> Agreed.  We have something along these lines, with the build system
> handling the definitions of the HAVE tests.
>
> We lean on POSIX whenever possible, but not all environments support
> POSIX.
>
> \code
> /* If the <sys/types.h> header file is found, including the file
>    should define the 'ssize_t' type. */
> #if defined(HAVE_SYS_TYPES_H)
> #  include <sys/types.h>
> #else
> #  if !defined(HAVE_SSIZE_T)
>      /*
>       * The best candidate to define 'ssize_t' is 'ptrdiff_t'.  If
>       * 'ptrdiff_t' is not found, then the fallback type will be
>       * 'long int'.
>       */
> #    if defined(PTRDIFF_MAX)
>        typedef ptrdiff_t ssize_t;
> #    else
>        typedef long int ssize_t;
> #    endif
> #  endif
> #endif
> C_STATIC_ASSERT (sizeof (ssize_t) == sizeof (size_t),
>                  ssize_t_is_compatible_with_size_t);
> \endcode

Rather than HAVE_SSIZE_T, you could check whether SSIZE_MAX is
defined in <limits.h>.

ptrdiff_t has been standard since C89/C90.  You can probably
get away with not testing for it.  Note that PTRDIFF_MAX wasn't
introduced until C99, so you could get a false negative on some
old implementations.

An alternative might be to check the values of UINT_MAX, ULONG_MAX,
and ULLONG_MAX vs. SIZE_MAX and use the corresponding signed type
int, long, or long long.  That's if you want to be really picky,
but what you have should work on any realistic target platform.

The name "ssize_t_is_compatible_with_size_t" is a bit misleading.
C type compatibility is defined very narrowly.  A signed type is
never *compatible* with an unsigned type.  What is "compatible"
supposed to mean in this context?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

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

Thread

FAQ list update: Q1.1: choosing types scs@eskimo.com (Steve Summit) - 2023-02-13 15:18 +0000
  Re: FAQ list update: Q1.1: choosing types Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-02-13 18:27 +0300
  Re: FAQ list update: Q1.1: choosing types scott@slp53.sl.home (Scott Lurndal) - 2023-02-13 16:27 +0000
    Re: FAQ list update: Q1.1: choosing types Oğuz <oguzismailuysal@gmail.com> - 2023-02-14 08:55 +0300
  Re: FAQ list update: Q1.1: choosing types Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-02-13 18:07 +0000
  Re: FAQ list update: Q1.1: choosing types Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-02-13 10:48 -0800
  Re: FAQ list update: Q1.1: choosing types Kaz Kylheku <864-117-4973@kylheku.com> - 2023-02-14 03:10 +0000
    Re: FAQ list update: Q1.1: choosing types Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-02-14 17:33 -0500
  Re: FAQ list update: Q1.1: choosing types Öö Tiib <ootiib@hot.ee> - 2023-02-13 23:24 -0800
  Re: FAQ list update: Q1.1: choosing types bart c <bart4858@gmail.com> - 2023-02-14 06:22 -0800
    Re: FAQ list update: Q1.1: choosing types Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-02-14 17:48 -0500
  Re: FAQ list update: Q1.1: choosing types John Dill <jadill33@gmail.com> - 2023-02-14 08:17 -0800
    Re: FAQ list update: Q1.1: choosing types Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-14 12:34 -0800
      Re: FAQ list update: Q1.1: choosing types John Dill <jadill33@gmail.com> - 2023-02-15 10:04 -0800
        Re: FAQ list update: Q1.1: choosing types Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-15 10:28 -0800
          Re: FAQ list update: Q1.1: choosing types Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-02-15 10:57 -0800
            Re: FAQ list update: Q1.1: choosing types Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-15 11:17 -0800
              Re: FAQ list update: Q1.1: choosing types Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-15 11:32 -0800
          Re: FAQ list update: Q1.1: choosing types John Dill <jadill33@gmail.com> - 2023-02-15 11:01 -0800
            Re: FAQ list update: Q1.1: choosing types Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-15 11:28 -0800
              Re: FAQ list update: Q1.1: choosing types John Dill <jadill33@gmail.com> - 2023-02-15 14:00 -0800
  Re: FAQ list update: Q1.1: choosing types Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-15 02:54 -0800
  Re: FAQ list update: Q1.1: choosing types Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-02-15 14:43 +0300
  Re: FAQ list update: Q1.1: choosing types David Brown <david.brown@hesbynett.no> - 2023-02-15 13:55 +0100
    Re: FAQ list update: Q1.1: choosing types Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-02-15 05:31 -0800

csiph-web