From: Vladimir T. <vtz...@gm...> - 2008-10-29 14:56:22
|
On Oct 29, 2008, at 4:31 PM, Sam Steingold wrote: > Vladimir Tzankov wrote: >> On Oct 29, 2008, at 12:59 AM, Gabriel Dos Reis wrote: >>> On Tue, Oct 28, 2008 at 4:53 PM, Sam Steingold <sd...@gn...> wrote: >>>> 1. is this c89 syntax? >>>> >>>> #define GC_SAFE_SYSTEM_CALL(type,statement) \ >>>> ({var type ret; \ >>>> begin_blocking_system_call(); \ >>>> ret=statement; \ >>>> end_blocking_system_call(); \ >>>> ret;}) >>>> >>>> do non-gcc compilers support it? >>> it is a GNU extension not supported by all C compilers. >>> (Intel compiler does support it though). I wouldn't >>> recommend it for portable C code. >>> >>> "static inline" tends to produce same effect these days. >>> If the C macro semantics is needed, then I would say, just >>> go for the C macro! >> It looks like this is quite popular extension. >> Intel: ftp://download.intel.com/support/performancetools/c/linux/ >> sb/ linuxcompilerscompatibility703.pdf >> Sun: http://developers.sun.com/sunstudio/downloads/ssx/compilers/ >> readme.html >> IBM: http://publib.boulder.ibm.com/infocenter/lnxpcomp/v7v91/ >> index.jsp?topic=/com.ibm.vacpp7l.doc/getstart/overview/port_gcc.htm >> however it is non-standard. > > MSVC is conspicuously absent. > > Bruno, what do you think? > should we use it? GC_SAFE_SYSTEM_CALL() (and other new macros introduced for MT) are easily fixable. I missed the Symbol_value() which in MT is defined as: #define Symbol_value(obj) \ *({var Symbol s=TheSymbol(obj); \ var clisp_thread_t *thr=current_thread();\ var gcv_object_t *r; \ r=(s->tls_index && !eq(SYMVALUE_EMPTY,thr->_ptr_symvalues[s- >tls_index]) ? \ thr->_ptr_symvalues+s->tls_index : &s->symvalue); \ r;}) Throughout the code it is used both as L-value and R-value. In order to be standard conformant we should have SetSymbolValue() / GetSymbolValue() and replace all Symbol_value() occurrences. Vladimir |