All of lore.kernel.org
 help / color / mirror / Atom feed
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: tim@xen.org, xen-devel@lists.xen.org, keir@xen.org,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: Re: [PATCH] xen: Minor modifications to platform.h to make it C++-friendly
Date: Mon, 23 Feb 2015 12:31:26 +0200	[thread overview]
Message-ID: <54EB017E.5000509@bitdefender.com> (raw)
In-Reply-To: <54EB0C0F0200007800062651@mail.emea.novell.com>

On 02/23/2015 12:16 PM, Jan Beulich wrote:
>>>> On 23.02.15 at 10:34, <rcojocaru@bitdefender.com> wrote:
>> Moved the definition of struct xenpf_efi_guid up, and rearranged
>> struct xenpf_efi_time in the containing union to avoid compilation
>> errors with C++ (structs defined inside unnamed structs become
>> unavailable outside their scope with C++). The change allows C++
>> applications to use platform.h with no consequences for current
>> C clients.
> 
> What's wrong with simply naming the union/struct, making for a
> much smaller change?

The bigger issue is not that the containing struct is unnamed, it is
that from C++'s standpoint the inner struct needs to be explictly
qualified, as if it were in a namespace. The fact that the outer struct
is unnamed makes it impossible to refer to the inner struct, but even if
it were possible to refer to it (by naming the outer struct), it would
still not be valid C code (and the change would arguably not be much
smaller anyway):

154 #define XEN_EFI_GET_TIME_SET_CLEARS_NS 0x00000001
155         struct get_time_t {
156             struct xenpf_efi_time {
157                 uint16_t year;
158                 uint8_t month;
159                 uint8_t day;
160                 uint8_t hour;
161                 uint8_t min;
162                 uint8_t sec;
163                 uint32_t ns;
164                 int16_t tz;
165                 uint8_t daylight;
166             } time;
167             uint32_t resolution;
168             uint32_t accuracy;
169         } get_time;
170
171         struct get_time_t::xenpf_efi_time set_time;
172
173 #define XEN_EFI_GET_WAKEUP_TIME_ENABLED 0x00000001
174 #define XEN_EFI_GET_WAKEUP_TIME_PENDING 0x00000002
175         struct get_time_t::xenpf_efi_time get_wakeup_time;
176
177 #define XEN_EFI_SET_WAKEUP_TIME_ENABLE      0x00000001
178 #define XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY 0x00000002
179         struct get_time_t::xenpf_efi_time set_wakeup_time;

This is why I think the proposed solution works best for everyone.

>> @@ -152,24 +159,24 @@ struct xenpf_efi_runtime_call {
>>      xen_ulong_t status;
>>      union {
>>  #define XEN_EFI_GET_TIME_SET_CLEARS_NS 0x00000001
>> +        struct xenpf_efi_time {
>> +            uint16_t year;
>> +            uint8_t month;
>> +            uint8_t day;
>> +            uint8_t hour;
>> +            uint8_t min;
>> +            uint8_t sec;
>> +            uint32_t ns;
>> +            int16_t tz;
>> +            uint8_t daylight;
>> +        } set_time;
>> +
> 
> If we were to go this proposed route, the insertion would need
> to happen above the #define.

Of course, if there are no other objections I'll move it above the
#define and submit V2.


Thanks,
Razvan

  reply	other threads:[~2015-02-23 10:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-23  9:34 [PATCH] xen: Minor modifications to platform.h to make it C++-friendly Razvan Cojocaru
2015-02-23 10:16 ` Jan Beulich
2015-02-23 10:31   ` Razvan Cojocaru [this message]
2015-02-23 10:54     ` Jan Beulich
2015-02-23 11:05       ` Razvan Cojocaru
2015-02-23 11:16         ` Jan Beulich
2015-02-23 11:09       ` Tim Deegan
2015-02-23 11:24         ` Jan Beulich
2015-02-23 11:24       ` Razvan Cojocaru

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54EB017E.5000509@bitdefender.com \
    --to=rcojocaru@bitdefender.com \
    --cc=JBeulich@suse.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.