Date: Mon, 19 Jan 2004 01:24:16 -0800 From: Max Khon <fjoe@FreeBSD.org> To: John Merryweather Cooper <john_m_cooper@yahoo.com> Cc: ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/mail/libesmtp Makefile Message-ID: <20040119092416.GA36498@FreeBSD.org> In-Reply-To: <400CD2A3.3090409@yahoo.com> References: <200401181147.i0IBl79Q029549@repoman.freebsd.org> <20040118204455.GA35450@FreeBSD.org> <400CD2A3.3090409@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040119092416.GA36498>