473,224 Members | 1,744 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,224 software developers and data experts.

Detecting typedef at preprocessing time

Imagine that there is some include file f.h that contains the following
line:

typedef unsigned int ui32 ;

My question is: If I have a C source file F.c that includes f.h, is it
possible for the preprocessor to detect that ui32 already exists, when
preprocessing F.c? The idea is that F.c will typedef ui32 as above if and
only if such typedef is not already in some include file used by F.c.
Apr 6 '06 #1
12 8152

Thomas Carter wrote:
Imagine that there is some include file f.h that contains the following
line:

typedef unsigned int ui32 ;

My question is: If I have a C source file F.c that includes f.h, is it
possible for the preprocessor to detect that ui32 already exists, when
preprocessing F.c? The idea is that F.c will typedef ui32 as above if and
only if such typedef is not already in some include file used by F.c.


/* File f.h */

#ifndef _UI32
#define _UI32
typedef unsigned int ui32 ;
#endif

Apr 6 '06 #2
In article <pa***************************@nanobots.com>,
Thomas Carter <T.******@nanobots.com> wrote:
Imagine that there is some include file f.h that contains the following
line: typedef unsigned int ui32 ; My question is: If I have a C source file F.c that includes f.h, is it
possible for the preprocessor to detect that ui32 already exists, when
preprocessing F.c? The idea is that F.c will typedef ui32 as above if and
only if such typedef is not already in some include file used by F.c.

No, not without assistance such as defining a macro to indicate the
existance of the feature.

The only currencies of the preprocessor are macros and arithmetic
constant expressions.
--
Prototypes are supertypes of their clones. -- maplesoft
Apr 6 '06 #3
Thomas Carter schrieb:
Imagine that there is some include file f.h that contains the following
line:

typedef unsigned int ui32 ;

My question is: If I have a C source file F.c that includes f.h, is it
possible for the preprocessor to detect that ui32 already exists, when
preprocessing F.c? The idea is that F.c will typedef ui32 as above if and
only if such typedef is not already in some include file used by F.c.


The preprocessor itself cannot interpret typedefs.

Usually, you want to have only one such typedef.
As you can protect the contents of a header against multiple
inclusion, the usual construct is

,-- mytypes.h --
#ifndef MY_TYPES_H__
#define MY_TYPES_H__
.....
typedef unsigned int ui32;
.....
#endif
`----

If you need ui32 or another of the typed from "mytypes.h", then
#include "mytypes.h"
If any header needs to provide ui32, too, then make sure it
includes mytypes.h as well.

If you are in the rare and unfortunate situation that you can
either have an implementation typedef or have to provide one of
your own, then do the same: There usually is a, possibly
implementation specific, means to detect whether the type already
is there. Use this in your header mytypes.h. Whenever this header
is included, you can be sure that you have either one typedef or
the other -- but that it is there.
Usually better: Provide your own typedef name.

Example: You need a signed integer type with at least 24 bits and
decide you want to try first whether <stdint.h> defines one before
typedef'ing your own:

One solution:
,-- mytypes.h --
#ifndef MY_TYPES_H__
#define MY_TYPES_H__
#include <limits.h>
#include <stdint.h>
.....
# ifndef INT_LEAST24_MAX
typedef signed long int_least24_t;
/* In order to "normalise" the picture: provide limits */
# define INT_LEAST24_MAX LONG_MAX
# define INT_LEAST24_MIN LONG_MIN
# endif
.....
#endif
`----

