[Qemu-devel] [patch 1/2] machine struct - use C99 initializers

[Qemu-devel] [patch 1/2] machine struct - use C99 initializers

[Jes Sorensen]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

Hi,

Here's an updated version to my machine struct patch. I've split it in
two so it is easier to validiate and track.

This patch simply converts all the machine structs to use C99 style
initializers. There is no actual code change in this.

Next I will follow up with the one that does the conversion of max_cpus.

Cheers,
Jes

[-- Attachment #2: 0050-qemu-machine-c99-initializers.patch --]
[-- Type: text/plain, Size: 12688 bytes --]

Modify all the machine struct declarations to use C99 initializers.
This patch has no functional changes.

Signed-off-by: Jes Sorensen <jes@sgi.com>

---
 hw/an5206.c        |    8 ++++----
 hw/dummy_m68k.c    |    6 +++---
 hw/etraxfs.c       |    8 ++++----
 hw/gumstix.c       |   16 ++++++++--------
 hw/integratorcp.c  |    8 ++++----
 hw/mainstone.c     |   10 +++++-----
 hw/mcf5208.c       |    8 ++++----
 hw/musicpal.c      |    8 ++++----
 hw/nseries.c       |   16 ++++++++--------
 hw/palm.c          |    8 ++++----
 hw/ppc405_boards.c |    8 ++++----
 hw/ppc_chrp.c      |    8 ++++----
 hw/ppc_oldworld.c  |    8 ++++----
 hw/ppc_prep.c      |    8 ++++----
 hw/r2d.c           |    8 ++++----
 hw/shix.c          |    8 ++++----
 hw/spitz.c         |   32 ++++++++++++++++----------------
 hw/stellaris.c     |   16 ++++++++--------
 hw/tosa.c          |    8 ++++----
 19 files changed, 100 insertions(+), 100 deletions(-)

Index: qemu/hw/an5206.c
===================================================================
--- qemu.orig/hw/an5206.c
+++ qemu/hw/an5206.c
@@ -88,8 +88,8 @@ static void an5206_init(ram_addr_t ram_s
 }
 
 QEMUMachine an5206_machine = {
-    "an5206",
-    "Arnewsh 5206",
-    an5206_init,
-    512,
+    .name = "an5206",
+    .desc = "Arnewsh 5206",
+    .init = an5206_init,
+    .ram_require = 512,
 };
Index: qemu/hw/dummy_m68k.c
===================================================================
--- qemu.orig/hw/dummy_m68k.c
+++ qemu/hw/dummy_m68k.c
@@ -63,7 +63,7 @@ static void dummy_m68k_init(ram_addr_t r
 }
 
 QEMUMachine dummy_m68k_machine = {
-    "dummy",
-    "Dummy board",
-    dummy_m68k_init,
+    .name = "dummy",
+    .desc = "Dummy board",
+    .init = dummy_m68k_init,
 };
Index: qemu/hw/etraxfs.c
===================================================================
--- qemu.orig/hw/etraxfs.c
+++ qemu/hw/etraxfs.c
@@ -141,8 +141,8 @@ void bareetraxfs_init (ram_addr_t ram_si
 }
 
 QEMUMachine bareetraxfs_machine = {
-    "bareetraxfs",
-    "Bare ETRAX FS board",
-    bareetraxfs_init,
-    0x8000000,
+    .name = "bareetraxfs",
+    .desc = "Bare ETRAX FS board",
+    .init = bareetraxfs_init,
+    .ram_require = 0x8000000,
 };
Index: qemu/hw/gumstix.c
===================================================================
--- qemu.orig/hw/gumstix.c
+++ qemu/hw/gumstix.c
@@ -122,15 +122,15 @@ static void verdex_init(ram_addr_t ram_s
 }
 
 QEMUMachine connex_machine = {
-    "connex",
-    "Gumstix Connex (PXA255)",
-    connex_init,
-    (0x05000000 + PXA2XX_INTERNAL_SIZE) | RAMSIZE_FIXED,
+    .name = "connex",
+    .desc = "Gumstix Connex (PXA255)",
+    .init = connex_init,
+    .ram_require = (0x05000000 + PXA2XX_INTERNAL_SIZE) | RAMSIZE_FIXED,
 };
 
 QEMUMachine verdex_machine = {
-    "verdex",
-    "Gumstix Verdex (PXA270)",
-    verdex_init,
-    (0x12000000 + PXA2XX_INTERNAL_SIZE) | RAMSIZE_FIXED,
+    .name = "verdex",
+    .desc = "Gumstix Verdex (PXA270)",
+    .init = verdex_init,
+    .ram_require = (0x12000000 + PXA2XX_INTERNAL_SIZE) | RAMSIZE_FIXED,
 };
Index: qemu/hw/integratorcp.c
===================================================================
--- qemu.orig/hw/integratorcp.c
+++ qemu/hw/integratorcp.c
@@ -540,8 +540,8 @@ static void integratorcp_init(ram_addr_t
 }
 
 QEMUMachine integratorcp_machine = {
-    "integratorcp",
-    "ARM Integrator/CP (ARM926EJ-S)",
-    integratorcp_init,
-    0x100000,
+    .name = "integratorcp",
+    .desc = "ARM Integrator/CP (ARM926EJ-S)",
+    .init = integratorcp_init,
+    .ram_require = 0x100000,
 };
Index: qemu/hw/mainstone.c
===================================================================
--- qemu.orig/hw/mainstone.c
+++ qemu/hw/mainstone.c
@@ -144,9 +144,9 @@ static void mainstone_init(ram_addr_t ra
 }
 
 QEMUMachine mainstone2_machine = {
-    "mainstone",
-    "Mainstone II (PXA27x)",
-    mainstone_init,
-    (MAINSTONE_RAM + MAINSTONE_ROM + 2 * MAINSTONE_FLASH +
-     PXA2XX_INTERNAL_SIZE) | RAMSIZE_FIXED,
+    .name = "mainstone",
+    .desc = "Mainstone II (PXA27x)",
+    .init = mainstone_init,
+    .ram_require = (MAINSTONE_RAM + MAINSTONE_ROM + 2 * MAINSTONE_FLASH +
+		    PXA2XX_INTERNAL_SIZE) | RAMSIZE_FIXED,
 };
Index: qemu/hw/mcf5208.c
===================================================================
--- qemu.orig/hw/mcf5208.c
+++ qemu/hw/mcf5208.c
@@ -305,8 +305,8 @@ static void mcf5208evb_init(ram_addr_t r
 }
 
 QEMUMachine mcf5208evb_machine = {
-    "mcf5208evb",
-    "MCF5206EVB",
-    mcf5208evb_init,
-    16384,
+    .name = "mcf5208evb",
+    .desc = "MCF5206EVB",
+    .init = mcf5208evb_init,
+    .ram_require = 16384,
 };
Index: qemu/hw/musicpal.c
===================================================================
--- qemu.orig/hw/musicpal.c
+++ qemu/hw/musicpal.c
@@ -1509,8 +1509,8 @@ static void musicpal_init(ram_addr_t ram
 }
 
 QEMUMachine musicpal_machine = {
-    "musicpal",
-    "Marvell 88w8618 / MusicPal (ARM926EJ-S)",
-    musicpal_init,
-    MP_RAM_DEFAULT_SIZE + MP_SRAM_SIZE + MP_FLASH_SIZE_MAX + RAMSIZE_FIXED
+    .name = "musicpal",
+    .desc = "Marvell 88w8618 / MusicPal (ARM926EJ-S)",
+    .init = musicpal_init,
+    .ram_require = MP_RAM_DEFAULT_SIZE + MP_SRAM_SIZE + MP_FLASH_SIZE_MAX + RAMSIZE_FIXED,
 };
Index: qemu/hw/nseries.c
===================================================================
--- qemu.orig/hw/nseries.c
+++ qemu/hw/nseries.c
@@ -1404,15 +1404,15 @@ static void n810_init(ram_addr_t ram_siz
 }
 
 QEMUMachine n800_machine = {
-    "n800",
-    "Nokia N800 tablet aka. RX-34 (OMAP2420)",
-    n800_init,
-    (0x08000000 + 0x00010000 + OMAP242X_SRAM_SIZE) | RAMSIZE_FIXED,
+    .name = "n800",
+    .desc = "Nokia N800 tablet aka. RX-34 (OMAP2420)",
+    .init = n800_init,
+    .ram_require = (0x08000000 + 0x00010000 + OMAP242X_SRAM_SIZE) | RAMSIZE_FIXED,
 };
 
 QEMUMachine n810_machine = {
-    "n810",
-    "Nokia N810 tablet aka. RX-44 (OMAP2420)",
-    n810_init,
-    (0x08000000 + 0x00010000 + OMAP242X_SRAM_SIZE) | RAMSIZE_FIXED,
+    .name = "n810",
+    .desc = "Nokia N810 tablet aka. RX-44 (OMAP2420)",
+    .init = n810_init,
+    .ram_require = (0x08000000 + 0x00010000 + OMAP242X_SRAM_SIZE) | RAMSIZE_FIXED,
 };
Index: qemu/hw/palm.c
===================================================================
--- qemu.orig/hw/palm.c
+++ qemu/hw/palm.c
@@ -282,8 +282,8 @@ static void palmte_init(ram_addr_t ram_s
 }
 
 QEMUMachine palmte_machine = {
-    "cheetah",
-    "Palm Tungsten|E aka. Cheetah PDA (OMAP310)",
-    palmte_init,
-    (0x02000000 + 0x00800000 + OMAP15XX_SRAM_SIZE) | RAMSIZE_FIXED,
+    .name = "cheetah",
+    .desc = "Palm Tungsten|E aka. Cheetah PDA (OMAP310)",
+    .init = palmte_init,
+    .ram_require = (0x02000000 + 0x00800000 + OMAP15XX_SRAM_SIZE) | RAMSIZE_FIXED,
 };
Index: qemu/hw/ppc405_boards.c
===================================================================
--- qemu.orig/hw/ppc405_boards.c
+++ qemu/hw/ppc405_boards.c
@@ -357,10 +357,10 @@ static void ref405ep_init (ram_addr_t ra
 }
 
 QEMUMachine ref405ep_machine = {
-    "ref405ep",
-    "ref405ep",
-    ref405ep_init,
-    (128 * 1024 * 1024 + 4096 + 512 * 1024 + BIOS_SIZE) | RAMSIZE_FIXED,
+    .name = "ref405ep",
+    .desc = "ref405ep",
+    .init = ref405ep_init,
+    .ram_require = (128 * 1024 * 1024 + 4096 + 512 * 1024 + BIOS_SIZE) | RAMSIZE_FIXED,
 };
 
 /*****************************************************************************/
Index: qemu/hw/ppc_chrp.c
===================================================================
--- qemu.orig/hw/ppc_chrp.c
+++ qemu/hw/ppc_chrp.c
@@ -331,8 +331,8 @@ static void ppc_core99_init (ram_addr_t 
 }
 
 QEMUMachine core99_machine = {
-    "mac99",
-    "Mac99 based PowerMAC",
-    ppc_core99_init,
-    BIOS_SIZE + VGA_RAM_SIZE,
+    .name = "mac99",
+    .desc = "Mac99 based PowerMAC",
+    .init = ppc_core99_init,
+    .ram_require = BIOS_SIZE + VGA_RAM_SIZE,
 };
Index: qemu/hw/ppc_oldworld.c
===================================================================
--- qemu.orig/hw/ppc_oldworld.c
+++ qemu/hw/ppc_oldworld.c
@@ -366,8 +366,8 @@ static void ppc_heathrow_init (ram_addr_
 }
 
 QEMUMachine heathrow_machine = {
-    "g3bw",
-    "Heathrow based PowerMAC",
-    ppc_heathrow_init,
-    BIOS_SIZE + VGA_RAM_SIZE,
+    .name = "g3bw",
+    .desc = "Heathrow based PowerMAC",
+    .init = ppc_heathrow_init,
+    .ram_require = BIOS_SIZE + VGA_RAM_SIZE,
 };
Index: qemu/hw/ppc_prep.c
===================================================================
--- qemu.orig/hw/ppc_prep.c
+++ qemu/hw/ppc_prep.c
@@ -760,8 +760,8 @@ static void ppc_prep_init (ram_addr_t ra
 }
 
 QEMUMachine prep_machine = {
-    "prep",
-    "PowerPC PREP platform",
-    ppc_prep_init,
-    BIOS_SIZE + VGA_RAM_SIZE,
+    .name = "prep",
+    .desc = "PowerPC PREP platform",
+    .init = ppc_prep_init,
+    .ram_require = BIOS_SIZE + VGA_RAM_SIZE,
 };
Index: qemu/hw/r2d.c
===================================================================
--- qemu.orig/hw/r2d.c
+++ qemu/hw/r2d.c
@@ -164,8 +164,8 @@ static void r2d_init(ram_addr_t ram_size
 }
 
 QEMUMachine r2d_machine = {
-    "r2d",
-    "r2d-plus board",
-    r2d_init,
-    SDRAM_SIZE | RAMSIZE_FIXED
+    .name = "r2d",
+    .desc = "r2d-plus board",
+    .init = r2d_init,
+    .ram_require = SDRAM_SIZE | RAMSIZE_FIXED,
 };
Index: qemu/hw/shix.c
===================================================================
--- qemu.orig/hw/shix.c
+++ qemu/hw/shix.c
@@ -108,8 +108,8 @@ static void shix_init(ram_addr_t ram_siz
 }
 
 QEMUMachine shix_machine = {
-    "shix",
-    "shix card",
-    shix_init,
-    (0x00004000 + 0x01000000 + 0x01000000) | RAMSIZE_FIXED
+    .name = "shix",
+    .desc = "shix card",
+    .init = shix_init,
+    .ram_require = (0x00004000 + 0x01000000 + 0x01000000) | RAMSIZE_FIXED,
 };
Index: qemu/hw/spitz.c
===================================================================
--- qemu.orig/hw/spitz.c
+++ qemu/hw/spitz.c
@@ -1010,29 +1010,29 @@ static void terrier_init(ram_addr_t ram_
 }
 
 QEMUMachine akitapda_machine = {
-    "akita",
-    "Akita PDA (PXA270)",
-    akita_init,
-    SPITZ_RAM + SPITZ_ROM + PXA2XX_INTERNAL_SIZE + RAMSIZE_FIXED,
+    .name = "akita",
+    .desc = "Akita PDA (PXA270)",
+    .init = akita_init,
+    .ram_require = SPITZ_RAM + SPITZ_ROM + PXA2XX_INTERNAL_SIZE + RAMSIZE_FIXED,
 };
 
 QEMUMachine spitzpda_machine = {
-    "spitz",
-    "Spitz PDA (PXA270)",
-    spitz_init,
-    SPITZ_RAM + SPITZ_ROM + PXA2XX_INTERNAL_SIZE + RAMSIZE_FIXED,
+    .name = "spitz",
+    .desc = "Spitz PDA (PXA270)",
+    .init = spitz_init,
+    .ram_require = SPITZ_RAM + SPITZ_ROM + PXA2XX_INTERNAL_SIZE + RAMSIZE_FIXED,
 };
 
 QEMUMachine borzoipda_machine = {
-    "borzoi",
-    "Borzoi PDA (PXA270)",
-    borzoi_init,
-    SPITZ_RAM + SPITZ_ROM + PXA2XX_INTERNAL_SIZE + RAMSIZE_FIXED,
+    .name = "borzoi",
+    .desc = "Borzoi PDA (PXA270)",
+    .init = borzoi_init,
+    .ram_require = SPITZ_RAM + SPITZ_ROM + PXA2XX_INTERNAL_SIZE + RAMSIZE_FIXED,
 };
 
 QEMUMachine terrierpda_machine = {
-    "terrier",
-    "Terrier PDA (PXA270)",
-    terrier_init,
-    SPITZ_RAM + SPITZ_ROM + PXA2XX_INTERNAL_SIZE + RAMSIZE_FIXED,
+    .name = "terrier",
+    .desc = "Terrier PDA (PXA270)",
+    .init = terrier_init,
+    .ram_require = SPITZ_RAM + SPITZ_ROM + PXA2XX_INTERNAL_SIZE + RAMSIZE_FIXED,
 };
Index: qemu/hw/stellaris.c
===================================================================
--- qemu.orig/hw/stellaris.c
+++ qemu/hw/stellaris.c
@@ -1413,15 +1413,15 @@ static void lm3s6965evb_init(ram_addr_t 
 }
 
 QEMUMachine lm3s811evb_machine = {
-    "lm3s811evb",
-    "Stellaris LM3S811EVB",
-    lm3s811evb_init,
-    (64 * 1024 + 8 * 1024) | RAMSIZE_FIXED,
+    .name = "lm3s811evb",
+    .desc = "Stellaris LM3S811EVB",
+    .init = lm3s811evb_init,
+    .ram_require = (64 * 1024 + 8 * 1024) | RAMSIZE_FIXED,
 };
 
 QEMUMachine lm3s6965evb_machine = {
-    "lm3s6965evb",
-    "Stellaris LM3S6965EVB",
-    lm3s6965evb_init,
-    (256 * 1024 + 64 * 1024) | RAMSIZE_FIXED,
+    .name = "lm3s6965evb",
+    .desc = "Stellaris LM3S6965EVB",
+    .init = lm3s6965evb_init,
+    .ram_require = (256 * 1024 + 64 * 1024) | RAMSIZE_FIXED,
 };
Index: qemu/hw/tosa.c
===================================================================
--- qemu.orig/hw/tosa.c
+++ qemu/hw/tosa.c
@@ -119,8 +119,8 @@ static void tosa_init(ram_addr_t ram_siz
 }
 
 QEMUMachine tosapda_machine = {
-    "tosa",
-    "Tosa PDA (PXA255)",
-    tosa_init,
-    TOSA_RAM + TOSA_ROM + PXA2XX_INTERNAL_SIZE + RAMSIZE_FIXED,
+    .name = "tosa",
+    .desc = "Tosa PDA (PXA255)",
+    .init = tosa_init,
+    .ram_require = TOSA_RAM + TOSA_ROM + PXA2XX_INTERNAL_SIZE + RAMSIZE_FIXED,
 };

Re: [Qemu-devel] [patch 1/2] machine struct - use C99 initializers

[Jes Sorensen]

Johannes Schindelin wrote:
>> This patch simply converts all the machine structs to use C99 style 
>> initializers. There is no actual code change in this.
> 
> Is it really such a good idea to do this?  I mean, the only real change 
> you make here is to break compilation on compilers that do not grok C99 
> (or do it badly).
> 
> Sure, it does not concern _you_.  You _obviously_ have a C99 compliant 
> compiler.

Ehm, what compiler does _not_ support C99 these days?

Point here is that using the proper initializers makes it a heck
of a lot easier to avoid bugs when a struct is extended, and it *does*
need to be extended.

> And do not even bother starting a discussion "but nobody has C89 compilers 
> anymore".  There are people out there, and you _will_ hear from them, and 
> _only_ when it is too late.

Sorry, but there is already plenty of use of C99 initializers in QEMU
today, the people who you refer to have either stopped building QEMU
or switched to a 21st century compiler.

> So maybe it is time to step back and defend why you need to "fix" 
> something that already works pretty well?  Or in the alternative, just 
> leave it?

Because it doesn't work well, it leaves a big hole open for bugs that
are much worse to fix than doing the right thing.

> P.S.: before somebody says that GCC is C99 compliant: search the mailing 
> list for the Beos GCC2 issue which was mentioned not long ago.

GCC is sufficiently C99 compliant to handle this style of initializers.
Maybe it's not C99 compliant enough for other stuff, but on this front
it does just fine.

Jes

Re: [Qemu-devel] [patch 1/2] machine struct - use C99 initializers

[Johannes Schindelin]

Hi,

On Mon, 6 Oct 2008, Jes Sorensen wrote:

> This patch simply converts all the machine structs to use C99 style 
> initializers. There is no actual code change in this.

Is it really such a good idea to do this?  I mean, the only real change 
you make here is to break compilation on compilers that do not grok C99 
(or do it badly).

Sure, it does not concern _you_.  You _obviously_ have a C99 compliant 
compiler.

And do not even bother starting a discussion "but nobody has C89 compilers 
anymore".  There are people out there, and you _will_ hear from them, and 
_only_ when it is too late.

So maybe it is time to step back and defend why you need to "fix" 
something that already works pretty well?  Or in the alternative, just 
leave it?

Ciao,
Dscho

P.S.: before somebody says that GCC is C99 compliant: search the mailing 
list for the Beos GCC2 issue which was mentioned not long ago.

Re: [Qemu-devel] [patch 1/2] machine struct - use C99 initializers

[Anthony Liguori]

Johannes Schindelin wrote:
> Hi,
>
> On Mon, 6 Oct 2008, Jes Sorensen wrote:
>
>   
>> Johannes Schindelin wrote:
>>
>>     
>>> P.S.: before somebody says that GCC is C99 compliant: search the 
>>> mailing list for the Beos GCC2 issue which was mentioned not long ago.
>>>       
>> GCC is sufficiently C99 compliant to handle this style of initializers. 
>> Maybe it's not C99 compliant enough for other stuff, but on this front 
>> it does just fine.
>>     
>
> I just wish you would have researched a bit better.  (And no, adding to 
> the pile does not make your intention any better.)
>
> Nobody ever disputed that _you_ have no problem with your patch.
>   

FWIW, we already use this feature in QEMU.  Is there a specific compiler 
you're concerned about?  QEMU won't compile on a compiler that doesn't 
support this construct right now and hasn't been able to for a very long 
time (years, if ever).

Regards,

Anthony Liguori

> Sigh,
> Dscho
>
>   

Re: [Qemu-devel] [patch 1/2] machine struct - use C99 initializers

[Johannes Schindelin]

Hi,

On Mon, 6 Oct 2008, Jes Sorensen wrote:

> Johannes Schindelin wrote:
> 
> > P.S.: before somebody says that GCC is C99 compliant: search the 
> > mailing list for the Beos GCC2 issue which was mentioned not long ago.
> 
> GCC is sufficiently C99 compliant to handle this style of initializers. 
> Maybe it's not C99 compliant enough for other stuff, but on this front 
> it does just fine.

I just wish you would have researched a bit better.  (And no, adding to 
the pile does not make your intention any better.)

Nobody ever disputed that _you_ have no problem with your patch.

Sigh,
Dscho

Re: [Qemu-devel] [patch 1/2] machine struct - use C99 initializers

[Thiemo Seufer]

Johannes Schindelin wrote:
> Hi,
> 
> On Mon, 6 Oct 2008, Jes Sorensen wrote:
> 
> > This patch simply converts all the machine structs to use C99 style 
> > initializers. There is no actual code change in this.
> 
> Is it really such a good idea to do this?  I mean, the only real change 
> you make here is to break compilation on compilers that do not grok C99 
> (or do it badly).

AFAICS Qemu is still stuck with GCC3 or later. Are you aware of a GCC 3.x
version which is capable of building dyngen code but can't handle C99
initializers?


Thiemo

Re: [Qemu-devel] [patch 1/2] machine struct - use C99 initializers

[Ronan Keryell]

>>>>> On Mon, 06 Oct 2008 17:03:56 +0200, Jes Sorensen <jes@sgi.com> said:

    Jes> Ehm, what compiler does _not_ support C99 these days?

M$ Visual C *2008* for example. :-)

But is it really even a C89 compiler, when you get a deprecation warning
about the use of fopen() ? :-)

Hopefully there are some more efficient C99 compilers such as the Intel
one on this architecture in the vendor world...

    Jes> Sorry, but there is already plenty of use of C99 initializers in
    Jes> QEMU today, the people who you refer to have either stopped
    Jes> building QEMU or switched to a 21st century compiler.

C99 adds many quite useful things to clean up the code and make it more
concise and more efficient (want to go back with alloca() instead of clean
automatic variable size array and so on ? Oh no ! :-) ).

But since everybody on this list has read the C99 norm and so knows what
is C89 and C99, I guess it will remains a religious discussion... :-)
-- 
  Ronan KERYELL                 |\/  Tel:    (+33|0) 2.29.00.14.15
  Département Informatique      |/)  Fax:    (+33|0) 2.29.00.12.82
  TÉLÉCOM Bretagne, CS 83818    K    GSM:    (+33|0) 6.13.14.37.66
  F-29238 PLOUZANÉ CEDEX 3      |\   E-mail: rk@enstb.org
  FRANCE                        | \  http://enstb.org/~keryell

Re: [Qemu-devel] [patch 1/2] machine struct - use C99 initializers

[Andreas Färber]

Jes,

Am 06.10.2008 um 17:03 schrieb Jes Sorensen:

