Xref: utzoo comp.lang.c:14762 comp.std.c:562
Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: Definition of isprint()
Message-ID: <9182@smoke.BRL.MIL>
Date: 15 Dec 88 00:24:23 GMT
References: <474@sdrc.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 28

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!

No doubt about it, one does find some stupid interpretations
of the CTYPE macros in many implementations.  Berkeley's was
pretty strange for a release or two (fixed now).

>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
>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.

I have to admit I don't find much use for isprint().
If it is broken in the standard, I can live with it.