Another solution (one I would favour):
,-- mytypes.h --
#ifndef MY_TYPES_H__
#define MY_TYPES_H__
#include <limits.h>
#include <stdint.h>
.....
# ifdef INT_LEAST24_MAX
typedef int_least24_t sint24;
/* Optional: Provide limits */
# else
typedef signed long sint24;
/* Optional: Provide limits */
# endif
.....
#endif
`----
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Apr 6 '06 #4
Ivanna Pee schrieb:
Thomas Carter wrote:
Imagine that there is some include file f.h that contains the following
line:

typedef unsigned int ui32 ;

My question is: If I have a C source file F.c that includes f.h, is it
possible for the preprocessor to detect that ui32 already exists, when
preprocessing F.c? The idea is that F.c will typedef ui32 as above if and
only if such typedef is not already in some include file used by F.c.
/* File f.h */

#ifndef _UI32
#define _UI32


In principle correct but the (macro) identifiers starting with
_ should be left to the implementation -- this is not the exact
truth but you are on the safe side if you keep to it.
typedef unsigned int ui32 ;
#endif

Cheers
Michael

--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Apr 6 '06 #5

Thomas Carter wrote:
Imagine that there is some include file f.h that contains the following
line:

typedef unsigned int ui32 ;

My question is: If I have a C source file F.c that includes f.h, is it
possible for the preprocessor to detect that ui32 already exists, when
preprocessing F.c? The idea is that F.c will typedef ui32 as above if and
only if such typedef is not already in some include file used by F.c.


In f.h:

#define UI32_TYPEDEF
typedef ... ui32;

in F.c:

#ifndef UI32_TYPEDEF
typedef ... ui32;
#endif

Apr 6 '06 #6
On Thu, 06 Apr 2006 18:53:58 +0000, Thomas Carter wrote:
Imagine that there is some include file f.h that contains the following
line:

typedef unsigned int ui32 ;

My question is: If I have a C source file F.c that includes f.h, is it
possible for the preprocessor to detect that ui32 already exists, when
preprocessing F.c? The idea is that F.c will typedef ui32 as above if and
only if such typedef is not already in some include file used by F.c.


Thanks everybody for your suggestions. I forgot to point out that, in
general, one is not allowed to modify f.h. I guess that with such
restriction, what I want to do in general just can't be done.
Apr 6 '06 #7
In article <pa****************************@nanobots.com>,
Thomas Carter <T.******@nanobots.com> wrote:
On Thu, 06 Apr 2006 18:53:58 +0000, Thomas Carter wrote:
My question is: If I have a C source file F.c that includes f.h, is it
possible for the preprocessor to detect that ui32 already exists, when
preprocessing F.c? The idea is that F.c will typedef ui32 as above if and
only if such typedef is not already in some include file used by F.c.
Thanks everybody for your suggestions. I forgot to point out that, in
general, one is not allowed to modify f.h. I guess that with such
restriction, what I want to do in general just can't be done.


You might want to look at "autoconf" as a mechanism to figure out
whether the typedef is present and to generate an include file with
the appropriate macro definition. "autoconf" (and other such tools)
are outside of the rhelm of standard C, but it is plausibly ported
to all of the environments you will care about.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
Apr 6 '06 #8
Thomas Carter <T.******@nanobots.com> writes:
On Thu, 06 Apr 2006 18:53:58 +0000, Thomas Carter wrote:
Imagine that there is some include file f.h that contains the following
line:

typedef unsigned int ui32 ;

My question is: If I have a C source file F.c that includes f.h, is it
possible for the preprocessor to detect that ui32 already exists, when
preprocessing F.c? The idea is that F.c will typedef ui32 as above if and
only if such typedef is not already in some include file used by F.c.


Thanks everybody for your suggestions. I forgot to point out that, in
general, one is not allowed to modify f.h. I guess that with such
restriction, what I want to do in general just can't be done.


There are ways to do it if you're wiling to go beyond the scope of
what the compiler alone can do for you.

For example, you can create a small test program that attempts to use
ui32:

#include "f.h"
#include <stdio.h>
int main(void)
{
ui32 dummy;
printf("ok\n");
return 0;
}

Attempt to compile and execute the program. If it prints "ok", the
typedef exists; otherwise, it doesn't. Use this result to generate,
say, another header file to be included by F.c (is that really an
uppercase "F"?). The generated header file might just include a
series of #define directives. Depending on your environment, a
reasonably simple shell script, batch file, or equivalent should do
the job.

Your F.c might then contain something like this:

#include "f.h"
#include "config.h"
....
#ifndef UI32_DEFINED
typedef unsigned int ui32;
#endif
....

If you're doing this kind of thing a lot, you might consider using a
tool like GNU autoconf (which is off-topic here, but easy to google).

You also need to be aware of what assumptions you're making. Type
unsigned int isn't necessarily 32 bits; it can be 16, 64, or even 47,
and even if it's 32 bits, some of them could be padding bits. There
might not even be a 32-bit integer type (though there will always be
some integer type that's *at least* 32 bits).

Ideally, you should use the <stdint.h> header, which defines typedefs
such as uint32_t, along with macros that let you determine whether
they're defined. The <stdint.h> header is new in C99, but it's not
difficult to implement most of it in C90; see Doug Gwyn's q8,
<http://www.lysator.liu.se/c/q8/index.html>.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 6 '06 #9
Michael Mair wrote:
Ivanna Pee schrieb:
Thomas Carter wrote:
Imagine that there is some include file f.h that contains the following
line:

typedef unsigned int ui32 ;

My question is: If I have a C source file F.c that includes f.h,
is it
possible for the preprocessor to detect that ui32 already exists, when
preprocessing F.c? The idea is that F.c will typedef ui32 as above if
and
only if such typedef is not already in some include file used by F.c.


/* File f.h */

#ifndef _UI32
#define _UI32


In principle correct but the (macro) identifiers starting with
_ should be left to the implementation -- this is not the exact
truth but you are on the safe side if you keep to it.
typedef unsigned int ui32 ;
#endif

Cheers
Michael


I agree with Michael. I normally follow the convention:

#ifndef H_FILENAME_H
....
#endif /* !defined(H_FILENAME_H) */

In reality it doesn't really matter what naming convention you use so
long as you are consistent throughout the code.

Hope that helps,

Joe
Apr 8 '06 #10
Me
Thomas Carter wrote:
Imagine that there is some include file f.h that contains the following
line:

typedef unsigned int ui32 ;

My question is: If I have a C source file F.c that includes f.h, is it
possible for the preprocessor to detect that ui32 already exists, when
preprocessing F.c? The idea is that F.c will typedef ui32 as above if and
only if such typedef is not already in some include file used by F.c.


You're better off using C++ for this which ignores duplicate typedefs.
If you decide to still do this with C, be very careful how you do this
because the majority of C compilers don't do any type safe linking so
you can run into strange and extremely hard to figure out problems if
code crosses 2 translation units and these typedefs get out of sync
somehow:

/* a.c */
typedef unsigned int ui32;
....

/* b.c */
typedef unsigned long ui32;
....

if the compiler is strict about aliasing (even if the representation of
unsigned int and unsigned long just happen to be the same on your
platform).

Apr 8 '06 #11
"Me" <an*****************@yahoo.com> writes:
Thomas Carter wrote:
Imagine that there is some include file f.h that contains the following
line:

typedef unsigned int ui32 ;

My question is: If I have a C source file F.c that includes f.h, is it
possible for the preprocessor to detect that ui32 already exists, when
preprocessing F.c? The idea is that F.c will typedef ui32 as above if and
only if such typedef is not already in some include file used by F.c.


You're better off using C++ for this which ignores duplicate typedefs.
If you decide to still do this with C, be very careful how you do this
because the majority of C compilers don't do any type safe linking so
you can run into strange and extremely hard to figure out problems if
code crosses 2 translation units and these typedefs get out of sync
somehow:

/* a.c */
typedef unsigned int ui32;
...

/* b.c */
typedef unsigned long ui32;
...

if the compiler is strict about aliasing (even if the representation of
unsigned int and unsigned long just happen to be the same on your
platform).


That's what header files are for.

You have a single definition for ui32, and every file that needs it
has a #include for the appropriate header (which has guards to avoid
multiple definitions).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 8 '06 #12
Joe Estock wrote:

Michael Mair wrote:
Ivanna Pee schrieb:
/* File f.h */

#ifndef _UI32
#define _UI32


In principle correct but the (macro) identifiers starting with
_ should be left to the implementation -- this is not the exact
truth but you are on the safe side if you keep to it.
typedef unsigned int ui32 ;
#endif

Cheers
Michael


I agree with Michael. I normally follow the convention:

#ifndef H_FILENAME_H
...
#endif /* !defined(H_FILENAME_H) */

In reality it doesn't really matter what naming convention you use so
long as you are consistent throughout the code.

Also, you should make sure that the naming convention,
is one that you reserve strictly for header file guards.
I used to use H_FILENAME for header guards,
but then I had a program with files sort.c and sort.h,
with a H_SORT header guard macro.
and anther file h_sort.c which also defined a macro H_SORT,
so I added the trailing underscore to the header guards
and I use that H_FILENAME_ convention only for header guards only.

I'd say that H_FILENAME_H is at least as good or better,
as long as you keep it straight that your program
won't generate an H_/**/_H macro for any other purpose.

--
pete
Apr 8 '06 #13

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: John Smith | last post by:
Hi I'm porting some C++ code to new platforms and have some 1-byte aligned structures which need a specific size. Since datatypes can vary on different platforms (which I found out the hard way...
12
by: Ark | last post by:
Hello NG, I arrange data in structs like { members... uint16_t crc; more members, maybe... } Then I need to save them, up to and including crc, in non-volatile memory or a file, as the case...
15
by: informativeguy | last post by:
Hi, I did typedef int Man; After some code I get a necessity to use the same name Man for char. I mean to say,I need to typedef char Man; But how can I do this???
20
by: Binary | last post by:
Hi, With keyword struct, we can simply do forward declare by: struct struct_a; but if we typedef it: typdef struct struct_a struct_a_t;
4
by: alex | last post by:
hi friends ... i am facing a problem while detecting floating point operations in my project, please help me. i want to find out the places in my C/C++ project where i am doing floating...
1
lotus18
by: lotus18 | last post by:
Hi This is a follow-up post from my post (please click here) as CyberSoftHari suggested me to post it here. These are the tables that I've made: Schedules -ScheduleID -StartTime
18
by: vivek | last post by:
What will happen if i replace a typedef with a #define?
40
by: Bill Cunningham | last post by:
I have been thinking about hiding headers from my compiler's preprocessor and allowing others to be shown. I want to use the most used and add others is necessary. Would this be how it is properly...
4
by: tkpmep | last post by:
I have a simulation that runs many times with different parameters, and I want to aggregate the output into a single file with one rub: I want a header to be written only the first time. My...
1
isladogs
by: isladogs | last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, Mike...
3
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 3 Jan 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). For other local times, please check World Time Buddy In...
0
by: abbasky | last post by:
### Vandf component communication method one: data sharing ​ Vandf components can achieve data exchange through data sharing, state sharing, events, and other methods. Vandf's data exchange method...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: fareedcanada | last post by:
Hello I am trying to split number on their count. suppose i have 121314151617 (12cnt) then number should be split like 12,13,14,15,16,17 and if 11314151617 (11cnt) then should be split like...
0
by: stefan129 | last post by:
Hey forum members, I'm exploring options for SSL certificates for multiple domains. Has anyone had experience with multi-domain SSL certificates? Any recommendations on reliable providers or specific...
0
Git
by: egorbl4 | last post by:
Скачал я git, хотел начать настройку, а там вылезло вот это Что это? Что мне с этим делать? ...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.