> Johannes Schindelin wrote:
>>> This patch simply converts all the machine structs to use C99  
>>> style initializers. There is no actual code change in this.
>> Is it really such a good idea to do this?  I mean, the only real  
>> change you make here is to break compilation on compilers that do  
>> not grok C99 (or do it badly).
>> Sure, it does not concern _you_.  You _obviously_ have a C99  
>> compliant compiler.
>
> Ehm, what compiler does _not_ support C99 these days?

>> P.S.: before somebody says that GCC is C99 compliant: search the  
>> mailing list for the Beos GCC2 issue which was mentioned not long  
>> ago.
>
> GCC is sufficiently C99 compliant to handle this style of  
> initializers.
> Maybe it's not C99 compliant enough for other stuff, but on this front
> it does just fine.

You're missing the point: GCC today is not necessarily GCC 4.3+ or  
whatever has just been released these days and included in your  
favorite Linux distro. Just like Sun continues to ship GCC 3.4.3 on  
their latest OpenSolaris builds, the BeOS world and therefore its  
successor(s) are stuck with GCC 2.95.3 due to C++ ABI breakage in  
between major GCC versions. GCC 2 was originally released in '98 iirc  
and hence not C99 compliant. I'd expect your IRIX to face a similar  
issue, at EOL.

Anyway, saying that GCC supports C99 is about as correct as saying  
that Windows supports Bluetooth (which it didn't for many years before  
Windows XP SP1 or sth.) - hell, many companies even still run  
mainframe software from the Eighties!

So while this argument for using C99 is flawed, there may be valid  
reasons for QEMU to use more C99 constructs. But their pure  
availability in the latest GCCs is not very convincing.

Andreas

Re: [Qemu-devel] [patch 1/2] machine struct - use C99 initializers

[Paul Brook]

> > GCC is sufficiently C99 compliant to handle this style of
> > initializers.
> > Maybe it's not C99 compliant enough for other stuff, but on this front
> > it does just fine.
>
> You're missing the point: GCC today is not necessarily GCC 4.3+ or
> whatever has just been released these days and included in your
> favorite Linux distro. Just like Sun continues to ship GCC 3.4.3 on
> their latest OpenSolaris builds, the BeOS world and therefore its
> successor(s) are stuck with GCC 2.95.3 due to C++ ABI breakage in
> between major GCC versions. GCC 2 was originally released in '98 iirc
> and hence not C99 compliant. I'd expect your IRIX to face a similar
> issue, at EOL.

If a host system hasn't bothered upgrading their toolchain in 10 years then I 
refuse to care. If you really want to run and ancient obsolete OS you should 
expect to run equally ancient software.

Paul

Re: [Qemu-devel] [patch 1/2] machine struct - use C99 initializers

[M. Warner Losh]

In message: <200810070007.59487.paul@codesourcery.com>
            Paul Brook <paul@codesourcery.com> writes:
: > > GCC is sufficiently C99 compliant to handle this style of
: > > initializers.
: > > Maybe it's not C99 compliant enough for other stuff, but on this front
: > > it does just fine.
: >
: > You're missing the point: GCC today is not necessarily GCC 4.3+ or
: > whatever has just been released these days and included in your
: > favorite Linux distro. Just like Sun continues to ship GCC 3.4.3 on
: > their latest OpenSolaris builds, the BeOS world and therefore its
: > successor(s) are stuck with GCC 2.95.3 due to C++ ABI breakage in
: > between major GCC versions. GCC 2 was originally released in '98 iirc
: > and hence not C99 compliant. I'd expect your IRIX to face a similar
: > issue, at EOL.
: 
: If a host system hasn't bothered upgrading their toolchain in 10 years then I 
: refuse to care. If you really want to run and ancient obsolete OS you should 
: expect to run equally ancient software.

You assume that all upgrades are a good thing.  There are often
serious regressions in newer software, especially in not Intel
platforms, that makes it much harder to upgrade and have a working
system afterwards.

I'm saying there needs to be a balance between the latest and
greatest, and known working software...

Warner

Re: [Qemu-devel] [patch 1/2] machine struct - use C99 initializers

[Jes Sorensen]

Andreas Färber wrote:
>> GCC is sufficiently C99 compliant to handle this style of initializers.
>> Maybe it's not C99 compliant enough for other stuff, but on this front
>> it does just fine.
> 
> You're missing the point: GCC today is not necessarily GCC 4.3+ or 
> whatever has just been released these days and included in your favorite 
> Linux distro. Just like Sun continues to ship GCC 3.4.3 on their latest 
> OpenSolaris builds, the BeOS world and therefore its successor(s) are 
> stuck with GCC 2.95.3 due to C++ ABI breakage in between major GCC 
> versions. GCC 2 was originally released in '98 iirc and hence not C99 
> compliant. I'd expect your IRIX to face a similar issue, at EOL.

