facing problem during compilation

[junky_fellow@yahoo.co.in]

Guys,

I have put the following two lines in a header file to prevent it
from getting included multiple times.

#ifndef __MY_HDR.H__
#define __MY_HDR.H__

// Some macros here

#endif

However, when I compile the code, I am getting following warnings,
warning: extra token at end of #ifndef directive
warning ISO C requires whitespace after the macro name


Can anyone help me finding the problem ?

thnaks a lot for any help.

[Joachim Schmitz]

Re: facing problem during compilation

<junky_fellow@y ahoo.co.inschri eb im Newsbeitrag
news:1190379028 .636557.216190@ q3g2000prf.goog legroups.com...

Guys,
>
I have put the following two lines in a header file to prevent it
from getting included multiple times.
>
#ifndef __MY_HDR.H__
#define __MY_HDR.H__
>
// Some macros here
>
#endif
>
However, when I compile the code, I am getting following warnings,
warning: extra token at end of #ifndef directive
warning ISO C requires whitespace after the macro name
>
>
Can anyone help me finding the problem ?

Guess it's complaining about the .
Also you shouldn't be usign macros or identifiers that start with an _, they
are resoved for the implementation, so try MY_HDR_H or MY_HDR_H_ instead

Bye, Jojo

[jacob navia]

Re: facing problem during compilation

junky_fellow@ya hoo.co.in wrote:

Guys,
>
I have put the following two lines in a header file to prevent it
from getting included multiple times.
>
#ifndef __MY_HDR.H__
#define __MY_HDR.H__
>
// Some macros here
>
#endif
>
However, when I compile the code, I am getting following warnings,
warning: extra token at end of #ifndef directive
warning ISO C requires whitespace after the macro name
>
>
Can anyone help me finding the problem ?
>
thnaks a lot for any help.
>

You wrote:

__MY_HDR.H__

The point is NOT an identifier, you can't write points into
an identifier. Then, the compiler sees
__MY_HDR . H__
This is NOT a valid #ifndef directive of course.

Solution
Change
__MY_HDR.H__ to:

__MY_HDR_H__

getting rid of the point.

[Martien verbruggen]

Re: facing problem during compilation

On Fri, 21 Sep 2007 05:50:28 -0700,
junky_fellow@ya hoo.co.in <junky_fellow@y ahoo.co.inwrote :

Guys,
>
I have put the following two lines in a header file to prevent it
from getting included multiple times.
>
#ifndef __MY_HDR.H__
#define __MY_HDR.H__

You can't use a full stop in a preprocessor macro identifier (or any
other identifier). You can use letters (from the english alphabet),
digits and the underscore, and the first character can't be a digit.

You also shouldn't start then with an underscore and follow that with
another underscore or an uppercase letter, as all of those identifiers
are reserved, and not for use by the programmer.

Use something like:

#ifndef MY_HDR_H
#define MY_HDR_H

Martien
--
|
Martien Verbruggen | "In a world without fences,
| who needs Gates?"
|

[Keith Thompson]

Re: facing problem during compilation

Martien verbruggen <mgjv@tradingpo st.com.auwrites :

On Fri, 21 Sep 2007 05:50:28 -0700,
junky_fellow@ya hoo.co.in <junky_fellow@y ahoo.co.inwrote :

> I have put the following two lines in a header file to prevent it
>from getting included multiple times.
>>
>#ifndef __MY_HDR.H__
>#define __MY_HDR.H__

>
You can't use a full stop in a preprocessor macro identifier (or any
other identifier). You can use letters (from the english alphabet),
digits and the underscore, and the first character can't be a digit.
>
You also shouldn't start then with an underscore and follow that with
another underscore or an uppercase letter, as all of those identifiers
are reserved, and not for use by the programmer.
>
Use something like:
>
#ifndef MY_HDR_H
#define MY_HDR_H

Using this pattern presents a risk of stepping on the implementation' s
reserved namespace if your header name happens to start with 'e',
since identifiers starting with an upper-case 'E' followed by another
upper-case letter are reserved as errno macros.

Even though it hurts readability a bit, consider using:

#ifndef H_MY_HDR
#define H_MY_HDR
...
#endif

--
Keith Thompson (The_Other_Keit h) kst-u@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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Re: facing problem during compilation

jacob navia wrote:

junky_fellow@ya hoo.co.in wrote:

>>
>I have put the following two lines in a header file to prevent
>it from getting included multiple times.
>>
>#ifndef __MY_HDR.H__
>#define __MY_HDR.H__
>// Some macros here
>#endif
>>
>However, when I compile the code, I am getting following
>warnings, warning: extra token at end of #ifndef directive
>warning ISO C requires whitespace after the macro name

>
You wrote:
>
__MY_HDR.H__
>
The point is NOT an identifier, you can't write points into
an identifier. Then, the compiler sees
__MY_HDR . H__
This is NOT a valid #ifndef directive of course.
>
Solution: Change
__MY_HDR.H__ to:
>
__MY_HDR_H__
>
getting rid of the point.

This is true, but the identifier is still illegal. Get rid of the
leading "__" in the name. Such names are reserved for the
implementation. I use a leading H_, thus avoiding every getting
the illegal E* names (also reserved).

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>



--
Posted via a free Usenet account from http://www.teranews.com

[jacob navia]

Re: facing problem during compilation

CBFalconer wrote:

jacob navia wrote:

>junky_fellow@ya hoo.co.in wrote:

>>I have put the following two lines in a header file to prevent
>>it from getting included multiple times.
>>>
>>#ifndef __MY_HDR.H__
>>#define __MY_HDR.H__
>>// Some macros here
>>#endif
>>>
>>However, when I compile the code, I am getting following
>>warnings, warning: extra token at end of #ifndef directive
>>warning ISO C requires whitespace after the macro name

>You wrote:
>>
> __MY_HDR.H__
>>
>The point is NOT an identifier, you can't write points into
>an identifier. Then, the compiler sees
> __MY_HDR . H__
>This is NOT a valid #ifndef directive of course.
>>
>Solution: Change
> __MY_HDR.H__ to:
>>
> __MY_HDR_H__
>>
>getting rid of the point.

>
This is true, but the identifier is still illegal. Get rid of the
leading "__" in the name. Such names are reserved for the
implementation. I use a leading H_, thus avoiding every getting
the illegal E* names (also reserved).
>

It is true that those names are reserved, but with
your schema you can conflict with some H_* name in the program...

Name conflicts are impossible to avoid.

jacob

[Richard Tobin]

Re: facing problem during compilation

In article <46F416C8.914E3 FB6@yahoo.com>,
CBFalconer <cbfalconer@mai neline.netwrote :

>This is true, but the identifier is still illegal. Get rid of the
>leading "__" in the name. Such names are reserved for the
>implementation . I use a leading H_, thus avoiding every getting
>the illegal E* names (also reserved).

The standard authors may have reserved to the implemention macro names
of the form E[A-Z0-9]_H, but I'll be happy to avoid any implementation
that uses them.

-- Richard

--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Richard Tobin]

Re: facing problem during compilation

In article <lnejgrdfoy.fsf @nuthaus.mib.or g>,
Keith Thompson <kst-u@mib.orgwrote:

>Using this pattern presents a risk of stepping on the implementation' s
>reserved namespace if your header name happens to start with 'e',
>since identifiers starting with an upper-case 'E' followed by another
>upper-case letter are reserved as errno macros.

But any library you use may happen to define a macro that conflicts
with a name you choose. The chance of an implementation defining an
errno ending _H is no greater - and probably much smaller, because it
would be Obviously Stupid.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[jacob navia]

Re: facing problem during compilation

Richard Tobin wrote:

In article <lnejgrdfoy.fsf @nuthaus.mib.or g>,
Keith Thompson <kst-u@mib.orgwrote:
>

>Using this pattern presents a risk of stepping on the implementation' s
>reserved namespace if your header name happens to start with 'e',
>since identifiers starting with an upper-case 'E' followed by another
>upper-case letter are reserved as errno macros.

>
But any library you use may happen to define a macro that conflicts
with a name you choose. The chance of an implementation defining an
errno ending _H is no greater - and probably much smaller, because it
would be Obviously Stupid.
>
-- Richard

The problem has no solution

besides...

#pragma once

But we have discussed this several times. I think
#pragma once
is a good solution and my compiler system implements it.

With this pragma, there is NO NEED to figure out a name.

jacob

[Keith Thompson]

Re: facing problem during compilation

jacob navia <jacob@jacob.re mcomp.frwrites:

Richard Tobin wrote:

>In article <lnejgrdfoy.fsf @nuthaus.mib.or g>,
>Keith Thompson <kst-u@mib.orgwrote:
>>

>>Using this pattern presents a risk of stepping on the implementation' s
>>reserved namespace if your header name happens to start with 'e',
>>since identifiers starting with an upper-case 'E' followed by another
>>upper-case letter are reserved as errno macros.

>But any library you use may happen to define a macro that conflicts
>with a name you choose. The chance of an implementation defining an
>errno ending _H is no greater - and probably much smaller, because it
>would be Obviously Stupid.
>-- Richard

>
The problem has no solution
>
besides...
>
#pragma once
>
But we have discussed this several times. I think
#pragma once
is a good solution and my compiler system implements it.
>
With this pragma, there is NO NEED to figure out a name.

But of course your code loses portability to implementations that
don't support #pragma once. I wouldn't mind if it had been
standardized, but it wasn't. (And determining whether two names refer
to the same file can be non-trivial on some systems; the #ifndef
technique lets the programmer assign a unique name to each file.)

