Unnamed struct members allowed?

Discussion in 'C Programming' started by Jalapeno, Jun 15, 2006.

  1. Jalapeno

    Jalapeno Guest

    I've a CICS program that uses BMS maps. Our wysiwyg map editor produces
    it's source in COBOL so I am manually creating C unions to match the
    COBOL output. Can I convert the FILLER statements to unnamed struct
    members or am I stuck with the scenario using filler0, filler1, filler2
    etc. ?


    01 PIDCI.
    02 FILLER PICTURE X(12).
    02 MAPTRANIDL COMP PICTURE S9(4).
    02 MAPTRANIDF PICTURE X.
    02 FILLER PICTURE X(04).
    02 MAPTRANIDI PICTURE X(04).
    etc...
    etc...
    etc...
    01 PIDCO REDEFINES PIDCI.
    02 FILLER PICTURE X(12).
    02 FILLER PICTURE X(02).
    02 MAPTRANIDA PICTURE X.
    02 MAPTRANIDC PICTURE X.
    02 MAPTRANIDP PICTURE X.
    02 MAPTRANIDH PICTURE X.
    02 MAPTRANIDV PICTURE X.
    02 MAPTRANIDO PICTURE X(04).
    02 FILLER PICTURE X(02).
    etc...
    etc...
    etc...


    union pidc {
    struct pidci {
    unsigned char filler0??(12??); /* <---<< here */
    int maptranidl;
    unsigned char maptranidf;
    unsigned char filler1??(4??); /* <---<< here */
    unsigned char maptranidi??(4??);
    etc...
    etc...
    etc...
    } pidci; /* struct pidci */

    struct pidco {
    unsigned char filler0??(12??); /* <---<< here */
    unsigned char filler1??(2??); /* <---<< here */
    unsigned char maptranida;
    unsigned char maptranidc;
    unsigned char maptranidp;
    unsigned char maptranidh;
    unsigned char maptranidv;
    unsigned char maptranido??(4??);
    unsigned char filler2??(2??); /* <---<< here */
    etc...
    etc...
    etc...
    } pidco; /* struc pidco */
    } pidc; /* union pidc */
     
    Jalapeno, Jun 15, 2006
    #1
    1. Advertising

  2. In article <>,
    Jalapeno <> wrote:
    >I've a CICS program that uses BMS maps. Our wysiwyg map editor produces
    >it's source in COBOL so I am manually creating C unions to match the
    >COBOL output. Can I convert the FILLER statements to unnamed struct
    >members or am I stuck with the scenario using filler0, filler1, filler2
    >etc. ?


    Within a C struct: sorry, no, every field must be named
    [with the exception of a bitfield specified as :0 -- which has
    to do with bitfield alignment and has no practical value for
    your situation.]
    --
    Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson
     
    Walter Roberson, Jun 15, 2006
    #2
    1. Advertising

  3. Jalapeno

    CBFalconer Guest

    Walter Roberson wrote:
    > Jalapeno <> wrote:
    >
    >> I've a CICS program that uses BMS maps. Our wysiwyg map editor
    >> produces it's source in COBOL so I am manually creating C unions
    >> to match the COBOL output. Can I convert the FILLER statements
    >> to unnamed struct members or am I stuck with the scenario using
    >> filler0, filler1, filler2 etc. ?

    >
    > Within a C struct: sorry, no, every field must be named
    > [with the exception of a bitfield specified as :0 -- which has
    > to do with bitfield alignment and has no practical value for
    > your situation.]


    He was also reflecting a COMP 4 item as an int. Even if the
    storage is the same, there may be alignment problems handled by
    Cobol, but not C. IIRC, it's been at least 20 years since I did
    any Cobol. Not greatly missed.

    --
    Some informative links:
    news:news.announce.newusers
    http://www.geocities.com/nnqweb/
    http://www.catb.org/~esr/faqs/smart-questions.html
    http://www.caliburn.nl/topposting.html
    http://www.netmeister.org/news/learn2quote.html
     
    CBFalconer, Jun 15, 2006
    #3
  4. CBFalconer wrote:
    >
    > Walter Roberson wrote:
    > > Jalapeno <> wrote:
    > >
    > >> I've a CICS program that uses BMS maps. Our wysiwyg map editor
    > >> produces it's source in COBOL so I am manually creating C unions
    > >> to match the COBOL output. Can I convert the FILLER statements
    > >> to unnamed struct members or am I stuck with the scenario using
    > >> filler0, filler1, filler2 etc. ?

    > >
    > > Within a C struct: sorry, no, every field must be named
    > > [with the exception of a bitfield specified as :0 -- which has
    > > to do with bitfield alignment and has no practical value for
    > > your situation.]

    >
    > He was also reflecting a COMP 4 item as an int. Even if the
    > storage is the same, there may be alignment problems handled by
    > Cobol, but not C. IIRC, it's been at least 20 years since I did
    > any Cobol. Not greatly missed.
    >

    I do miss writing in Cobol, and I miss it quite pleasantly TYVM.

    --
    +----------------------------------------------------------------+
    | Charles and Francis Richmond richmond at plano dot net |
    +----------------------------------------------------------------+
     
    Charles Richmond, Jun 16, 2006
    #4
  5. Jalapeno

    Jalapeno Guest

    Walter Roberson wrote:
    > In article <>,
    > Jalapeno <> wrote:
    > > Can I convert the FILLER statements to unnamed struct
    > >members or am I stuck with the scenario using filler0, filler1, filler2
    > >etc. ?

    >
    > Within a C struct: sorry, no, every field must be named


    Thanks. I'm currently programming in COBOL, REXX, and C and maintaining
    old BAL, CLIST and PL/I code and sometimes get the features mixed up.
     
    Jalapeno, Jun 16, 2006
    #5
  6. Jalapeno

    Jalapeno Guest

    CBFalconer wrote:
    > Walter Roberson wrote:
    > > Jalapeno <> wrote:
    > >
    > >> Our wysiwyg map editor produces it's source in COBOL so I am manually creating C unions
    > >> to match the COBOL output.

    > >
    > > Within a C struct: sorry, no,

    >
    > He was also reflecting a COMP 4 item as an int. Even if the
    > storage is the same, there may be alignment problems handled by
    > Cobol, but not C.


    COMP S9(4) is a 32 bit signed computational field. It translates to int
    with z/OS C compilers. It may not on other platforms but CICS regions
    are sparse outside of z/OS (although I do have CICS for Windows loaded
    on my PC and I've read some shops still use CICS for VSE).

    > ... IIRC, it's been at least 20 years since I did
    > any Cobol. Not greatly missed.
    >


    I have no particular love for COBOL myself and I moved into CICS
    systems programming when my COBOL application job went to India.
    Unfortunately, we systems programmers are now spending half our time
    "teaching" outsourced applications programmers how to do the jobs they
    took from us.
     
    Jalapeno, Jun 16, 2006
    #6
  7. Jalapeno

    SM Ryan Guest

    "Jalapeno" <> wrote:
    # I've a CICS program that uses BMS maps. Our wysiwyg map editor produces
    # it's source in COBOL so I am manually creating C unions to match the
    # COBOL output. Can I convert the FILLER statements to unnamed struct
    # members or am I stuck with the scenario using filler0, filler1, filler2
    # etc. ?

    Unless you're exploiting compiler specific options, you cannot
    depend on struct fields ending up on any particular byte or bit
    boundary.

    An alternative way is to use a char array and place fields
    manually. Such as

    # 01 PIDCI.
    # 02 FILLER PICTURE X(12).
    # 02 MAPTRANIDL COMP PICTURE S9(4).
    # 02 MAPTRANIDF PICTURE X.
    # 02 FILLER PICTURE X(04).
    # 02 MAPTRANIDI PICTURE X(04).

    typedef char PIDCI[12+4+1+4+4+...];
    enum {
    oPIDC1MAPTRANIDL = 12, lPIDC1MAPTRANIDL = 4,
    oPIDC1MAPTRANIDF = 12+4, lPIDC1MAPTRANIDF = 1,
    oPIDC1MAPTRANIDI = 12+4+1+4, lPIDC1MAPTRANIDI = 4,
    ...
    };
    int getInt1(char *a,int o,int l) {
    int r = 0; memcpy(&r,a+o,l); return r;
    }
    void putInt1(char *a,int o,int l,int v) {
    int r = v; memcpy(a+o,&r,l);
    }

    #define getInt(a,field) (getInt1(a,o##field,l##field))
    #define putInt(a,field,v) (putInt1(a,o##field,l##field,v))

    #define getChar(a,field) ((a)[o##field])
    #define putChar(a,field,v) ((a)[o##field]=(v))

    #define getChars(a,field,r) (memcpy(r,(a)+o##field,l##field))
    #define putChars(a,field,v) (memcpy((a)+o##field,v,l##field))

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    Raining down sulphur is like an endurance trial, man. Genocide is the
    most exhausting activity one can engage in. Next to soccer.
     
    SM Ryan, Jun 16, 2006
    #7
  8. Jalapeno

    Jalapeno Guest

    SM Ryan wrote:
    >
    > Unless you're exploiting compiler specific options, you cannot
    > depend on struct fields ending up on any particular byte or bit
    > boundary.
    >


    How the struct members are aligned is documented for both C and COBOL.
    Without getting into off topic details, the COBOL and C compilers
    "working storage"/"automatic variables" in CICS match the layout of the
    BMS assembler macro. My job as a C programmer in this instance is
    basically to make sure the C type matches the COBOL type and let the
    compiler do the work. Using an unsigned (or plain) char array is, I
    believe, actually treading on ice-more-thin in this situation. Thanks
    for the interesting idea. My question was really about C's syntax
    rather than about converting COBOL.
     
    Jalapeno, Jun 16, 2006
    #8
  9. Jalapeno

    Jalapeno Guest

    Jalapeno wrote:
    > Unfortunately, we systems programmers are now spending half our time
    > "teaching" outsourced applications programmers how to do the jobs they
    > took from us.


    After rereading what I wrote here it sounds more harsh than I intended.
    I have nothing against folks competing in a global economy. I work with
    individuals who are quite bright. If I have a beef it is with
    outsourcing companies that get a contract, hire newby programmers, give
    them a few weeks training, and then put them on the job less than half
    prepared. I hope I did not offend anyone with that statement.
     
    Jalapeno, Jun 16, 2006
    #9
  10. "Jalapeno" <> writes:
    > SM Ryan wrote:
    >> Unless you're exploiting compiler specific options, you cannot
    >> depend on struct fields ending up on any particular byte or bit
    >> boundary.

    >
    > How the struct members are aligned is documented for both C and COBOL.


    Correction: it may be documented for your particular implementation.
    The C standard makes only a few guarantees about how struct members
    are allocated. A compiler may insert arbitrary padding between
    members, or after the last member. I don't believe it's even required
    to document how it does so, or to behave consistently across different
    phases of the moon.

    If you're working in an environment that makes additional guarantees,
    of course, you're free to depend on those guarantees; just be aware
    that your code could break if it's ported to another implementation.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Jun 16, 2006
    #10
  11. Jalapeno

    CBFalconer Guest

    Jalapeno wrote:
    > SM Ryan wrote:
    >>
    >> Unless you're exploiting compiler specific options, you cannot
    >> depend on struct fields ending up on any particular byte or bit
    >> boundary.

    >
    > How the struct members are aligned is documented for both C and COBOL.

    .... snip ...

    Not for C it isn't. I believe the only guarantee you have is that
    the address of the first component is also the address of the
    complete structure.

    --
    "A man who is right every time is not likely to do very much."
    -- Francis Crick, co-discover of DNA
    "There is nothing more amazing than stupidity in action."
    -- Thomas Matthews
     
    CBFalconer, Jun 16, 2006
    #11
  12. CBFalconer <> writes:
    > Jalapeno wrote:
    >> SM Ryan wrote:
    >>>
    >>> Unless you're exploiting compiler specific options, you cannot
    >>> depend on struct fields ending up on any particular byte or bit
    >>> boundary.

    >>
    >> How the struct members are aligned is documented for both C and COBOL.

    > ... snip ...
    >
    > Not for C it isn't. I believe the only guarantee you have is that
    > the address of the first component is also the address of the
    > complete structure.


    And that addresses of other members increase in the order in which
    they're declared, and (implicitly) that the layout leaves at least
    enough room for each member.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Jun 16, 2006
    #12
  13. Jalapeno

    SM Ryan Guest

    # How the struct members are aligned is documented for both C and COBOL.
    # Without getting into off topic details, the COBOL and C compilers

    For a specific C compiler. Other C compilers might lay out a
    struct differently. The first field is at the very beginning
    of the struct, and subsequent fields are strictly increasing
    offsets, but there's no guarentee by the language definition
    what those offsets will be.

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    I love the smell of commerce in the morning.
     
    SM Ryan, Jun 17, 2006
    #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. Chris Fogelklou
    Replies:
    36
    Views:
    1,438
    Chris Fogelklou
    Apr 20, 2004
  2. Tom Plunket

    Unnamed members

    Tom Plunket, Jun 23, 2006, in forum: C Programming
    Replies:
    9
    Views:
    588
    Tom Plunket
    Jun 23, 2006
  3. Ehud Shapira
    Replies:
    20
    Views:
    1,180
    Ehud Shapira
    Jun 30, 2007
  4. Iñaki Baz Castillo
    Replies:
    13
    Views:
    551
    Iñaki Baz Castillo
    May 1, 2011
  5. John Reye
    Replies:
    28
    Views:
    1,412
    Tim Rentsch
    May 8, 2012
Loading...

Share This Page