Initializing compound type containing opaque type

[Nate Eldredge]

Consider the following pseudo-code:

#include <opaque.h>

struct foo {
int a;
opaque_t op;
int b;
};

struct foo blah = { 17, /* ??? */ , 23 };

Here we suppose that `opaque_t' is defined in <opaque.has some type
not known to us, or which we cannot rely on. In particular, it may be
a scalar or compound type. The goal is to initialize `blah' in such a
way that `blah.a == 17' and `blah.b == 23'. We don't care about the
value of `blah.op'.

It seems to me that there is no way to do this in standard C. Is this
correct, or am I missing something?

A workaround would be to rearrange the members of `struct foo' as

struct foo2 {
int a;
int b;
opaque_t op;
};

struct foo2 blah2 = { 17, 23 };

I believe this is legal, but I could be wrong. My compiler warns
about a missing initializer, but accepts the code.

If `opaque_t' is known to be a compound type, we could write

struct foo blah3 = { 17, { }, 23 };

which again provokes a missing initializer warning but is accepted.
Again I am curious whether it is actually legal.

I thought of this issue after reading a post here a couple weeks ago,
"Exception handling crashes or exits" by Fabiano Sidler,
<48**********@n ews.bluewin.ch> , in which the poster wants a struct
with a jmp_buf as one member. He initializes that member with { 0 },
which is certainly non-portable. But I wondered if there is a
portable way to do the same thing.

If not, it seems like it might be useful for the authors of <opaque.h>
to provide a macro which is suitable as an initializer for opaque_t.
E.g. <opaque.hmigh t contain

typedef opaque_t struct {
int x,
double d;
};

#define OPAQUE_INITIALI ZER { 0, 0.0 }

so that one could write

struct foo blah = { 17, OPAQUE_INITIALI ZER, 23 };

In particular, this could be a useful extension for library authors to
provide for opaque library types (e.g. jmp_buf, FILE, etc).

Any thoughts?

[William Pursell]

On 1 Oct, 22:05, Nate Eldredge <[e-mail] nwrote:

Consider the following pseudo-code:

#include <opaque.h>

struct foo {
* * * *int a;
* * * *opaque_t op;
* * * *int b;

};

If opaque_t is truly opaque, and not specified
in opaque.h, then the compiler won't accept
this definition of struct foo. If the compiler
is accepting this, then the header is specifying
opaque_t completely, so (I would argue) has
misnamed it because it isn't opaque.

struct foo blah = { 17, /* ??? */ , 23 };

Here we suppose that `opaque_t' is defined in <opaque.has some type
not known to us, or which we cannot rely on.

I don't understand what you mean by "not known to us". If
the compiler can get the definition from opaque_t, then
you can, too! Am I using the word "opaque" in a
stricter sense than you? When I say opaque type,
I mean that the header contains no more than:
typedef struct opaque * opaque_t;
or just:
struct opaque;

<snip>

If not, it seems like it might be useful for the authors of <opaque.h>
to provide a macro which is suitable as an initializer for opaque_t.
E.g. <opaque.hmigh t contain

typedef opaque_t struct {
* * * * int x,
* * * * double d;

};

Is this an opaque type? It's got an int and
a double, so ... no, it's not. At least not
by my understanding of the word opaque.

[William Pursell]

On 2 Oct, 00:45, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

vipps...@gmail. com writes:

<snip>

You can also do this for array elements

char foo[2] = { .[1] = 'a' };

There's no dot. *I.e.:

* char foo[2] = { [1] = 'a' };

Is that C99? I thought that was a gnu extension.

[Nate Eldredge]

William Pursell <bi**********@g mail.comwrites:

On 1 Oct, 22:05, Nate Eldredge <[e-mail] nwrote:

>Consider the following pseudo-code:

#include <opaque.h>

struct foo {
* * * *int a;
* * * *opaque_t op;
* * * *int b;

};

If opaque_t is truly opaque, and not specified
in opaque.h, then the compiler won't accept
this definition of struct foo. If the compiler
is accepting this, then the header is specifying
opaque_t completely, so (I would argue) has
misnamed it because it isn't opaque.

By "opaque" I mean an object whose format and contents are not
intended to be used by the programmer, and are subject to change.
This is how I've heard it used in the past.

jmp_buf is an example. Certainly you can open up <setjmp.hand find
out how it is defined on your system; maybe it's a struct with a
member for each of your CPU's registers. But you can't use any of
that information in a portable program, since on another system, or a
later version of the same system, it may be defined differently, or
used differently by the library, so in a more general sense you don't
really "know" how it's defined. All you "know" about jmp_buf is that
you can create one using setjmp() and pass it to longjmp() later on.
From the programmer's point of view it's just a magic cookie.

Other examples in the standard library would be time_t and FILE.
div_t is a library type that I would not call opaque; it is documented
as being a struct with two members, `quot' and `rem', whose types and
meanings are well described and guaranteed to be the same in all
conforming implementations .

[Ben Bacarisse]

William Pursell <bi**********@g mail.comwrites:

On 2 Oct, 00:45, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

>vipps...@gmail .com writes:

<snip>

You can also do this for array elements

char foo[2] = { .[1] = 'a' };

There's no dot. Â*I.e.:

Â* char foo[2] = { [1] = 'a' };

Is that C99? I thought that was a gnu extension.

Yes, it is C99:

designation:
designator-list =

designator-list:
designator
designator-list designator

designator:
[ constant-expression ]
. identifier

--
Ben.

[James Kuyper]

William Pursell wrote:

On 2 Oct, 00:45, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

....

> char foo[2] = { [1] = 'a' };

Is that C99? ...

Yes.

[Keith Thompson]

William Pursell <bi**********@g mail.comwrites:

On 1 Oct, 22:05, Nate Eldredge <[e-mail] nwrote:

>Consider the following pseudo-code:

#include <opaque.h>

struct foo {
* * * *int a;
* * * *opaque_t op;
* * * *int b;

};

If opaque_t is truly opaque, and not specified
in opaque.h, then the compiler won't accept
this definition of struct foo. If the compiler
is accepting this, then the header is specifying
opaque_t completely, so (I would argue) has
misnamed it because it isn't opaque.

There are different kinds of opacity. Consider type FILE, defined in
<stdio.h>. That header must completely specify the type -- but code
that uses it is expected to depend only on the standard functions and
the fact that it's an object type.

>struct foo blah = { 17, /* ??? */ , 23 };

Here we suppose that `opaque_t' is defined in <opaque.has some type
not known to us, or which we cannot rely on.

I don't understand what you mean by "not known to us". If
the compiler can get the definition from opaque_t, then
you can, too!

Sure you *can* -- but then the next version of the library defines it
differently and your code breaks.

It's both common and reasonable to define an "opaque" type that's
completely defined in the header, just by *asking* authors of client
code not to cheat by peeking at its innards. (Which is not to say
that there aren't other reasonable approaches.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Nick Keighley <ni************ ******@hotmail. comwrites:

On 2 Oct, 17:28, Keith Thompson <[e-mail] rote:

<snip>

>There are different kinds of opacity. *Consider type FILE, defined in
<stdio.h>. *That header must completely specify the type

why? user code only needs a pointer

>-- but code
that uses it is expected to depend only on the standard functions and
the fact that it's an object type.

<snip>

The standard requires FILE to be

an object type capable of recording all the information needed to
control a stream, including its file position indicator, a pointer
to its associated buffer (if any), an _error indicator_ that
records whether a read/write error has occurred, and an
_end-of-file indicator_ that records whether the end of the file
has been reached

The declaration of FILE in <stdio.hneedn 't indicate *how* it records
all that information. For example, it could be declared as

typedef unsigned char[_FILE_BYTES] FILE;

and the library code that uses it could cast the FILE* to, say,
_FILE_STRUCT* to access the information. Most implementations don't
do this; for one thing, the macro definitions for putc and getc are
going to expose some of the inner details anyway.

Since user code only needs to use FILE*, not type FILE itself, an
implementation that declares:

typedef void FILE;

would be perfectly sensible, except that it would violate the
standard's requirement. In my opinion, the standard over-specifies
this, but it's not a huge deal.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Szabolcs Nagy]

Nate Eldredge wrote:

Eric Sosman <Er*********@su n.comwrites:

In C90 you could initialize the unknown member to "zero of
the appropriate type:"

struct foo blah = { 17, { 0 }, 23 };

Some compilers may emit warnings for too few initializers, but
the initialization is valid; if opaque_t is compound, its sub-
elements are initialized to appropriate zeroes. The warnings may
be a nuisance, but they do no actual harm.

Interesting, so the OP was correct after all. I never knew about
"zero of the appropriate type". I assumed that would be wrong if
opaque_t turned out to be a scalar type, or a compound whose first
member was also compound, but apparently not. Those clever language
designers, always one step ahead. :)

{0} initializer is wrong if the first member of opaque_t is an array

[Nate Eldredge]

Szabolcs Nagy <ns*******@gmai l.comwrites:

Nate Eldredge wrote:

>Eric Sosman <Er*********@su n.comwrites:

In C90 you could initialize the unknown member to "zero of
the appropriate type:"

struct foo blah = { 17, { 0 }, 23 };

Some compilers may emit warnings for too few initializers, but
the initialization is valid; if opaque_t is compound, its sub-
elements are initialized to appropriate zeroes. The warnings may
be a nuisance, but they do no actual harm.

Interesting, so the OP was correct after all. I never knew about
"zero of the appropriate type". I assumed that would be wrong if
opaque_t turned out to be a scalar type, or a compound whose first
member was also compound, but apparently not. Those clever language
designers, always one step ahead. :)

{0} initializer is wrong if the first member of opaque_t is an array

Is it really? gcc -ansi -pedantic accepts it.

[vippstar]

On Oct 4, 12:41 am, Nate Eldredge <[e-mail] nwrote:

Szabolcs Nagy <nszabo...@gmai l.comwrites:

Nate Eldredge wrote:

Eric Sosman <Eric.Sos...@su n.comwrites:
In C90 you could initialize the unknown member to "zero of
the appropriate type:"

struct foo blah = { 17, { 0 }, 23 };

Some compilers may emit warnings for too few initializers, but
the initialization is valid; if opaque_t is compound, its sub-
elements are initialized to appropriate zeroes. The warnings may
be a nuisance, but they do no actual harm.

Interesting, so the OP was correct after all. I never knew about
"zero of the appropriate type". I assumed that would be wrong if
opaque_t turned out to be a scalar type, or a compound whose first
member was also compound, but apparently not. Those clever language
designers, always one step ahead. :)

{0} initializer is wrong if the first member of opaque_t is an array

Is it really? gcc -ansi -pedantic accepts it.

No it isn't, it's correct.

When not all of an object is initialized, the rest is initialized as
if it were 'static'.