[haiku-commits] Re: r34716 - haiku/trunk/src/libs/compat/freebsd_network/compat/sys

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Sun, 20 Dec 2009 15:46:44 +0100

On 2009-12-20 at 14:43:01 [+0100], Colin Günther <coling@xxxxxx> wrote:
> ingo_weinhold@xxxxxx schrieb:
> > Author: bonefish
> > Date: 2009-12-20 14:07:02 +0100 (Sun, 20 Dec 2009)
> > New Revision: 34716
> > Changeset: http://dev.haiku-os.org/changeset/34716/haiku
> >
> > Modified:
> >    haiku/trunk/src/libs/compat/freebsd_network/compat/sys/systm.h
> > Log:
> > Fixed build. Since vprintf() is defined as a macro, it's a good idea to
> > include the <stdio.h> first. I don't see, why the header defines stuff 
> > that
> > is already defined in <stdio.h> anyway.
> >   
> Did you see that vprintf is used to make driver_vprintf called instead
> of  vprintf,
> #define vprintf(fmt, vl) driver_vprintf(fmt, vl)

Yep, and exactly that is the problem. If you include <stdio.h> after this 
file, you'll also rename the vprintf() prototype there and the two don't 
match (void vs. int return type).

> so there must be another solution to the borken build issue you
> encounted. The nice thing of driver_vprintf is that it prints out the
> corresponding driver name. I'd like to keep that feature :)

It's still used as before. Though I don't see, why the function must be 
named driver_vprintf(). One could just as well implement it as vprintf() 
(with the correct return type).

> Mmh, the header files under compat/ are designed in a way that they
> match the inclusion pattern of their FreeBSD counterparts. There is no
> stdio.h inclusion in FreeBSD's systm.h, this is why I'm feeling somewhat
> uncomfortable with this change.
> Can't reproduce a broken build here, for me all compat layer related
> stuff compiles just fine. Can you tell me where the broken build occurs,
> so maybe we can spot another solution?

IIRC the error occurred when 3com/pci/if_xl.c was compiled. As another 
solution (and something that should be done anyway), you can fix the return 
type. But since <stdio.h>. seems to be included somewhere anyway, I'd 
rather just leave the include as is and remove the duplicate prototypes.

CU, Ingo

Other related posts: