It *does* get alignment right. CDSECT's output does not depend on "inherent" C alignment. Char[8] and uint64_t both end up in the same place. It constructs the struct using the SYSADATA offsets. It inserts its own padding where necessary. It emits #pragma pack(packed).
Going from structs to DSECTs would make a lot of sense except that there is no C equivalent of SYSADATA, so the utility would have to have its own built-in (partial) C compiler. Going from PL/X to DSECTs (or C headers!) makes a lot of (technical) sense. I fail to see how &ptr32 is any clearer than A, unless you happen to be coming from a C-only background. Neither one is clear if you don't know what it means. A means "32-bit pointer." Generally. Of course HLASM is all but untyped. A might mean an integer constant, especially since A supports expressions while F somewhat inexplicably does not. You can code A(BUFF_LEN+7) but not F'BUFF_LEN+7'. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Wednesday, July 18, 2018 10:10 AM To: [email protected] Subject: Re: New Metal C standalone product for z/OS On 2018-07-17, at 18:04:14, Charles Mills wrote: > One annoying thing also is that it is non-trivial to use a text editor to find and convert all > > char foo[8]; > to > uint64_t foo; > > It would be easier if the c syntax were char[8] foo; then getting to uint64_t foo; would be trivial. > It seems the designers were fixated on making declarators look like member references. > -----Original Message----- > From: Charles Mills > Sent: Tuesday, July 17, 2018 4:57 PM > > Well, the problem of course is that assembler is not strongly typed. You can code > > BUFFADDR DS CL4 (or even 4C) and it works just fine for assembler, but what is poor CDSECT supposed to do. > > Last I knew, it did all FD and AD as char[8] which IMHO is pretty d@mned stupid. But it is syntactically valid and the storage layout is correct. > Subject to bouldary alignment. A more useful design would code the data area descriptions initially as C structs and supply an ASTRUCT utility to convert to DSECTS. I believe I'd name it DESTRUCT. Or, an assembler programmer with foresight could have employed SETC symbols such as: &__ptr32 SETC A POINTER DC &__ptr32(symbol) ... Providing some guidance for a CDSECT utility and clarity for the reader of the source. (IMO, "&__ptr32" conveys better information than "A". I'm not advocating Hungarian Notation.) (This solves nothing for legacy source code.) -- gil
