Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.std.c
Subject: Re: The \c escape
Message-ID: <8136@brl-smoke.ARPA>
Date: 22 Jun 88 15:45:21 GMT
References: <4604@haddock.ISC.COM> <5907@umn-cs.cs.umn.edu> <8125@brl-smoke.ARPA> <8127@brl-smoke.ARPA> <963@ficc.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 21

In article <963@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes:
>In article <8127@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
>> Multiple-character character constants are unportable and
>> considered bad style.  They're only permitted because they were in previous
>> practice.  Many of us don't think you should ever try to make use of them.

>(1) OK, how do you spell "\x234\c5"? "\x234""5"?

Sure.  What's wrong with using the more general facility for strings?

>(2) What's wrong with a readable and maintainable way of initialising a
>    32-bit unsigned integer to 0x464F524DL? You prefer that (or ('F'<<24)|
>    ('O'<<16)|('R'<<8)|('M')) to 'FORM'?

I would prefer that you not depend on being able to jam 'FORM' into
an int in the first place.  It will obviously not work on a 16-bit
implementation.

If you nonetheless feel you have to use a kludge a la troff, try
	#define	PACK(c1,c2)	((c1)<<8 | (c2))
which at least is portable across 8-bit byte implementations.