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]

yeah wrote:

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]

yeah wrote:

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]

Martin Wells <wa****@eircom.netwrote:

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

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.

>

>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

--
<Insert your favourite quote here.>
Erik Trulsson
er******@student.uu.se

[yeah]

On Oct 3, 1:08 pm, Martin Wells <[e-mail]:

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

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]

yeah wrote:

On Oct 3, 1:08 pm, Martin Wells <[e-mail]:

>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 << ".

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

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Old Wolf]

On Oct 4, 1:24 am, Richard Heathfield <[e-mail]:

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

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]

Martin Wells wrote:

>

>#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"

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

--
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

[Charlie Gordon]

"CBFalconer" <cb********@yahoo.coma écrit dans le message de news:
47***************@yahoo.com...

Martin Wells wrote:

>>

>>#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"

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

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

--
Chqrlie.

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

On Fri, 05 Oct 2007 00:14:50 +0200, Charlie Gordon wrote:

"CBFalconer" <cb********@yahoo.coma écrit dans le message de news:
47***************@yahoo.com...

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

[Charlie Gordon]

"Harald van D?k" <tr*****@gmail.coma écrit dans le message de news:
fe**********@news6.zwoll1.ov.home.nl...

On Fri, 05 Oct 2007 00:14:50 +0200, Charlie Gordon wrote:

>"CBFalconer" <cb********@yahoo.coma écrit dans le message de news:
47***************@yahoo.com...

>>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 ;-)

--
Chqrlie.

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

On Fri, 05 Oct 2007 08:39:06 +0200, Charlie Gordon wrote:

"Harald van D?k" <tr*****@gmail.coma écrit dans le message de news:
fe**********@news6.zwoll1.ov.home.nl...

>On Fri, 05 Oct 2007 00:14:50 +0200, Charlie Gordon wrote:

>>"CBFalconer" <cb********@yahoo.coma écrit dans le message de news:
47***************@yahoo.com...
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.