Andreas,

I have sympathy with the BeOS users, however C99 style (not I am not
arguing that we necessarily need to require a full C99 compliant
compiler), are very common today and trying to stick to an ancient and
by now, far obsolete compiler, like 2.95.3 simply means that BeOS little
by little will not be able to compile any recent applications. The BeOS
community can try and battle every codebase being modernized or it can
put the efforts into updating it's compiler suite. Yes I know it's
painful, but I am going to argue it will be a better spent effort than
trying to hold back reality. It's a bit like argueing that everybody
must use candle lighting and not electrical because there are still a
few people living in houses which doesn't have any electricity.

One interim step could be for OSes like BeOS to switch to egcs or Red
Hat's old gcc-2.96 base. I believe both support C99 style struct
initializers while still sticking to the old C++ ABI.

FWIW, please don't try and use my email address as an indication that I
care about IRIX. If you do so, you obviously don't know me. That OS has
been dead for years and it's proprietary.

> So while this argument for using C99 is flawed, there may be valid 
> reasons for QEMU to use more C99 constructs. But their pure availability 
> in the latest GCCs is not very convincing.

Well given that QEMU doesn't contain any C++, another option would be to
say we require at least gcc3 for QEMU and have BeOS users compile it
with gcc3. I don't see that affecting the issue with broken C++ ABIs.

