"extern struct foobar" linux compilation warning

[Rick Anderson]

All,

I am receiving the following compilation error on LINUX
(but not Solaris, HPUX, WIN32, etc):

compiling osr.c
LBFO.h(369): warning #64: declaration does not declare anything
extern struct foobar;
^

This is apparently a forward reference to a data structure
for the purposes of declaring a pointer to this opaque
structure.

Any ideas how to get rid of this warning???

Thanks in advance!
Rick

[Rick Anderson]

Re: "extern struct foobar" linux compilation warning

BTW: This is the "icc" (intel compiler) *not*
gcc...

It appears -fms_extensions compiler option is not supported.

FYI

Thanks!
Rick

[Kevin Bracey]

Re: "extern struct foobar" linux compilation warning

In message <Xns96144B798C6 43RichardAnders onoracl@148.87. 1.53>
Rick Anderson <Richard.Anders on@oracle.com> wrote:
[color=blue]
> I am receiving the following compilation error on LINUX
> (but not Solaris, HPUX, WIN32, etc):
>
> compiling osr.c
> LBFO.h(369): warning #64: declaration does not declare anything
> extern struct foobar;
> ^
>
> This is apparently a forward reference to a data structure
> for the purposes of declaring a pointer to this opaque
> structure.
>
> Any ideas how to get rid of this warning???[/color]

Remove the "extern". It's meaningless unless you're actually declaring an
object, which you're not. You're merely naming a structure type.

--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: +44 (0) 1223 503464
182-190 Newmarket Road Fax: +44 (0) 1728 727430
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/

[Michael Mair]

Re: &quot;extern struct foobar&quot; linux compilation warning

Rick Anderson wrote:[color=blue]
> All,
>
> I am receiving the following compilation error on LINUX
> (but not Solaris, HPUX, WIN32, etc):
>
> compiling osr.c
> LBFO.h(369): warning #64: declaration does not declare anything
> extern struct foobar;
> ^[/color]

extern struct foobar baz;

would make sense.

struct foobar;

can make sense.
"extern" goes with objects, not with types.

[color=blue]
> This is apparently a forward reference to a data structure
> for the purposes of declaring a pointer to this opaque
> structure.[/color]

Is it?

If it is really necessary to get something opaque,
use void *:

typedef void * FooBarHandle;

The user gets only the handle and even a look at the
typedef does not tell how and where information is stored.
If the user can be trusted to not circumvent your access
macros and functions (and your data structures are not
top secret), the header file giving the type definition
for "struct foobar" should be included.
[color=blue]
> Any ideas how to get rid of this warning???[/color]

Heal the code.


Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Kevin Bracey]

Re: &quot;extern struct foobar&quot; linux compilation warning

In message <3989n5F5vqe4bU 1@individual.ne t>
Michael Mair <Michael.Mair@i nvalid.invalid> wrote:
[color=blue]
> If it is really necessary to get something opaque,
> use void *:
>
> typedef void * FooBarHandle;
>
> The user gets only the handle and even a look at the
> typedef does not tell how and where information is stored.
> If the user can be trusted to not circumvent your access
> macros and functions (and your data structures are not
> top secret), the header file giving the type definition
> for "struct foobar" should be included.[/color]

I beg to differ. I'd prefer

typedef struct foobar *FooBarHandle;

leaving the contents of struct foobar opaque. That gives you a bit more type
safety - someone can't accidentally give you a BarHandle instead of a
FooBarHandle.

--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: +44 (0) 1223 503464
182-190 Newmarket Road Fax: +44 (0) 1728 727430
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/

[Michael Mair]

Re: &quot;extern struct foobar&quot; linux compilation warning

Kevin Bracey wrote:[color=blue]
> In message <3989n5F5vqe4bU 1@individual.ne t>
> Michael Mair <Michael.Mair@i nvalid.invalid> wrote:
>
>[color=green]
>>If it is really necessary to get something opaque,
>>use void *:
>>
>> typedef void * FooBarHandle;
>>
>>The user gets only the handle and even a look at the
>>typedef does not tell how and where information is stored.
>>If the user can be trusted to not circumvent your access
>>macros and functions (and your data structures are not
>>top secret), the header file giving the type definition
>>for "struct foobar" should be included.[/color]
>
>
> I beg to differ. I'd prefer
>
> typedef struct foobar *FooBarHandle;
>
> leaving the contents of struct foobar opaque. That gives you a bit more type
> safety - someone can't accidentally give you a BarHandle instead of a
> FooBarHandle.[/color]

You are right, at least for the application at hand.

I was thinking of completely opaque information where you do not
even want the people to know what kind of type may be underlying,
i.e. if the type in question is an array, structure or whatever
-- in this case, one obviously does not want type safety.


Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[CBFalconer]

Re: &quot;extern struct foobar&quot; linux compilation warning

Kevin Bracey wrote:[color=blue]
> Michael Mair <Michael.Mair@i nvalid.invalid> wrote:
>[color=green]
>> If it is really necessary to get something opaque,
>> use void *:
>>
>> typedef void * FooBarHandle;
>>
>> The user gets only the handle and even a look at the
>> typedef does not tell how and where information is stored.
>> If the user can be trusted to not circumvent your access
>> macros and functions (and your data structures are not
>> top secret), the header file giving the type definition
>> for "struct foobar" should be included.[/color]
>
> I beg to differ. I'd prefer
>
> typedef struct foobar *FooBarHandle;
>
> leaving the contents of struct foobar opaque. That gives you a
> bit more type safety - someone can't accidentally give you a
> BarHandle instead of a FooBarHandle.[/color]

Exactly what I was mulling how to express, when I decided to look
onwards and see what others had said about it. void* allows you to
receive and pass pointers of unknown types and purpose onward
freely, but this is not such a case.

--
Chuck F (cbfalconer@yah oo.com) (cbfalconer@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Ian Pilcher]

Re: &quot;extern struct foobar&quot; linux compilation warning

Kevin Bracey wrote:[color=blue]
>
> I beg to differ. I'd prefer
>
> typedef struct foobar *FooBarHandle;
>
> leaving the contents of struct foobar opaque. That gives you a bit more type
> safety - someone can't accidentally give you a BarHandle instead of a
> FooBarHandle.
>[/color]

Definitely better than a void *, but really not necessary. As long as

struct foobar;

is declared, pointers to struct foobar can be freely passed around, but
not dereferenced.

--
=============== =============== =============== =============== ============
Ian Pilcher i.pilcher@comca st.net
=============== =============== =============== =============== ============

[Rick Anderson]

Re: &quot;extern struct foobar&quot; linux compilation warning

Ian Pilcher <i.pilcher@comc ast.net> wrote in
news:QNadndIDlY tLvLLfRVn-1g@comcast.com:
[color=blue]
> Kevin Bracey wrote:
> Definitely better than a void *, but really not necessary. As long as
>
> struct foobar;
>
> is declared, pointers to struct foobar can be freely passed around,
> but not dereferenced.
>[/color]

That works great - thanks!
Rick

[Kevin Bracey]

Re: &quot;extern struct foobar&quot; linux compilation warning

In message <QNadndIDlYtLvL LfRVn-1g@comcast.com>
Ian Pilcher <i.pilcher@comc ast.net> wrote:
[color=blue]
> Kevin Bracey wrote:[color=green]
> >
> > I beg to differ. I'd prefer
> >
> > typedef struct foobar *FooBarHandle;
> >
> > leaving the contents of struct foobar opaque. That gives you a bit more
> > type safety - someone can't accidentally give you a BarHandle instead of
> > a FooBarHandle.
> >[/color]
>
> Definitely better than a void *, but really not necessary. As long as
>
> struct foobar;
>
> is declared, pointers to struct foobar can be freely passed around, but
> not dereferenced.[/color]

Ah, but making it a typedef hides the fact the handle is a struct from the
basic API. One might want (for whatever reason) to change the handle from an
int to a structure or vice-versa.

--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: +44 (0) 1223 503464
182-190 Newmarket Road Fax: +44 (0) 1728 727430
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/

[Chris Torek]

Re: &quot;extern struct foobar&quot; linux compilation warning

In article <ba7308494d.kbr acey@tematic.co m>
Kevin Bracey <kevin.bracey@t ematic.com> wrote:[color=blue]
>... [using] a typedef hides the fact the handle is a struct from the
>basic API. One might want (for whatever reason) to change the handle
>from an int to a structure or vice-versa.[/color]

Sure -- but then one could just define a struct containing a single
"int".

Always just use "struct"; it is C's way of defining abstract data
types. :-)

I am "only almost kidding" about "always", too. Note that using a
struct to hold a single scalar variable gives you type-safety:

struct temperature { double val; };
struct pressure { double val; };

Now it is impossible to accidentally pass a "temperatur e" to a
function requiring a "pressure". You can add a typedef if you
really want:

#ifdef USE_TYPEDEFS
typedef struct temperature Temperature;
typedef struct pressure Pressure;
typedef struct counter Counter;
#endif

struct temperature; /* opaque */
struct pressure; /* opaque */
struct counter { int val; }; /* exposed */

If you make the handle an int, you are stuck. If you make it a
typedef and make the typedef an int and someone uses an int, you
are *still* stuck:

/* remove previous typedef and struct */
typedef int Counter;

extern Counter add(Counter previous, int offset);
...
/* bad programmer, using int instead of the typeef-name: */
void f(void) {
int x;
...
x = add(x, 3); /* this code compiles just fine */
...
}

but if you use a struct -- whether opaque or exposed -- even the
bad programmer has to use the name you gave it:

/* put back typedef and struct */

/* bad programmer attempts to use int instead of the typedef-name: */
void f(void) {
int x;
...
x = add(x, 3); /* error: function add() requires a
struct counter and returns a struct counter,
so this code does not compile */
...
}

Of course, if you always use struct, the typedef is unnecessary. Just
think of the word "struct" as meaning "type":

#define type struct

type foo; /* declare type foo to exist */
type bar; /* declare type bar to exist */

static type foo x = FOO_INITIALIZER ; /* make x a foo */
extern type bar y; /* declare y as a bar, defined elsewhere */

and you have a language with an obvious user-defined abstract data
type mechanism. Take out the single "#define" and you still have
that language -- it is called "C". :-) (Of course, to get everything
to work right, you need C99 with its compound-literals.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.