mysterious error while compiling device driver

[yeah]

hi all
I am working with linux environment and i compiled device driver
programs using native compiler "gcc".In one of my macro i have these
lines

#if (1 << HARDIRQ_BITS) < MAX_HARDIRQS_PER_CPU
# error HARDIRQ_BITS is too low!
#endif

while compiling,it gives error like this
"error : # error HARDIRQ_BITS is too low"

The error doesnt mean any particular type of error.
plz Help me to eliminate this error...

 

[Martin Ambuhl]

hi all
I am working with linux environment and i compiled device driver
programs using native compiler "gcc".In one of my macro i have these
lines

#if (1 << HARDIRQ_BITS) < MAX_HARDIRQS_PER_CPU
# error HARDIRQ_BITS is too low!
#endif

while compiling,it gives error like this
"error : # error HARDIRQ_BITS is too low"

The error doesnt mean any particular type of error.
plz Help me to eliminate this error...

Whatever the nonstandard macro HARDIRQ_BITS is defined as seems to be to
low, unless your code is lying to you. Defining it to be a large enough
value will make the error message go away. What other behavior that
might introduce is another question.

 

[Martin Wells]

yeah:

#if (1 << HARDIRQ_BITS) < MAX_HARDIRQS_PER_CPU
# error HARDIRQ_BITS is too low!
#endif

The logic seems very strange here. I would have expected:

#if (1u << HARDIRQ_BITS) > MAX_HARDIRQS_PER_CPU
# error HARDIRQ_BITS is too high!
#endif

while compiling,it gives error like this
"error : # error HARDIRQ_BITS is too low"

The error doesnt mean any particular type of error.
plz Help me to eliminate this error...

Purchase a fully-functional human brain with an intelligence rating
higher than 5. With such a device, I think you'd clearly see that
either:

1: HARDIRQ_BITS is too small
2: MAX_HARDIRQS_PER_CPU is too big

