This is the mail archive of the
cygwin@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: Permission denied with makeinfo from texinfo-4.0
- To: cygwin at sourceware dot cygnus dot com
- Subject: Re: Permission denied with makeinfo from texinfo-4.0
- From: "J. David Bryan" <dbryan at bcpl dot net>
- Date: Wed, 15 Mar 2000 00:30:41 -0500
- Organization: Palomar Corporation
- References: <200003150435.XAA12288@mail.bcpl.net>; from dbryan@bcpl.net on Tue, Mar 14, 2000 at 11:35:37PM -0500
On 15 Mar 2000, at 0:08, Chris Faylor wrote:
> Defining -DWIN32 is not usually a good idea. It usually causes packages
> to use windows specific code and workarounds which are not necessary for
> cygwin.
Generally sound advice. However, in this case, -DWIN32 changes the
behavior of only file (files.c) of the makeinfo source. It does two
things:
* It works around the bug mentioned, albeit by reading the source file a
character at a time instead of all in one go.
* It does not use $HOME as a search path for texinfo files.
The intent of my workaround was to avoid the buffer problem in makeinfo
without changing the source. The proper solution, of course, is to fix the
error causing the invalid buffer to be passed to "read".
> Is it possible to provide a little more pinpoint control to get the
> files opened with O_BINARY?
>
> Usually I do something like this:
>
> #ifndef O_BINARY
> #define O_BINARY 0
> #endif
>
> .
> .
> .
> open("foo", O_CREATE|O_TRUNC|O_BINARY);
To avoid the problem, O_BINARY must be undefined, not simply zero.
Undefining it will avoid the invalid buffer (by compiling different code)
at the cost of losing the ability to process texinfo files containing
Windows line ends.
For anyone interested, the problem lines are in makeinfo/files.c, lines 167-
185.
-- Dave Bryan
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com