Re: constify dirname/basename [was: CVS commit: src]

[Simon Burge <simonb%NetBSD.org@localhost>]

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
certainly common: 

   thoreau 10932> grep -lw const susv3/functions/* | wc -l
        470
   thoreau 10933> grep -Lw const susv3/functions/* | wc -l
        672

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.

Cheers,
Simon.