Many things that are easily thought will get you in trouble if you think them. Understand the difference or get bitten; your choice.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Tony Thigpen <[email protected]> Sent: Wednesday, July 18, 2018 4:20 PM To: [email protected] Subject: Re: New Metal C standalone product for z/OS c pointers are easily thought of as just automatic 'using' statements. Tony Thigpen Steve Thompson wrote on 07/18/2018 03:54 PM: > * TYPEing > > &LABEL DC 0F,A(BUFF_LEN+7) Get The Charles Constant... > > The type of the LABEL is "F" not "A" and you got what you needed. yes? > > This is typically done for certain "ASSIST" type macros that I've used > in the past where they check what the label is (IF, DO, DOWHILE, > SELECT, etc.). > > Meanwhile, I'm thinking a bit about c and learning it. I still remember > that c's pointers are about as obtuse as they get... But I'm told once > you get past that, c becomes easy.... :) > > Regards, > Steve Thompson > > On 07/18/2018 01:42 PM, Charles Mills wrote: >> 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 >> > >
