Xref: utzoo comp.lang.c:14894 comp.std.c:586 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!uflorida!novavax!proxftl!twwells!bill From: bill@twwells.uucp (T. William Wells) Newsgroups: comp.lang.c,comp.std.c Subject: Re: Definition of isprint() Message-ID: <256@twwells.uucp> Date: 18 Dec 88 09:23:31 GMT References: <474@sdrc.UUCP> <9182@smoke.BRL.MIL> Reply-To: bill@twwells.UUCP (T. William Wells) Organization: None, Ft. Lauderdale Lines: 59 Summary: Expires: Sender: Followup-To: Distribution: Keywords: In article <9182@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) writes: : In article <474@sdrc.UUCP> scjones@sdrc.UUCP (Larry Jones) writes: : >SAS has defined "printing character" in : >terms of what is printable on an ancient line printer so some : >obviously printable characters such as "{", "}", "[", "]", "\", : >and "!" cause isprint() to return 0! : >The dpANS seems to allow this, since "printing character" is : >implementation defined, but it seems to me that the C source : >character set should be specified as printable in the "C" locale. : >The problem seems to be that the exact semantics of ispunct() are ^isprint()? : >not specified for the "C" locale. : : I don't have the proposed standard at hand, but I believe : that the intention was that in the "C" locale all the C source : graphic characters (glyphs) plus the space character are : supposed to satisfy isprint(). I believe that other non-control : characters were also supposed to be allowed (but not required) : to satify isprint() in the "C" locale, since that is the existing : practice and base document requirement from which the standard : was derived. If indeed we missed this, implementors should : still do it right, if only as a favor to programmers of portable : applications. Here is what the May 13 draft says: 4.3 "The term `printing character' refers to an implementation-defined set of characters, each of which occupies one printing position on a display device;..." 4.3.1.7 "The isprint function tests for any printing character including space(' ')." However, the standard doesn't require that all characters which are printable be "printable characters". In fact, the set of printable characters could, without contradicting the wording, be NULL! (Or, maybe if you think of 4.3.1.7 as a constraint on printing characters, the set could contain only space.) Uk! [One more example of why some kind of "reasonable interpretation" clause needs to be an implicit or explicit part of any standard, even though it opens up another can of worms. Standards for something as complicated as C are never complete; there is always *something* which is left out. Implementers need to interpolate this information, but the mere absence of the information ought not be taken as a licence for wildly inappropriate implementations.] --- Bill {uunet|novavax}!proxftl!twwells!bill