linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@mindspring.com>
To: C programming list <linux-c-programming@vger.kernel.org>
Subject: curious about whether i can count on certain features of C
Date: Sun, 29 May 2005 15:31:04 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.61.0505291517130.31836@localhost.localdomain> (raw)


[newbie alert! :-)]

  i just inherited a sizable C-based project and, perusing the code,
i've come across a number of in-house defined constructs that would
seem to already be supported in standard (C99?) C, and i'm wondering
if there's a reason the previous developer felt he needed to define
these features himself.

  first, there's the definition of "offsetof":

#ifndef offsetof
# define offsetof(type, field) \
    ( (char *) &( ((type *) 0)[0].field ) - (char *) &( ((type *) 0)[0] ) )
#endif

  using any modern definition of C, can i safely assume that this
function/macro is just part of the language (stddef.h)?  and, at the
very least, is there a reason it's defined in such an obscure way
rather than just

  #define offsetof(type,memb) ((size_t)&((type *)0) -> memb)   ???

that first definition might be technically correct but i'm really
trying to simplify things and i don't see any obvious need to keep
that local definition around.

  next, booleans.  based on my copy of "harbison and steele" (5th
ed.), can i reasonably assume the existence of a boolean data type
(stdbool.h)?  i don't have much interest in supporting legacy
compilers, and booleans appear to be part of the C99 definition, so
i'd be really tempted to ditch the following enum type i found:

    enum TCS_bool_Type {
        TCS_bool_FALSE = 0, /**< false/no state */
        TCS_bool_TRUE /**< true/yes state */
    } GCC_PACKED;                       /* enum TCS_bool_Type */

  next, there are a number of typedefs for fixed-width data types:

    typedef signed char TCS_int8_t; /**< signed 8-bit integer */
    typedef unsigned char TCS_u_int8_t; /**< unsigned 8-bit integer */
    typedef signed short TCS_int16_t; /**< signed 16-bit integer */
    typedef unsigned short TCS_u_int16_t; /**< unsigned 16-bit integer */
    typedef signed int TCS_int32_t; /**< signed 32-bit integer */
    typedef unsigned int TCS_u_int32_t; /**< unsigned 32-bit integer */
    typedef TCS_int8_t TCS_tiny_t; /**< signed tiny integer */
    typedef TCS_u_int8_t TCS_u_tiny_t; /**< unsigned tiny integer

is there any compelling reason why i can't just use the types defined
in /usr/include/stdint.h?  that is, int8_t, uint32_t, and so on?  is
there any rationale for someone wanting to do this themselves, apart
from perhaps legacy compiler support?

  i'll probably have a couple more questions after more perusal.
thanks for any advice.

rday


             reply	other threads:[~2005-05-29 19:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-29 19:31 Robert P. J. Day [this message]
2005-05-30 13:24 ` curious about whether i can count on certain features of C Glynn Clements

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.61.0505291517130.31836@localhost.localdomain \
    --to=rpjday@mindspring.com \
    --cc=linux-c-programming@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).