All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PULL for-1.7 v2 3/6] acpi-build: fix build on glib < 2.22
Date: Mon, 25 Nov 2013 22:15:40 +0100	[thread overview]
Message-ID: <5293BDFC.1020208@redhat.com> (raw)
In-Reply-To: <20131125205404.GF12689@redhat.com>

On 11/25/13 21:54, Michael S. Tsirkin wrote:
> On Tue, Nov 26, 2013 at 06:37:43AM +1000, Richard Henderson wrote:
>> On 11/26/2013 06:31 AM, Michael S. Tsirkin wrote:
>>> On Tue, Nov 26, 2013 at 06:24:53AM +1000, Richard Henderson wrote:
>>>> On 11/25/2013 09:48 PM, Michael S. Tsirkin wrote:
>>>>> g_string_vprintf was only introduced in 2.24 so switch to vsnprintf
>>>>> instead.  A bit uglier but name size is fixed at 4 bytes here so it's
>>>>> easy.
>>>>
>>>> You list 2.24 here,
>>>>
>>>>> -    GString *s = g_string_new("");
>>>>> +    /* It would be nicer to use g_string_vprintf but it's only there in 2.22 */
>>>>
>>>> ... 2.22 here.
>>>>
>>>> But https://developer.gnome.org/glib/2.28/glib-Strings.html#g-string-vprintf
>>>>
>>>> says "since 2.14".
>>>>
>>>>> +    char s[] = "XXXX";
>>>>
>>>> char s[5];
>>>>
>>>> Initializing it is a waste of time.
>>>>
>>>>
>>>> r~
>>>
>>> It's sets the length in a nice way.
>>>
>>
>> Then do something like
>>
>>   char s[sizeof("XXXX")];
>>
>> so that the actual initialization doesn't happen.
>>
>>
>> r~
> 
> Why? As an optimization?
> I'm not quite sure this doesn't mean we are using VLA which I'd rather not.
> Would need to look at language spec ... simple initialization is shorter
> and more obviously correct.

No, it's not a VLA.

C99 6.7.5.2 Array declarators, p4:

    [...] If the size is an integer constant expression and the element
    type has a known constant size, the array type is not a variable
    length array type; [...]

6.6 Constant expressions, p6:

    An integer constant expression [...] shall have integer type and
    shall only have operands that are [...] sizeof expressions whose
    results are integer constants, [...]

6.5.3.4 The sizeof operator, p2:

    [...] The result is an integer. If the type of the operand is a
    variable length array type, the operand is evaluated; otherwise,
    the operand is not evaluated and the result is an integer constant.

6.4.5 String literals, p2:

    [...] The multibyte character sequence is then used to initialize
    an array of static storage duration and length just sufficient to
    contain the sequence. [...]

6.7.5.2 Array declarators, p2:

    [...] If an identifier is declared to be an object with static
    storage duration, it shall not have a variable length array type.

6.7.5.2 Array declarators, p10:

    EXAMPLE 4 [...] Array objects declared with the static or extern
    storage-class specifier cannot have a variable length array (VLA)
    type. [...]

So,

    char s[sizeof("XXXX")]
                  ^^^^^^
                  string literal, static storage duration, not a VLA

           ^^^^^^^^^^^^^^
           operand not evaluated, result is integer constant
           ... which qualifies as integer constant expression

    ^^^^^^^^^^^^^^^^^^^^^^
    size is an integer constant expression,
    element type has a known constant size: not a VLA

(Admittedly, EXAMPLE 4 in 6.7.5.2 Array declarators, p10, is informative
(not normative), and 6.7.5.2 Array declarators, p2, speaks about an
"identifier". We don't have an identifier for "XXXX", but I think we can
still derive that static storage duration implies non-variable length
for the array that holds the string.)

Laszlo

  reply	other threads:[~2013-11-25 21:15 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-25 11:48 [Qemu-devel] [PULL for-1.7 v2 0/5] pc very last minute fixes for 1.7 Michael S. Tsirkin
2013-11-25 11:48 ` [Qemu-devel] [PULL for-1.7 v2 1/6] s390x: fix flat file load on 32 bit systems Michael S. Tsirkin
2013-11-25 11:48 ` [Qemu-devel] [PULL for-1.7 v2 2/6] pci: unregister vmstate_pcibus on unplug Michael S. Tsirkin
2013-11-25 11:48 ` [Qemu-devel] [PULL for-1.7 v2 3/6] acpi-build: fix build on glib < 2.22 Michael S. Tsirkin
2013-11-25 20:24   ` Richard Henderson
2013-11-25 20:31     ` Michael S. Tsirkin
2013-11-25 20:37       ` Richard Henderson
2013-11-25 20:54         ` Michael S. Tsirkin
2013-11-25 21:15           ` Laszlo Ersek [this message]
2013-11-25 21:22             ` Eric Blake
2013-11-25 21:18           ` Richard Henderson
2013-11-25 21:26             ` Michael S. Tsirkin
2013-11-25 21:02         ` Michael S. Tsirkin
2013-11-25 21:21           ` Richard Henderson
2013-11-25 21:33             ` Michael S. Tsirkin
2013-11-25 21:57               ` Laszlo Ersek
2013-11-25 11:48 ` [Qemu-devel] [PULL for-1.7 v2 4/6] acpi-build: fix build on glib < 2.14 Michael S. Tsirkin
2013-11-25 20:14   ` Erik Rull
2013-11-25 20:59     ` Michael S. Tsirkin
2013-11-25 21:01     ` Michael S. Tsirkin
2013-11-25 21:47       ` Richard Henderson
2013-11-25 22:41         ` Erik Rull
2013-11-25 20:26   ` Richard Henderson
2013-11-25 11:48 ` [Qemu-devel] [PULL for-1.7 v2 5/6] Revert "e1000/rtl8139: update HMP NIC when every bit is written" Michael S. Tsirkin
2013-11-25 11:48 ` [Qemu-devel] [PULL for-1.7 v2 6/6] configure: make --iasl option actually work Michael S. Tsirkin

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=5293BDFC.1020208@redhat.com \
    --to=lersek@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@redhat.com \
    /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.