In any case, C has a fundamental problem with name collisions. The
usual workaround is to apply a common prefix to each visible
identifier, but there's no real guarantee that two organizations won't
pick the same prefix. Even C++-style namespaces and other similar
mechanisms don't completely solve the problem, unless you can set up
and enforce a central registry of prefixes, or namespace names, or
whatever.

#pragma once is a nice feature, and it's useful for reasons other than
avoiding name collisions, but it only addresses one small piece of the
general name collision problem.

In practice, programmers *usually* can manage to pick unique names
with only occasional problems. There are no perfect solutions, but
there are plenty of imperfect ones.

--
Keith Thompson (The_Other_Keit h) kst-u@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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Re: facing problem during compilation

Keith Thompson wrote:

In practice, programmers *usually* can manage to pick unique names
with only occasional problems. There are no perfect solutions, but
there are plenty of imperfect ones.
>

Yes, there are no solutions that are perfect in all cases for this
problem.

One advantage of the
#ifndef
#define
....
#endif
method, is that you can "turn off" an included
file!!

Imagine that foo.c includes keith.h and
that includes chris.h

If you want to include keith.h without including
chris.h for whatever reason you call the compiler
with

compiler -D__chris_h__ foo.c

and you have that file completely commented out!

[CBFalconer]

Re: facing problem during compilation

Richard Tobin wrote:

CBFalconer <cbfalconer@mai neline.netwrote :
>

>This is true, but the identifier is still illegal. Get rid of the
>leading "__" in the name. Such names are reserved for the
>implementation . I use a leading H_, thus avoiding every getting
>the illegal E* names (also reserved).

>
The standard authors may have reserved to the implemention macro
names of the form E[A-Z0-9]_H, but I'll be happy to avoid any
implementation that uses them.

Then you will have to avoid almost all implementations of a C
system. Take a look at the E(rror) id macros.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>



--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

Re: facing problem during compilation

CBFalconer <cbfalconer@yah oo.comwrites:

Richard Tobin wrote:

>CBFalconer <cbfalconer@mai neline.netwrote :

>>This is true, but the identifier is still illegal. Get rid of the
>>leading "__" in the name. Such names are reserved for the
>>implementatio n. I use a leading H_, thus avoiding every getting
>>the illegal E* names (also reserved).

>>
>The standard authors may have reserved to the implemention macro
>names of the form E[A-Z0-9]_H, but I'll be happy to avoid any
>implementati on that uses them.

>
Then you will have to avoid almost all implementations of a C
system. Take a look at the E(rror) id macros.

I think he's well aware of that.

Yes, it's true that all identifiers starting with an uppercase 'E'
followed by either a digit or another uppercase letter are reserved.
But using such an identifier that doesn't happen to be one that's used
by the current implementation is very likely to be harmless, and it's
extremely unlikely that any implementation actually uses an identifier
starting with "E" and ending with "_H".

I'd still prefer to stick to H_NAME, for include guard macros, but its
true that using NAME_H is very unlikely *in practice* to cause any
problems.

--
Keith Thompson (The_Other_Keit h) kst-u@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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jaysome]

Re: facing problem during compilation

On Fri, 21 Sep 2007 19:03:04 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>CBFalconer <cbfalconer@yah oo.comwrites:

>Richard Tobin wrote:

>>CBFalconer <cbfalconer@mai neline.netwrote :
>>>This is true, but the identifier is still illegal. Get rid of the
>>>leading "__" in the name. Such names are reserved for the
>>>implementati on. I use a leading H_, thus avoiding every getting
>>>the illegal E* names (also reserved).
>>>
>>The standard authors may have reserved to the implemention macro
>>names of the form E[A-Z0-9]_H, but I'll be happy to avoid any
>>implementatio n that uses them.

>>
>Then you will have to avoid almost all implementations of a C
>system. Take a look at the E(rror) id macros.

>
>I think he's well aware of that.
>
>Yes, it's true that all identifiers starting with an uppercase 'E'
>followed by either a digit or another uppercase letter are reserved.
>But using such an identifier that doesn't happen to be one that's used
>by the current implementation is very likely to be harmless, and it's
>extremely unlikely that any implementation actually uses an identifier
>starting with "E" and ending with "_H".

Let alone any identifier that begins with "E" and contains an
underscore, let alone one that contains *multiple* underscores. For
example, the identifier used here:

/* entropy.h */
#ifndef ENTROPY_H_INCLU DED__

has 0 probability of being used by an implementation, IMHO.

>I'd still prefer to stick to H_NAME, for include guard macros, but its
>true that using NAME_H is very unlikely *in practice* to cause any
>problems.

Just like an identifier that matches the regular expression:
..+.*_H_INCLUDE D__

is very unlikely *in practice* to cause any problems.

--
jay