[Bug libc/26545] New: Deprecated getcwd (NULL, n) for positive n

[Bug libc/26545] New: Deprecated getcwd (NULL, n) for positive n

[fweimer at redhat dot com]

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

            Bug ID: 26545
           Summary: Deprecated getcwd (NULL, n) for positive n
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: fweimer at redhat dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Using malloc with a fixed buffer size does not make much sense. This usage
conflicts with attribute access, which produces a warning because a non-zero
size implies that the pointer cannot be null.

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

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

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=25219

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

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

[adhemerval.zanella at linaro dot org]

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

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
Should we add a compat symbol for Linux? The generic implementation always
initially allocates PATH_MAX+1, but the Linux one initially allocates the
provided size for the syscall and fallbacks to generic code if the syscall
fails.
I think it should not really matter.

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

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

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #2 from Florian Weimer <fweimer at redhat dot com> ---
I don't think we need to change the implementation, just the documentation.

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

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

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Deprecated getcwd (NULL, n) |Deprecate getcwd (NULL, n)
                   |for positive n              |for positive n

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

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

[adhemerval.zanella at linaro dot org]

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

--- Comment #3 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
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.

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.

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

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

[fweimer at redhat dot com]

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

--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
(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.

> 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.

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

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

[adhemerval.zanella at linaro dot 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.

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

[aurelien at aurel32 dot net]

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

Aurelien Jarno <aurelien at aurel32 dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aurelien at aurel32 dot net

--- Comment #6 from Aurelien Jarno <aurelien at aurel32 dot net> ---
(In reply to Florian Weimer from comment #0)
> Using malloc with a fixed buffer size does not make much sense. This usage
> conflicts with attribute access, which produces a warning because a non-zero
> size implies that the pointer cannot be null.

For what I have seen from code that now fails to compile, the use case is to
call getcwd(NULL, PATH_MAX). That way you can easily use string functions to
build a path from the result of getcwd() without allocating more memory.

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

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

[jbglaw@lug-owl.de]

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

Jan-Benedict Glaw <jbglaw@lug-owl.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jbglaw@lug-owl.de

--- Comment #7 from Jan-Benedict Glaw <jbglaw@lug-owl.de> ---
It's about a year since pointer/size checking was added, and now that Debian
picked up a newer glibc (2.32-2), this instrumentation came live and breaks
test builds for the GNU Toolchain. (I'm running an autobuilder for binutils,
gcc, Linux kernel, NetBSD and SIMH.)

Breakage is in fixincl.c, with a call like "getcwd(NULL, PATH_MAX)", as
Aurelien Jarno commeted in
https://sourceware.org/bugzilla/show_bug.cgi?id=26545#c0 .

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