From owner-cvs-all@FreeBSD.ORG  Mon Jan 19 01:24:16 2004
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Delivered-To: cvs-all@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 904)
	id 2690F16A4CF; Mon, 19 Jan 2004 01:24:16 -0800 (PST)
Date: Mon, 19 Jan 2004 01:24:16 -0800
From: Max Khon <fjoe@FreeBSD.org>
To: John Merryweather Cooper <john_m_cooper@yahoo.com>
Message-ID: <20040119092416.GA36498@FreeBSD.org>
References: <200401181147.i0IBl79Q029549@repoman.freebsd.org>
	<20040118204455.GA35450@FreeBSD.org> <400CD2A3.3090409@yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <400CD2A3.3090409@yahoo.com>
User-Agent: Mutt/1.4.1i
cc: Clement LAFORET <clement@FreeBSD.org>
cc: cvs-ports@FreeBSD.org
cc: cvs-all@FreeBSD.org
cc: ports-committers@FreeBSD.org
Subject: Re: cvs commit: ports/mail/libesmtp Makefile
X-BeenThere: cvs-all@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the entire tree <cvs-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-all>
List-Post: <mailto:cvs-all@freebsd.org>
List-Help: <mailto:cvs-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jan 2004 09:24:16 -0000

Hello!

On Mon, Jan 19, 2004 at 11:02:59PM -0800, John Merryweather Cooper wrote:

> I was away in Seattle, so viewing the code was a might difficult.  Now 
> that I'm back home, I have to agree that the internal memrchr() fix 
> better preserves the semantics of RFC 2818 (which parses from tail to head).
> 
> I wonder since we have both a strchr() and a strrchr() in libc why this 
> is not echoed with memchr() and a memrchr() since these functions are so 
> similar.

memrchr() is not mentioned in any standards and is GNU libc extension.
Adding memrchr to libc might be a good idea though.
 
> Also, the implementation of memrchr() seems to make some very 
> i386-specific assumptions about pointers.  Couldn't this be better 
> implemented wrapping strrchr() to handle NUL and size_t?

Please point out which i386-specific assumptions are made (I do not see any)
so we can fix them. memrchr could not be mapped to our strrchr()
implementation (please take a look at how it is implemented there).

/fjoe