Questions on X3J11 draft

Philip Peake philip at axis.UUCP
Thu Dec 18 22:48:05 AEST 1986


In article <5446 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <775 at axis.UUCP> philip at axis.UUCP (Philip Peake) writes:
>>How can I know, when trying to write portable code, if the 'library'
>>function I am going to use is a real function or a macro ?
>
>The only time it can matter is if it's a macro and you need a function.
>In this case, #undef it first (this is harmless if it's not a macro).

Firstly, let me make it clear that I am not specifically picking on the
author of this article - it is just a convenient example.

After my original posting I received several emails and there were several
follow-up articles. The emails were (for the most part) geuine attempts
to be helpfull (thank you people), the follow-up articles have ALL
followed the pattern above - a small extract is quoted out of context.
This may be because of a desire not to re-transmit vast chunks of previous
articles - I don't know. But in many cases the quote is selected in such
a way as to justify the comments which the person wants to make, and
is not given the same interpretation as it would have been when seen
in its original context.

I have seen this happen many times before, to many different people -
I just thought that I would comment on it.

NOW - on to the reall issue .....

Allowing implementors to choose to implement 'standard' library functions
as macros is going to just make my life more difficult. I thought that
one of the purposes of any standardisation exersise was to make peoples
lives easier (scratch one illusion ...).

Most of the follow-up articles suggest that I can use pre-processor
macro tests and undefs etc.

Any code that I have to port to many machines already has too many
#ifdef lines for my liking. They obscure the program, and in some peverse
cases you find more pre-processor code than C code !

I dont want to have to write:

#ifndef	malloc
extern char	*malloc();
#endif
#ifdef	lseek
extern	long	lseek();
#endif

and contine to do the same for every libary 'function' I want to use.
Its a horrible idea!

Another suggestion is that one relies upon the definitions in the appropriate
include files - my VAX doesn't have them, nor does my XENIX system, nor
does my PDP11 etc ...

I still have to write code to work on any of them. An XJ311 conforming
compiler is just going to be another pain in the neck - for a long time to
come. I can't tell all our clients that they have got to go out and buy
an XJ311 compiler if they want our products.

Many of the obtuse inclusions in this standard are there simply for the
convenience of certain manufacturers. Not for the convenience of those
who have to use C compilers. It allows almost ANYTHING to be called
a conforming compiler - good for buisness for the manufacturers .. they
can tell the government departments that they have a conforming compiler -
which is probably the same one that that departments programmers refused
to accept 2 years ago !

There are ways around the problem of macro-functions, but non are nice.
Why not let the compier implementors do what they should always do
anyway - work just a little bit harder, so that 10,000,000 programmers
can work just a little bit easier in the future ?

Philip



More information about the Comp.lang.c mailing list