[Bug libc/26545] Deprecate getcwd (NULL, n) for positive n
adhemerval.zanella at linaro dot org
sourceware-bugzilla@sourceware.org
Wed Sep 2 11:48:42 GMT 2020
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.
More information about the Glibc-bugs
mailing list