Path: utzoo!attcan!uunet!lll-winken!ncis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!sun!thetone!swilson
From: swilson%thetone@Sun.COM (Scott Wilson)
Newsgroups: comp.lang.c
Subject: Re: portability
Message-ID: <86097@sun.uucp>
Date: 19 Jan 89 19:28:35 GMT
References: <16573@iuvax.cs.indiana.edu> <9419@smoke.BRL.MIL>
Sender: news@sun.uucp
Reply-To: swilson@sun.UUCP (Scott Wilson)
Organization: Sun Microsystems, Mountain View
Lines: 30

In article <9419@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>One hopes that MicroSoft will provide alternative names within the
>name space reserved for implementations (e.g. "__pascal") for these
>extensions, in which case those names would not need to be disabled

Excuse my ignorance but the radio's turned up too loud.  What happens
to the names of routines used to implement standard library functions?
Don't these pollute the name space?  Are implementations required to
work around this?  For example can a pANS program with a routine
called write() reliably be compiled and run on a UNIX system without
causing printf (really _flsbuf) to call the user's routine and botching
everything?  Does _flsbuf need to be rewritten to call __write() or
something similar where __write is implemented as:

	__write(d, buf, nbytes)
		int d;
		char *buf;
		int nbytes;
	{
		syscall(SYS_write, d, buf, nbytes);
	}

to avoid getting the symbol "write".  Of course, we're left with
syscall polluting the name space.


--
Scott Wilson		arpa: swilson@sun.com
Sun Microsystems	uucp: ...!sun!swilson
Mt. View, CA