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.