apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: apr_token_* conclusions (was: Better casecmpstr[n]?)
Date Wed, 25 Nov 2015 21:10:35 GMT
In a library that has:

	apr_pstrdup()
	apr_pstrndup()
	apr_pstrmemdup()

and apr_pstrmemdup() and apr_pstrndup() are functionally
the same, as well as:

	apr_strnatcasecmp()
	apr_strnatcmp()

neither of which use an 'n' variable to determine string
size, yet is called 'strn...' whereas the dups use that
'n' in 'strndup' to signify that we have a size parameter
BUT its functionally equiv function apr_pstrmemdup() is
called what it is instead of apr_pstrnmemdup()...

... I think we are WAY overthinking naming here.

Mime
View raw message