tech-userlevel archive

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

   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.


Home | Main Index | Thread Index | Old Index