On Sep 8, 2009, at 12:56 PM, Chris Espinosa wrote: On Sep 8, 2009, at 8:29 AM, Brian Barnes wrote: I'm trying to track down a number of clang errors, but they mysterious get fixed through undos. For example, I had a header file with a number of defines like this:
#define xxx abc\
def\
hij\
etc. Maybe about 100 lines of this, in different defines. About halfway down, I get "backslash and newline separated by space" which is repeated for all other lines past that.
The nature of the gcc parser is that a syntax error on one line tends to confuse the parsing of subsequent lines in the file. It's entirely possible that only one has the extra space after the backslash and the rest are fine.
It's clang, not gcc, though I understand the problem and the extra errors are understandable. That's not the problem, though .. the problem ... I retyped the line, and it works. Now the odd part -- I "undo" the typing to try to determine the difference -- and it still works!
Does undo fix line endings, or remove control characters?
Generally not. I lost the change I was tracking there, so I can't figure it out to submit a bug report! I suspect this might be a problem with changing line endings or control characters in the file, but now I can't get a handle because it's "fixed"! So, there's some information for you, it's the best I can do (sorry).
Some forms of "smart cut and paste" attempt to add appropriate word spacing. Xcode generally disables these, but it's possible that an extra space crept in depending on the position of the insertion point when you pasted, or what application you copied from.
Is that clang was acting differently then gcc 4.0, which compiled the code find. I wanted to track the bug for you guys but the undo seemed to not give me back the original code, therefore I'm guessing at hidden characters or different line endings in the code. Note that these c files are edited both in XCode and VS, so it's possible that's where the funkyness came from. Regardless, gcc compiles it fine, so if clang is a drop in replacement, it'll probably need to do the same.
Again, I apologize for not having a lot of information, the undo lost what I had. I'll see if I can recreate it in another way.
Also, when I have gotten things to compile, my code always ends up crashing in OS X -- usually in a UI routine -- my code's still in carbon (yes, I know) so that might be a factor, or it's an unforeseen problem I got away with in gcc.
When a cash occurs in a system framework, the first thing to check is whether you're passing useful and correct values to it. Compilers will only ensure they are of the correct type and aren't uninitialized; they won't ensure your code is correct. Also tracking this, and I also get spurious "symbol not found" which I haven't gotten a handle on yet, either.
It's probably not spurious. I'm wondering -- should I not use this for carbon? There's nothing particular about Carbon that makes apps crash due to bugs.
Posting examples of the code that is crashing and the crash log is probably going to be key to figuring out what's wrong.
My point here is that my applications -- and it's 3 of them -- run fine when compiled with gcc 4.0, but crash when compiled with clang. That's what I'm trying to get at here (sorry I wasn't specific enough.) The "clang = drop in replacement for gcc" is problematic for me. I'm trying to come up with more info for you.
[>] Brian |