rbutterworth@watmath.waterloo.edu (Ray Butterworth) (01/26/89)
In article <877@auspex.UUCP>, guy@auspex.UUCP (Guy Harris) writes: > > Does _flsbuf need to be rewritten to call __write() or > >something similar > Yes. > >where __write is implemented as: > No. What I think AT&T plans to do for S5R4, for example, is to *rename* > the "write" routine "_write", and have a mechanism by which the linker > will let "_write" satisfy unresolved references for "write" (or > something like that); this means programs that call "write" and expect > it to be the "write" in the system library will not have to be changed - > but neither will programs that have their own private "write". It seems to me that every implementor of a library other than the Standard C library is going to need a means of having alternate names for its functions (unless none of them call each other). If not, it means that for anyone using part of a large library all the identifiers in the library become reserved words that he must be aware of. Thus, unless one wants to have library source that look like: write(args) { return __write(args); } __write(args) { implementation of normal write function } and have all user calls carry double the calling overhead, every compiler writer is going to have to come up with a mechanism for doing this aliasing. And every library implementor (unless he also controls the compiler) is going to be out of luck. At least I, as a library implementor, don't know of any nice way of doing this without making changes to the compiler. I don't understand why the C Standard didn't require, or at least suggest, some such standard mechanism. e.g. write(args) entry __write { c_blah c_blah } i.e. the resulting assembly code should look something like: write: __write: a_blah a_blah
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/27/89)
In article <23254@watmath.waterloo.edu> rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes: >It seems to me that every implementor of a library other than >the Standard C library is going to need a means of having >alternate names for its functions (unless none of them call >each other). I disagree with this. Generally, one takes a library (for example, a "graphics library") as a package, and assumes that everything defined in the manual for it is reserved if the library is used at all. In effect, ANSI C does this for the standard C library in a hosted implementation; although there can be extra stuff in there, in effect it has to be isolated into what amounts to a different package from the standard C routines. C could obviously use some formal notion of packages, and extensions such as C++ do provide this. Meanwhile, providers of C support packages of all kinds are well advised to use some sort of package prefix naming scheme such as recently discussed in comp.lang.c, so that various packages can be used together without interference. >I don't understand why the C Standard didn't require, or at least >suggest, some such standard mechanism. Because such implementor-provided libraries are outside the scope of the Standard. The C Standard itself requires, it does not suggest; and there is no way for it to impose requirements on things unrelated to the specifications in the Standard. There would be no way that such a constraint could be verified, for example, as part of product acceptance testing against procurement specifications. That doesn't mean that most or all of X3J11 wouldn't agree that it is desirable for "add-on" packages to do something to keep their own name spaces in order.
diamond@csl.sony.JUNET (Norman Diamond) (01/27/89)
In article <877@auspex.UUCP>, guy@auspex.UUCP (Guy Harris) writes: > > What I think AT&T plans to do for S5R4, for example, is to *rename* > > the "write" routine "_write", and have a mechanism by which the > > linker will let "_write" satisfy unresolved references for "write" > > (or something like that); In article <23254@watmath.waterloo.edu>, rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes: > It seems to me that every implementor of a library other than > the Standard C library is going to need a means of having > alternate names for its functions (unless none of them call > each other). If not, it means that for anyone using part of > a large library all the identifiers in the library become > reserved words that he must be aware of. > > Thus, unless one wants to have library source that look like: > write(args) { return __write(args); } > __write(args) { implementation of normal write function } #if defined (mylib_requested) || defined (__mylib_requested) #define mylib_reserved_name __mylib_reserved_name #endif __mylib_reserved_name(args) { ... } [ #ifdef inews_sucks ] [ filler line ] [ filler line ] [ filler line ] [ filler line ] -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-inventing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
bryan@quame.UUCP (Bryan A. Woodruff) (09/09/89)
Here is a question directed towards those involved with ANSI C. I have noticed a certain amount of care taken towards the "portability" aspect of C... When C was designed, was it not the idea to have a completely portable language from system to system? Do not all systems have a tree directory or some other directory structure? Why then are there not portable functions for accessing the directories? I want to write a module that has the ability to access a directory (read, create, cd, etc...) without having to worry about the operating system (i.e. MS-DOS, UNIX, (flavors), XENIX, etc) When is C going to be completely portable, without having to worry about #IFDEF's???? Bryan Woodruff, Product Manager/Senior Programmer Quality America, Inc. (uunet!quame!bryan)
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/09/89)
In article <116@quame.UUCP> bryan@quame.UUCP (Bryan A. Woodruff) writes: >I have noticed a certain amount of care taken towards the "portability" >aspect of C... When C was designed, was it not the idea to have a completely >portable language from system to system? No, C was designed as a system implementation language for UNIX on one particular machine (PDP-11). Its designer was sufficiently careful in specifying an abstract language that it turned out to be implementable on a wide range of other architectures, although some nagging inconsistencies were not resolved until the ANSI standardization process. Many programmers discovered that it was not only possible to write extremely architecture-specific applications such as OS device drivers in C, but it was actually possible with a modest amount of care to write C applications that were highly portable across different operating systems and machine architectures. The "standard I/O library" contributed substantially to this. Portability of applications is important, but it is not everything. >Do not all systems have a tree directory or some other directory >structure? No. >Why then are there not portable functions for accessing the >directories? There are, for limited classes of operating systems (e.g., POSIX specifies one such set, a public-domain UNIX version of which I maintain and send out on request). >I want to write a module that has the ability to access a directory >(read, create, cd, etc...) without having to worry about the >operating system (i.e. MS-DOS, UNIX, (flavors), XENIX, etc) The POSIX interface, augmented by mkdir(), rmdir(), etc. would be a good starting place. Unfortunately, some OSes don't fully support all these operations. (Some don't support any of them.) >When is C going to be completely portable, without having to worry about >#IFDEF's???? When are all operating systems going to act identically? By the way, it's not necessary to sprinkle #ifdefs liberally through your code. You should try to isolate system dependencies in separately compiled plug-replaceable modules, so the main application code does the same thing in all environments, calling on support functions that themselves are tailored to the specific environment.
chris@mimsy.UUCP (Chris Torek) (09/09/89)
In article <116@quame.UUCP> bryan@quame.UUCP (Bryan A. Woodruff) writes: >... When C was designed, was it not the idea to have a completely >portable language from system to system? No, actually, the idea was to rewrite the Unix system, which until then had been written largely in assembly, in a higher level language so that Ken Thompson could get back to working on his chess game. :-) >Do not all systems have a tree directory or some other directory structure? Nope. Take a look at a TRS-80 model I with 48 kB and a cassette recorder. There exist C compilers that would fit on this machine. It has no directories. >Why then are there not portable functions for accessing the directories? You have just answered your own question. More seriously, directories on some systems (the Univac comes to mind, as does IBM's CMS) are very weird entities with so many special cases that a general `directory access' or `file tree walk' (such as readdir() and scandir() and, in 4.4BSD, ftw()) would be largely useless anyway. >When is C going to be completely portable, without having to worry about >#IFDEF's???? Never. No language is completely portable (just try running *ANYTHING* on a FooBletch Mark 6-and-a-half :-) ). In particular, language standards are not good places to hide operating system standards. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gisle@ifi.uio.no (Gisle Hannemyr) (09/10/89)
bryan@quame.UUCP (Bryan A. Woodruff) wrote:
> Do not all systems have a tree directory or some other directory structure?
No, they do no.
Embedded systems do not even have a file system, and some
operating systems (e.g. CMS, SINTRAN-III) have a sufficiently weird file
system to make directory operations targeted towards the UNIX, MS-DOS,
OS/2, VMS directory paradigms more or less useless.
There is a standard that do what you want. IEEE POSIX 1003.1 is an
_operating system_ interface standard, and defines how C should interface
to the operating system, including the interface to the directory.
To put the specification of that interface in the _language_ standard
would severely limit the scope of the language.
- gisle hannemyr (Norwegian Computing Center)
EAN: gisle@nr.uninett
Inet: gisle@ifi.uio.no
UUCP: ...!mcvax!ifi!gisle
------------------------------------------------usenet@cps3xx.UUCP (Usenet file owner) (09/12/89)
In article <116@quame.UUCP> bryan@quame.UUCP (Bryan A. Woodruff) writes: >Here is a question directed towards those involved with ANSI C. > >I have noticed a certain amount of care taken towards the "portability" >aspect of C... When C was designed, was it not the idea to have a completely >portable language from system to system? Do not all systems have a tree >directory or some other directory structure? Why then are there not No. Try IBM's CMS. There are no notions of subdirectories there. CMS's filenames are "8char 8char 2char?" the last being a minidisk name (a virtual disk which is a fixed partition of a real disk). Other OSs allow large filenames, but still no real subdirs. Even if you could depend on a directory tree, there may be limits to its size, and how you go between levels of the tree is different. In unix, you use . .. and / In messydos use . .. and \ On vaxen it works something like [-] for parent, and then [subdir.subdir2]file.ext;revision Vaxen have troubles with directories deeper than 8. On amigas use <null string> for current dir, / for parent, : for root What about devices that are in the filespace? What about wild cards? They work differently on all of the above implementations. These are problems that would be hard to deal with in a general fashion. REAL NAME: Joe Porkka jap@frith.cl.msu.edu