(...that's assuming your logic is right)

And I'd advocate not to do bitshifting on signed integers, I'd prefer
"1u << ".

Martin

 

[Mark Bluemel]

hi all
I am working with linux environment and i compiled device driver
programs using native compiler "gcc".In one of my macro i have these
lines

#if (1 << HARDIRQ_BITS) < MAX_HARDIRQS_PER_CPU
# error HARDIRQ_BITS is too low!
#endif

while compiling,it gives error like this
"error : # error HARDIRQ_BITS is too low"

The error doesnt mean any particular type of error.

Of course it means a particular type of error. But it's not really one
which we as a newsgroup are particularly well-placed to help you resolve.

plz Help me to eliminate this error...

I'm sure someone will be along to castigate me for this, but to
paraphrase the great Obi-Wan Kenobi "this is not the newsgroup you are
looking for".

In fact it's doubtful that a newsgroup is the right place to look at all.

How about contacting the originator of the code? (I assume you didn't
write it as otherwise you'd know what the error implied).

Alternatively, a brief scan with Google indicates that there's a fair
amount of information about this stuff on the web.

 

[Erik Trulsson]

yeah:



The logic seems very strange here. I would have expected:

#if (1u << HARDIRQ_BITS) > MAX_HARDIRQS_PER_CPU
# error HARDIRQ_BITS is too high!
#endif

That depends on what the rest of the code does. My guess
is that test is to see that HARDIRQ_BITS is large enough to
keep track of all the possible HARDIRQS, in which case the
logic is right.

 

[yeah]

yeah:


The logic seems very strange here. I would have expected:

#if (1u << HARDIRQ_BITS) > MAX_HARDIRQS_PER_CPU
# error HARDIRQ_BITS is too high!
#endif



Purchase a fully-functional human brain with an intelligence rating
higher than 5. With such a device, I think you'd clearly see that
either:

1: HARDIRQ_BITS is too small
2: MAX_HARDIRQS_PER_CPU is too big

(...that's assuming your logic is right)

And I'd advocate not to do bitshifting on signed integers, I'd prefer
"1u << ".

Martin

hi martin:

First understand that the error is not while running but during the
compilation.
So no matter whether the condition is true or false.

thanks

 

[santosh]

hi martin:

First understand that the error is not while running but during the
compilation. So no matter whether the condition is true or false.

Martin perfectly understands the code. It you who is not understanding. A
conforming compiler is required to abort translation when it encounters an
active #error directive.

In the case of this code the conditional following the #if directive
apparently is true, hence the #error directive is selected and hence
translation stops.

Your solution involves understanding exactly what the conditional means,
semantically, and doing what is necessary to prevent the statement from
resolving to true. This involves information specific to your system and
the program in question and we cannot give any answer from the perspective
of Standard C.

Also it's better to supply a string literal to the #error directive than a
sequence of token like you've done above.

 

[Martin Wells]

yeah:

hi martin:

First understand that the error is not while running but during the
compilation.
So no matter whether the condition is true or false.

thanks

My troll-o-meter is starting to beep a little... but I'll give you one
last try.

If you don't understand the following, then I think you should take up
gardening.

#define ROWS 5
#define COLS 6

#if COLS > ROWS
# error "Can't have more columns than rows!"
#endif

This is EXACTLY what's happening in your code.

Martin

 

[Richard Heathfield]

santosh said:

A conforming compiler is required to abort translation when it encounters
an active #error directive.

Only in C99. Astonishingly, this is *not* required in C90. (Nevertheless,
C90 compilers are free to stop translation if they wish, and I don't know
of any that don't.)

 

[Old Wolf]

santosh said:


Only in C99. Astonishingly, this is *not* required in C90. (Nevertheless,
C90 compilers are free to stop translation if they wish, and I don't know
of any that don't.)

The one I'm using currently reports the #error but then
continues to translate the rest of the file. It does
report a failure code to the caller though, so the 'make'
system stops the build after that.

The command is:
arm-linux-unknown-gnu-gcc-3.4.4 -c -std=c89 -Os -Wall

and a handful of other warnings and CPU-specific code
generation flags.

 

[CBFalconer]

The logic seems very strange here. I would have expected:

#if (1u << HARDIRQ_BITS) > MAX_HARDIRQS_PER_CPU
# error HARDIRQ_BITS is too high!
#endif
.... snip ...

1: HARDIRQ_BITS is too small
or
2: MAX_HARDIRQS_PER_CPU is too big

(...that's assuming your logic is right)

And I'd advocate not to do bitshifting on signed integers, I'd
prefer "1u << ".

Shifting of positive values is allowable, provided that the value
never overflows the value handled by an int. However, as you say,
the overall logic is suspect.

 

[Charlie Gordon]

Shifting of positive values is allowable, provided that the value
never overflows the value handled by an int. However, as you say,
the overall logic is suspect.

In this case, 1 is not an int, it is a preprocessor integer literal that is
supposed to behave like an intmax_t.

 

[=?iso-2022-kr?q?Harald_van_D=0E=29=26=0Fk?=]

#if (1 << HARDIRQ_BITS) < MAX_HARDIRQS_PER_CPU # error HARDIRQ_BITS
[...]
#if (1u << HARDIRQ_BITS) > MAX_HARDIRQS_PER_CPU # error
[...]
And I'd advocate not to do bitshifting on signed integers, I'd prefer
"1u << ".

Shifting of positive values is allowable, provided that the value never
overflows the value handled by an int. However, as you say, the
overall logic is suspect.

In this case, 1 is not an int, it is a preprocessor integer literal that
is supposed to behave like an intmax_t.

It is a bit of both, actually: 1 is an integer constant of type int, and
the type int is supposed to behave like intmax_t.

 

[Charlie Gordon]

Martin Wells wrote:
#if (1 << HARDIRQ_BITS) < MAX_HARDIRQS_PER_CPU # error HARDIRQ_BITS
[...]
#if (1u << HARDIRQ_BITS) > MAX_HARDIRQS_PER_CPU # error
[...]
And I'd advocate not to do bitshifting on signed integers, I'd prefer
"1u << ".

Shifting of positive values is allowable, provided that the value never
overflows the value handled by an int. However, as you say, the
overall logic is suspect.

In this case, 1 is not an int, it is a preprocessor integer literal that
is supposed to behave like an intmax_t.

It is a bit of both, actually: 1 is an integer constant of type int, and
the type int is supposed to behave like intmax_t.

I dont know where you derive this. The text of 6.10.1p4 does not mention
type int, it says:

"...each preprocessing token is converted into a token. The resulting tokens
compose the controlling constant expression which is evaluated according to
the rules of 6.6. For the purposes of this token conversion and evaluation,
all signed integer types and all unsigned integer types act as if they have
the same representation as, respectively, the types intmax_t and
uintmax_t defined in the header <stdint.h>."

But the net result is that ``1 << HARDIRQ_BITS'' is OK to use as a
preprocessing test expression for values of HARDIRQ_BITS at least up to 62.

A more difficult question is whether ``(1 == 1) << 62'' is a valid
preprocessor expression ;-)

 

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

"CBFalconer" <[email protected]> a écrit dans le message de (e-mail address removed)...
Martin Wells wrote:
#if (1 << HARDIRQ_BITS) < MAX_HARDIRQS_PER_CPU # error HARDIRQ_BITS
[...]
#if (1u << HARDIRQ_BITS) > MAX_HARDIRQS_PER_CPU # error
[...]
And I'd advocate not to do bitshifting on signed integers, I'd
prefer "1u << ".

Shifting of positive values is allowable, provided that the value
never overflows the value handled by an int. However, as you say,
the overall logic is suspect.

In this case, 1 is not an int, it is a preprocessor integer literal
that is supposed to behave like an intmax_t.

It is a bit of both, actually: 1 is an integer constant of type int,
and the type int is supposed to behave like intmax_t.

I dont know where you derive this. The text of 6.10.1p4 does not
mention type int, it says:

"...each preprocessing token is converted into a token. The resulting
tokens compose the controlling constant expression which is evaluated
according to the rules of 6.6. For the purposes of this token conversion
and evaluation, all signed integer types and all unsigned integer types
act as if they have the same representation as, respectively, the types
intmax_t and uintmax_t defined in the header <stdint.h>."

That's where I get it from. It says all integer _types_ act as if they
have the same representation as (u)intmax_t. 1 is an integer literal. 1
is not an integer type. int is an integer type.

But the net result is that ``1 << HARDIRQ_BITS'' is OK to use as a
preprocessing test expression for values of HARDIRQ_BITS at least up to
62.
Agreed.

A more difficult question is whether ``(1 == 1) << 62'' is a valid
preprocessor expression ;-)

Sure. (1 == 1) is an expression of type int, int behaves as if it has the
same representation as intmax_t, intmax_t has at least 64 bits, so there
can be no overflow.