Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uakari.primate.wisc.edu!unmvax!pprg.unm.edu!topgun.dspo.gov!lanl!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Uninitialized externals and statics
Message-ID: <10869@smoke.BRL.MIL>
Date: 29 Aug 89 20:10:05 GMT
References: <2128@infmx.UUCP> <4700042@m.cs.uiuc.edu> <1989Aug25.185428.3511@utzoo.uucp> <609@paperboy.OSF.ORG> <10831@smoke.BRL.MIL> <1392@atanasoff.cs.iastate.edu> <10859@smoke.BRL.MIL> <1403@atanasoff.cs.iastate.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22

In article <1403@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu.UUCP (John Hascall) writes:
>   If you are not going to restrict the "local alphabet" *
>   characters to a contiguous sequence of integer values it certainly
>   makes the problem of writing a portable sorting routine difficult.

Sorting in dictionary order is obviously locale-dependent.  The C standard
specifies facilities to assist in this (see strcoll()).  Note that it did
not attempt to constrain the alphabet.

>   That's the point.  They should be an international data transport
>   standard not a C programming language standard.

There IS such a standard (ISO 646), but it doesn't include representations
for certain glyphs that are used in C source code!

>   What if some group decides on a "insert other langauge here"
>   standard that wants to use quadgraphs of $*$c, for example
>   for this file transfer purpose.

C appears to have the first programming language standard that made a
serious attempt to address internationalization concerns.  Others can
do what they will, but some of them may follow C's general approaches.