[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: constify dirname/basename [was: CVS commit: src]
On Wed, Apr 23, 2008 at 03:17:37PM +0100, Iain Hibbert wrote:
> Simon Burge writes:
> > Iain Hibbert wrote:
> > > constify dirname(3) and basename(3)
> > Does this change have an SUSv3/Posix issues? SUSv3 says that both
> > functions "may modify the string pointed to by path" (the argument to
> those functions). While our
> > implementations don't do that, are we OK by the standards to now declare
> > those functions as having a const argument?
> Its a good question. I think it does not contradict the standard, in
> that you can still pass a modifiable string but it allows you also to
> pass a const string which was problematic before. (how prevalent was
> const when SUS/Posix was published?)
There's more function pages that don't mention "const" than do, but it's
thoreau 10932> grep -lw const susv3/functions/* | wc -l
thoreau 10933> grep -Lw const susv3/functions/* | wc -l
As for correctness, I'll let other language lawyers jump in. :-)
> It could perhaps 'encourage' bad behaviour by software being written
> for the const version and this is actually why I noticed it - FreeBSD
> and OpenBSD have had this for many years and I found comms/obexapp
> needs an _UNCONST patch to build..
My first take is that if a standard says dirname(3)/basename(3) may
modify the arg, then portable code shouldn't past in a const pointer.
It sounds like comms/obexapp is making assumptions about implementations
it shouldn't be.
Main Index |
Thread Index |