Bug 2417 - getcwd() uses ENAMETOOLONG instead of ERANGE
Summary: getcwd() uses ENAMETOOLONG instead of ERANGE
Status: RESOLVED WONTFIX
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.3.6
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-05 16:52 UTC by Aurelien Jarno
Modified: 2018-04-19 13:51 UTC (History)
1 user (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Last reconfirmed:
fweimer: security-

Attachments
proposed patch (330 bytes, patch)
2006-03-05 16:54 UTC, Aurelien Jarno 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Aurelien Jarno 2006-03-05 16:52:57 UTC 
A call to getcwd() with a buffer smaller than the actual path returns an error
ENAMETOOLONG on all architectures but ia64, whereas POSIX and the *GNU libc
manual* say ERANGE. Actually this is the value returned by the kernel.

IMHO the kernel has to be fixed, but the GNU libc should also correct the
number. That's the purpose of the attached patch.
Comment 1 Aurelien Jarno 2006-03-05 16:54:23 UTC 
Created attachment 902 [details]
proposed patch
Comment 2 Dwayne Grant McConnell 2006-03-10 17:12:19 UTC 
When you say "on all architectures but ia64" do you mean this is true for the
generic kernel or is this Debian specific? On OpenSUSE x86 10.0 I get ERANGE.

I do not see why glibc should put in a patch to work around a bug in the kernel.
This bug should be fixed in the kernel only. If glibc put in a workaround for
every simple kernel bug which code be fixed the code would quickly become
unmanageable.
Comment 3 Dwayne Grant McConnell 2006-03-10 17:12:57 UTC 
s/code be fixed/could be fixed/
Comment 4 Ulrich Drepper 2006-04-01 20:57:35 UTC 
There is no problem in libc and I cannot see anything wrong in the current
kernel sources either.