From Keith.Bierman@Eng.Sun.COM Thu Feb 1 03:20:49 1996 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id DAA03612 for ; Thu, 1 Feb 1996 03:20:46 +0100 From: Keith.Bierman@Eng.Sun.COM Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id SAA20294; Wed, 31 Jan 1996 18:19:50 -0800 Received: from chiba.eng.sun.com by Eng.Sun.COM (5.x/SMI-5.3) id AA15402; Wed, 31 Jan 1996 18:19:48 -0800 Received: from localhost by chiba.eng.sun.com (4.1/SMI-4.1) id AA16941; Wed, 31 Jan 96 18:19:46 PST Message-Id: <9602010219.AA16941@chiba.eng.sun.com> To: Craig Dedo Cc: "Jerrold L. Wagener" , WG5 Mailing List Subject: Re: (SC22WG5.1021) (x3j3.1996-41) Re: fodder for meeting In-Reply-To: Your message of "Tue, 30 Jan 96 20:00:48 CST." <199602010040.BAA02017@dkuug.dk> Date: Wed, 31 Jan 96 18:19:45 PST > Too bad this did not get the attention it deserved at the time. > Unfortunately, I do not remember any such message. Arguably it did. Where could we have found time for extensive coco discussions otherwise? ;> The committee choses which problems to solve; there are far more than can be solved in the time alloted ;> > I may be wrong on this (Stan Whitlock or Steve Lionel can correct >... >thru regular RMS file calls and therefore supports all of the >(elaborate and complex) RMS file structure. The OpenVMS RMS file ... Questions of formatting beyond 80columns aside, the point of this escapes me. RMS is a fine file system. However it has nothing to do with the C standard. That some implementation can "get it right" isn't really the question. It can be done. It has been done. It will be done. > If this is true, we should fix the problem ASAP. The purpose of >ANY programming language is to support the developoment of practical There are many practical applications which are not easily coded in Fortran. That doesn't mean that we have to add the functionality of LISP, Sybase and multimedia authoring systems. All address useful and practical problem domains. Large files are important, but that aren't worth tossing aside the state of the standard for. And, as previously mentioned, there is nothing to stop implementations from getting it right. The problem is that there is nothing in the Standard to force it, and many solutions may be non-portable. How many users have applications which deal with such large files? How many of the people with such problems mind a bit of non-portability (which they have in spades anyway?). The one data point provided, AMOCO, wasn't upset. Why are you? Do you own a system which could deal with such a large file? Have you ever worked on such a project? Until now did you realize such applications existed? (I can probably answer yes to all three, for some version of "yes") Creating a new process is absurd. We have corrigenda. We have balloting. If this really were a fatal problem, we'd make it a country position to fix it, and delay f95. It isn't that bad. Getting a new formal process started would take longer than the delay would entail. Getting yet another informal process would accomplish ????