audio: fix bug in mixeng_template.h build on NetBSD

This is a bug fix for rc1, although I think this bug has been present
for a long time.

NetBSD has typedefs and defines of types, so all the types specified
in mixeng.c IN_T define (int8_t, uint8_t...) got expanded to __int8_t,
__uint8_t, and the construction of types in mixeng_template.h failed.

audio/mixeng.c:150:17: error: 'conv_natural_uint8_t_to_mono'
undeclared here (not in a function)
[...]
audio/mixeng_template.h:114:1: warning:
'conv_natural___uint8_t_to_mono' defined but not used
[...]

Undef those types, so we can safely compile. This is safe even if the
types are not defined.

Cc: Vassili Karpov (malc) <av1474@comtv.ru>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 audio/mixeng_template.h |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

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:

  - 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?

Regards, Roger.

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)