Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Saving an empty (no elements) document yields an empty file and no error #614

Open
Dmitry-Me opened this issue Aug 30, 2017 · 3 comments
Open
Assignees
Labels

Comments

@Dmitry-Me
Copy link
Contributor

This code:

XMLDocument doc;
doc.SaveFile( "some/valid/path.xml" );

yields an empty file on disk and XMLDocument::Error() being false. Is that expected?

@leethomason
Copy link
Owner

Good question. Well, 3 questions:

  1. Should we save or not save?
  2. Is saving something empty an error?
  3. Should we write the xml encoding declaration?

Actually my initial reaction is that the code should 1) save, 2) no error, and 3) yes, and the file produced is:

<?xml version="1.0" encoding="UTF-8"?>

But that would mean that a new document would be created with the encoding declaration. Which may be correct and would be replaced on load (to whatever is in the loaded file.) I'm a little concerned about breaking existing uses - specifically people who are adding the declaration by hand. So that's one meta question: should we insert that by default?

You question though is: what should we do now? I'd argue that the existing behavior is correct. The user created an empty XML file, saved it, and it resulted in an empty file. TinyXML-2 is being less helpful than it should, but I'm hesitant to introduce (more) behavior that conflicts with a future fix (if we create the encoding declaration.)

Thoughts? This is an edge case, but raises tricky issues about default behavior.

@Dmitry-Me
Copy link
Contributor Author

The empty cannot be loaded afterwards - that's why there's "empty.xml" in the testset. So the current implementation is happy to save an empty document but then will not load the result of such saving.

@leethomason leethomason self-assigned this Sep 18, 2017
@leethomason
Copy link
Owner

Spent some time looking at this. I acknowledge the bug; however, there are already test cases enforcing the asymmetric behavior. The only real answer I see is "injecting" the declaration and that's going to cause all sorts of trouble.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants