the rationale for defining macros for simple types?

the rationale for defining macros for simple types?

[Robert P. J. Day]

  a project that i inherited a while back contains a header file with
the following macros:

#ifndef UCHAR
#define UCHAR   unsigned char
#endif

#ifndef UINT
#define UINT    unsigned short int
#endif

#ifndef ULONG
#define ULONG   unsigned long int
#endif

#ifndef BOOL
#define BOOL    unsigned int
#endif

#ifndef TRUE
#define TRUE    (1>0)
#define FALSE   !TRUE
#endif


and proceeds to, naturally, define numerous variables using those
macros.  it's not clear why the original programmer chose to do it
this way rather than just use <stdint.h> and things like uint8_t and
so on.  i don't see any overwhelming need to add yet another level of
complexity when the standard types would seem to do just fine.

also, i'm uncomfortable by the fact that "UINT" is defined as being
"unsigned short int", which is visually misleading.  not to mention
that "unsigned long int" is machine-dependent, no?

is there a reason for having done it this way in the first place that
anyone knows of?  or can i just rip all that nonsense out and use
<stdint.h> types directly?  thanks.

rday

RE: the rationale for defining macros for simple types?

[Smith, Jason - VA]

Robert,

stdint.h is a part of glibc methinks, and not part of any blessed
standard that I am aware of.  What you probably want to include for the
int*_t types is <inttypes.h>, which found in /usr/(local/)?/include on
most of the common *nix's out there (might be part of a standard like
C99 too).

Typically these "convention-establishing" macros are only needed when
you need to get exact sizing for native types to compensate for word
size on multiple processor/OS/compiler combinations.  But they'll be
peppered with #ifdef wrappers for whatever dependent macro is defined
for the compiler/OS/processor you need to support.  In other words, what
inttypes.h is most likely already doing for you.

As a second opinion, I agree that those macros you have there are close
to worthless, as they are just abbreviated rehashes of the word-size
dependent native types.  Unless you have a compelling reason for making
the code less readable with no benefit over inttypes.h, I'd ditch those
macros.

Regards,
--jls 

P.S.  If you want your code to perform consistently across platforms
(and you don't care about absolute variable size), consider using the
"fast" (better speed, possible bigger size) or "least" (smaller size,
possibly slower) versions of int*_t's, such as int_fast32_t or
int_least32_t.

> -----Original Message-----
> From: linux-c-programming-owner@vger.kernel.org 
> [mailto:linux-c-programming-owner@vger.kernel.org] On Behalf 
> Of Robert P. J. Day
> Sent: Thursday, 10 August, 2006 07:58
> To: C programming list
> Subject: the rationale for defining macros for simple types?
> 
> 
>   a project that i inherited a while back contains a header 
> file with the following macros:
> 
> #ifndef UCHAR
> #define UCHAR   unsigned char
> #endif
> 
> #ifndef UINT
> #define UINT    unsigned short int
> #endif
> 
> #ifndef ULONG
> #define ULONG   unsigned long int
> #endif
> 
> #ifndef BOOL
> #define BOOL    unsigned int
> #endif
> 
> #ifndef TRUE
> #define TRUE    (1>0)
> #define FALSE   !TRUE
> #endif
> 
> 
> and proceeds to, naturally, define numerous variables using 
> those macros.  it's not clear why the original programmer 
> chose to do it this way rather than just use <stdint.h> and 
> things like uint8_t and so on.  i don't see any overwhelming 
> need to add yet another level of complexity when the standard 
> types would seem to do just fine.
> 
> also, i'm uncomfortable by the fact that "UINT" is defined as 
> being "unsigned short int", which is visually misleading.  
> not to mention that "unsigned long int" is machine-dependent, no?
> 
> is there a reason for having done it this way in the first 
> place that anyone knows of?  or can i just rip all that 
> nonsense out and use <stdint.h> types directly?  thanks.
> 
> rday
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-c-programming" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> 
> 

RE: the rationale for defining macros for simple types?

[Robert P. J. Day]

On Thu, 10 Aug 2006, Smith, Jason - VA wrote:

> Robert,
>
> stdint.h is a part of glibc methinks, and not part of any blessed
> standard that I am aware of.

my copy of harbison and steele lists <stdint.h> as part of C99.  am i
somehow reading that incorrectly?

> What you probably want to include for the int*_t types is
> <inttypes.h>, which found in /usr/(local/)?/include on most of the
> common *nix's out there (might be part of a standard like C99 too).

again, from my copy of H&S, inttypes.h includes stdint.h, so i guess
either one would work fine.  i'm guessing inttypes.h would be the
better choice since it's more all-encompassing.  thanks.

rday

RE: the rationale for defining macros for simple types?

[Robert P. J. Day]

On Thu, 10 Aug 2006, Smith, Jason - VA wrote:

> Robert,
>
> stdint.h is a part of glibc methinks, and not part of any blessed
> standard that I am aware of.  What you probably want to include for
> the int*_t types is <inttypes.h>, which found in
> /usr/(local/)?/include on most of the common *nix's out there (might
> be part of a standard like C99 too).

