All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thiemo Seufer <ths@networkno.de>
To: "Todd T. Fries" <qemu@email.fries.net>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Patch: dyngen-exec.h for OpenBSD
Date: Sat, 7 Apr 2007 00:21:26 +0100	[thread overview]
Message-ID: <20070406232126.GE21953@networkno.de> (raw)
In-Reply-To: <20070405221242.GB4559@fries.net>

Todd T. Fries wrote:
> 
> Penned by Thiemo Seufer on 20070402 10:54.53, we have:
> | >  /* NOTE: standard headers should be used with special care at this
> | >     point because host CPU registers are used as global variables. Some
> | >     host headers do not allow that. */
> | >  #include <stddef.h>
> | > -
> | > +#ifdef __OpenBSD__
> | > +#include <sys/types.h>
> | > +#else
> | >  typedef unsigned char uint8_t;
> | >  typedef unsigned short uint16_t;
> | >  typedef unsigned int uint32_t;
> | > @@ -61,6 +65,7 @@ typedef signed long int64_t;
> | >  typedef signed long long int64_t;
> | >  #endif
> | >  #endif
> | > +#endif
> | 
> | Is this specialcase really needed for OpenBSD?
> 
> Can you honestly tell me that on all platforms this is true?
> 
> Hello? Portability?  sys/types.h defines these types portably.
> Doing so the way this code does it, is not portable.
> 
> I left your non portable code to you; if systems in general
> define these types in sys/types.h then just remove the
> typedefs, problem solved.

Please consider the NOTE: above those includes.

> | >  /* XXX: This may be wrong for 64-bit ILP32 hosts.  */
> | >  typedef void * host_reg_t;
> | > @@ -78,11 +83,15 @@ typedef void * host_reg_t;
> | >  #define UINT32_MAX		(4294967295U)
> | >  #define UINT64_MAX		((uint64_t)(18446744073709551615))
> | >  
> | > +#ifdef __OpenBSD__
> | > +typedef struct __sFILE FILE;
> | > +#else
> | >  typedef struct FILE FILE;
> | >  extern int fprintf(FILE *, const char *, ...);
> | >  extern int printf(const char *, ...);
> | >  #undef NULL
> | >  #define NULL 0
> | > +#endif
> | 
> | Shouldn't this cover only the FILE typedef?
> 
> Why is it that qemu knows what the definition of these prototypes
> are on all systems without consulting the header files.  I have a
> better idea, lets let the header files define the prototypes.
> Who would have though of that?
> 
> .. of course I purposefully intended to remove cruft that is
> in header files and belongs in header files.

See above.


Thiemo

  reply	other threads:[~2007-04-06 23:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-21  2:39 [Qemu-devel] Patch: dyngen-exec.h for OpenBSD Todd T. Fries
2007-04-02  9:54 ` Thiemo Seufer
2007-04-05 22:12   ` Todd T. Fries
2007-04-06 23:21     ` Thiemo Seufer [this message]
2007-04-07  0:50     ` Paul Brook
2007-04-07  3:34       ` Anthony Liguori
  -- strict thread matches above, loose matches on Subject: below --
2007-04-02 10:25 Juergen Keil
2007-04-02 12:41 ` Thiemo Seufer
2007-04-02 14:58   ` M. Warner Losh
2007-04-02 16:08     ` Thiemo Seufer
2007-04-02 16:55       ` M. Warner Losh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070406232126.GE21953@networkno.de \
    --to=ths@networkno.de \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu@email.fries.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.