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: (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".