From: Thorsten B. <tho...@do...> - 2011-05-20 09:41:44
|
Hi! I'm new to this mailinglist. I've started studying/using Plplot because we want to use Plplot within some of our software and I'll be the one to implement it. I've already installed Plplot (version 5.9.7) together with all necessary tools (CMake, in this case). I was then able to build PLplot and compile the examples. So far, so good. Development of our software currently is in Ada (and will stay in Ada as long as I'm to develop it). The OS used is Windows (in different flavours, currently I'm working on a Windows 7 machine). When running all examples as well as some other test programs of mine, I always get this error on the console that opens when starting a program: ---snip--- *** PLPLOT WARNING *** Unrecognized cmap0 format data line. Line is #000000 ---snap--- Also, the background color is always white, while all drawing (even if explicitly setting a pen color) is done in red. I read this thread ( https://sourceforge.net/mailarchive/message.php?msg_id=24879301 ) but although it seemed to be the same problem, it was not (but may be similar). I also read all the online documentation, but found no format description of the cmap0_default.pal file. I'm sure the file is found and read, because when I edit the file cmap0_default.pal, I can achieve better (and seemingly correct) results. I've added an additional "column" after all the color definitions in the cmap0 file. It currently looks like this ---snap--- 16 #000001 0 #ff0000 0 #ffff00 0 #00ff00 0 #7fffd4 0 #ffc0cb 0 #f5deb3 0 #bebebe 0 #a52a2a 0 #0000ff 0 #8a2be2 0 #00ffff 0 #40e0d0 0 #ff00ff 0 #fa8072 0 #ffffff 0 ---snap--- Et voilà: There is no error/warning output done to the console and the background is black, while drawings are done in red (or any other color, if explicitly setting apen color). To me it looks as if the format of the cmap0 file has changed, but this change is not (yet) reflected in the cmap0 being delivered. -- Gruß, Thorsten |
From: Alan W. I. <ir...@be...> - 2011-05-21 16:05:14
|
On 2011-05-20 11:41+0200 Thorsten Behrens wrote: > Hi! > > I'm new to this mailinglist. I've started studying/using Plplot because we > want to use Plplot within some of our software and I'll be the one to > implement it. Hi Thorsten: Thanks for your interest in PLplot. > > I've already installed Plplot (version 5.9.7) together with all necessary > tools (CMake, in this case). I was then able to build PLplot and compile > the examples. So far, so good. > > Development of our software currently is in Ada (and will stay in Ada as > long as I'm to develop it). The OS used is Windows (in different flavours, > currently I'm working on a Windows 7 machine). > > When running all examples as well as some other test programs of mine, I > always get this error on the console that opens when starting a program: > > ---snip--- > > *** PLPLOT WARNING *** > Unrecognized cmap0 format data line. Line is #000000 > > ---snap--- > > Also, the background color is always white, while all drawing (even if > explicitly setting a pen color) is done in red. > > I read this thread ( > https://sourceforge.net/mailarchive/message.php?msg_id=24879301 ) but > although it seemed to be the same problem, it was not (but may be > similar). I also read all the online documentation, but found no format > description of the cmap0_default.pal file. > > I'm sure the file is found and read, because when I edit the file > cmap0_default.pal, I can achieve better (and seemingly correct) results. > I've added an additional "column" after all the color definitions in the > cmap0 file. It currently looks like this > > ---snap--- > 16 > #000001 0 > #ff0000 0 > #ffff00 0 > #00ff00 0 > #7fffd4 0 > #ffc0cb 0 > #f5deb3 0 > #bebebe 0 > #a52a2a 0 > #0000ff 0 > #8a2be2 0 > #00ffff 0 > #40e0d0 0 > #ff00ff 0 > #fa8072 0 > #ffffff 0 > ---snap--- > > Et voilà: There is no error/warning output done to the console and the > background is black, while drawings are done in red (or any other color, > if explicitly setting apen color). > > To me it looks as if the format of the cmap0 file has changed, but this > change is not (yet) reflected in the cmap0 being delivered. I agree there should be better documentation of the various cmap0 (and cmap1) file formats. (I would be happy to accept such a document from you if you dive deeper into this.) However, every style in data/cmap[01]*.pal should be well supported. All of those work well on Linux and Mac OS X, and on the Windows platforms we have tested. But Windows consists of large numbers of different platforms, and our developers don't have access to all of them. So we must rely on our Windows users to help us figure out issues. For example, your Windows experience (and possibly the guy who contributed to the thread you mentioned above) seems to be an exception for some reason to the good results we have gotten on other Windows platforms with the *.pal files. I would like to get to the bottom of this issue with your help. I have forgotten the details, but IIRC the file reading code does get messed up by the extra CR in the usual Windows line endings which is why in our svn version of PLplot, all *.pal files _must_ be checked out with Unix line endings (only the line feed, not CR) for all platforms including Windows. (This happens automatically because of the svn:eol-style LF svn property of those files.) And, of course, those Unix line endings also get propagated to our distribution tarball so all should be well if you leave those Unix line endings as is. But I am now wondering if you (and the guy who had similar issues in the previous thread) are using some "smart" tarball unpacker on Windows that is converting the necessary Unix line endings to the incorrect (for our cmap[01]*.pal file reading) Windows line endings? Anyhow, if you have some control of line endings when you unpack the tarball, then please leave them as Unix and see if that solves the problem. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Thorsten B. <tho...@do...> - 2011-05-27 10:25:19
|
Hi Alan! >> ... >> When running all examples as well as some other test programs of mine, I >> always get this error on the console that opens when starting a program: >> >> ---snip--- >> >> *** PLPLOT WARNING *** >> Unrecognized cmap0 format data line. Line is #000000 >> >> ---snap--- >> >> Also, the background color is always white, while all drawing (even if >> explicitly setting a pen color) is done in red. >> >> I'm sure the file is found and read, because when I edit the file >> cmap0_default.pal, I can achieve better (and seemingly correct) results. >> I've added an additional "column" after all the color definitions in the >> cmap0 file. It currently looks like this >> >> ---snap--- >> 16 >> #000001 0 >> #ff0000 0 >> #ffff00 0 >> #00ff00 0 >> #7fffd4 0 >> #ffc0cb 0 >> #f5deb3 0 >> #bebebe 0 >> #a52a2a 0 >> #0000ff 0 >> #8a2be2 0 >> #00ffff 0 >> #40e0d0 0 >> #ff00ff 0 >> #fa8072 0 >> #ffffff 0 >> ---snap--- >> >> Et voilà: There is no error/warning output done to the console and the >> background is black, while drawings are done in red (or any other color, >> if explicitly setting apen color). >> >> To me it looks as if the format of the cmap0 file has changed, but this >> change is not (yet) reflected in the cmap0 being delivered. > > I agree there should be better documentation of the various cmap0 (and > cmap1) file formats. (I would be happy to accept such a document from > you if you dive deeper into this.) However, every style in > data/cmap[01]*.pal should be well supported. All of those work well on > Linux and Mac OS X, and on the Windows platforms we have tested. But > Windows consists of large numbers of different platforms, and our > developers don't have access to all of them. So we must rely on our > Windows users to help us figure out issues. > > For example, your Windows experience (and possibly the guy who > contributed to the thread you mentioned above) seems to be an > exception for some reason to the good results we have gotten on other > Windows platforms with the *.pal files. I would like to get to the > bottom of this issue with your help. > > I have forgotten the details, but IIRC the file reading code does get > messed up by the extra CR in the usual Windows line endings which is > why in our svn version of PLplot, all *.pal files _must_ be checked > out with Unix line endings (only the line feed, not CR) for all > platforms including Windows. (This happens automatically because of > the svn:eol-style LF svn property of those files.) And, of course, > those Unix line endings also get propagated to our distribution > tarball so all should be well if you leave those Unix line endings as > is. > > But I am now wondering if you (and the guy who had similar issues in > the previous thread) are using some "smart" tarball unpacker on > Windows that is converting the necessary Unix line endings to the > incorrect (for our cmap[01]*.pal file reading) Windows line endings? > > Anyhow, if you have some control of line endings when you unpack the > tarball, then please leave them as Unix and see if that solves the > problem. That indeed was the problem. I unpacked the tar-Archive with Winzip. Winzip indeed uses a "smart" CR/LF detection and corrects UNIX-style line endings to Windows-style line endings. Although I was sure, I had this checked before posting to the list, I obviously hadn't. I extracted the *.pal files again (with smart detection disabled) and all executables using PLplot run without the above mentioned warning. I also digged into the file reading code. BTW: I now remember, why I dislike C ;-) I'm no expert in C, but the problem to me seems to be somewhere in the line-reading code of cmap0_palette_read. After checking the input file for existence, the contents of that file are read. First, a line with the number of colors to be defined is expected. That line (although also ending with "incorrect" CRLF) is read without a problem - otherwise we would have seen the error message "Unrecognized cmap0 header". A loop over the number of colors follows. Within this loop each line is analyzed - however, a line is read here using fgets instead of fscanf as before (and reading at most 29 characters). The last character of the data read is then replaced by NUL which C needs to terminate strings correctly. If the line ending is just 0x0A this will work correctly, as it also will, if the line has no ending (because 29 characters have been read) - however, if the line ending is 0x0D0A the 0x0D will remain in the string read. This string is then checked for either being seven characters long or being longer than 9 characters - everything else results in the error we saw. This explains, why the column added by me to the cmap0_default.pal file seemed to fix the problem. To me, there seem to be several ways to correct the line-ending problem here: 1) According to http://pubs.opengroup.org/onlinepubs/009695399/functions/fgets.html fgets, if returning without an error, adds a NUL character already to the string. So, to me it seems unnecessary to replace the last character by NUL. OTOH, it might not hurt, though. 2) Wouldn't it be more safe to check, whether the last characters of the string are 0x0A, 0x0D or any combination of them and replace each of these characters by a Null-byte? That should not hurt in any case and would involve just changing line 1300 of file plctrl.c from <code> color_info[strlen( color_info ) - 1] = '\0'; /* remove return character */ </code> to something like (may not be correct C, but the idea should be understandable) <code> for (my_local_i = 0 ; my_local_i < 30; my_local_i++) { /* remove return character(s) */ if (color_info[my_local_i] == 0x0A) || (color_info[my_local_i] == 0x0D) { color_info[my_local_i] = 0x00; } } </code> 3) Usage of fscanf instead of fgets and sscanf. However, this might bring up new problems. -- Gruß, Thorsten |
From: Alan W. I. <ir...@be...> - 2011-05-27 17:18:51
|
Hi Thorsten: On 2011-05-27 12:25+0200 Thorsten Behrens wrote: > Hi Alan! >> But I am now wondering if you (and the guy who had similar issues in >> the previous thread) are using some "smart" tarball unpacker on >> Windows that is converting the necessary Unix line endings to the >> incorrect (for our cmap[01]*.pal file reading) Windows line endings? >> >> Anyhow, if you have some control of line endings when you unpack the >> tarball, then please leave them as Unix and see if that solves the >> problem. > > That indeed was the problem. I unpacked the tar-Archive with Winzip. > Winzip indeed uses a "smart" CR/LF detection and corrects UNIX-style line > endings to Windows-style line endings. Although I was sure, I had this > checked before posting to the list, I obviously hadn't. I extracted the > *.pal files again (with smart detection disabled) and all executables > using PLplot run without the above mentioned warning. > > I also digged into the file reading code. BTW: I now remember, why I > dislike C ;-) > > I'm no expert in C, but the problem to me seems to be somewhere in the > line-reading code of cmap0_palette_read. After checking the input file for > existence, the contents of that file are read. First, a line with the > number of colors to be defined is expected. That line (although also > ending with "incorrect" CRLF) is read without a problem - otherwise we > would have seen the error message "Unrecognized cmap0 header". > > A loop over the number of colors follows. Within this loop each line is > analyzed - however, a line is read here using fgets instead of fscanf as > before (and reading at most 29 characters). The last character of the data > read is then replaced by NUL which C needs to terminate strings correctly. > If the line ending is just 0x0A this will work correctly, as it also will, > if the line has no ending (because 29 characters have been read) - > however, if the line ending is 0x0D0A the 0x0D will remain in the string > read. > > This string is then checked for either being seven characters long or > being longer than 9 characters - everything else results in the error we > saw. This explains, why the column added by me to the cmap0_default.pal > file seemed to fix the problem. > > To me, there seem to be several ways to correct the line-ending problem > here: > > 1) According to > http://pubs.opengroup.org/onlinepubs/009695399/functions/fgets.html fgets, > if returning without an error, adds a NUL character already to the string. > So, to me it seems unnecessary to replace the last character by NUL. OTOH, > it might not hurt, though. > > 2) Wouldn't it be more safe to check, whether the last characters of the > string are 0x0A, 0x0D or any combination of them and replace each of these > characters by a Null-byte? That should not hurt in any case and would > involve just changing line 1300 of file plctrl.c > > from > > <code> > color_info[strlen( color_info ) - 1] = '\0'; /* remove return character */ > </code> > > to something like (may not be correct C, but the idea should be > understandable) > > <code> > for (my_local_i = 0 ; my_local_i < 30; my_local_i++) > { > /* remove return character(s) */ > if (color_info[my_local_i] == 0x0A) || > (color_info[my_local_i] == 0x0D) > { > color_info[my_local_i] = 0x00; > } > } > </code> > > 3) Usage of fscanf instead of fgets and sscanf. However, this might bring > up new problems. I believe we need the fgets/sscanf combination since that allows the code to reread the line for the case of alternate formats. So I think idea (2) is the way to go to fix this issue. Since it turns out that indeed Windows tarball unpackers can convert Unix line endings to Windows line endings, this is an accident that has obviously happened before (the historical posting about this issue which has been referred to previously in this thread), which has happened now to Thorsten, and which is waiting to happen to others. Therefore, it is important to fix the file-reading code so that *.pal files can have either Unix or Windows line endings. Does one of our developers with access to Windows want to take responsibility for fixing this (or evaluating Thorsten's patch if he goes further with his idea 2?). An obvious test of the updated code (and something we should do anyway once the issue is fixed) would be the change the svn properties of the *.pal files to native so they will be checked out on Windows with the Windows line endings. Thanks, Thorsten, for being persistent about this issue so we finally discovered the exact source of this nagging problem. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Thorsten B. <tho...@do...> - 2011-05-27 20:14:09
|
Hi Alan! >>> [problem with different line endings in *nix/Windows] >> >> I'm no expert in C, but the problem to me seems to be somewhere in the >> line-reading code of cmap0_palette_read. After checking the input file >> for existence, the contents of that file are read. First, a line with >> the number of colors to be defined is expected. That line (although also >> ending with "incorrect" CRLF) is read without a problem - otherwise we >> would have seen the error message "Unrecognized cmap0 header". >> >> A loop over the number of colors follows. Within this loop each line is >> analyzed - however, a line is read here using fgets instead of fscanf as >> before (and reading at most 29 characters). The last character of the >> data read is then replaced by NUL which C needs to terminate strings >> correctly. >> If the line ending is just 0x0A this will work correctly, as it also >> will, if the line has no ending (because 29 characters have been read) - >> however, if the line ending is 0x0D0A the 0x0D will remain in the string >> read. I'd suggest this to be checked by someone with deeper C experience - especially with experience regarding the caveats of C. Had it come to Ada, I would have been able to give advice, but not for C. >> This string is then checked for either being seven characters long or >> being longer than 9 characters - everything else results in the error we >> saw. This explains, why the column added by me to the cmap0_default.pal >> file seemed to fix the problem. >> >> To me, there seem to be several ways to correct the line-ending problem >> here: >> >> 1) According to >> http://pubs.opengroup.org/onlinepubs/009695399/functions/fgets.html >> fgets, if returning without an error, adds a NUL character already to >> the string. So, to me it seems unnecessary to replace the last >> character by NUL. OTOH, it might not hurt, though. >> >> 2) Wouldn't it be more safe to check, whether the last characters of >> the string are 0x0A, 0x0D or any combination of them and replace each >> of these characters by a Null-byte? That should not hurt in any case >> and would involve just changing line 1300 of file plctrl.c >> >> from >> >> <code> >> color_info[strlen( color_info ) - 1] = '\0'; /* remove return character >> */ >> </code> >> >> to something like (may not be correct C, but the idea should be >> understandable) >> >> <code> >> for (my_local_i = 0 ; my_local_i < 30; my_local_i++) >> { >> /* remove return character(s) */ >> if (color_info[my_local_i] == 0x0A) || >> (color_info[my_local_i] == 0x0D) >> { >> color_info[my_local_i] = 0x00; >> } >> } >> </code> >> >> 3) Usage of fscanf instead of fgets and sscanf. However, this might >> bring up new problems. > > I believe we need the fgets/sscanf combination since that allows the > code to reread the line for the case of alternate formats. I doubt this, because there is no re-reading of a line in case of an error. If something is wrong with the current line, an error flag is set and the "line reading loop" is immediately left. At least within the routine reading cmap0 (cmap0_palette_read) files this is the case. > So I think idea (2) is the way to go to fix this issue. But nonetheless I do also think that (2) is the best way to solve this issue. > Since it turns out that indeed Windows tarball unpackers can convert > Unix line endings to Windows line endings, this is an accident that > has obviously happened before (the historical posting about this issue > which has been referred to previously in this thread), which has > happened now to Thorsten, and which is waiting to happen to others. > Therefore, it is important to fix the file-reading code so that *.pal > files can have either Unix or Windows line endings. I have spent more time looking at this source file and while it seems easy to fix this issue for cmap0 files, it might be more difficult to fix this for cmap1 files. These are read in routine c_plspal1, which as fas as may understanding of C goes, has no re-reading loop, too (this needs to be verified!). In this routine, a NUL character is written to the string read only in a single case ("Old tk file format") - to assure that strings longer than 160 characters are correctly terminated. I wonder why this isn't done for newer file formats. Anyway: The fix I suggested (i.e. checking the string character by character for 0x0A or 0x0D) should work here as well. > Does one of our developers with access to Windows want to take > responsibility for fixing this (or evaluating Thorsten's patch if he > goes further with his idea 2?). An obvious test of the updated code > (and something we should do anyway once the issue is fixed) would be > the change the svn properties of the *.pal files to native so they > will be checked out on Windows with the Windows line endings. I could patch my sources here (on Monday, when I'm back in the office, that is) and test this on my windows system using the automatically "corrected" line endings by WinZIP, if that helps. > Thanks, Thorsten, for being persistent about this issue so we finally > discovered the exact source of this nagging problem. You're welcome. -- Gruß, Thorsten |
From: Thorsten B. <tho...@do...> - 2011-05-30 11:19:11
|
Hi Arjen! >> Anyway: The fix I suggested (i.e. checking the string character by >> character for 0x0A or 0x0D) should work here as well. > > I suggest using the symbolic escape sequences \r and \n, > as that is what they are for. Yes. I didn't know C has constants for that. BTW: You can also define a constant for the string length instead of using integer literals in the code. > I can check your patch, that should be no problem (and > check it in) That would be of great help. Thanks. -- Gruß, Thorsten |
From: Thorsten B. <tho...@do...> - 2011-05-30 11:53:50
|
Hi Arjen! >> BTW: You can also define a constant for the string length instead of >> using integer literals in the code. > > Good thinking! Actually, as I look at the code, I see that it presumes > that lines are never longer than 30 characters. If I understand http://en.wikipedia.org/wiki/Fgets corrytly, then the code assumes lines to be no longer than 29 characters because fgets always appends a NUL-byte to the string read (or do I misunderstand something here?). This is why I also thought that you could omit changing the lineending to a NUL-byte. Howevere, just changing all /r, /n to NUL is the safest way, I guess. > If they are, the reading process will fail in an uneasy way. I will try > and take care of that too. Why does it fail in an uneasy way? Will strlen not terminate, because there is no NUL-byte in the string returned by fgets then? -- Gruß, Thorsten |
From: Arjen M. <arj...@de...> - 2011-05-30 11:59:09
|
Hi Thorsten, On 2011-05-30 13:53, Thorsten Behrens wrote: > Hi Arjen! > >>> BTW: You can also define a constant for the string length instead of >>> using integer literals in the code. >> Good thinking! Actually, as I look at the code, I see that it presumes >> that lines are never longer than 30 characters. > > If I understand http://en.wikipedia.org/wiki/Fgets corrytly, then the code > assumes lines to be no longer than 29 characters because fgets always > appends a NUL-byte to the string read (or do I misunderstand something > here?). This is why I also thought that you could omit changing the > lineending to a NUL-byte. Howevere, just changing all /r, /n to NUL is the > safest way, I guess. Yes, that is true. > >> If they are, the reading process will fail in an uneasy way. I will try >> and take care of that too. > > Why does it fail in an uneasy way? Will strlen not terminate, because > there is no NUL-byte in the string returned by fgets then? > Because the file pointer will not be moved to the end of the line. The next read would pick up where it left off, so it would read the rest of the same line, not the next line. That results in errors that are probably difficult to detect. I have written a small test program that reads 30 characters and then skips the rest of the line. Not entirely trivial but it works, so I will apply that. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <arj...@de...> - 2011-05-28 10:20:33
|
On Fri, 27 May 2011 22:13:58 +0200 "Thorsten Behrens" <tho...@do...> wrote: > Hi Alan! > > Anyway: The fix I suggested (i.e. checking the string >character by > character for 0x0A or 0x0D) should work here as well. > I suggest using the symbolic escape sequences \r and \n, as that is what they are for. >> Does one of our developers with access to Windows want >>to take >> responsibility for fixing this (or evaluating Thorsten's >>patch if he >> goes further with his idea 2?). An obvious test of the >>updated code >> (and something we should do anyway once the issue is >>fixed) would be >> the change the svn properties of the *.pal files to >>native so they >> will be checked out on Windows with the Windows line >>endings. > > I could patch my sources here (on Monday, when I'm back >in the office, > that is) and test this on my windows system using the >automatically > "corrected" line endings by WinZIP, if that helps. > I can check your patch, that should be no problem (and check it in) Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <arj...@de...> - 2011-05-30 11:31:06
|
Hi Thorsten, On 2011-05-30 13:19, Thorsten Behrens wrote: > Hi Arjen! > >>> Anyway: The fix I suggested (i.e. checking the string character by >>> character for 0x0A or 0x0D) should work here as well. >> I suggest using the symbolic escape sequences \r and \n, >> as that is what they are for. > > Yes. I didn't know C has constants for that. > There is a short list of such constants, the most useful are \t, \r and \n. > BTW: You can also define a constant for the string length instead of using > integer literals in the code. > Good thinking! Actually, as I look at the code, I see that it presumes that lines are never longer than 30 characters. If they are, the reading process will fail in an uneasy way. I will try and take care of that too. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <arj...@de...> - 2011-05-31 14:46:39
|
Hi Thorsten, I implemented the patch (with a bit more code to make it robust against a variety of issues), with this patch line endings are no longer a problem for the palette files. Regards, Arjen On 2011-05-30 13:53, Thorsten Behrens wrote: > Hi Arjen! > >>> BTW: You can also define a constant for the string length instead of >>> using integer literals in the code. >> Good thinking! Actually, as I look at the code, I see that it presumes >> that lines are never longer than 30 characters. > > If I understand http://en.wikipedia.org/wiki/Fgets corrytly, then the code > assumes lines to be no longer than 29 characters because fgets always > appends a NUL-byte to the string read (or do I misunderstand something > here?). This is why I also thought that you could omit changing the > lineending to a NUL-byte. Howevere, just changing all /r, /n to NUL is the > safest way, I guess. > >> If they are, the reading process will fail in an uneasy way. I will try >> and take care of that too. > > Why does it fail in an uneasy way? Will strlen not terminate, because > there is no NUL-byte in the string returned by fgets then? > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2011-06-01 21:02:21
|
On 2011-05-31 16:46+0200 Arjen Markus wrote: > Hi Thorsten, > > I implemented the patch (with a bit more code to make it robust > against a variety of issues), with this patch line endings are > no longer a problem for the palette files. Thanks to both of you for dealing with this issue. I have changed the svn properties of *.pal files (svn revision 11761) to native (i.e., checked out *.pal files will have Unix line endings on Linux, but Windows line endings on Windows). Revision 11761 works fine on Linux. >From Arjen's previous tests revision 11761 should also work on Windows, but will you both confirm that? Of course, for our next release if somebody unpacks the tarball with Windows line endings that should also work, which takes care of the original issue. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@de...> - 2011-06-06 07:33:17
|
Hi Alan, when I developed this patch, based on the first patch by Thorsten, I tested it with .pal files I had edited: - Windows format (carriage-return-line-feed endings) - Trailing blanks and a very long line with text beyond the 30th column - Invalid hex numbers - Even files without an end-of-line marker for the last line (on Windows this is pitifully common, it seems the end-of-line marker is regarded as a line-separator) With all these variations the reading routines did their work fine. I will not claim that all possible issues have been solved with this code, but the routines appear quite robust. Regards, Arjen PS On Windows the C runtime library is supposed to convert \r\n in a file to \n in the string. A problem might appear on Linux, where this is not the case, but that ought to be taken care of now. On 2011-06-01 23:02, Alan W. Irwin wrote: > On 2011-05-31 16:46+0200 Arjen Markus wrote: > >> Hi Thorsten, >> >> I implemented the patch (with a bit more code to make it robust >> against a variety of issues), with this patch line endings are >> no longer a problem for the palette files. > > Thanks to both of you for dealing with this issue. I have changed the > svn properties of *.pal files (svn revision 11761) to native (i.e., > checked out *.pal files will have Unix line endings on Linux, but > Windows line endings on Windows). Revision 11761 works fine on Linux. > From Arjen's previous tests revision 11761 should also work on > Windows, but will you both confirm that? Of course, for our next > release if somebody unpacks the tarball with Windows line endings that > should also work, which takes care of the original issue. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |