Date: Sat, 29 Jan 2000 06:57:04 -0200 From: =?iso-8859-1?Q?Jo=E3o?= Carlos Mendes =?iso-8859-1?Q?Lu=EDs?= <jonny@jonny.eng.br> To: Brian Fundakowski Feldman <green@FreeBSD.ORG> Cc: Bruce Evans <bde@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/gen Makefile.inc Message-ID: <3892AB60.85F0B786@jonny.eng.br> References: <Pine.BSF.4.21.0001281637390.41451-100000@green.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Brian Fundakowski Feldman wrote: > > Am I the only one that's disturbed by the fact that this (nonstandard) > > function pair has such generic names? Already, it has broken world > > in two places. It's just not a good idea to have such generic functions > > in our headers (even if it's more okay for them to be in the libaries...) ... > The strflags(3) function will follow the convention of strerror(3) and ... > buffer, consistent with the return value behavior when "flags" contains > valid flags. If not possible to return a character pointer to malloc(3)d You are missing the (probably) most important point. strflags() et al. are name space pollution mostly because the name "flags" is too generic. Why not use something like strufsflags() or strffsflags() to let this part clear... This way, I think that application namespace pollution can be mostly ignored. Now you only have to care for standards namespace pollution. Jonny -- João Carlos Mendes Luís jonny@jonny.eng.br Networking Engineer jcml@ieee.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3892AB60.85F0B786>