nanogui: Thread: usage of posix functions in src/engine/ and src/drivers/


[<<] [<] Page 1 of 1 [>] [>>]
Subject: usage of posix functions in src/engine/ and src/drivers/
From: Alexander Neundorf ####@####.####
Date: 28 May 2005 12:37:30 +0100
Message-Id: <200505281337.26636.neundorf@kde.org>

Hi,

I'd like to try to use the microwindows graphics engine directly (GdXXX(), 
i.e. without nanox or microwindows) under ecos.
There are some places in this code where abort(), fprintf() and maybe some 
more functions like this are called.
While ecos has packages which provide these functions, it can also run very 
well without these packages and has a slightly smaller memory footprint then.

I'd like to replace the abort(), fprintf() and similar calls in drivers/ and 
engine/ with macros in order to make it more portable:

#ifdef __ECOS
  #define ABORT() CYG_FAIL("aborted");
  #define DEBUG_PRINTF(args...) diag_printf(args...)
#else
  #define ABORT() abort()
  #define DEBUG_PRINTF(args...) fprintf(stderr, args...)
#endif

What do you think ?

Bye
Alex
-- 
Work: ####@####.#### - http://www.jenoptik-los.de
Home: ####@####.####                - http://www.kde.org
      ####@####.####               - http://www.neundorf.net
Subject: Re: [nanogui] usage of posix functions in src/engine/ and src/drivers/
From: Jachym Holecek ####@####.####
Date: 28 May 2005 17:26:51 +0100
Message-Id: <20050528162647.GB17914@merlot.ics.muni.cz>

Hello,

> I'd like to replace the abort(), fprintf() and similar calls in drivers/ and 
> engine/ with macros in order to make it more portable:

Abstracting error/debug reporting is a Good Thing IMO.

> #ifdef __ECOS
>   #define ABORT() CYG_FAIL("aborted");
>   #define DEBUG_PRINTF(args...) diag_printf(args...)
> #else
>   #define ABORT() abort()
>   #define DEBUG_PRINTF(args...) fprintf(stderr, args...)
> #endif
> 
> What do you think ?

I'd avoid vararg macros with something like:

#ifdef FOOBAR
void debug(const char *, ...);

#  define ABORT() 	foo("aborted")
#  define DEBUG(arg) 	do { debug arg ; } while(/*CONTCOND*/)
#else ...
#endif

Or have varag macros been made sanely portable while I was sleeping? ;)
Alternatively, one could just make ABORT(), DEBUG() etc. real functions,
selected on platform basis.

	Regards,
		-- Jachym Holecek
Subject: Re: [nanogui] usage of posix functions in src/engine/ and src/drivers/
From: "Greg Haerr" ####@####.####
Date: 7 Jun 2005 05:03:06 +0100
Message-Id: <215201c56b15$a3d7a0b0$6401a8c0@winXP>

: I'd like to try to use the microwindows graphics engine directly (GdXXX(),
: i.e. without nanox or microwindows) under ecos.

Cool


: There are some places in this code where abort(), fprintf() and maybe some
: more functions like this are called.
: While ecos has packages which provide these functions, it can also run
very
: well without these packages and has a slightly smaller memory footprint
then.

Agreed


:
: I'd like to replace the abort(), fprintf() and similar calls in drivers/
and
: engine/ with macros in order to make it more portable:
:
: #ifdef __ECOS
:   #define ABORT() CYG_FAIL("aborted");
:   #define DEBUG_PRINTF(args...) diag_printf(args...)
: #else
:   #define ABORT() abort()
:   #define DEBUG_PRINTF(args...) fprintf(stderr, args...)
: #endif

There shouldn't be any places where printf or fprintf are used
directly, just for the reasons you've stated above.  In device.h,
the EPRINTF and DPRINTF macros were created to allow
testing output (where stdout is used) and production output
(where a GdError routine is called) without changing source.
So, the same should follow for your eCos port where you'd
use DPRINTF or EPRINTF instead of DEBUG_PRINTF
above.

For the abort() case, I suggest a patch where an ABORT() macro
is created, and included in device.h.

Regards,

Greg

Subject: Re: [nanogui] usage of posix functions in src/engine/ and src/drivers/
From: "Greg Haerr" ####@####.####
Date: 7 Jun 2005 05:09:51 +0100
Message-Id: <217a01c56b16$934dd010$6401a8c0@winXP>

: Or have varag macros been made sanely portable while I was sleeping? ;)

No, we have to resort to gcc-specific "..." in the parameter list to
handle them...  See include/device.h::MW_FEATURE_GDERROR
for the gory details.  Not pretty.


: Alternatively, one could just make ABORT(), DEBUG() etc. real functions,
: selected on platform basis.

Yes, that's the current design intention.

Regards,

Greg

[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.