🚀 go-pugleaf

In article <4880@brl-smoke.ARPA> kb5mu@NOSC.ARPA writes:
>>But. . .is there a way to write an ANSI cpp version of
>>        #define CTRL(c)
>
>I don't have an ANSI cpp handy (does anybody?), so I can't test
>this, but how about using the ANSI invention of # for "string-izing":
>        #define CTRL(c) (#c[0] & 037)
>This should turn
>        CTRL(z)
>into
>        ("z"[0] & 037)
>which would get what you wanted, except that relatively stupid
>compilers might allocate storage for the string literal "z".

It's worse than that. "z"[0] is *("z"), and unary * is not allowed
in constant expressions. So ALL compilers would allow storage for "z"
and then generate code to read that storage at run-time.
Of course, ``case CTRL(c):'' wouldn't work either.

You don't expect C compilers to pull constants out of string literals,
do you?
[ I don't have an Ansi draft, so as far as I know there may be a rule
saying that constant expressions may contain string literals indexed by
constants. But I doubt it].

-- 
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg

) >But. . .is there a way to write an ANSI cpp version of
) >        #define CTRL(c)
) 
) I don't have an ANSI cpp handy (does anybody?), so I can't test
) this, but how about using the ANSI invention of # for "string-izing":
)         #define CTRL(c) (#c[0] & 037)

Not everybody has it.  What's wrong with this old trick?

	#define Q "
	#define CTRL(z) (Q z "[1]^0100)
-- 
Col. G. L. Sicherman
UU: ...{rocksvax|decvax}!sunybcs!colonel
CS: colonel@buffalo-cs
BI: colonel@sunybcs, csdsiche@sunyabvc

In article <4880@brl-smoke.ARPA> kb5mu@NOSC.ARPA writes:
>>But. . .is there a way to write an ANSI cpp version of
>>        #define CTRL(c)
>
>I don't have an ANSI cpp handy (does anybody?), so I can't test
>this, but how about using the ANSI invention of # for "string-izing":
>        #define CTRL(c) (#c[0] & 037)
>This should turn
>        CTRL(z)
>into
>        ("z"[0] & 037)
>which would get what you wanted, except that relatively stupid
>compilers might allocate storage for the string literal "z".

The problem with using string-izing, is that it is not a constant expression,
and can't be used in switch statements.  Many of the places CTRL(x) is
currently used ARE in switch statements.  Another approach would be to use
token pasting, instead of string-izing:

	enum _ctrl_chars {
		_ctrl_a = 1,
		_ctrl_b = 2,
			/* c, d, etc. */
		_ctrl_z = 26,
		_ctrl_A = 1,
		_ctrl_B = 2,
			/* C, D, etc. */
		_ctrl_Z = 26
	};

	#define CTRL(x)		(int)( _ctrl_ ## x)

The problem with the above is that people have also used CTRL([) to
represent the escape character.

	Michael Meissner, Data General
	...mcnc!rti-sel!dg_rtp!meissner

In article <666@dg_rtp.UUCP>, meissner@dg_rtp.UUCP (Michael Meissner) writes:
>In article <4880@brl-smoke.ARPA> kb5mu@NOSC.ARPA writes:
>>        #define CTRL(c) (#c[0] & 037)
>>This should turn
>>        CTRL(z)
>>into
>>        ("z"[0] & 037)
>The problem with using string-izing, is that it is not a constant expression,
>and can't be used in switch statements.  Many of the places CTRL(x) is
>currently used ARE in switch statements.  Another approach would be to use
>token pasting, instead of string-izing:
>
>	enum _ctrl_chars {
>		_ctrl_a = 1,
>		...
>		_ctrl_Z = 26
>	};
>	#define CTRL(x)		(int)( _ctrl_ ## x)
>The problem with the above is that people have also used CTRL([) to
>represent the escape character.
>	Michael Meissner, Data General

At this point, I begin to wonder out loud why all the contortions people are
going to just to avoid typing two silly little single quotes when using a
CTRL macro, i.e.:

#define CTRL(x) (x & 037)

	char c;
	switch (c) {
		CTRL('A'):	blah blah blah...; break;
		CTRL('E'):	bleh bleh bleh...; break;
		...

This even lets you have your CTRL('@') for NUL and CTRL('[') for escape, etc.
I contend this is just as useful as anyone else's suggestion and doesn't rely
on any large list of values or fancy-ANSI [:-)] preprocessor either.
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
	   go for it!  			allegra,ulysses,vax135}!ttrdc!levy