martin@mwtech.UUCP (Martin Weitzel) (11/23/89)
Following the discussion up to this point, I don't want to continue, but I whished the committee had left out the C-stdlib completly on the first run and later defined this item in several subsets, to which the C-implementations could seperatly conform (or not). There are so many more things than directory handling, for which I would like to see a 'standard' way. Eg for me as applications-programmer the first on the list is 'curses' for a mathematican it might be vector- and matrix-operations, a.s.o. Furthermore, at least for us europeans the approach on international character sets is a real *big* issue, but it's a pitty, that it has retarded the final standard. I feel, because C is an *extendable* language on behalf of its concept of seperate translation, there should not be so much discussion about the contents of the stdlib. The only thing which which is important are the rules for 'reserved names' that I may not use in my own libraries.
gwyn@smoke.BRL.MIL (Doug Gwyn) (11/25/89)
In article <481@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >Following the discussion up to this point, I don't want to continue, >but I whished the committee had left out the C-stdlib completly on the >first run and later defined this item in several subsets, to which the >C-implementations could seperatly conform (or not). X3J11 was generally of the sentiment that there was a de facto fuzzy standard for string operations, I/O, etc. and that any really useful C standard would have to include these facilities (at least for the "hosted" environment; "freestanding" excludes almost all of them). I agree with the decision; from my point of view standardizing the library facilities was MORE important than standardizing the raw language.
henry@utzoo.uucp (Henry Spencer) (11/25/89)
In article <481@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >Following the discussion up to this point, I don't want to continue, >but I whished the committee had left out the C-stdlib completly on the >first run and later defined this item in several subsets, to which the >C-implementations could seperatly conform (or not). The trouble is, if you have N optional packages that are part of the standard, then you have 2^N different "standard" languages. COBOL tried this. Looking at the results of that experience was, I believe, one of the things that influenced X3J11 in its decision to avoid that approach and try to produce *one* standard. (Actually they ended up with a standard and a "freestanding" subset, but that's close enough and there were good reasons for it.) For all practical purposes the more basic library functions are part of the language. -- That's not a joke, that's | Henry Spencer at U of Toronto Zoology NASA. -Nick Szabo | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
idall@augean.OZ (Ian Dall) (11/27/89)
In article <11682@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > >X3J11 was generally of the sentiment that there was a de facto fuzzy >standard for string operations, I/O, etc. and that any really useful >C standard would have to include these facilities (at least for the >"hosted" environment; "freestanding" excludes almost all of them). >I agree with the decision; from my point of view standardizing the >library facilities was MORE important than standardizing the raw >language. This sounds reasonable. There is a difference between functions which can be defined entirely internally to the language and functions which define operations on the outside world. "memset", "strcpy" etc are in the former class and I see no reason they should not be in a language spec. "fork" is in the latter set and so are directory operations. That is not to say that standard semantics for directory operations are not useful, but the proper place is an operating system standard (POSIX) not the C language standard. On this rationale one could argue that stdio does not belong in the C standard since the stream of bytes model of a file is not universal, but I suppose leaving it out would make the writing of a portable program impossible. Disclaimer: I don't have access to the standard and my examples of what is or is not in the standard library are based on heresay. -- Ian Dall life (n). A sexually transmitted disease which afflicts some people more severely than others. idall@augean.oz