From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7a11feaaac0ff47b146e04dba05a7244@proxima.alt.za> To: 9fans@cse.psu.edu Subject: Re: [9fans] GNU Make Date: Thu, 3 Jun 2004 07:14:05 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 91034712-eacd-11e9-9e20-41e7f4b1d025 > I have had sam give "/n/netware/a/b/xxx.c cannot open - file locked" > on occasion. File locking is an alien concept to plan9 but I still > get the correct and informative error from the imported netware filesystem. Maybe I'm harping, feel free to tell me. However, the utility that reports an error merely passes to the caller a pointer to a character string. That very pointer could be used as a message identifier if used in such fashion. So why not return an index? So you may need a lookup function that traps accesses beyond the table boundaries and reports them as erroneous together with, if possible, the source and location of the problem. How hard is that going to be? As for the efficiencies involved, it is not only performance that's involved, it's also scalability: use a slightly different format for your error message (a tab turned to a space) and the mapping fails. Not that I know the answer, I'm just stirring the pond, hoping some new ideas pop up. ++L