From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Faylor To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: DOS/Windows-specific code: source.c Date: Tue, 08 May 2001 12:33:00 -0000 Message-id: <20010508153123.B26261@redhat.com> References: <20010503211502.21716.qmail@web6401.mail.yahoo.com> <3AF1DAA0.3060702@cygnus.com> <200105071609.TAA24129@is.elta.co.il> <200105081149.OAA06252@is.elta.co.il> <20010508141246.A25705@redhat.com> <3995-Tue08May2001222604+0300-eliz@is.elta.co.il> X-SW-Source: 2001-05/msg00151.html On Tue, May 08, 2001 at 10:26:05PM +0300, Eli Zaretskii wrote: >> Date: Tue, 8 May 2001 14:12:46 -0400 >> From: Christopher Faylor >> >> On Tue, May 08, 2001 at 02:49:19PM +0300, Eli Zaretskii wrote: >> > >> > * source.c:openp() >> > >> > #ifdef _WIN32 >> > mode |= O_BINARY; >> > #endif >> > >> >I think this is obsolete and should be removed: defining >> >CRLF_SOURCE_FILES in xm-whatever should solve the underlying problem. >> > >> >For those who don't know: the problem here is that find_source_lines >> >creates a table which records the byte position of each line in a >> >source file, but many DOS/Windows libraries don't DTRT with byte >> >offsets unless the file is open in binary mode. So this issue is >> >limited to source files, and CRLF_SOURCE_FILES should provide the >> >solution there for Windows systems. >> > >> >(Code which wants to open binary files, like in exec.c, already uses >> >O_BINARY when it calls openp. Hmm, perhaps solib.c should be fixed to >> >use O_BINARY when it looks for the libraries.) >> >> Actually, why not always just use O_BINARY in this file without the >> conditional and remove the use of O_BINARY everywhere else? > >Because it's wrong to read source files in binary mode. Not necessarily. If you are storing CTRL-Zs in the source file, it might make sense on MS-DOS and Windows. cgf