From:	wdoyle AT bode DOT cdsp DOT neu DOT edu (Patrick Doyle)
Subject:	Re: patch - strange behaviour
8 Aug 1997 06:55:31 -0700 :
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<199708081319.JAA02801.cygnus.gnu-win32@cdsp.neu.edu>
Original-To:	wbach AT iicm DOT tu-graz DOT ac DOT at
Original-Cc:	gnu-win32 AT cygnus DOT com
In-Reply-To:	<v02130500b00fc1f21707@[193.83.160.71]>
	(wbach AT iicm DOT tu-graz DOT ac DOT at)
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

   I've tried to apply Mumit Khan's patches to b18 and experienced very strage
   behaviour of patch:

   patch aborts a after some patches, typically a few files, with the message
   "Assertion hunk failed ..." (don't remember exact wording).

   If I split the patch file into seven parts, I can apply the separate patch
   files without problems. I can live with that, but it's inconvenient.

   Has anyone got an idea what's going on?

Yes, "patch" reads its patch file in TEXT mode (rather than BINARY
mode) and occasionally caches a location in the file by performing an
'ftell()' type of operation.  It expects to be able to perform an
'fseek()' to get back to that location in the file, but this doesn't
work for text files (where CR's are silently eaten).  I worked around
it the brute force way by replacing calls to 'fseek()' with calls to
'my_brute_force_fseek()', which looped until 'ftell()' returned the
desired position, reading and discarding one character at a time along
the way.  This is basically what I recall doing... I can send you a
patch (ha ha) if you would like.

-- 
--patrick


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -