Re: [Qemu-devel] [PATCH] audio: fix bug in mixeng_template.h build on NetBSD

[malc <av1474@comtv.ru>]

On Mon, 14 May 2012, Roger Pau Monne wrote:

> malc escribi?:
> > On Fri, 11 May 2012, Roger Pau Monne wrote:
> > 
> > > This is a bug fix for rc1, although I think this bug has been present
> > > for a long time.
> > 
> > If there's a bug than it's within NetBSD itself, this issue has been
> > discussed few times (at least twice it hink) in the past, please search
> > the ML archives.
> > 
> > [..snip..]
> > 
> 
> Hello,
> 
> I've found
> 
> http://copilotco.com/mail-archives/qemu.2008/msg11157.html
> 
> and
> 
> http://lists.gnu.org/archive/html/qemu-devel/2009-09/msg00255.html
> 
> But none of them seems to reach a conclusion about how to solve this. The
> standard regarding stdint.h doesn't forbid having this types defined as both
> typedefs and preprocessor macros, so I don't think this is a NetBSD bug. As
> far as I can see, we have at least three ways of solving this:

7.20.1.1#1 (and similarly #2)

The typedef name intN_t designates a signed integer type with width N,
no padding bits, and a two's complement representation. Thus, int8_t
denotes such a signed integer type with a width of exactly 8 bit

> 
>  - Undef the macros.
>  - Use something like concat(conv_natural_, uint8_t, _to_mono) (as done on the
> second thread I've posted).
>  - Pass two separate arguments; instead of using:
> 
> #define IN_T uint8_t
> 
> use something like:
> 
> #define BSIZE 8
> #define ITYPE uint
> 
> But this will probably introduce quite some modifications.
> 
> Anyway, how do you think it's best to solve this?
> 

To be honest, i think if NetBSD breaks the standard then it can also
carry QEMU patches in its ports collection. Regardless, from my point
of view the last option is the only one viable (not that i will commit
the patch once presented, but i might consider it)

-- 
mailto:av1474@comtv.ru