#include problem

Discussion in 'C Programming' started by arnuld, Oct 7, 2011.

  1. arnuld

    arnuld Guest

    I am running into some issue of inclusion of header and I am unable to
    understand what is wrong:



    fileA.h

    #ifndef TEST_HEADERS_A
    #define TEST_HEADERS_A

    struct myStruct_A
    {
    int num;
    };


    void use_print_values(void);

    #endif




    fileB.h

    #ifndef TEST_HEADERS_B
    #define TEST_HEADERS_B

    #include "fileA.h"

    void print_values(struct s1 s);

    #endif




    fileA.c

    #include <stdio.h>
    #include "fileA.h"
    #include "fileB.h"

    void use_print_values(void)
    {
    struct myStruct_A s;
    print_values(s);
    }




    fileB.c

    #include <stdio.h>
    #include "fileA.h"
    #include "fileB.h"

    void print_values(struct myStruct_A s)
    {
    printf("Num = %d\n", s.num);
    }




    ==================== OUTPUT ======================
    [arnuld@dune C]$ gcc -ansi -pedantic -Wall -Wextra -c fileA.c
    In file included from fileA.c:3:
    fileB.h:6: warning: ‘struct s1’ declared inside parameter list
    fileB.h:6: warning: its scope is only this definition or declaration,
    which is probably not what you want
    fileA.c: In function ‘use_print_values’:
    fileA.c:8: error: type of formal parameter 1 is incomplete
    [arnuld@dune C]$


    [arnuld@dune C]$ gcc -ansi -pedantic -Wall -Wextra -c fileB.c
    In file included from fileB.c:3:
    fileB.h:6: warning: ‘struct s1’ declared inside parameter list
    fileB.h:6: warning: its scope is only this definition or declaration,
    which is probably not what you want
    fileB.c:6: error: conflicting types for ‘print_values’
    fileB.h:6: error: previous declaration of ‘print_values’ was here
    [arnuld@dune C]$





    --
    arnuld
    www.LispMachine.Wordpress.com
     
    arnuld, Oct 7, 2011
    #1
    1. Advertising

  2. arnuld

    Ike Naar Guest

    On 2011-10-07, arnuld <> wrote:
    > I am running into some issue of inclusion of header and I am unable to
    > understand what is wrong:
    >
    > [sni]
    >
    > fileB.h
    >
    > #ifndef TEST_HEADERS_B
    > #define TEST_HEADERS_B
    >
    > #include "fileA.h"
    >
    > void print_values(struct s1 s);


    Did you mean "struct myStruct_A s" here?

    >
    > #endif
     
    Ike Naar, Oct 7, 2011
    #2
    1. Advertising

  3. arnuld <> writes:

    > I am running into some issue of inclusion of header and I am unable to
    > understand what is wrong:


    It's not inclusion that is the problem.

    > fileA.h
    >
    > #ifndef TEST_HEADERS_A
    > #define TEST_HEADERS_A
    >
    > struct myStruct_A
    > {
    > int num;
    > };
    >
    >
    > void use_print_values(void);
    >
    > #endif
    >
    >
    >
    >
    > fileB.h
    >
    > #ifndef TEST_HEADERS_B
    > #define TEST_HEADERS_B
    >
    > #include "fileA.h"
    >
    > void print_values(struct s1 s);


    struct s1 is not defined. Presumably you intended to refer to the
    structure defined in fileA.h but that struct myStruct_A.

    > #endif


    <snip>
    --
    Ben.
     
    Ben Bacarisse, Oct 7, 2011
    #3
  4. arnuld

    arnuld Guest

    > On Fri, 07 Oct 2011 12:34:22 +0000, Ike Naar wrote:

    >> On 2011-10-07, arnuld <> wrote:


    > Did you mean "struct myStruct_A s" here?


    Eh.... confused me :\




    --
    arnuld
    http://LispMachine.Wordpress.com
     
    arnuld, Oct 7, 2011
    #4
  5. arnuld

    arnuld Guest

    > On Fri, 07 Oct 2011 13:38:54 +0100, Ben Bacarisse wrote:

    > It's not inclusion that is the problem.


    fileA.h was incomplete, here it is:

    #ifndef TEST_HEADERS_A
    #define TEST_HEADERS_A

    #include "fileB.h"

    struct myStruct_A
    {
    int num;
    };


    void use_print_values(void);

    #endif

    ============ OUTPUT ==============
    [arnuld@dune C]$ gcc -ansi -pedantic -Wall -Wextra -c fileB.c
    In file included from fileA.h:4,
    from fileB.c:2:
    fileB.h:6: warning: ‘struct myStruct_A’ declared inside parameter list
    fileB.h:6: warning: its scope is only this definition or declaration,
    which is probably not what you want
    fileB.c:6: error: conflicting types for ‘print_values’
    fileB.h:6: error: previous declaration of ‘print_values’ was here
    [arnuld@dune C]$



    Header A asks for Header B and Header B asks for Header A, recursive
    issue, anyway to solve this ?




    --
    arnuld
    http://LispMachine.Wordpress.com
     
    arnuld, Oct 7, 2011
    #5
  6. arnuld

    Mark Guest

    "arnuld" <> wrote in message
    news:4e8ef020$0$287$...
    > #ifndef TEST_HEADERS_A
    > #define TEST_HEADERS_A
    >
    > struct myStruct_A
    > {
    > int num;
    > };
    >


    Sorry for asking additional questions instead of answering yours: I often
    observe the structures containing a single member, often that is an array.
    What is the reason for doing so?

    Mark
     
    Mark, Oct 8, 2011
    #6
  7. arnuld

    Ian Collins Guest

    On 10/ 9/11 07:53 AM, Mark wrote:
    > "arnuld"<> wrote in message
    > news:4e8ef020$0$287$...
    >> #ifndef TEST_HEADERS_A
    >> #define TEST_HEADERS_A
    >>
    >> struct myStruct_A
    >> {
    >> int num;
    >> };
    >>

    >
    > Sorry for asking additional questions instead of answering yours: I often
    > observe the structures containing a single member, often that is an array.
    > What is the reason for doing so?


    So the array can be copied with one assignment.

    --
    Ian Collins
     
    Ian Collins, Oct 8, 2011
    #7
  8. arnuld

    Mark Guest

    "Ian Collins" <> wrote in message
    news:...
    > On 10/ 9/11 07:53 AM, Mark wrote:
    >> "arnuld"<> wrote in message
    >> news:4e8ef020$0$287$...
    >>> #ifndef TEST_HEADERS_A
    >>> #define TEST_HEADERS_A
    >>>
    >>> struct myStruct_A
    >>> {
    >>> int num;
    >>> };
    >>>

    >>
    >> Sorry for asking additional questions instead of answering yours: I
    >> often
    >> observe the structures containing a single member, often that is an
    >> array.
    >> What is the reason for doing so?

    >
    > So the array can be copied with one assignment.


    But what exactly do you mean by "can be copied with one assignment" ?

    struct my
    {
    unsigned int foo[6];
    };

    struct my a1 = { {0xa, 0xb, 0xc, 0x1, 0x2, 0x3} };
    struct my a2;

    memcpy(&a1, &2, sizeof(struct my));

    I still need memcpy, like I would for copying arrays.

    Mark
     
    Mark, Oct 9, 2011
    #8
  9. arnuld

    Ian Collins Guest

    On 10/ 9/11 04:20 PM, Mark wrote:
    > "Ian Collins"<> wrote:
    >> On 10/ 9/11 07:53 AM, Mark wrote:
    >>>
    >>> Sorry for asking additional questions instead of answering yours: I
    >>> often
    >>> observe the structures containing a single member, often that is an
    >>> array.
    >>> What is the reason for doing so?

    >>
    >> So the array can be copied with one assignment.

    >
    > But what exactly do you mean by "can be copied with one assignment" ?
    >
    > struct my
    > {
    > unsigned int foo[6];
    > };
    >
    > struct my a1 = { {0xa, 0xb, 0xc, 0x1, 0x2, 0x3} };
    > struct my a2;
    >
    > memcpy(&a1,&2, sizeof(struct my));
    >
    > I still need memcpy, like I would for copying arrays.


    No, just write

    a2 = 1a;

    --
    Ian Collins
     
    Ian Collins, Oct 9, 2011
    #9
  10. arnuld

    James Kuyper Guest

    On 10/08/2011 11:32 PM, Ian Collins wrote:
    > On 10/ 9/11 04:20 PM, Mark wrote:

    ....
    >> But what exactly do you mean by "can be copied with one assignment" ?
    >>
    >> struct my
    >> {
    >> unsigned int foo[6];
    >> };
    >>
    >> struct my a1 = { {0xa, 0xb, 0xc, 0x1, 0x2, 0x3} };
    >> struct my a2;
    >>
    >> memcpy(&a1,&2, sizeof(struct my));


    memcpy(&a2, &a1, sizeof a2);

    >> I still need memcpy, like I would for copying arrays.

    >
    > No, just write
    >
    > a2 = 1a;


    a2 = a1;
    --
    James Kuyper
     
    James Kuyper, Oct 9, 2011
    #10
  11. arnuld

    Ike Naar Guest

    On 2011-10-09, James Kuyper <> wrote:
    >> On 10/ 9/11 04:20 PM, Mark wrote:
    >>> memcpy(&a1,&2, sizeof(struct my));

    >
    > memcpy(&a2, &a1, sizeof a2);


    It destroys the symmetry.
    Is there a specific reason to prefer sizeof a2 over sizeof a1 ?
     
    Ike Naar, Oct 9, 2011
    #11
  12. arnuld

    Nobody Guest

    On Sun, 09 Oct 2011 12:30:16 +0000, Ike Naar wrote:

    >>>> memcpy(&a1,&2, sizeof(struct my));

    >>
    >> memcpy(&a2, &a1, sizeof a2);

    >
    > It destroys the symmetry.
    > Is there a specific reason to prefer sizeof a2 over sizeof a1 ?


    Normally, the two should be equal. If they aren't, you have a problem; the
    choice of which one to take the size of has some effect upon how the
    problem will manifest. All other factors being equal, reading too much
    data is typically less problematic than writing too much data.

    If the last parameter is the size of the object pointed to by the first
    parameter, memcpy() will always fill the destination exactly (unless it
    segfaults due to the read). It will probably fill it with garbage, but it
    won't overwrite some adjacent object.

    Hopefully this will facilitate identifying the source of the problem
    sooner rather than later. I.e. you discover that a2 contains garbage, look
    at what touches a2, you've found the problem. Rather than discovering that
    z3 contains garbage but finding that nothing which touches z3 looks
    suspicious.
     
    Nobody, Oct 9, 2011
    #12
  13. arnuld

    James Kuyper Guest

    On 10/09/2011 08:30 AM, Ike Naar wrote:
    > On 2011-10-09, James Kuyper <> wrote:
    >>> On 10/ 9/11 04:20 PM, Mark wrote:
    >>>> memcpy(&a1,&2, sizeof(struct my));

    >>
    >> memcpy(&a2, &a1, sizeof a2);

    >
    > It destroys the symmetry.
    > Is there a specific reason to prefer sizeof a2 over sizeof a1 ?


    Well, in this particular, case, as previously mentioned, a2 = a1 is
    clearly better than any use of memcpy().

    However, in the more general case where a simple assignment statement is
    not a viable alternative, I can't really make a strong argument for
    "sizeof destination" over "sizeof source". Writing too much is slightly
    more likely to be dangerous than reading too much, but I won't claim
    that this is a strong argument. However, I strongly prefer either one to
    "sizeof(type)". There's two closely related reasons for that preference:
    it allows me to change the types of the source and destination (as long
    as both are the same) without having to re-write the call to memcpy().
    The other, and in my opinion, most important reason, is that I can
    confirm that the size is correct just by looking at the memcpy() call, I
    don't need to check backwards to the declaration of the destination to
    confirm that it is in fact of type 'struct my'.

    In principle, it would be better to make sure that both the source and
    destination have the same size as that used in the copy; but that would
    make the code substantially more clumsy - I don't think it's worth the
    effort.
    --
    James Kuyper
     
    James Kuyper, Oct 9, 2011
    #13
    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. Danny Anderson
    Replies:
    5
    Views:
    507
    Victor Bazarov
    Aug 15, 2003
  2. Rolf Magnus
    Replies:
    2
    Views:
    605
    Karl Heinz Buchegger
    Nov 28, 2003
  3. Elie Nader
    Replies:
    1
    Views:
    641
  4. web4all
    Replies:
    0
    Views:
    3,137
    web4all
    May 11, 2006
  5. Andreas Bogenberger
    Replies:
    3
    Views:
    927
    Andreas Bogenberger
    Feb 22, 2008
Loading...

Share This Page