- From: <hallam@alws.cern.ch>
- Date: Wed, 13 Jul 1994 21:17:50 +0200
OK, If its beat up on ARGSx and PARAMS time... For Shen I first thought `yuk!' then I had second thoughts `yuk!'. Then I wrote a C preprocessor that takes ANSI C and produces the ARGS stuff and HTML headers and a few other bits. I'm a big fan of having the headers generated from the C source. This means that headers for structures are kept separately - but I always do this anyway because I use data models such as Gvdel to build C strutures etc from a more abstract form, allow attachment of metadata etc etc... On the MALLOC side. Can we do the job properly? Like have macros where the TYPE of the malloced item is declared:- bytes = MALLOC (char, 32) Or better STATUS = MALLOC (char, 32, &bytes) This means that you can have metadata attachments which then means that hypertext coredumps can be produced... dead kool... I agree with Dan on the forcing WINDOZE to be proper... I always use the macros BEGIN and END in my proceedures to force handling of status info transparently. So if I'm on VMS I can get proper VMS error codes and if I'm on UNIX they look well yukky. But you can then play games with the END macro... Stick some sort of label in and a return then becomes a jump to the label and return... Can force a lot of cleanups that way.... I also use macros to assert PRE and POST conditions.... PRE (WWW_an_error_code, x!=NULL); PRE .... >Not only should we require an ANSI C compiler for development, but we >should write squeaky-clean ANSI C code, except for modules that need >POSIX features, in which case we should write squeaky-clean POSIX code. I don't like using gcc for development for this very reason.. I get many more error messages from the DEC-C compiler on VMS... Phill
Received on Wednesday, 13 July 1994 21:18:01 UTC