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

[kxml_compiler]Fix segfault when parsing an XSD containing a sequence type rootitem #49

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

martonmiklos
Copy link
Collaborator

The kxml_compiler segfaulted when generated code from an XSD where the root element was a complexType which was a sequence of elements. This was becasuse the subelements was not added by the schema/parser class during the parse.

@martonmiklos martonmiklos force-pushed the fix_sequence_root_item_parsing branch 2 times, most recently from bb0b86e to 2e65897 Compare May 1, 2020 17:32
XSD where the root element was a complexType which was a sequence of
elements. This was becasuse the subelements was not added by the schema/
parser class during the parse.
@martonmiklos martonmiklos force-pushed the fix_sequence_root_item_parsing branch from 2e65897 to 070423a Compare May 1, 2020 18:44
@@ -260,7 +260,8 @@ ClassDescription Creator::createClassDescription(const Schema::Element &element)

QString targetClassName = Namer::getClassName(targetElement.name());

if (targetElement.text() && !targetElement.hasAttributeRelations() && !r.isList()) {
if ((targetElement.text() || targetElement.type() < Schema::Element::ComplexType)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why < and not just !=?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why < and not just !=?

Makes sense I will fix it!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This probably means there's no need for it to be last anymore, i.e. you could revert the change to the enum, unless I'm missing something?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. When I started to work on this I was not 100% confident that no other kind of types needs to be treated similar to complexTypes. But at the end it turned out that no need for that.

Also it might be useful to remove/refactor the Schema::Element::text in this PR because I think the name 'text' is a bit misleading and from the type (complexType or not) and from the number of attributes and relations it is possible to determine that a simple C++ type (QString/int/something similar) member or a class representing the questioned element shall be generated.

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

Successfully merging this pull request may close these issues.

2 participants