Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
|
From: <noreply@so...> - 2002-01-29 12:48:47
|
Bugs item #508060, was opened at 2002-01-24 09:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=104664&aid=508060&group_id=4664 Category: Curses interface Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Hans-Bernhard Broeker (broeker) >Summary: Nonstandard whitespace in source confuses Unix display Initial Comment: CSCOPE 15.3 compiled with GCC 3.0.x on Solaris 7 using Solaris curses. Source code is from a DOS machine and has CR/LF at the end of lines. Unless the source line is too long to fit on the screen (a large one - 136x61), the display for the source lines is blank; remove the CR characters, and all is back to normal. ---------------------------------------------------------------------- >Comment By: Hans-Bernhard Broeker (broeker) Date: 2002-01-29 04:48 Message: Logged In: YES user_id=27517 We can't update the records, but that doesn't really matter --- you can subscribe to be emailed updates of the bugreport without being the submittor. GCC may seem to accept those files as-is, but I wouldn't bet money on that before trying whether the preprocessor does, too. The typical breakage is that backslash-newline sequences aren't recognized if there's a CRLF as the newline. To GCC (at least to all versions I've tested that on), this doesn't qualify as backslash-newline, and that leads to all kinds of funny problems. To test, consider this two-liner: #define MACRO blabla \ #error backslash-newline got eaten! And see what happens: broeker ~> gcc -E tt.c # 1 "tt.c" broeker ~> unix2dos tt.c unix2dos: converting file tt.c to DOS format ... broeker ~> gcc -E tt.c tt.c:2: #error backslash-newline got eaten! # 1 "tt.c" This is with gcc-2.8.1 on an ancient Linux box. But I very strongly suspect the same bug to happen if there's any other whitespace (FF, VT, HT) between the backslash and the newline, and also with more recent GCCs. I'll change the subject line to more closely reflect the scope of this problem then. ---------------------------------------------------------------------- Comment By: Jonathan Leffler (jleffler) Date: 2002-01-28 14:54 Message: Logged In: YES user_id=22937 I submitted this bug - can we update the records to reflect this? I agree with Hans-Bernhard that I should have converted the source; indeed, that was the workaround. At the time when I ran CSCOPE on the source, I was not aware that it had been modified by a DOS box. I note that although I mentioned carriage return (CR or ^M) as the problem, vertical tab (VT or ^K) and formfeed (FF or ^L) also yield interesting effects. Note that GCC accepts the source code as valid - primarily because all those characters are (presumably) mapped to white space and none of the syntax depends on the type of white space. I think that it would be wise for CSCOPE to note that characters such as these do not have a printable representation and to ensure that when the character is displayed, it is handled suitably. What is suitable? That is harder to answer. I incline towards printing a space, at least for characters that satisfy isspace(c). For the more general case, I don't know that I have a good solution to offer -- maybe '@' since it is not a valid character in C outside of a string. You may well be right to decide this is outside the scope of your project. OTOH, it means there are some files that are accepted by some C compilers that cannot usefully be shown by CSCOPE on some platforms; it seems a pity not to handle it somehow. However, I have not looked at what it would take to handle it properly, so I am not in a position to offer detailed coding suggestions (yet). Question (for which I certainly don't have an answer): will C compilers start accepting Unicode characters? Probably not, but... ---------------------------------------------------------------------- Comment By: Hans-Bernhard Broeker (broeker) Date: 2002-01-25 09:01 Message: Logged In: YES user_id=27517 The real breakage is outside cscope, of course: you should have transferred these files as text, and thus got rid of those CR's at the source already. That's what ftp has that "ascii" transfer mode for, see? Or zip/unzip their '-a' option. I'm not quite sure it would be a good idea to artificially remove CR characters from cscope.out if they are found by cscope running on a system that doesn't usually have CRLF lineends. Plus, it might be rather hard to do. Can't you just recode ibmpc..latin1 your files and be done with it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=104664&aid=508060&group_id=4664 |
|
From: <noreply@so...> - 2002-06-20 16:50:33
|
Bugs item #508060, was opened at 2002-01-24 18:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=104664&aid=508060&group_id=4664 Category: Curses interface Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Hans-Bernhard Broeker (broeker) Summary: Nonstandard whitespace in source confuses Unix display Initial Comment: CSCOPE 15.3 compiled with GCC 3.0.x on Solaris 7 using Solaris curses. Source code is from a DOS machine and has CR/LF at the end of lines. Unless the source line is too long to fit on the screen (a large one - 136x61), the display for the source lines is blank; remove the CR characters, and all is back to normal. ---------------------------------------------------------------------- >Comment By: Hans-Bernhard Broeker (broeker) Date: 2002-06-20 18:50 Message: Logged In: YES user_id=27517 I've checked in a patch to fix this at least for the flex-based scanner (fscanner.l). ---------------------------------------------------------------------- Comment By: Hans-Bernhard Broeker (broeker) Date: 2002-01-29 13:48 Message: Logged In: YES user_id=27517 We can't update the records, but that doesn't really matter --- you can subscribe to be emailed updates of the bugreport without being the submittor. GCC may seem to accept those files as-is, but I wouldn't bet money on that before trying whether the preprocessor does, too. The typical breakage is that backslash-newline sequences aren't recognized if there's a CRLF as the newline. To GCC (at least to all versions I've tested that on), this doesn't qualify as backslash-newline, and that leads to all kinds of funny problems. To test, consider this two-liner: #define MACRO blabla \ #error backslash-newline got eaten! And see what happens: broeker ~> gcc -E tt.c # 1 "tt.c" broeker ~> unix2dos tt.c unix2dos: converting file tt.c to DOS format ... broeker ~> gcc -E tt.c tt.c:2: #error backslash-newline got eaten! # 1 "tt.c" This is with gcc-2.8.1 on an ancient Linux box. But I very strongly suspect the same bug to happen if there's any other whitespace (FF, VT, HT) between the backslash and the newline, and also with more recent GCCs. I'll change the subject line to more closely reflect the scope of this problem then. ---------------------------------------------------------------------- Comment By: Jonathan Leffler (jleffler) Date: 2002-01-28 23:54 Message: Logged In: YES user_id=22937 I submitted this bug - can we update the records to reflect this? I agree with Hans-Bernhard that I should have converted the source; indeed, that was the workaround. At the time when I ran CSCOPE on the source, I was not aware that it had been modified by a DOS box. I note that although I mentioned carriage return (CR or ^M) as the problem, vertical tab (VT or ^K) and formfeed (FF or ^L) also yield interesting effects. Note that GCC accepts the source code as valid - primarily because all those characters are (presumably) mapped to white space and none of the syntax depends on the type of white space. I think that it would be wise for CSCOPE to note that characters such as these do not have a printable representation and to ensure that when the character is displayed, it is handled suitably. What is suitable? That is harder to answer. I incline towards printing a space, at least for characters that satisfy isspace(c). For the more general case, I don't know that I have a good solution to offer -- maybe '@' since it is not a valid character in C outside of a string. You may well be right to decide this is outside the scope of your project. OTOH, it means there are some files that are accepted by some C compilers that cannot usefully be shown by CSCOPE on some platforms; it seems a pity not to handle it somehow. However, I have not looked at what it would take to handle it properly, so I am not in a position to offer detailed coding suggestions (yet). Question (for which I certainly don't have an answer): will C compilers start accepting Unicode characters? Probably not, but... ---------------------------------------------------------------------- Comment By: Hans-Bernhard Broeker (broeker) Date: 2002-01-25 18:01 Message: Logged In: YES user_id=27517 The real breakage is outside cscope, of course: you should have transferred these files as text, and thus got rid of those CR's at the source already. That's what ftp has that "ascii" transfer mode for, see? Or zip/unzip their '-a' option. I'm not quite sure it would be a good idea to artificially remove CR characters from cscope.out if they are found by cscope running on a system that doesn't usually have CRLF lineends. Plus, it might be rather hard to do. Can't you just recode ibmpc..latin1 your files and be done with it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=104664&aid=508060&group_id=4664 |
|
From: SourceForge.net <noreply@so...> - 2004-01-08 13:56:12
|
Bugs item #508060, was opened at 2002-01-24 18:47 Message generated for change (Comment added) made by broeker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104664&aid=508060&group_id=4664 Category: Curses interface Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Hans-Bernhard Broeker (broeker) Summary: Nonstandard whitespace in source confuses Unix display Initial Comment: CSCOPE 15.3 compiled with GCC 3.0.x on Solaris 7 using Solaris curses. Source code is from a DOS machine and has CR/LF at the end of lines. Unless the source line is too long to fit on the screen (a large one - 136x61), the display for the source lines is blank; remove the CR characters, and all is back to normal. ---------------------------------------------------------------------- >Comment By: Hans-Bernhard Broeker (broeker) Date: 2004-01-08 14:56 Message: Logged In: YES user_id=27517 An equivalent patch for scanner.l is (finally) going in, too. Closing this. ---------------------------------------------------------------------- Comment By: Hans-Bernhard Broeker (broeker) Date: 2002-06-20 18:50 Message: Logged In: YES user_id=27517 I've checked in a patch to fix this at least for the flex-based scanner (fscanner.l). ---------------------------------------------------------------------- Comment By: Hans-Bernhard Broeker (broeker) Date: 2002-01-29 13:48 Message: Logged In: YES user_id=27517 We can't update the records, but that doesn't really matter --- you can subscribe to be emailed updates of the bugreport without being the submittor. GCC may seem to accept those files as-is, but I wouldn't bet money on that before trying whether the preprocessor does, too. The typical breakage is that backslash-newline sequences aren't recognized if there's a CRLF as the newline. To GCC (at least to all versions I've tested that on), this doesn't qualify as backslash-newline, and that leads to all kinds of funny problems. To test, consider this two-liner: #define MACRO blabla #error backslash-newline got eaten! And see what happens: broeker ~> gcc -E tt.c # 1 "tt.c" broeker ~> unix2dos tt.c unix2dos: converting file tt.c to DOS format ... broeker ~> gcc -E tt.c tt.c:2: #error backslash-newline got eaten! # 1 "tt.c" This is with gcc-2.8.1 on an ancient Linux box. But I very strongly suspect the same bug to happen if there's any other whitespace (FF, VT, HT) between the backslash and the newline, and also with more recent GCCs. I'll change the subject line to more closely reflect the scope of this problem then. ---------------------------------------------------------------------- Comment By: Jonathan Leffler (jleffler) Date: 2002-01-28 23:54 Message: Logged In: YES user_id=22937 I submitted this bug - can we update the records to reflect this? I agree with Hans-Bernhard that I should have converted the source; indeed, that was the workaround. At the time when I ran CSCOPE on the source, I was not aware that it had been modified by a DOS box. I note that although I mentioned carriage return (CR or ^M) as the problem, vertical tab (VT or ^K) and formfeed (FF or ^L) also yield interesting effects. Note that GCC accepts the source code as valid - primarily because all those characters are (presumably) mapped to white space and none of the syntax depends on the type of white space. I think that it would be wise for CSCOPE to note that characters such as these do not have a printable representation and to ensure that when the character is displayed, it is handled suitably. What is suitable? That is harder to answer. I incline towards printing a space, at least for characters that satisfy isspace(c). For the more general case, I don't know that I have a good solution to offer -- maybe '@' since it is not a valid character in C outside of a string. You may well be right to decide this is outside the scope of your project. OTOH, it means there are some files that are accepted by some C compilers that cannot usefully be shown by CSCOPE on some platforms; it seems a pity not to handle it somehow. However, I have not looked at what it would take to handle it properly, so I am not in a position to offer detailed coding suggestions (yet). Question (for which I certainly don't have an answer): will C compilers start accepting Unicode characters? Probably not, but... ---------------------------------------------------------------------- Comment By: Hans-Bernhard Broeker (broeker) Date: 2002-01-25 18:01 Message: Logged In: YES user_id=27517 The real breakage is outside cscope, of course: you should have transferred these files as text, and thus got rid of those CR's at the source already. That's what ftp has that "ascii" transfer mode for, see? Or zip/unzip their '-a' option. I'm not quite sure it would be a good idea to artificially remove CR characters from cscope.out if they are found by cscope running on a system that doesn't usually have CRLF lineends. Plus, it might be rather hard to do. Can't you just recode ibmpc..latin1 your files and be done with it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104664&aid=508060&group_id=4664 |