RE: Agree: Require ANSI C for development [Was: libwww ]

>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...

Oooh, I don't think I'd *really* want my headers generated from
my C code.  Though, I can't say that I've tried it.

>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'd rather keep this real simple.  I never call malloc without a cast anyway.
Just a nice simple, obvious #define symbol which is #defined to malloc under
UNIX would suit me.  I'll check its result for NULL just like always.

>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....

Well, first of all it's not Windows, it's the Mac.  Windows has a fine
malloc implementation, and I use it all the time.  The fact that Windows
doesn't free memory on process exit is not the fault of malloc, and
malloc is not the place to fix it.  Just free whatever you allocate.

The problem is the Mac.  There is no memory allocation function in any
Mac compiler which is reliable and is also named malloc().  I don't
want to write one.  I also don't any function I write to have the same
name as an ANSI function unless I got to the effort to make *very sure*
that my implementation is ANSI compliant.  I don't have the time or
motivation to do that.  #define W3_MALLOC solves the whole problem.
If it creates other problems, then maybe we can find another solution,
but I'd sure like it to be a simple one.

>>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...

gcc -pedantic -whatever_the_option_is_to_turn_on_ALL_the_warnings

It's almost like using lint.  I've never used DEC's VMS C compiler, but
their Ultrix compiler is awful.

Eric W. Sink, Software Engineer --  eric@spyglass.com 217-355-6000 ext 237
All opinions expressed are mine, and may not be those of my employer.
        "Only academic people put cheese in their pocket."
            -SW, 24 May 1994

Received on Wednesday, 13 July 1994 21:39:43 UTC