From: manubee <ma...@wa...> - 2003-10-22 20:22:15
|
Hi Benny, Benjamin Riefenstahl wrote: >Hi, > >"manubee" <ma...@wa...> writes: >> The first <LF> is erroneous. If you edit "file.txt" and turn the >> 15th <LF> into <CRLF>, then it works. Indeed, any <LF> after the >> saved file position, in our case after "The computer scientist" will >> cause an error of one or more chars. > >In other words, you used a non-text file (one that didn't use CRLF for >every line, actually one that wasn't even consistent about it) with a >text file program. Why did you expect that to work? :-/ If I create a diff file with MSYS and send it to someone who would use a MinGW port of patch, he would get the assertion failed message, unless he uses "--binary". >If you have non-text files and want to treat them as text, you need to >invent your own mapping scheme. Lots of generic packages do that, >like e.g. Tcl. The text mode of the C runtime won't help, it is >targeted for regular native text files only. Even if text mode of >Windows compilers/runtimes mostly works for reading Unix text files, >that is just coincidence as far as it goes. Agreed. The danger is when you think that your file have CR/LF and that it is not true. >Of course, feel free to implement an alternative. This is a case of >undefined behaviour, so it can be used for usefull extensions. I'm just curious to know if a solution exists. Otherwise, I would tend to think that the default mode in GNU patch should be binary. Manu. |
From: manubee <ma...@wa...> - 2003-10-23 20:34:00
Attachments:
testcase2.zip
|
Hi Earnie, Earnie Boyd wrote: >Obviously, the problem is the \r\n combination. The solution, open the >files in binary mode and take care of the trailing \r yourself. Let's play with a "real-life" test case this time. _ALL_TEXT_FILES_ contains only \r\n. From me, under MSYS: unknown@PAVILION /c/Dev/Visual-MinGW/Projects/patch/testcase2 $ diff -rup the-chaos-orig the-chaos-new > the-chaos.diff I send that file to a friend who will use "mingw32-patch". Then in his DOS box: C:\Dev\Visual-MinGW\Projects\patch\test2>mingw32-patch -dthe-chaos-orig -i.. /the -chaos.diff --dry-run patching file file1.txt Assertion failed: hunk, file patch.c, line 340 abnormal program termination Why? Open "the-chaos.diff", you'll see that it contains both CRLF and LF. :) Convinced Earnie? Manu. I wrote: -----Message d'origine----- De : manubee <ma...@wa...> À : min...@li... <min...@li...> Cc : st...@ca... <st...@ca...> Date : mercredi 22 octobre 2003 22:32 Objet : Re: [Mingw-users] safe ftell/fseek in text mode? [...] >If I create a diff file with MSYS and send it to someone who would >use a MinGW port of patch, he would get the assertion failed message, >unless he uses "--binary". |
From: Earnie B. <ea...@us...> - 2003-10-24 05:46:32
|
manubee wrote: > Hi Earnie, -8<- >>From me, under MSYS: > unknown@PAVILION /c/Dev/Visual-MinGW/Projects/patch/testcase2 > $ diff -rup the-chaos-orig the-chaos-new > the-chaos.diff > > I send that file to a friend who will use "mingw32-patch". > > Then in his DOS box: > C:\Dev\Visual-MinGW\Projects\patch\test2>mingw32-patch -dthe-chaos-orig -i.. > /the > -chaos.diff --dry-run > patching file file1.txt > Assertion failed: hunk, file patch.c, line 340 > > abnormal program termination > > Why? > > Open "the-chaos.diff", you'll see that it contains both CRLF and LF. > > :) Convinced Earnie? > I don't know why your trying to convince me. I well aware of what the problem is. For mingw32-patch to effectively handle, the mix, mingw32-patch needs to open the input files in binary mode, and if \r is trailing on the string read replace it with \0. Then your assertion becomes true. Earnie. -- http://www.mingw.org Powered by SourceForge <http://sourceforge.net/projects/mingw> |
From: Manu <ma...@wa...> - 2003-10-24 20:51:15
|
Earnie Boyd wrote: > > Open "the-chaos.diff", you'll see that it contains both CRLF and LF. > > > > :) Convinced Earnie? > > > > I don't know why your trying to convince me. I well aware of what the > problem is. Ok, I misunderstood. It is fascinating though, I think that if such patch contains only one hunk, it may succeed since no LF exits after the current file position that patch sees. But if there's several hunks, the first will fail because the header of the second hunk is LF terminated. Amusing. > For mingw32-patch to effectively handle, the mix, > mingw32-patch needs to open the input files in binary mode, and if \r is > trailing on the string read replace it with \0. Then your assertion > becomes true. I think that already exits in intuit_diff_type() and in pget_line(): if (strip_trailing_cr && 2 <= i && b[i - 2] == '\r') b[i-- - 2] = '\n'; b[i] = '\0'; return i; AFAICT, strip_trailing_cr is 0. I'll have to find out where strip_trailing_cr is defined, then it should be ok. Manu. |
From: Greg C. <chi...@mi...> - 2003-10-25 00:35:39
|
Manu wrote: > > It is fascinating though, I think that if such patch contains only one hunk, > it may succeed since no LF exits after the current file position that > patch sees. But if there's several hunks, the first will fail because the header > of the second hunk is LF terminated. > Amusing. The manual I have for gnu patch 2.1 (perhaps outdated) says "Since patch does not handle incomplete lines properly, make sure that all the source files in your program end with a newline whenever you release a version." This seems to suggest that patch's behavior would be the opposite of what your testcase shows. Either this explains something that I don't understand, or at least it adds to the amusement. |
From: Benjamin R. <Ben...@ep...> - 2003-10-23 14:09:40
|
Hi Manu, > Benjamin Riefenstahl wrote: >>In other words, you used a non-text file (one that didn't use CRLF >>for every line, actually one that wasn't even consistent about it) >>with a text file program. Why did you expect that to work? :-/ "manubee" <ma...@wa...> writes: > If I create a diff file with MSYS and send it to someone who would > use a MinGW port of patch, he would get the assertion failed > message, unless he uses "--binary". So there is at least one bug somewhere between diff and patch, probably in diff, because it doesn't create text files in the first place. > I'm just curious to know if a solution exists. Borland has the same output from your test case. Of course VC++ also has it, as it is using the same runtime lib. > Otherwise, I would tend to think that the default mode in GNU patch > should be binary. I don't know what the binary mode for patch does, so I can't comment on that. benny |
From: Greg C. <chi...@mi...> - 2003-10-23 17:37:49
|
Benjamin Riefenstahl wrote: > > So there is at least one bug somewhere between diff and patch, > probably in diff, because it doesn't create text files in the first > place. My manual for gnu diff-2.5 (a bit out of date) says | In operating systems that distinguish between text and binary files, | diff normally reads and writes all data as text. Use the `--binary' | option to force diff to read and write binary data instead. so in some sense it creates text files under windows. Is there some other sense in which it doesn't? |
From: Luke D. <cod...@ho...> - 2003-10-24 03:56:25
|
----- Original Message ----- From: "Benjamin Riefenstahl" <Ben...@ep...> To: <min...@li...> Cc: <st...@ca...> Sent: Thursday, October 23, 2003 6:24 PM Subject: [Mingw-users] Re: safe ftell/fseek in text mode? > Hi Manu, > > > > Benjamin Riefenstahl wrote: > >>In other words, you used a non-text file (one that didn't use CRLF > >>for every line, actually one that wasn't even consistent about it) > >>with a text file program. Why did you expect that to work? :-/ > > "manubee" <ma...@wa...> writes: > > If I create a diff file with MSYS and send it to someone who would > > use a MinGW port of patch, he would get the assertion failed > > message, unless he uses "--binary". > > So there is at least one bug somewhere between diff and patch, > probably in diff, because it doesn't create text files in the first > place. No, the problem is the difference between MinGW and MSYS, as Manu implied. MSYS tools deal with binary mode only (except that they sometimes have slight modifications to handle DOS text files), so MSYS diff produces Unix format text files. Luke > > > I'm just curious to know if a solution exists. > > Borland has the same output from your test case. Of course VC++ also > has it, as it is using the same runtime lib. > > > Otherwise, I would tend to think that the default mode in GNU patch > > should be binary. > > I don't know what the binary mode for patch does, so I can't comment > on that. > > > benny |
From: Benjamin R. <Ben...@ep...> - 2003-10-24 17:22:41
|
Hi Luke, >> > Benjamin Riefenstahl wrote: >> So there is at least one bug somewhere between diff and patch, >> probably in diff [...] "Luke Dunstan" <cod...@ho...> writes: > No, the problem is the difference between MinGW and MSYS, as Manu implied. > MSYS tools deal with binary mode only Ah, I forgot about that. Anyway where is the contradiction here? :-/ [Hint: *I* think that "tools [that] deal with binary mode only" on Windows are broken by design. But that may be just me.] benny |
From: Earnie B. <ea...@us...> - 2003-10-25 00:26:53
|
Benjamin Riefenstahl wrote: > Hi Luke, > > > >>>>Benjamin Riefenstahl wrote: >>> >>>So there is at least one bug somewhere between diff and patch, >>>probably in diff [...] > > > "Luke Dunstan" <cod...@ho...> writes: > >>No, the problem is the difference between MinGW and MSYS, as Manu implied. >>MSYS tools deal with binary mode only > > > Ah, I forgot about that. Anyway where is the contradiction here? :-/ > > [Hint: *I* think that "tools [that] deal with binary mode only" on > Windows are broken by design. But that may be just me.] > So I suppose the infamous Notepad is broken then? The files it opens are opened in binary mode, reads a stream of data and gets all funky because there is no \r to move it to the beginning of the line. At least MSYS tries to deal with the \r, \r\n and \n possibilities so that you don't complain about it. Earnie. -- http://www.mingw.org Powered by SourceForge <http://sourceforge.net/projects/mingw> |
From: Benjamin R. <Ben...@ep...> - 2003-10-25 14:17:04
|
Hi Earnie, > Benjamin Riefenstahl wrote: >> [Hint: *I* think that "tools [that] deal with binary mode only" >> on Windows are broken by design. But that may be just me.] Earnie Boyd <ea...@us...> writes: > So I suppose the infamous Notepad is broken then? ;-) Nice idea, to put it that way ... > The files it opens are opened in binary mode, reads a stream of data > and gets all funky because there is no \r to move it to the > beginning of the line. AFAIK Notepad reads the files in binary mode (because Notepad probably doesn't use the C RTL in the first place), and than it passes the data to a text widget that only understands native text mode. This means that it doesn't profit from the usual coincidence that C programs reading through C RTL text mode on Windows read Unix text files ok. Notepad is not broken, it's just too simple and limited for a cross-platform editor. But of course it is not meant to be a cross-platform editor. Lots of editors on all platforms are too simple and limited for a cross-platform editor. "Luke Dunstan" <cod...@ho...> writes: > No, the problem is the difference between MinGW and MSYS, as Manu > implied. MSYS tools deal with binary mode only Earnie Boyd <ea...@us...> writes: > At least MSYS tries to deal with the \r, \r\n and \n possibilities > so that you don't complain about it. ? Which is it, only one of you two can be right. Or I am misunderstanding something, wouldn't be the first time :-\. benny |
From: Earnie B. <ea...@us...> - 2003-10-25 21:39:50
|
Benjamin Riefenstahl wrote: > > "Luke Dunstan" <cod...@ho...> writes: > >>No, the problem is the difference between MinGW and MSYS, as Manu >>implied. MSYS tools deal with binary mode only > > > Earnie Boyd <ea...@us...> writes: > >>At least MSYS tries to deal with the \r, \r\n and \n possibilities >>so that you don't complain about it. > > > ? Which is it, only one of you two can be right. Or I am > misunderstanding something, wouldn't be the first time :-\. > The runtime dll, msys-1.0.dll, enforces all opens to be in binary mode regardless of user desire for tools dependent on the msys-1.0.dll runtime. The tools (e.g. sh, sed, etc) have been modified to take into consideration the dangling \r on the line and will remove it so that it's not it the way. Earnie -- http://www.mingw.org Powered by SourceForge <http://sourceforge.net/projects/mingw> |
From: Luke D. <cod...@ho...> - 2003-10-26 05:46:53
|
----- Original Message ----- From: "Earnie Boyd" <ea...@us...> To: <min...@li...> Sent: Sunday, October 26, 2003 5:32 AM Subject: Re: [Mingw-users] Re: safe ftell/fseek in text mode? > Benjamin Riefenstahl wrote: > > > > "Luke Dunstan" <cod...@ho...> writes: > > > >>No, the problem is the difference between MinGW and MSYS, as Manu > >>implied. MSYS tools deal with binary mode only > > > > > > Earnie Boyd <ea...@us...> writes: > > > >>At least MSYS tries to deal with the \r, \r\n and \n possibilities > >>so that you don't complain about it. > > > > > > ? Which is it, only one of you two can be right. Or I am > > misunderstanding something, wouldn't be the first time :-\. > > > > The runtime dll, msys-1.0.dll, enforces all opens to be in binary mode > regardless of user desire for tools dependent on the msys-1.0.dll > runtime. The tools (e.g. sh, sed, etc) have been modified to take into > consideration the dangling \r on the line and will remove it so that > it's not it the way. > > Earnie Perhaps MSYS diff should discard carriage return characters so that its output will be entirely in Unix text format even if the input is in DOS format? Luke |
From: Earnie B. <ea...@us...> - 2003-10-26 14:22:44
|
Luke Dunstan wrote: > > Perhaps MSYS diff should discard carriage return characters so that its > output will be entirely in Unix text format even if the input is in DOS > format? > I agree, care to work the patch for diff? Earnie -- http://www.mingw.org Powered by SourceForge <http://sourceforge.net/projects/mingw> |
From: Manu <ma...@wa...> - 2003-10-26 15:13:41
|
Earnie Boyd wrote: > Luke Dunstan wrote: > > > > Perhaps MSYS diff should discard carriage return characters so that its > > output will be entirely in Unix text format even if the input is in DOS > > format? > > > > I agree, care to work the patch for diff? MSYS' diff works as expected isn't it? There will be still a bug in M$' ftell. Then, other Unix packages may encounter the same troubles. Do you know that the implementation from DJGPP and Wine works fine in text mode? cf: "More ftell hacking" and the_chaos_4 test. Manu. |
From: Earnie B. <ea...@us...> - 2003-10-23 18:10:04
|
Obviously, the problem is the \r\n combination. The solution, open the files in binary mode and take care of the trailing \r yourself. Earnie. manubee wrote: > Hi Benny, > > Benjamin Riefenstahl wrote: > >>Hi, >> >>"manubee" <ma...@wa...> writes: >> >>>The first <LF> is erroneous. If you edit "file.txt" and turn the >>>15th <LF> into <CRLF>, then it works. Indeed, any <LF> after the >>>saved file position, in our case after "The computer scientist" will >>>cause an error of one or more chars. >> >>In other words, you used a non-text file (one that didn't use CRLF for >>every line, actually one that wasn't even consistent about it) with a >>text file program. Why did you expect that to work? :-/ > > > If I create a diff file with MSYS and send it to someone who would > use a MinGW port of patch, he would get the assertion failed message, > unless he uses "--binary". > > >>If you have non-text files and want to treat them as text, you need to >>invent your own mapping scheme. Lots of generic packages do that, >>like e.g. Tcl. The text mode of the C runtime won't help, it is >>targeted for regular native text files only. Even if text mode of >>Windows compilers/runtimes mostly works for reading Unix text files, >>that is just coincidence as far as it goes. > > > Agreed. The danger is when you think that your file have CR/LF and that > it is not true. > > >>Of course, feel free to implement an alternative. This is a case of >>undefined behaviour, so it can be used for usefull extensions. > > > I'm just curious to know if a solution exists. Otherwise, I would tend > to think that the default mode in GNU patch should be binary. > > Manu. > > > > > ------------------------------------------------------- > This SF.net email is sponsored by OSDN developer relations > Here's your chance to show off your extensive product knowledge > We want to know what you know. Tell us and you have a chance to win $100 > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > -- http://www.mingw.org Powered by SourceForge <http://sourceforge.net/projects/mingw> |