Cheers,
Jes

Re: [Qemu-devel] [patch 1/2] machine struct - use C99 initializers

[Paul Brook]

> : If a host system hasn't bothered upgrading their toolchain in 10 years
> : then I refuse to care. If you really want to run and ancient obsolete OS
> : you should expect to run equally ancient software.
>
> You assume that all upgrades are a good thing.  There are often
> serious regressions in newer software, especially in not Intel
> platforms, that makes it much harder to upgrade and have a working
> system afterwards.
>
> I'm saying there needs to be a balance between the latest and
> greatest, and known working software...

IMHO anything using gcc2 has the balance tipped completely the wrong way, and 
requires a disproportionately large amount of effort to support.  I make a 
distinction between systems that are a few of revisions behind the bleeding 
edge, and systems that are not making enough effort to stay current. If we 
were requiring gcc4 then I'd agree with you. However I think sufficient time 
has passed that it's reasonable to expect at least gcc3.

As a side note, I'd be surprised if most modern c++ code even compiled with 
gcc2.95. The language implemented by g++2.95 only bears passing resemblance 
to modern c++, which is the reason the ABI is completely different.

> [Jes wrote]
> One interim step could be for OSes like BeOS to switch to egcs or Red
> Hat's old gcc-2.96 base. I believe both support C99 style struct
> initializers while still sticking to the old C++ ABI.

