Is declaring a pointer to an undefined struct legal?

Discussion in 'C Programming' started by Chris Barts, Jan 12, 2005.

  1. Chris Barts

    Chris Barts Guest

    Let's say we have a library with an opaque data type implemented as a
    struct in the library's C source file. The definition of the struct
    isn't duplicated in the header included by the programs that make use of
    this library. Is it legal for the header and the programs that include
    it to declare pointers to this struct for which no definition is in
    scope and to pass those pointers into functions declared in that header?
    Chris Barts, Jan 12, 2005
    #1
    1. Advertising

  2. Chris Barts

    Richard Bos Guest

    Chris Barts <> wrote:

    > Let's say we have a library with an opaque data type implemented as a
    > struct in the library's C source file. The definition of the struct
    > isn't duplicated in the header included by the programs that make use of
    > this library. Is it legal for the header and the programs that include
    > it to declare pointers to this struct for which no definition is in
    > scope and to pass those pointers into functions declared in that header?


    In short, yes.

    But you cannot initialise these pointers, except to null; you cannot
    assign values to them unless that value is passed to you from a function
    which does have a declaration for the struct type in scope; and you
    cannot dereference those pointers. For an opaque type, of course, this
    is precisely what you want.

    Richard
    Richard Bos, Jan 12, 2005
    #2
    1. Advertising

  3. Chris Barts

    Alex Fraser Guest

    "Chris Barts" <> wrote in message
    news:...
    > Let's say we have a library with an opaque data type implemented as a
    > struct in the library's C source file. The definition of the struct
    > isn't duplicated in the header included by the programs that make use of
    > this library. Is it legal for the header and the programs that include
    > it to declare pointers to this struct for which no definition is in
    > scope and to pass those pointers into functions declared in that header?


    Yes, it's perfectly legal and IMO often quite useful, since only changes in
    the interface require users of the interface to be recompiled, and even
    better, all changes to the members of the struct are made inside the
    library. The only downsides are that you can't use macros for (typically)
    quicker access to struct members, and in most cases dynamic allocation is
    required, so performance may suffer slightly.

    Alex
    Alex Fraser, Jan 12, 2005
    #3
  4. Chris Barts

    Chris Barts Guest

    Richard Bos wrote:
    > Chris Barts <> wrote:
    >
    >

    [partial snip]
    >>Is it legal for the header and the programs that include
    >>it to declare pointers to this struct for which no definition is in
    >>scope and to pass those pointers into functions declared in that header?

    >
    >
    > In short, yes.


    That's good to know.

    > But you cannot initialise these pointers, except to null; you cannot
    > assign values to them unless that value is passed to you from a function
    > which does have a declaration for the struct type in scope; and you
    > cannot dereference those pointers.


    And all of those limits are precisely what I'd expect: Unless the
    definition is in scope, there is no way to know the names of the
    members, let alone their offsets into the object.

    > For an opaque type, of course, this is precisely what you want.


    Very true.
    Chris Barts, Jan 12, 2005
    #4
  5. Chris Barts

    CBFalconer Guest

    Chris Barts wrote:
    >
    > Let's say we have a library with an opaque data type implemented as a
    > struct in the library's C source file. The definition of the struct
    > isn't duplicated in the header included by the programs that make use of
    > this library. Is it legal for the header and the programs that include
    > it to declare pointers to this struct for which no definition is in
    > scope and to pass those pointers into functions declared in that header?


    Yes.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Jan 12, 2005
    #5
  6. Chris Barts

    Chris Barts Guest

    Alex Fraser wrote:
    > "Chris Barts" <> wrote in message
    > news:...
    >

    [snip]
    >
    > Yes, it's perfectly legal and IMO often quite useful, since only changes in
    > the interface require users of the interface to be recompiled, and even
    > better, all changes to the members of the struct are made inside the
    > library.


    This was precisely my thinking: It enforces complete locality of
    everything within the opaque type, preventing programmers, and therefore
    the library's author, from becoming wedded to implementation details.

    I'm a pretty strong believer in that sort of thing.

    > The only downsides are that you can't use macros for (typically)
    > quicker access to struct members, and in most cases dynamic allocation is
    > required, so performance may suffer slightly.


    The key word here, I believe, is 'slightly': Given the advantages stated
    above, it would be rare (hopefully) that the performance edge of the
    less-safe case is a deciding factor in how the library is implemented.

    [semi-OT]Plus, passing a pointer into a function is typically a cheap
    operation, so if the library itself is reasonably optimized the problem
    is essentially solved.[/semi-OT]
    Chris Barts, Jan 12, 2005
    #6
  7. Chris Barts

    Alex Fraser Guest

    "Chris Barts" <> wrote in message
    news:...
    > Alex Fraser wrote:
    > > The only downsides are that you can't use macros for (typically)
    > > quicker access to struct members, and in most cases dynamic allocation
    > > is required, so performance may suffer slightly.

    >
    > The key word here, I believe, is 'slightly': Given the advantages stated
    > above, it would be rare (hopefully) that the performance edge of the
    > less-safe case is a deciding factor in how the library is implemented.


    The getc() function/macro is an obvious example of the trade-off. Most of
    the time, it doesn't do very much, so if implemented as a function, the
    overall overhead from the function calls can be a significant fraction of
    the total time.

    The performance cost of dynamic allocation/deallocation can usually be
    minimised, and is less likely to be significant anyway. One thing I didn't
    mention is that dynamic allocation needs explicit deallocation, which is
    sometimes inconvenient. But some sort of cleanup besides deallocating the
    structure is often needed anyway, so it's a bit of a moot point - the
    inconvenience often exists either way.

    Alex
    Alex Fraser, Jan 12, 2005
    #7
  8. On Wed, 12 Jan 2005 08:30:49 -0700, Chris Barts
    <> wrote:

    > Alex Fraser wrote:
    > > "Chris Barts" <> wrote in message
    > > news:...
    > >

    > [snip: using pointers to struct type encapsulated in module]
    > >
    > > Yes, it's perfectly legal and IMO often quite useful, since only changes in
    > > the interface require users of the interface to be recompiled, and even
    > > better, all changes to the members of the struct are made inside the
    > > library.

    >
    > This was precisely my thinking: It enforces complete locality of
    > everything within the opaque type, preventing programmers, and therefore
    > the library's author, from becoming wedded to implementation details.
    >
    > I'm a pretty strong believer in that sort of thing.
    >

    One warning: s/preventing/discouraging/ . Some people will still poke
    around in your source, or hex-dump the data, or disassemble your code,
    and find and use things you wanted to keep hidden. And some people
    will occasionally perhaps even accidentally do "dirty" things that
    cause dependencies -- like, say, memcpy'ing 32 bytes to a savearea and
    later memcpy'ing it back and assuming that's enough. (I speak from
    experience on both sides of this fence.)

    Using 'struct hidden *' is a very good start, but _also_ document
    clearly that you intend the type to be opaque -- and hope that you
    either persuade users you are right to do so, or are able to ignore
    the anguished screams that do arise.
    - David.Thompson1 at worldnet.att.net
    Dave Thompson, Jan 17, 2005
    #8
  9. Chris Barts

    Flash Gordon Guest

    Dave Thompson wrote:
    > On Wed, 12 Jan 2005 08:30:49 -0700, Chris Barts
    > <> wrote:
    >
    >
    >>Alex Fraser wrote:
    >>
    >>>"Chris Barts" <> wrote in message
    >>>news:...
    >>>

    >>
    >>[snip: using pointers to struct type encapsulated in module]
    >>
    >>>Yes, it's perfectly legal and IMO often quite useful, since only changes in
    >>>the interface require users of the interface to be recompiled, and even
    >>>better, all changes to the members of the struct are made inside the
    >>>library.

    >>
    >>This was precisely my thinking: It enforces complete locality of
    >>everything within the opaque type, preventing programmers, and therefore
    >>the library's author, from becoming wedded to implementation details.
    >>
    >>I'm a pretty strong believer in that sort of thing.
    >>

    >
    > One warning: s/preventing/discouraging/ . Some people will still poke
    > around in your source, or hex-dump the data, or disassemble your code,
    > and find and use things you wanted to keep hidden. And some people
    > will occasionally perhaps even accidentally do "dirty" things that
    > cause dependencies -- like, say, memcpy'ing 32 bytes to a savearea and
    > later memcpy'ing it back and assuming that's enough. (I speak from
    > experience on both sides of this fence.)


    People will always find ways around if they really want to. One just has
    to try to provide functions to do all the things people are likely to
    want to do, such as copying the structure if that is a sensible thing to
    allow.

    > Using 'struct hidden *' is a very good start, but _also_ document
    > clearly that you intend the type to be opaque -- and hope that you
    > either persuade users you are right to do so, or are able to ignore
    > the anguished screams that do arise.


    Also state explicitly that anything bypassing your interface *will* be
    broken by subsequent releases.
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
    Flash Gordon, Jan 17, 2005
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris Fogelklou
    Replies:
    36
    Views:
    1,373
    Chris Fogelklou
    Apr 20, 2004
  2. beetle
    Replies:
    2
    Views:
    907
    beetle
    Jan 25, 2005
  3. Zero
    Replies:
    16
    Views:
    652
    Barry Schwarz
    Nov 19, 2005
  4. Richard Mathis

    Issues with declaring struct arrays inside of a struct

    Richard Mathis, Oct 10, 2003, in forum: ASP .Net Building Controls
    Replies:
    0
    Views:
    239
    Richard Mathis
    Oct 10, 2003
  5. aleksa

    Struct pointer vs. struct array pointer

    aleksa, Feb 20, 2013, in forum: C Programming
    Replies:
    16
    Views:
    466
    Shao Miller
    Feb 20, 2013
Loading...

Share This Page