Quote without comment on char constant expansion

Chris Torek chris at mimsy.UUCP
Thu Apr 14 14:12:22 AEST 1988


[#define _IO(x,y) (IOC_VOID|('x'<<8)|y), a `Reiserism', has no counterpart
in the dpANS]

>In article <3432 at haddock.ISC.COM> karl at haddock.ima.isc.com (Karl Heuer) writes:
>>The original problem showed up in BSD <sys/ioctl.h>.  I would recommend that
>>this header be fixed ....

In article <7677 at brl-smoke.ARPA> gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
>The important thing is that this can be fixed NOW -- you don't have
>to wait for an ANSI C compliant compiler to apply the suggested fix.
>Then when 4BSD switches to an ANSI C compiler this wouldn't break.

It not only can be fixed, it has been fixed.  But that is not the
`important thing'.  The `important thing' is that the Reiser
preprocessor offers one function---turning a macro argument into a
character constant---that cannot be performed by a preprocessor that
works as defined in the dpANS.  Without the introduction of the
so-called `stringize' operator `#', there would have been two such
functions, and so (the argument goes) perhaps there should be a
`charize' operator.

The argument against this, of course, is that somehow `stringize'
is useful while `charize' is not, or not enough so.  The argument
holds up to some extent when one considers another change from
existing practise: string concatenation.  A debug-variable-value
macro can now be written as follows:

	#ifdef DEBUG
	#define printint(x) (void) printf("DEBUG: " #x " = %d\n", x)
	#else
	#define printint(x)
	#endif

Personally, I never liked the Reiser behaviour; I found it rather
counterintuitive.  I do wonder, though, whether the loss of a
macro-argument-to-character-constant function will prove more
significant than it already has (in the `CTRL' macro---the ioctl
macros are much better confined and hence easier to alter).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris



More information about the Comp.lang.c mailing list