Eric Blake writes:
> On 11/13/2015 11:13 AM, Markus Armbruster wrote:
>
>> We need c_name() to protect ticklish identifiers only when its result is
>> used as identifier. Not when it's *part* of an identifier,
>> e.g. prefixed with qapi_, or camel_to_upper(type_name) + '_'.
>>
>> We can protect
On 11/13/2015 11:13 AM, Markus Armbruster wrote:
> We need c_name() to protect ticklish identifiers only when its result is
> used as identifier. Not when it's *part* of an identifier,
> e.g. prefixed with qapi_, or camel_to_upper(type_name) + '_'.
>
> We can protect even when we don't need to,
Eric Blake writes:
> On 11/10/2015 11:51 PM, Eric Blake wrote:
>> When munging enum values, the fact that we were passing the entire
>> prefix + value through camel_to_upper() meant that enum values
>> spelled with CamelCase could be turned into CAMEL_CASE. However,
>> this provides a potential
On 11/10/2015 11:51 PM, Eric Blake wrote:
> When munging enum values, the fact that we were passing the entire
> prefix + value through camel_to_upper() meant that enum values
> spelled with CamelCase could be turned into CAMEL_CASE. However,
> this provides a potential collision (both OneTwo and
Gerd Hoffmann writes:
> Hi,
>
>> > If desired, I can prepare an alternate patch that adds the dash to the
>> > qapi enum definition, to see what we think.
>>
>> If Gerd is fine with the rename, let's do it.
>
> No need to do so I think ...
>
>> >> -[INPUT_BUTTON_WHEEL_UP] = SDL_BUTTON(
Hi,
> > If desired, I can prepare an alternate patch that adds the dash to the
> > qapi enum definition, to see what we think.
>
> If Gerd is fine with the rename, let's do it.
No need to do so I think ...
> >> -[INPUT_BUTTON_WHEEL_UP] = SDL_BUTTON(SDL_BUTTON_WHEELUP),
> >> -[
Hi,
> The InputButton type has existed since 2.0; which is then part of the
> 'InputBtnEvent' struct, then the 'InputEvent' union, also since 2.0. I
> can't easily tell if it was only used internally at that point,
Internal only.
> 'x-input-send-event' (since 2.2, but the x- prefix gives us f
Eric Blake writes:
> [hmm, wonder why scripts/get-maintainer.pl didn't loop in Gerd to the
> patch itself]
>
> On 11/11/2015 07:50 AM, Markus Armbruster wrote:
>> Eric Blake writes:
>>
>>> When munging enum values, the fact that we were passing the entire
>>> prefix + value through camel_to_upp
On 11/11/2015 07:50 AM, Markus Armbruster wrote:
>> Thankfully, only two enums are affected: ErrorClass and InputButton.
[Visiting just ErrorClass in this email]
>
> By convention (see CODING_STYLE), we use CamelCase for type names, and
> nothing else.
>
> Only enums violating this naming conv
[hmm, wonder why scripts/get-maintainer.pl didn't loop in Gerd to the
patch itself]
On 11/11/2015 07:50 AM, Markus Armbruster wrote:
> Eric Blake writes:
>
>> When munging enum values, the fact that we were passing the entire
>> prefix + value through camel_to_upper() meant that enum values
>> s
Eric Blake writes:
> When munging enum values, the fact that we were passing the entire
> prefix + value through camel_to_upper() meant that enum values
> spelled with CamelCase could be turned into CAMEL_CASE. However,
> this provides a potential collision (both OneTwo and One-Two would
> munge
Am 11.11.2015 um 07:51 schrieb Eric Blake:
> When munging enum values, the fact that we were passing the entire
> prefix + value through camel_to_upper() meant that enum values
> spelled with CamelCase could be turned into CAMEL_CASE. However,
> this provides a potential collision (both OneTwo and
When munging enum values, the fact that we were passing the entire
prefix + value through camel_to_upper() meant that enum values
spelled with CamelCase could be turned into CAMEL_CASE. However,
this provides a potential collision (both OneTwo and One-Two would
munge into ONE_TWO). By changing th
13 matches
Mail list logo
