Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.26/text0005.txt

Text File | 1992-02-21 | 1.8 KB | 38 lines

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Jason Zions) writes:
>The only thing which is perhaps atrocious about "c89" is the name itself. It
>had to be different from "cc"; what would you have chosen?

That's NOT a "given".  It is wrong to think that a UNIX standard would
have to speciay EVERYBODY's options to a standard "cc".  Rather, all
that would be needed in a software portability standard would be the
stuff that virtually every UNIX implementation agrees upon:

    cc -Dmacrostufff -Iheaderdir -c -O foo.c bar.o mylib.a -lX

The requirement that this invocation (when -I etc. aren't being used)
obtain a C implementation that conforms to the C standard could be left
as a separate specification, not necessarily required for 1003.2 proper.

>More than that, regexp's as usually implemented were hopelessly
>ethnocentric; changing languages was impossible.

No, to the contrary the existing regexp implementation was acultural;
you're referring to the idea that "[a-z]" for example ought to mean
"match any lowercase character in the current locale", but that is
NOT what it meant.  It actually meant "match any byte having value
between the values I gave you around the dash-representation" (this
already was important to understand on machines that preferred
EBCDIC codesets, for example).  You should keep in mind that you as
a user are inputting BITS into these patterns, some bytes of which
have special interpretation ([, ^, -, etc.) and others taken
literally as standing for their values.  The ethocentricity was
introduced by 1003.2, presumably because people thought it would be
"nice" to be able to specify locale-dependent character classes; it
did not inhere in the previous regexp mechanism.


Volume-Number: Volume 26, Number 6