I wouldn't touch "2.96" unless you absolutely have to (i.e. you're still 
running RH7 systems). There's about a million different variants, most of 
which are broken.

Paul

Re: [Qemu-devel] [patch 1/2] machine struct - use C99 initializers

[Anthony Liguori]

Jes Sorensen wrote:
> Hi,
>
> Here's an updated version to my machine struct patch. I've split it in
> two so it is easier to validiate and track.
>
> This patch simply converts all the machine structs to use C99 style
> initializers. There is no actual code change in this.
>
> Next I will follow up with the one that does the conversion of max_cpus.

Applied. Thanks.

Regards,

Anthony Liguori

> Cheers,
> Jes

Re: [Qemu-devel] [patch 1/2] machine struct - use C99 initializers

[Andreas Färber]

Jes,

Am 07.10.2008 um 09:13 schrieb Jes Sorensen:

> Andreas Färber wrote:
>>> GCC is sufficiently C99 compliant to handle this style of  
>>> initializers.
>>> Maybe it's not C99 compliant enough for other stuff, but on this  
>>> front
>>> it does just fine.
>> You're missing the point: GCC today is not necessarily GCC 4.3+ or  
>> whatever has just been released these days and included in your  
>> favorite Linux distro. Just like Sun continues to ship GCC 3.4.3 on  
>> their latest OpenSolaris builds, the BeOS world and therefore its  
>> successor(s) are stuck with GCC 2.95.3 due to C++ ABI breakage in  
>> between major GCC versions. GCC 2 was originally released in '98  
>> iirc and hence not C99 compliant. I'd expect your IRIX to face a  
>> similar issue, at EOL.
>
> Andreas,
>
> I have sympathy with the BeOS users, however C99 style (not I am not
> arguing that we necessarily need to require a full C99 compliant
> compiler), are very common today and trying to stick to an ancient and
> by now, far obsolete compiler, like 2.95.3 simply means that BeOS  
> little
> by little will not be able to compile any recent applications. The  
> BeOS
> community can try and battle every codebase being modernized or it can
> put the efforts into updating it's compiler suite. Yes I know it's
> painful, but I am going to argue it will be a better spent effort than
> trying to hold back reality. It's a bit like argueing that everybody
> must use candle lighting and not electrical because there are still a
> few people living in houses which doesn't have any electricity.
>
> One interim step could be for OSes like BeOS to switch to egcs or Red
> Hat's old gcc-2.96 base. I believe both support C99 style struct
> initializers while still sticking to the old C++ ABI.
>
> FWIW, please don't try and use my email address as an indication  
> that I
> care about IRIX. If you do so, you obviously don't know me. That OS  
> has
> been dead for years and it's proprietary.

I am as much a BeOS user as you are an IRIX user. They're examples. As  
another one, see the more recent Sun C99 stdbool.h and math issues  
(gcc3). It used to compile fine, now without having even such a C99-or- 
not discussion it is broken due to C99 stuff. Btw even recent GCCs  
have an -ansi switch that some software deliberately uses, e.g.  
freetype2 iirc, so that today's system headers need to be ANSI- 
compliant, not C99.

Which GCC version an OS like Haiku or Solaris or Mac OS X chooses to  
use is not under my control, nor probably anyone else's here, and  
porting gcc is not among my skills to date. Nor would I want to do  
that for every OS someone wants to use QEMU on, fwiw. Personally, I am  
hoping for Haiku to get some gcc4 fully up and running.

>
>> So while this argument for using C99 is flawed, there may be valid  
>> reasons for QEMU to use more C99 constructs. But their pure  
>> availability in the latest GCCs is not very convincing.
>
> Well given that QEMU doesn't contain any C++, another option would  
> be to
> say we require at least gcc3 for QEMU

QEMU still does officially require gcc3.

> and have BeOS users compile it
> with gcc3. I don't see that affecting the issue with broken C++ ABIs.

The issue with C++ ABI breakage is in the use of C++ system libraries,  
like Michael does iiuc (Be API). I am not involved in that port myself  
though, nor running QEMU on Haiku/BeOS, so cannot offer any more  
details.


All that people here have been telling you is that the latest and  
greatest GCC on The OS shouldn't affect the choice of C99 features  
used because some platforms cannot use them (fully). No one, certainly  
not me, has been battling the use of gcc3+ or existing C99 features.

Hope that clarifies things,

Andreas