[Bug libc/26545] Deprecate getcwd (NULL, n) for positive n

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=26545

--- Comment #5 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Florian Weimer from comment #4)
> (In reply to Adhemerval Zanella from comment #3)
> > But if the idea is not to change the function semantic in a future release
> > why deprecate it? My understanding is the GNU extension aims to make the
> > getcwd have the same semantic regarding the returned result, the only
> > difference is whether it would be allocated or not. I am not sure we should
> > deprecate it only because it does not fit the newer gcc warning annotation.
> 
> I think it's not a good programming practice because it prevents getcwd from
> sizing the buffer appropriately.

But the idea of exactly to limit the allocation to a certain limit, similar to
when you use provided a buffer.  It will either return an allocated buffer with
the asked size with the expand current directory or NULL. 

> 
> > One possibility is to make getcwd ignore the size argument if the buffer is
> > NULL, in this case the buffer will be always allocated to fit to obtained
> > path.
> 
> That would be a backwards-incompatible change.  Right now, programmers can
> use getcwd essentially as a malloc replacement.

That's why I asked if we should add a compat symbol.  I don't see much gain in
just document the behaviour as deprecated if we won't change the function
semantic.

-- 
You are receiving this mail because:
You are on the CC list for the bug.