Date: Mon, 16 Oct 1995 11:22:53 EST From: "Kaleb S. KEITHLEY" <kaleb@x.org> To: ache@astral.msk.su Cc: hackers@freefall.FreeBSD.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Message-ID: <199510161522.LAA07456@exalt.x.org> In-Reply-To: Your message of Mon, 16 Oct 1995 04:13:55 EST. <KkJ7RWmaE4@ache.dialup.demos.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> >>BLANK fixes are incorrect, see isblank(3). >>> >>As I said, at least one system's docs claim it spec'd in ISO8859-1. I >>don't have an ISO8859-1 at hand, and I'm not even sure I have one at >>work, although I must, somewhere. >I don't need 8859-1 docs, I already have them. I need any isblank() >references. Maybe ANSI? 8859-1 is ISO. I would not expect ANSI or IEEE to address function behavior in a locale based on an ISO character encoding. What ANSI does say is that the behavior of is...() and to...() functions are implementation dependent when the locale is not "C". ANSI/POSIX/ISO C do not define isblank(), but do allow functions like it to be added. Now that I'm at work I can't find ISO8859-1. ISO8859-2 does not define what constitutes a blank, so I'll stick my neck out a little further than I already have and guess that ISO8859-1 does not either. When I say that SVR4 does not consider '\t' to be a blank I am not saying that FreeBSD should do the same merely because SVR4 does. What I am saying is: if you take iBSC seriously, then you should make isblank, in an ISO locale, work the same way that it would work on other systems. SunOS, Digital UNIX, and all various versions of SVR4 (Solaris 2,x, IRIX 5.x/6.x, NEWS-OS 6.x, and Unixware 2.x) all say '\t' is not blank. HPUX-10 and AIX-4 say it is, but they're not contenders for iBSC. Linux says it is too, and I would argue that Linux is broken for the same reason. I think we've made a mountain out of a molehill. -- Kaleb
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510161522.LAA07456>