qapi: Fix to reject optional members with reserved names

check_type() fails to reject optional members with reserved names,
because it neglects to strip off the leading '*'. Fix that.

The strippin

qapi: Fix to reject optional members with reserved names

check_type() fails to reject optional members with reserved names,
because it neglects to strip off the leading '*'. Fix that.

The stripping in check_name_str() is now useless. Drop.

Also drop the "no leading '*'" assertion, because valid_name.match()
ensures it can't fail.

Fixes: 9fb081e0b98409556d023c7193eeb68947cd1211
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20210323094025.3569441-8-armbru@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>

show more ...

tests/qapi-schema: Tweak to demonstrate buggy member name check

Member name 'u' and names starting with 'has-' or 'has_' are reserved
for the generator. check_type() enforces this, covered by tests

tests/qapi-schema: Tweak to demonstrate buggy member name check

Member name 'u' and names starting with 'has-' or 'has_' are reserved
for the generator. check_type() enforces this, covered by tests
reserved-member-u and reserved-member-has.

These tests neglect to cover optional members, where the name starts
with '*'. Tweak reserved-member-u to fix that. Test
reserved-member-has still covers non-optional members.

This demonstrates the reserved member name check is broken for
optional members. The next commit will fix it.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20210323094025.3569441-7-armbru@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
[Commit message improved slightly]

show more ...

Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2015-11-02' into staging

QAPI patches

# gpg: Signature made Mon 02 Nov 2015 09:07:23 GMT using RSA key ID EB918653
# gpg: Good signature

Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2015-11-02' into staging

QAPI patches

# gpg: Signature made Mon 02 Nov 2015 09:07:23 GMT using RSA key ID EB918653
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>"
# gpg: aka "Markus Armbruster <armbru@pond.sub.org>"

* remotes/armbru/tags/pull-qapi-2015-11-02: (25 commits)
qapi: Simplify gen_struct_field()
qapi: Reserve 'u' member name
qapi: Finish converting to new qapi union layout
tpm: Convert to new qapi union layout
memory: Convert to new qapi union layout
input: Convert to new qapi union layout
char: Convert to new qapi union layout
net: Convert to new qapi union layout
sockets: Convert to new qapi union layout
block: Convert to new qapi union layout
tests: Convert to new qapi union layout
qapi-visit: Convert to new qapi union layout
qapi: Start converting to new qapi union layout
qapi-visit: Remove redundant functions for flat union base
qapi: Unbox base members
qapi: Prefer typesafe upcasts to qapi base classes
qapi-types: Refactor base fields output
qapi-visit: Split off visit_type_FOO_fields forward decl
vnc: Hoist allocation of VncBasicInfo to callers
qapi: Reserve 'q_*' and 'has_*' member names
...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

show more ...

qapi: Reserve 'u' member name

Now that we have separated union tag values from colliding with
non-variant C names, by naming the union 'u', we should reserve
this name for our use. Note that we wan

qapi: Reserve 'u' member name

Now that we have separated union tag values from colliding with
non-variant C names, by naming the union 'u', we should reserve
this name for our use. Note that we want to forbid 'u' even in
a struct with no variants, because it is possible for a future
qemu release to extend QMP in a backwards-compatible manner while
converting from a struct to a flat union. Fortunately, no
existing clients were using this member name. If we ever find
the need for QMP to have a member 'u', we could at that time
relax things, perhaps by having c_name() munge the QMP member to
'q_u'.

Note that we cannot forbid 'u' everywhere (by adding the
rejection code to check_name()), because the existing QKeyCode
enum already uses it; therefore we only reserve it as a struct
type member name.

Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1445898903-12082-24-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>

show more ...