X-Authentication-Warning: new-smtp2.ihug.com.au: Host p234-tnt6.syd.ihug.com.au [203.173.146.234] claimed to be acceleron Message-ID: <00bc01c12ddd$cd6c8c70$0a02a8c0@acceleron> From: "Andrew Cottrell" To: "Charles Sandmann" , Cc: References: <10108251652 DOT AA17486 AT clio DOT rice DOT edu> Subject: Re: Read 3F00 STDIN problem on Win 2K ( was Re: Fseek on STDIN problem on Win 2K) Date: Sun, 26 Aug 2001 13:18:38 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Reply-To: djgpp-workers AT delorie DOT com Could someone please correct me on redirection and pipes as my understandign is a little lacking in that I do not see how we change the way they are used from an application of my understanding of these is correct. The following is my understanding and it appears to be eiher wrong or missing something: a) redirection uses "<" and ">" b) redirection can be either input or output c) Pipes uses "|" d) Pipes are only output from prog1 to prog2, eg prog1 | prog2 e) Redirection and pipes are a function of the shell used ----- Original Message ----- From: "Charles Sandmann" To: Cc: ; Sent: Sunday, August 26, 2001 2:52 AM Subject: Re: Read 3F00 STDIN problem on Win 2K ( was Re: Fseek on STDIN problem on Win 2K) > > > 3) This problem is masked on 2.03 due to call sequences which are different > > > (when using fstat, no one calls the get magic manually). > > > > ??? What do you mean by that? fstat _always_ tries to get the magic > > number if the handle refers to a file (not a character device). > > If you call get_magic under 2.03 you can see the problem, but if you > call fstat() - which calls get_magic, you don't. So some sequence of > additional calls on the handle under 2.03 makes the problem go away. > More testing to find out why. What if we find some other interrupt > called before _get_magic on the same handle prevents the problem? That > would be a much better fix than slowing down each an every _read. See my other email about a refined example. > > > 4) This problem is masked on 2.04 if lfn=n due to call sequence differences > > > (when using fstat). > > > > And just to be sure we are talking about the same issue: by ``this > > problem'' do you mean the weird behvaior of read and lseek wrt file > > position? Or is there anything else? > > The problem specifically is Andrew's original test problem using fstat() > on stdin and that causing subsequent calls to read to have missed the > first 2 characters in the file. This is why it has taken me so long to figure out that the 3F00 call is the root problem. > > > What I think, but must be confirmed: > > > 1) This problem is only seen on handle 0 when opened by NT, not Bash > > > > I think you saw similar problems on handle 1. The current hypothesis > > is that any handle opened by the NT shell will behave like that, which > > means handles 0-4 could potentially be affected. > > I saw other problems on handle 1 - since reads failed completely on handle > 1 there were not any missing data or offset problems. But getting the > current position did return bogus values on appended files. This could > eventually cause us to destroy all data in an appended handle by writing > to the start instead of appending. > > > Sounds like a good plan to me. But if an extra seek solves the > > problem, why not try use it? We could make it part of this testing as > > well, to see whether it indeed solves the problems. > > _read() is one of the most heavily used calls in the library. For all > DOS 5 systems we will be adding an extra interrupt to get true dos > version. For all NT systems we will be adding two new interrupts for > every read, the get dos version and a seek. And this may be for > a very specific problem that we don't even fix completely! I have patched the LIBC I am using so that I can get patch working on Win2K. I updated the pat253b.zip file on the unofficial DJGPP Win 2K web site so people can download a functioning patch for Win 2K. I have not updated LIBC as the exact change is still not decided and will change. > > if we patch _read(), I would want a static variable for true_dos_version > set up, and to only do this for handle 0. If we are doing this, let's > also have get magic call _read instead so we don't have the patch multiple > places. I think that we do need to introduce a varable or a set of variables that holds the true OS info at some stage. The real issue here is do we do it now or later? When it is done then someone needs to go through the code and cleaup all of the exisitng tests to use the new variable(s). I would rather get the exisitng code working and then we can let more people test it while it is being cleaned up and optimized, this does not mean that we cannot add the variables now and start using them. I have done similar cleanup work previously and it is time consuming and as such would be best left until we get into the testing phase. My vote is that we add a variable or set of variables now and start using them on any mods from now on and then go back later and perfrom a cleanup. > > > A similar problem is seen when redirecting from NUL for example - this is > > > shown as a regular file. We shouldn't be seeking on NUL, or reading > > > magic numbers, but we do today. > > > > We seek on NUL because we don't know it's a character device. > > Exactly. I think we should fix the root problem of the strange redirected > handles instead of adding new interrupt calls to routines which will > slow everything down. > > What about having _get_dev_info be smart about these? If this works then it would eleviate the other patches and not slow down any library calls, except the _get_dev_info call.. What about the case where _get_dev_info is not called before a call to 3F00 was done on STDIN? In this case would it be better to think about having the change (if it can be done) in crt1.c so it gets done before the application starts?