Skip to contentSkip to conversation

ERROR: do not initialise externals to 0 or NULL

DISCUSSION Joe Eloff 3 participants 10 messages Jul 5, 2010 Kernel janitors

lore
Share & tools
lore

Joe Eloff

author
#0 lore raw

Hi,

I have searched for results on this and most things I find is that it must be dropped.

Could someone please give me an indication of ways to solve this or should I just leave it in the patch?

Thanks,

Joe

#1 lore raw
Quoted 5 lines · Joe Eloff

Hi,

I have searched for results on this and most things I find is that it must be dropped.

You mean something like:

extern int foo = 0;

initializing an extern doesn't make sense. It doesn't matter what you initialize it to. Gcc should warn about this. The initialization should go where the actual variable is declared.

If that doesn't answer your question, can you send some sample code that causes the error?

regards,
dan carpenter

Quoted 11 lines

Could someone please give me an indication of ways to solve this or should I just leave it in the patch?

Thanks,

Joe

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw
In reply to Joe Eloff
Quoted 9 lines · Dan Carpenter
Quoted 5 lines · Joe Eloff

Hi,

I have searched for results on this and most things I find is that it must be dropped.

You mean something like:

Quoted 8 lines

extern int foo = 0;

initializing an extern doesn't make sense. It doesn't matter what you initialize it to. Gcc should warn about this. The initialization should go where the actual variable is declared.

If that doesn't answer your question, can you send some sample code that causes the error?

For what it is worth, I didn't find anything with the following semantic match:

@@
type T;
identifier x;
expression E;
@@

* extern T x = E;

This, if there actually is such a thing, I would be interested to know about it.

julia

author
#3 lore raw
In reply to Joe Eloff

Hi Dan,

Here is the line of code:
/* Error variable. Zero means no error. */
int dt3155_errno = 0;

no extern results in following error:
ERROR: do not initialise externals to 0 or NULL

It is declared in the globals scope at the top of the file just after includes not in any function.

Have no idea why or how to make it go away??

Regards,

Joe

Quoted 32 lines · Dan Carpenter
Quoted 5 lines · Joe Eloff

Hi,

I have searched for results on this and most things I find is that it must be dropped.

You mean something like:

extern int foo = 0;

initializing an extern doesn't make sense. It doesn't matter what you initialize it to. Gcc should warn about this. The initialization should go where the actual variable is declared.

If that doesn't answer your question, can you send some sample code that causes the error?

regards,
dan carpenter

Quoted 11 lines

Could someone please give me an indication of ways to solve this or should I just leave it in the patch?

Thanks,

Joe

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#4 lore raw
In reply to Joe Eloff
Quoted 6 lines · Joe Eloff

Hi Dan,

Here is the line of code:
/* Error variable. Zero means no error. */
int dt3155_errno = 0;

Quoted 7 lines

no extern results in following error:
ERROR: do not initialise externals to 0 or NULL

It is declared in the globals scope at the top of the file just after includes not in any function.

Have no idea why or how to make it go away??

Wouldn't "global" be a better word than "external"? Anyway, global variables default to being zero so they don't need to be initialized.

/* Error variable. Zero means no error. */
int dt3155_errno;

But really this global variable is pretty ugly. It would be better to eliminate it. You would have to modify wait_ibsyclr() somehow...

regards,
dan carpenter

#5 lore raw
In reply to Joe Eloff
Quoted 6 lines · Dan Carpenter

/* Error variable. Zero means no error. */
int dt3155_errno;

But really this global variable is pretty ugly. It would be better to eliminate it. You would have to modify wait_ibsyclr() somehow...

The variable gets assigned but never used. Maybe try figure out if that means there is a larger bug, otherwise you can just removed it entirely.

Quoted 2 lines

regards,
dan carpenter

author
#6 lore raw
In reply to Joe Eloff
Quoted 18 lines · Dan Carpenter
Quoted 6 lines · Joe Eloff

Hi Dan,

Here is the line of code:
/* Error variable. Zero means no error. */
int dt3155_errno = 0;

Quoted 7 lines

no extern results in following error:
ERROR: do not initialise externals to 0 or NULL

It is declared in the globals scope at the top of the file just after includes not in any function.

Have no idea why or how to make it go away??

Wouldn't "global" be a better word than "external"? Anyway, global variables default to being zero so they don't need to be initialized.

Quoted 10 lines

/* Error variable. Zero means no error. */
int dt3155_errno;

But really this global variable is pretty ugly. It would be better to eliminate it. You would have to modify wait_ibsyclr() somehow...

regards,
dan carpenter

Ah thanks...

Will look into it and fix it up.

Who will ever know why the result and the cause can't have the correct message. Personally I would have said "global" but we didn't write the message did we :(!

author
#7 lore raw
In reply to Joe Eloff
Quoted 4 lines · Dan Carpenter
Quoted 3 lines · Dan Carpenter

/* Error variable. Zero means no error. */
int dt3155_errno;

Quoted 9 lines
Quoted 3 lines

But really this global variable is pretty ugly. It would be better to eliminate it. You would have to modify wait_ibsyclr() somehow...

The variable gets assigned but never used. Maybe try figure out if that means there is a larger bug, otherwise you can just removed it entirely.

Quoted 2 lines

regards,
dan carpenter

Saw that it never gets used but assigned as looking into it.

Regards,

Joe

#8 lore raw
In reply to Joe Eloff
Quoted 8 lines · Joe Eloff

Ah thanks...

Will look into it and fix it up.

Who will ever know why the result and the cause can't have the correct message. Personally I would have said "global" but we didn't write the message did we :(!

Well... No one would get upset with you if you were to send a patch for checkpatch.pl with a better message. *hint* *hint*

regards,
dan carpenter

author
#9 lore raw
In reply to Joe Eloff
Quoted 10 lines · Dan Carpenter
Quoted 8 lines · Joe Eloff

Ah thanks...

Will look into it and fix it up.

Who will ever know why the result and the cause can't have the correct message. Personally I would have said "global" but we didn't write the message did we :(!

Quoted 5 lines

Well... No one would get upset with you if you were to send a patch for checkpatch.pl with a better message. *hint* *hint*

regards,
dan carpenter

LOL will dust of my perl and look at it :) *sharp* *sharp*!