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. I guess if I were handier with regex it would be a piece of cake. I should just figure it out once and then I would have it. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Charles Mills Sent: Tuesday, July 17, 2018 4:57 PM To: [email protected] Subject: Re: New Metal C standalone product for z/OS 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. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Farley, Peter x23353 Sent: Tuesday, July 17, 2018 4:19 PM To: [email protected] Subject: Re: New Metal C standalone product for z/OS And of course I confused my assembler and my C. I meant to say ". . . address variables as "void *" and __PTR32 or __PTR64 as needed . . . ". CDSECT (at least as of V2.1) has a bad habit of translating some assembler address variable definitions as "char[4}" or "char[8]". I haven't exercised CDSECT V2.2 yet, it will be interesting to see what it does with those kind of definitions.
