machine struct - use C99 initializers
PATCH 1/2 machine struct - use C99 initializers
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
Modify all the machine struct declarations to use C99 initializers. This patch has no functional changes.
--- 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(-)
hw/an5206.c +4 -4
@@ -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 , };
hw/dummy_m68k.c +3 -3
@@ -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, };
hw/etraxfs.c +4 -4
@@ -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 , };
hw/gumstix.c +8 -8
@@ -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 , };
hw/integratorcp.c +4 -4
@@ -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 , };
hw/mainstone.c +5 -5
@@ -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 , };
hw/mcf5208.c +4 -4
@@ -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 , };
hw/musicpal.c +4 -4
@@ -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 , };
hw/nseries.c +8 -8
@@ -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 , };
hw/palm.c +4 -4
@@ -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 , };
hw/ppc405_boards.c +4 -4
@@ -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 , };/*****************************************************************************/
hw/ppc_chrp.c +4 -4
@@ -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 , };
hw/ppc_oldworld.c +4 -4
@@ -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 , };
hw/ppc_prep.c +4 -4
@@ -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 , };
hw/r2d.c +4 -4
@@ -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 , };
hw/shix.c +4 -4
@@ -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 , };
hw/spitz.c +16 -16
@@ -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 , };
hw/stellaris.c +8 -8
@@ -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 , };
hw/tosa.c +4 -4
@@ -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 , };
Hi,
Quoted 2 lines · Jes Sorensen
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.
Quoted 5 lines · Johannes Schindelin
Quoted 1 line
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.
Quoted 1 line
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.
Quoted 1 line
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.
Quoted 1 line
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
Hi,
Quoted 8 lines · Jes Sorensen
Quoted 2 lines · Johannes Schindelin
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
Quoted 8 lines · Johannes Schindelin
Hi,
Quoted 3 lines · Jes Sorensen
Johannes Schindelin wrote:
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
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
Quoted 4 lines
Sigh,
Dscho
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Jes Sorensen
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... :-)
Signature · 5 lines
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: [email protected] FRANCE | \ http://enstb.org/~keryell
Jes,
Am 06.10.2008 um 17:03 schrieb Jes Sorensen:
Quoted 5 lines
Quoted 3 lines · Johannes Schindelin
Quoted 1 line
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.
Quoted 7 lines
Ehm, what compiler does _not_ support C99 these days?
Quoted 1 line
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
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
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
In message: <[email protected]>
Paul Brook <[email protected]> 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
Quoted 11 lines
: 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.
Quoted 4 lines
[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
Quoted 5 lines · Andreas Färber
Quoted 3 lines
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.
Quoted 1 line
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
Jes,
Am 07.10.2008 um 09:13 schrieb Jes Sorensen:
Quoted 20 lines
Quoted 4 lines · Andreas Färber
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 2 lines
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
Quoted 10 lines · Johannes Schindelin
Hi,
Quoted 2 lines · Jes Sorensen
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
Anthony Liguori
AppliedQuoted 9 lines · Jes Sorensen
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
Quoted 2 lines
Cheers,
Jes