Please submit a simple reproducible example that demonstrates the crash.
I just opened your file (with new line removed) in FireFox, which uses Expat, and had no crash. Also, given that Expat is used i n millions of installations, we would have heard of this earlier. I am inclined to reject this bug report unless I can see a reproducible example.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Scenario: install GoogleEarth for linux and try to start it, make sure you have .drirc without newline at the end (for me it's crashing on start with error).
Then add newline at the end of this file and start GoogleEarth again (for me it starts fine).
On my system (x86_64 linux with lib32-expat installed) it is fully reproducible.
Feel free to ask for more details if you need to.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First: Installing GoogleEarth and running it is not a simple example to demonstrate the bug in Expat.
Secondly: this example proves nothing, as there are so many components involved that anyone of them could be to blame.
So many unanswered questions: How is the code written that uses Expat to process the file, is a call-back handler expecting the end of line and crashes because of it, is there some pre or post-processing done on the file, what are the runtime libraries installed, etc. etc.
Also, the link you mentioned offers a few solutions, some of them simply replacing another Dll with no hint that XML parsing is even involved.
As I said, a simple example that involves only Expat and some C code is necessary to prove that an XML file without newline at end of file will cause a crash.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I don't know for sure if this is expat bug. I'm not so familiar with C as to produce scenario that you speak of, this example with GoogleEarth is the best I can do. Do whatever you like with this information, if you think there's nothing to gain from it - throw it out :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please submit a simple reproducible example that demonstrates the crash.
I just opened your file (with new line removed) in FireFox, which uses Expat, and had no crash. Also, given that Expat is used i n millions of installations, we would have heard of this earlier. I am inclined to reject this bug report unless I can see a reproducible example.
Scenario: install GoogleEarth for linux and try to start it, make sure you have .drirc without newline at the end (for me it's crashing on start with error).
Then add newline at the end of this file and start GoogleEarth again (for me it starts fine).
On my system (x86_64 linux with lib32-expat installed) it is fully reproducible.
Feel free to ask for more details if you need to.
First: Installing GoogleEarth and running it is not a simple example to demonstrate the bug in Expat.
Secondly: this example proves nothing, as there are so many components involved that anyone of them could be to blame.
So many unanswered questions: How is the code written that uses Expat to process the file, is a call-back handler expecting the end of line and crashes because of it, is there some pre or post-processing done on the file, what are the runtime libraries installed, etc. etc.
Also, the link you mentioned offers a few solutions, some of them simply replacing another Dll with no hint that XML parsing is even involved.
As I said, a simple example that involves only Expat and some C code is necessary to prove that an XML file without newline at end of file will cause a crash.
Well, I don't know for sure if this is expat bug. I'm not so familiar with C as to produce scenario that you speak of, this example with GoogleEarth is the best I can do. Do whatever you like with this information, if you think there's nothing to gain from it - throw it out :)
Closing this, no proper followup to demonstrate a bug.