Definition of isprint()
T. William Wells
bill at twwells.uucp
Sun Dec 18 19:23:31 AEST 1988
In article <9182 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
: In article <474 at sdrc.UUCP> scjones at 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
More information about the Comp.lang.c
mailing list