Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: silencing compiler warnings from gcc 4
- X-seq: zsh-workers 21605
- From: Peter Stephenson <pws@xxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: PATCH: silencing compiler warnings from gcc 4
- Date: Fri, 12 Aug 2005 12:31:14 +0100
- In-reply-to: <20050811200252.GA19497@xxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- Organization: Cambridge Silicon Radio
- References: <20050811200252.GA19497@xxxxxxxxx>
Wayne Davison <wayned@xxxxxxxxxxxxxxxxxxxxx> wrote:
> As for the portability of "inline", there is an autoconf macro that I
> included, AC_C_INLINE, that redefines the word "inline" as appropriate.
> The rsync package used a static inline function in its rsync.h for many
> years (thought I eliminated it recently), so it would seem to be quite
> portable.
Hmm... did I read this the right way? I had assumed that if inline wasn't
available we'd use a macro. But maybe it simply means if inline isn't
available, we end up calling two functions to get a simple strlen(). If
that's the case it seems to be over the top... I think we would need
something like
#ifdef <inline is available>
static inline size_t ZS_strlen(ZLE_STRING_T s)
{ return strlen((char*)s); }
#else
#define ZS_strlen(s) strlen((char *)s)
#endif
Then we still get debugging information from gcc without unnecessarily
increasing the overhead with other compilers.
--
Peter Stephenson <pws@xxxxxxx> Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
**********************************************************************
Messages sorted by:
Reverse Date,
Date,
Thread,
Author