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
next 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).