public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "aurelien at aurel32 dot net" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sources.redhat.com
Subject: [Bug libc/2418] getcwd() print an assertion for a path greater than MAX_PATH
Date: Sat, 01 Apr 2006 21:38:00 -0000	[thread overview]
Message-ID: <20060401213826.23725.qmail@sourceware.org> (raw)
In-Reply-To: <20060305170201.2418.aurelien@aurel32.net>


------- Additional Comments From aurelien at aurel32 dot net  2006-04-01 21:38 -------
(In reply to comment #1) 
> Removing assert is almost never good.  Provide a test case.  Note that 
neither 
> the libc or kernel side of getcwd is architecture-speicfic.  Otherwise I'll 
just 
> close the bug. 
 
I haven't found the time to look more at this bug, however LaMont Jones sent me  
a more detailed analysis of the problem: 
 
Actually, it will occur on any machine that has PAGE_SIZE >> PATH_MAX 
 
Possible workarounds for coreutils:  Use a path of more than 16384 
bytes in length for the test, rather than just more than 4096.  :-)  
 
For glibc:  The assertion is bogus.  In fact, the path in question from 
this test is more than PATH_MAX bytes in length.  Because 
PAGE_SIZE==PATH_MAX, sys_getcwd returns ENAMETOOLONG (since it can't 
construct the path in the buffer it's using internally), while ia64 has 
enough room to build a path (up to 16K), but not enough room to return 
it in the malloced buffer from getcwd(3). 
 
The correct solution is, of course, to copy the code from the readlink 
loop immediately below the assert to realloc until it fits.  OTOH, 
the diff below makes it behave the same as it does today on all 
machines. 
 
--- sysdeps/unix/sysv/linux/getcwd.c.orig	2003-09-19 19:05:49.000000000 
-0600 
+++ sysdeps/unix/sysv/linux/getcwd.c	2006-03-23 16:11:04.000000000 -0700 
@@ -124,10 +124,11 @@ 
 	} 
  
 # if __ASSUME_GETCWD_SYSCALL 
-      /* It should never happen that the `getcwd' syscall failed because 
-	 the buffer is too small if we allocated the buffer ourselves 
-	 large enough.  */ 
-      assert (errno != ERANGE || buf != NULL || size != 0); 
+      /* It is possible that the `getcwd' syscall failed because 
+	 the buffer is too small even though we allocaed MAX_PATH 
+	 bytes.  if PAGE_SIZE != PATH_MAX, then we can get back ERANGE 
+	 instead of ENAMETOOLONG in this case. */ 
+      /* assert (errno != ERANGE || buf != NULL || size != 0); */ 
  
 #  ifndef NO_ALLOCATION 
       if (buf == NULL) 
 

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2418

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


  parent reply	other threads:[~2006-04-01 21:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-05 17:02 [Bug libc/2418] New: " aurelien at aurel32 dot net
2006-04-01 20:59 ` [Bug libc/2418] " drepper at redhat dot com
2006-04-01 21:38 ` aurelien at aurel32 dot net [this message]
2006-04-01 21:40 ` aurelien at aurel32 dot net
2006-04-01 21:51 ` schwab at suse dot de
2006-04-02 17:59 ` drepper at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060401213826.23725.qmail@sourceware.org \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).