enag@ifi.uio.no (Erik Naggum) (02/14/91)
This concerns the ANSI C standard. The localeconv function has some examples on page 111. I'm concerned with the specific entry on line 4 of that page. It says something about Norway. I live in Norway. According to this example, Norwegians write "kr1234,56" when they mean 1,234.56 units of local currency. According to this example, they also write "kr1234,56-" when they mean -1,234.56 units of local currency. I wonder how this managed to get into a standard in the year 1989. After spending a few days asking friends, and them their fathers, I my friends in the Norwegian Standards Association, the uniform reply is "that went out of recommended use more than 20 years ago". In 1968 NS 4133 (Norwegian Standard for Letters and other Documents, Writing and Layout), the international currency code "NOK" is recommended for all international trade and communication, and is preferred for domestic use, as well. "kr" was still allowed, but deprecated, as one would say. There is a space after the "kr", and has been since the birth of the predecessor of NS 4133, NS 1119. Furthermore, negative amounts were specified with trailing minus in NS 1119. NS 4133 and its source NS 4057 changes this to parenthesized form or having the minus sign precede the quantity. NS 1119 went out of circulation in 1968. I mean, NINETEEN SIXTY-EIGHT. I'm not impressed. One is led to believe that whatever else they say on localization is also grossly out of date, and subsequently that the whole locale stuff is bugridden at its core, never really tested. My direct questions are: Where did X3J11 get the input for these examples? Are they didactic only, or are they intended to show real use of the localization features? I would appreciate pointers to how this can be updated, as well. -- [Erik Naggum] <enag@ifi.uio.no> Naggum Software, Oslo, Norway <erik@naggum.uu.no>
peter@world.std.com (Peter Salus) (02/15/91)
In article <ENAG.91Feb13234959@holmenkollen.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes: >This concerns the ANSI C standard. The localeconv function has some >examples on page 111. I'm concerned with the specific entry on line 4 >of that page. It says something about Norway. I live in Norway. > >According to this example, Norwegians write "kr1234,56" when they mean >1,234.56 units of local currency. According to this example, they >also write "kr1234,56-" when they mean -1,234.56 units of local >currency. > >I wonder how this managed to get into a standard in the year 1989. >After spending a few days asking friends, and them their fathers, I my >friends in the Norwegian Standards Association, the uniform reply is >"that went out of recommended use more than 20 years ago". In 1968 NS >4133 (Norwegian Standard for Letters and other Documents, Writing and >Layout), the international currency code "NOK" is recommended for all >international trade and communication, and is preferred for domestic >use, as well. "kr" was still allowed, but deprecated, as one would The interesting thing is that NS4133 is in line with ISO. ISO3166 (Codes for the Representation of names of countries) and ISO4217 (Codes for the representation of currencies and funds) call for NOK for Norwegian Krone. ISO4217 is maintained by the BSI in Milton Keynes, United Kingdom, which I find funny as the ISO designation is GB (and GBP), not UK. Peter -- The difference between practice and theory in practice is always greater than the difference between practice and theory in theory.
domo@tsa.co.uk (Dominic Dunlop) (02/16/91)
[Note that I'm making an attempt to divert this discussion into comp.std.internat] In article <ENAG.91Feb13234959@holmenkollen.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes: > This concerns the ANSI C standard. The localeconv function has some > examples on page 111. I'm concerned with the specific entry on line 4 > of that page. It says something about Norway. I live in Norway. > > According to this example, Norwegians write "kr1234,56" when they mean > 1,234.56 units of local currency. According to this example, they > also write "kr1234,56-" when they mean -1,234.56 units of local > currency. > > I wonder how this managed to get into a standard in the year 1989. > After spending a few days asking friends, and them their fathers, I my > friends in the Norwegian Standards Association, the uniform reply is > "that went out of recommended use more than 20 years ago". In 1968 NS > 4133 (Norwegian Standard for Letters and other Documents, Writing and > Layout), the international currency code "NOK" is recommended... > international trade and communication, and is preferred for domestic > [and so on] > > I'm not impressed. One is led to believe that whatever else they say > on localization is also grossly out of date, and subsequently that the > whole locale stuff is bugridden at its core, never really tested. Well, yes. It is fair to say that internationalization issues were introduced to both the X3J11 and the POSIX working groups rather late in the day, with the result that ANSI X3-159 (C) and ANSI/IEEE 1003.1 (POSIX operating system interface) are rather light on internationalization-related content. This lightness is likely to be redressed in two forthcoming standards, the X3J16 C++ work, and the POSIX 1003.2 standard (shell and utilities): the internationalization lobby was able to get at these projects sufficiently early in their development to ensure that internationalization issues are considered at every turn. Well, most turns. Well, a good proportion of turns. It is also the case that the 1990 version of 1003.1 (which is the same thing as ISO 9945-1:1990) says a bit more about internationalization than the 1988 edition, and that the next edition of the C standard will also pay more attention to the issue, thanks to much work by Japan and Nordic countries, among others. (Sadly, ISO 9899:1990, the first edition of the international standard for C, has the same technical content as ANSI X3-159.) As for testing, where do you get things tested? In the marketplace, that's where. Unfortunately, there was very little prior art for X3J11 and POSIX workers to standardize, and what prior art there was had known shortcomings -- for example in the handling (or lack of handling) of wide characters. As a result, much of what the standardizers did was to try to make sure that practical fixes to known problems were not precluded in the future, rather than trying to come up with fixes at once. I believe POSIX did fairly well in this respect. I'm not so sure about C. A word of praise here for X/Open, which has thrown a lot of resource at the issue. But X/Open has to learn that standards working groups do not respond well to being told that a proposal must be accepted unchanged or not at all. > My direct questions are: > > Where did X3J11 get the input for these examples? > The point is that X3J11 set out to create an American National Standard. Should they be expected to know about Norway? Probably not. It's just rather a shame that they claimed to, because it creates a very bad impression with those who know better. It happens that the working group rules would have allowed participation by Norweigian companies, but what Norweigian company would want to spend money on the creation of an American standard? Try selling that idea to your management. In general, I wish more people around the world in general, and in America in particular, knew about such things as ISO 4217, Codes for the representation of currencies and funds. But they don't. People may, if you're lucky, know about their local conventions (don't rely on it though -- how many Norweigians know of the existence of NS 4133, I wonder?) This means that the right place for the definition of such things is in their target market (or ``locale'' as standards people have it). The 1990 edition of the POSIX.1 standard has annexes addressing this issue -- including a Danish example created by the Danish standards body. The internationalization rapporteur group of the ISO POSIX working group is trying to make sure that POSIX internationalization facilities do not preclude the definition of any locale that anybody, anywhere might reasonably require. The more people who get in touch with us and tell us what we're doing wrong, the happier we'll be. (Yes, I'm the UK rapporteur, but take this posting as individual comment.) > Are they didactic only, or are they intended to show real use > of the localization features? Obviously, didactic only -- intended as an example, since the text says ``may well be used'', rather than ``shall be used''. A dangerous example, though: implementors are inclined to take anthing that appears in a standard as gospel. Let me know as soon as someone tries to sell you a compiler with this example cast into its libraries... > > I would appreciate pointers to how this can be updated, as well. > Personally, I would not bother trying to fix the ANSI standard. Get in touch with your national standards body, obtain pointers to those associated with ISO/IEC JTC1/SC22/WG14 (C language), and take it up with them so as to make sure that the problem, if it exists in the current edition (I'm told it's out) of ISO 9899, is fixed in the next, or in an corrigendum or addendum. -- Dominic Dunlop
rex@aussie.COM (Rex Jaeschke) (02/17/91)
> Sender: enag@ifi.uio.no (Erik Naggum) > > This concerns the ANSI C standard. The localeconv function has some > examples on page 111. I'm concerned with the specific entry on line 4 > of that page. It says something about Norway. I live in Norway. ... First, to the importance of this: The part of the standard document you cite is in an example. EXAMPLES ARE NOT PART OF THE STANDARD. If an example (or footnote or anything in the Rationale) contradicts something in the standard proper, the standard proper wins. If nothing is said in the standard proper, the example (etc) is simply a possible guideline/tutorial which, as you appear to believe, is incorrect or, at least, out of date. So, from a validation aspect, `It doesn't matter.' If, however, you are correct, it should be fixed. Derek Jones of the UK is the Project Editor for the Normative Adendum being produced by ISO C WG14. I shall bring this to his attention to see if it can be fixed by him. As I recall, most (if not all) of the locale stuff relating to currency in locales was researched by IBM's X3J11 reps (who, by the way, came from IBM Canada). Others may have contributed and/or confirmed all this. I, personally, did not yet I still voted to accept it in the final document. I have no expertise or interest in this particular area as I'm sure many others voting did not either. There comes a point in any such venture where you must trust people to do `the right thing'. Knowing the IBM reps well I trust they did what they thought was the right thing at the time they researched it and so I stand by their efforts and my vote. Hindsight is the most exacting science and we can also improve something. Also note that it was unlikely anyone working on ANSI C had a vested interest in the Norgegian marketplace at that time. We did, however, try to accomodate both European and Asian cultures with locales, etc., as best as we knew how and by cooperating with their suggestions and requests. I am not personally aware of any direct input from Norway either at the ANSI C or ISO C level re this or any other issue. If Norway has a standards body why aren't they participating in ISO C? Denmark is and they are concerned about their specific alphabet issues. > I'm not impressed. One is led to believe that whatever else they say > on localization is also grossly out of date, and subsequently that the > whole locale stuff is bugridden at its core, never really tested. This is a very extreme position. You are assuming locales are trashed just because the example has a problem. The standard does not require any implementor to provide any locales beyond "C". I'm sure that if you provided a Norwegian locale and did it `the right way' your customers will thank you for it. I may be reading into this something that isn't there but it sounds like `The damned US is ignoring the rest of the world again.' In any event I'd like to publicly state that having been heavily involved with X3J11 from about the 4th or 5th meeting on I never once saw evidence of the committee as a whole trying to subvert any attempt to provide reasonable support for non-USA, non-English cultures. The addition of locales and multibyte primitives delayed the standard probably 2 years but we did it anyway. And, FYI, although I may be the US international rep, I am an Australian citizen. BTW, The Danish Standards Assoc. has done a LOT of work on defining a Danish National Locale. Their ISO C rep is very much involved with ISO POSIX which is also looking at standardizing locales. Rex ---------------------------------------------------------------------------- Rex Jaeschke | Journal of C Language Translation | C Users Journal (703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL rex@aussie.COM | Reston, Virginia 22091, USA | Programmers Journal ---------------------------------------------------------------------------- Convener of the Numerical C Extensions Group (NCEG) ----------------------------------------------------------------------------
enag@ifi.uio.no (Erik Naggum) (02/17/91)
In reply to Rex Jaeschke's article <54.UUL1.3#5077@aussie.COM>. Quotes are from that article. First, thanks for an elaborate answer, Rex. > Examples are not part of the standard. I did overlook that rather important piece of information. Sorry. There are several implications from this, some of which you note. > I shall bring this to his [Derek Jones] attention to see if it can > be fixed by him. I appreciate that. > I have no expertise or interest in this particular area as I'm sure many > others voting did not either. The whole locale stuff is botched, in my opinion. It seems that too few people did have any real interest in this. The solution proposed is very cumbersome, and using it in all its ramifications basically requires a tutorial or at least a lot of example code. I haven't looked very hard, so I would appreciate pointers to such things if they do exist. > Also note that it was unlikely anyone working on ANSI C had a vested > interest in the Norgegian marketplace at that time. ... I am not > personally aware of any direct input from Norway either at the ANSI > C or ISO C level re this or any other issue. Then why was Norway chosen for the example? Norwegians tend to think that Norway is terribly important for world affairs in general, but I (a Norwegian only with respect to the longitude and latitude of my office and home, a regrettable accident) am not of that opinion. I do think, however, that if an example is chosen, it should be correct and relevant. This is not the case with one prominently chosen country in the example. > If Norway has a standards body why aren't they participating in ISO > C? Because I wasn't there at the time. Seriously, I have contacts inside the Norwegian Standards Association, and I'm trying to figure out why we are not represented in ISO/IEC JTC1/SC2 (character set issues), or why Norway does not have anybody officially working with SGML, or why some of the special things we have in this country invariably fail to show up in important international standards. Norwegians are soi disant individualists, but "individualist" seems to mean "different from everybody else" rather than "the way I think is best". (There is a big difference.) (Discussions of that in soc.culture.nordic, pls.) There are, however, limits to how much I can do. I like ANSI C, and I was just recently made aware of the efforts by ISO to adopt it. I run a one-man consulting company, and I do have to make a living on top of all this involvement, too. (Besides, slowly earning that university degree is not any less demanding.) I think it's important and inter- esting; that's why I do all these things. Few others seem to think it's worth it. Not my fault. And, I _am_ trying to fix it. (Please note that ISO work is unpaid, volunteer effort, and that the funds available to travel to meetings all over the world has to come from somewhere. I'm not going to play altruist and invest my own hard- earned money in travel budgets for ISO. My time, however, is avail- able for whatever I like to do -- that's why I'm self-employed. Other people I've talked to about doing something about the regrettable state of affairs always resort to arguments about "funding", i.e. getting someone to give them full salary for the time spent, which means that they are not really interested. The other problem is that the number and complexity of the strings attached to "grants" would choke me.) > You are assuming locales are trashed just because the example has a > problem. Well, no, but it could look like that. I'm sorry I didn't provide more background in my first posting. > The standard does not require any implementor to provide any locales > beyond "C". I'm sure that if you provided a Norwegian locale and > did it `the right way' your customers will thank you for it. I'm working on it. Don't hold your breath, though. > I may be reading into this something that isn't there but it sounds > like `The damned US is ignoring the rest of the world again.' It's not in there. I don't think it could sound like it, either. And I'm not going to into apologetic-mode in defense of the U.S., but I would like to state for the record that I would never say anything like "the damned U.S.". > The addition of locales and multibyte primitives delayed the > standard probably 2 years but we did it anyway. For which I'm not particularly thankful, but never mind. If I can get to be an ISO rep without _losing_ money on it, we may have a chance to meet sometime. With the hysterical attitudes we have against people not employed by the Government and under their control in this country, it might take some time. Again, thanks for your elaboration. -- [Erik Naggum] <enag@ifi.uio.no> Naggum Software, Oslo, Norway <erik@naggum.uu.no>
rex@aussie.COM (Rex Jaeschke) (02/18/91)
> The whole locale stuff is botched, in my opinion. It seems that too You still have not said in what way. Give a specific example please. > few people did have any real interest in this. The solution proposed > is very cumbersome, and using it in all its ramifications basically > requires a tutorial or at least a lot of example code. I haven't > looked very hard, so I would appreciate pointers to such things if > they do exist. I expect that most programmers will fall into 2 main camps: those that will use the "C" locale getting the behavior they have been used to for years; and those who use an entire local locale. That is, they will not likely use composite locales. In the latter case I expect implementers will provide a compiler option to make their own locale the default so programmers won't even have to call setlocale. (This might not be sanctioned by Standard C but if you aren't interested in portability so what?) If you want to mix locales then I agree it can get messy. But the simple fact is that places near (and not so near) international borders DO HAVE composite ways of doing things. For example, one Swiss location might use composites made up from France, Switzerland, and Italy while another might use German and/or Austrian. I think the ability to have composite locales simply reflects the real world. As to a tutorial, I think the definition of locales was intentionally left vague so we did not arbitrarily constrain implementors. As more experience is gained it will be documented. PJ Plauger, ANSI C secretary and ISO C convenor, played a significant role in our support for internationalization. He is now an independent consultant and recently, finished writing a complete portable C runtime library (in C, of course). He is licensing this to implementors. This will all be documented in his upcoming book from Prentice-Hall and the source will be available `at reasonable cost'. One thing he has spent quite some time on is locales. Basically, he spent lot's of time looking at ways to implement them given the direction of ANSI C. He has suceeded in doing so and learned a lot along the way. He documents much of his efforts in his column in the March 1991 issue of my publication `The Journal of C Language Translation.' And I expect there will be a second article probably in June. I am not personally aware of many groups working hard on locale definitions. One I do know is DEC. Their PDP-11 C compiler group supports quite an elaborate set. I mentioned the Danish national effort last posting. I suspect IBM, H-P, AT&T, and Unisys all have significant efforts in this area given their general interest in internationalization. Note too that all these companies were represented on ANSI C and I recall seeing input from them during deliberations. Rex ---------------------------------------------------------------------------- Rex Jaeschke | Journal of C Language Translation | C Users Journal (703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL rex@aussie.COM | Reston, Virginia 22091, USA | Programmers Journal ---------------------------------------------------------------------------- Convener of the Numerical C Extensions Group (NCEG) X3J11 member and US International Representative to ISO C (WG14) ----------------------------------------------------------------------------
gwyn@smoke.brl.mil (Doug Gwyn) (02/19/91)
In article <1991Feb16.140510.22226@tsa.co.uk> domo@ukc.ac.uk (Dominic Dunlop) writes: >Well, yes. It is fair to say that internationalization issues were >introduced to both the X3J11 and the POSIX working groups rather late in >the day, with the result that ANSI X3-159 (C) and ANSI/IEEE 1003.1 >(POSIX operating system interface) are rather light on >internationalization-related content. This lightness is likely to be >redressed in two forthcoming standards, the X3J16 C++ work, and the >POSIX 1003.2 standard (shell and utilities): the internationalization >lobby was able to get at these projects sufficiently early in their >development to ensure that internationalization issues are considered at >every turn. Well, most turns. Well, a good proportion of turns. It is >also the case that the 1990 version of 1003.1 (which is the same thing >as ISO 9945-1:1990) says a bit more about internationalization than the >1988 edition, and that the next edition of the C standard will also pay >more attention to the issue, thanks to much work by Japan and Nordic >countries, among others. (Sadly, ISO 9899:1990, the first edition of the >international standard for C, has the same technical content as ANSI >X3-159.) I take strong exception to what Dominic has posted on this issue. In fact, approval of the final C standard for ratification was delayed for quite a long time due to the additional work by X3J11 necessary to accommodate legitimate concerns for "internationalization" issues. Coordination with various internationalization working groups was part of this process. So far as I am aware, the C standard was the first major programming language standard to specifically address these issues. It is not "sad", but rather encouraging, that ISO 9899 adopted the internationalization mechanisms (wide character and localization) that had been jointly worked out for ANS X3.159. It was recognized that these mechanisms form the basis for extensions to better address specific international localization concerns, and that it was neither necessary nor desirable for X3.159 to attempt to further address these. It is appropriate for WG14, however, and indeed work is in progress to prepare normative addenda to ISO 9899 that may further address these issues. Note that the input from "Japan and Nordic countries" started with participation in the preparation of the joint ANSI/ISO C standard, contrary to the impression that one might get from Dominic's posting that this input was missing during preparation of ANS X3.159-1989 and IS 9899:1990. I know that as an X3J11 member I personally spent a SIGNIFICANT amount of my time working on these issues. Any implication that they were slighted therefore really annoys me. >but what Norweigian company would want to spend money on the creation >of an American standard? X3.159 is certainly more than "an American standard", as is demonstrated by the adoption of its technical content unchanged as the international standard. It was generally considered by the X3J11 membership that we were working toward a SINGLE technical specification for C for EVERYONE. There was active participation in X3J11 by many individuals from non- American institutions, and during the public reviews of drafts of the proposed standard we received considerable commentary from many nations. P.S. I am not speaking on behalf of X3J11 or ANSI here, although I tend to think they would agree with me on this.
domo@tsa.co.uk (Dominic Dunlop) (02/20/91)
In article <15241@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: > I take strong exception to what Dominic has posted on this issue. Oh dear. This seems to be one of those threads where everybody upsets everybody else, whether intentionally or not. And I certainly wouldn't want to upset Doug. > In fact, approval of the final C standard for ratification was delayed > for quite a long time due to the additional work by X3J11 necessary to > accommodate legitimate concerns for "internationalization" issues. I'm aware of that. > Coordination with various internationalization working groups was part > of this process. So far as I am aware, the C standard was the first > major programming language standard to specifically address these > issues. Right. C, if you like, got ``fingered'' by the international community to be the test-bed for the provision of useful internationalization support in prgramming languages. So all those lucky people working on the standard got to feel their way through a poorly-illuminated and unexplored territory strewn with lumpy obstacles and pitfalls. It's the kind of process which is bound to attract accusations of poor performance after the event from those with the benefit of hindsight. Even if all you get wrong is Norweigian conventions in an example. It's like the single spelling error which makes a certain class of person reject an entire and otherwise useful document. I'm sorry if I appeared to be such a commentator. Apart from anything else, it's embarrasing to be found out in making such a glib criticism! > > >but what Norweigian company would want to spend money on the creation > >of an American standard? > > X3.159 is certainly more than "an American standard", as is demonstrated > by the adoption of its technical content unchanged as the international > standard. It was generally considered by the X3J11 membership that we > were working toward a SINGLE technical specification for C for EVERYONE. > There was active participation in X3J11 by many individuals from non- > American institutions, and during the public reviews of drafts of the > proposed standard we received considerable commentary from many nations. Yes, but. As long as a standardization effort is PERCEIVED as American (perceived, perhaps, by the same type of person as those who are over-sensitive to spelling errors), it is my contention that many non-Americans who could usefully participate will not participate -- hence my point about justifying participation to management. Any standard developed under the auspices of ANSI (or the IEEE, for that matter) appears to be an American standard. Happily for both C and POSIX, a number of interested people and organizations from around the world have been able to see through that preconception, and have made useful contributions -- as, indeed, have many inside the U.S. -- Dominic Dunlop
Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) (02/26/91)
>>>>> On 18 Feb 91 14:28:28 GMT, rex@aussie.COM (Rex Jaeschke) said:
Rex> PJ Plauger, ANSI C secretary and ISO C convenor, played a significant role
Rex> in our support for internationalization. He is now an independent
Rex> consultant and recently, finished writing a complete portable C runtime
Rex> library (in C, of course). He is licensing this to implementors. This will
Rex> all be documented in his upcoming book from Prentice-Hall and the source
Rex> will be available `at reasonable cost'.
Not fair! What is the name of the book? When is it expected to be
available? When will we know the "reasonable cost" of the source?
If the cost for the source is _really_ reasonable (i.e. inexpensive) I
could see a lot of non-implementors buying it and using it with various
"ANSI compliant" compilers from various vendors to ease porting. It's no
fun when two supposedly compliant compilers yield different behavior.
Getting locales right appears (to me) to be an especially tricky problem.
#include<std/disclaimer.h>
--
Chuck Phillips MS440
NCR Microelectronics chuck.phillips%ftcollins.ncr.com
2001 Danfield Ct.
Ft. Collins, CO. 80525 ...uunet!ncrlnk!ncr-mpd!bach!chuckprex@aussie.COM (Rex Jaeschke) (03/03/91)
> >>>>> On 18 Feb 91 14:28:28 GMT, rex@aussie.COM (Rex Jaeschke) said: > Rex> PJ Plauger, ANSI C secretary and ISO C convenor, played a significant role ... > Not fair! What is the name of the book? When is it expected to be > available? When will we know the "reasonable cost" of the source? > > If the cost for the source is _really_ reasonable (i.e. inexpensive) I > could see a lot of non-implementors buying it and using it with various > "ANSI compliant" compilers from various vendors to ease porting. It's no > fun when two supposedly compliant compilers yield different behavior. > Getting locales right appears (to me) to be an especially tricky problem. While I've known for quite a while he was doing a portable library to be made available under license I was not aware until the week of my posting it was going to be documented and made available to the public as such. When I find out I shall try and remember to post the info here. Right now I don't know the answers and I'm just as interested as you are. Rex ---------------------------------------------------------------------------- Rex Jaeschke | Journal of C Language Translation | C Users Journal (703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL rex@aussie.COM | Reston, Virginia 22091, USA | Programmers Journal ---------------------------------------------------------------------------- Convener of the Numerical C Extensions Group (NCEG) X3J11 member and US International Representative to ISO C (WG14) ----------------------------------------------------------------------------