as a followup to my last post, i suspect i need include only
<stdint.h>, as i don't really need the additional info from
<inttypes.h>.  i'm a minimalist, and i'd just as soon include as
little as i actually need.  if some file genuinely needs the extras
from <inttypes.h>, then that file can include it explicitly.

> As a second opinion, I agree that those macros you have there are
> close to worthless, as they are just abbreviated rehashes of the
> word-size dependent native types.  Unless you have a compelling
> reason for making the code less readable with no benefit over
> inttypes.h, I'd ditch those macros.

i'd suspected as much, i just wanted to make sure there wasn't some
really tricky C idiom at work here.  so just declaring things with
"int8_t" (for example) is the way to go if i really and truly need to
get that specific.  thanks.

rday

Re: the rationale for defining macros for simple types?

[Glynn Clements]

Robert P. J. Day wrote:

>   a project that i inherited a while back contains a header file with
> the following macros:
> 
> #ifndef UCHAR
> #define UCHAR   unsigned char
> #endif
> 
> #ifndef UINT
> #define UINT    unsigned short int
> #endif
> 
> #ifndef ULONG
> #define ULONG   unsigned long int
> #endif
> 
> #ifndef BOOL
> #define BOOL    unsigned int
> #endif
> 
> #ifndef TRUE
> #define TRUE    (1>0)
> #define FALSE   !TRUE
> #endif
> 
> 
> and proceeds to, naturally, define numerous variables using those
> macros.  it's not clear why the original programmer chose to do it
> this way rather than just use <stdint.h> and things like uint8_t and
> so on.

Probably because <stdint.h> isn't in C89. It's in C99, and also
provided by some compilers which don't otherwise implement C99.

Also, macros such as the above might simply be used as shorthand, to
save typing and/or screen area (although I don't think that's the case
here). In which case, they should refer to the platform-dependent
types rather than fixed-size types. E.g. if the code used:

	LONG offset;
	...
	fseek(fp, offset, seek_set);

then LONG needs to be "long" not some fixed-width type.

>  i don't see any overwhelming need to add yet another level of
> complexity when the standard types would seem to do just fine.
> 
> also, i'm uncomfortable by the fact that "UINT" is defined as being
> "unsigned short int", which is visually misleading.  not to mention
> that "unsigned long int" is machine-dependent, no?

The fact that UINT is defined as unsigned short int leads me to
suspect that this project started out on a 16-bit system (e.g. DOS)
then was ported to 32-bit architectures.

> is there a reason for having done it this way in the first place that
> anyone knows of?  or can i just rip all that nonsense out and use
> <stdint.h> types directly?  thanks.

In this case, where the programmer appears to have specific sizes in
mind (e.g. UINT is 16 bits), you should probably use the <stdint.h>
types (although you may need to provide that file yourself; it's not
part of the C89 standard).

-- 
Glynn Clements <glynn@gclements.plus.com>