if (target && ft == ftHeader && compiler && compiler->GetSwitches().supportsPCH)1. Why doesn't the following code crashes?Because if compiler is NULL all following checks are *not* done. The if statement exits early if the fist boolean is false... at least this applies to GCC. Other compiler *might* handle this different.
Line 286: projectfile.cppCodeif (target && ft == ftHeader && compiler && compiler->GetSwitches().supportsPCH)
2. Why compiler is getting NULL value? At least it should get a Compiler.Actually this can easily happen. Suppose you create a copy of a compiler and setup a project based on that. Now if you open the project on another PC where this compiler (the copy) isn't setup then the compiler will usually be NULL. Another option is that the one or other (like me ;-)) might have base compilers integrated that do not exist at all. In that case opening such a project would result in the compiler being NULL, too.
Because if compiler is NULL all following checks are *not* done. The if statement exits early if the fist boolean is false... at least this applies to GCC. Other compiler *might* handle this different.
2. Why compiler is getting NULL value? At least it should get a Compiler.Actually this can easily happen. Suppose you create a copy of a compiler and setup a project based on that. Now if you open the project on another PC where this compiler (the copy) isn't setup then the compiler will usually be NULL. Another option is that the one or other (like me ;-)) might have base compilers integrated that do not exist at all. In that case opening such a project would result in the compiler being NULL, too.
In the end there is another option: Disable the compiler plugin and the compiler will always be NULL. ;-)
BTW: You can easily simulate these cases by modifying a C::B project file and setting the compiler to an invalid string like: <Option compiler="does_not_exist" />... and/or disable the compiler plugin. This reminds me that at the time Yiannis implemented the plugin activate/de-activate facility we were hunting quite some bugs with missing checks for a valid compiler. Maybe we should repeat this step from time to time. ;-)
I think we should put a MessageBox throwing some *Warning* message before returning 0 in GetCompiler() or at least throw some messages in the Debug-Log. User would come to know about this problem then.I'm not sure about that. This may confuse people who disabled the compiler plugin on purpose (imagine they are using C::B for Python development or similar). Because they would see this message over and over again (just count the number of GetCompiler() calls accross C::B). An AnnoyingDialog wouldn't be of much help I suppose.
Alternatively it can be set to return Default Compiler. :)This wouldn't work entirely if the compiler plugin is disabled because in that case there is no default compiler.
else
{
if (pf->GetParentProject()->GetExtendedObjectNamesGeneration())
{
object_file_native = objOut + sep + fname.GetFullPath();
object_file_flat_native = objOut + sep + fname.GetFullName();
if (compiler)
{
object_file_native += _T('.') + compiler->GetSwitches().objectExtension;
object_file_flat_native += _T('.') + compiler->GetSwitches().objectExtension;
}
}
else
{
if (compiler)
fname.SetExt(compiler->GetSwitches().objectExtension);
object_file_native = objOut + sep + fname.GetFullPath();
object_file_flat_native = objOut + sep + fname.GetFullName();
}
}
This will fix the crash. Unfortunately I don't have access to SVN ATM - maybe another dev could... after approval?!
I can put it, if you wish. ;)I didn't verify completely but I believe things are better with this "patch" applied... so please go on! ;-)
But if the object extension is not set, will it compile?No, but remember: If compiler is NULL then it *can't* compile because there is no (valid) compiler. ;-) So for this patch this is OK... but I agree -> there should be a message for the case the compiler is enabled but not valid. I'd say we have to ask Yiannis about that. But he'll surely say "Yes" to this "patch" (or throw a brick at me).
Edit 1: Applied patch. In revision 3665. Thanks to Jan van den Borst for posting the bug. :)Sorry for answering a little late (I've been quite busy today). Thanks for applying - unfortunately I'd say it only one half of the proposal (my fault - I should really have produced a true patch file). There is another crash candidate in the first if-clause. If I look at the diff in the WebSVN it seems this part is missing... I might be wrong, though... Could you have another look, please?
Do I need to convert the file to Unix line endings before I commit?Hmmm... to be honest: I don't know. Actually SVN should handle this for you. When you checkout files with Windows linefeeds but the Repository is Unix based SVN will convert the files automatically on submission. I am using SmartSVN - and there it works that way... What I don't know exactly is whether this is an option of SmartSVN or the underlying base SVN client software...!?