Bug 21821 - MAXPATHLEN usage in libjava
MAXPATHLEN usage in libjava
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: libgcj
4.0.0
: P2 normal
: 4.3.0
Assigned To: Not yet assigned to anyone
: build
: 28234 32846 (view as bug list)
Depends on:
Blocks: 21824
  Show dependency treegraph
 
Reported: 2005-05-30 14:40 UTC by Alfred M. Szmidt
Modified: 2007-08-06 05:00 UTC (History)
6 users (show)

See Also:
Host: i686-pc-gnu0.3
Target: i686-pc-gnu0.3
Build: i686-pc-gnu0.3
Known to work:
Known to fail:
Last reconfirmed: 2005-05-30 15:35:43


Attachments
Remove arbitrary limit in getCanonicalPath(). (1.43 KB, patch)
2005-10-01 16:35 UTC, Alfred M. Szmidt
Details | Diff
Remove arbitrary limit in File.Java:createTempFile (1.41 KB, patch)
2005-10-01 18:58 UTC, Alfred M. Szmidt
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alfred M. Szmidt 2005-05-30 14:40:12 UTC
Please do not use MAXPATHLEN, it is a arbitrary limit, and is not
defined on GNU.  Currently this makes libjava (gcc 4.0.0) unbuildable on GNU
since [gcc]/libjava/gnu/java/nio/channels/natFileChannelImpl.cc assumes that
MAXPATHLEN is defined.  Please do not use these kind of limits in GNU programs.

Not having MAXPATHLEN is perfectly compliant with POSIX, same goes for
MAXHOSTNAMELEN, PATH_MAX etc.
Comment 1 Alfred M. Szmidt 2005-05-30 14:53:56 UTC
[gcc]/libjava/java/io/natFilePosix.cc is also broken due to the usage of MAXPATHLEN.
Comment 2 Bryce McKinlay 2005-05-30 15:35:42 UTC
Its easy to fix this for natFileChannelImpl.cc.

For natFilePosix.cc it is not so simple - is there a portable alternative to
realpath() that does not require the use of MAXPATHLEN / PATH_MAX ?
Comment 3 CVS Commits 2005-05-30 16:14:37 UTC
Subject: Bug 21821

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	bryce@gcc.gnu.org	2005-05-30 16:02:40

Modified files:
	libjava        : ChangeLog 
	libjava/gnu/java/nio/channels: natFileChannelPosix.cc 

Log message:
	2005-05-30  Bryce McKinlay  <mckinlay@redhat.com>
	
	PR libgcj/21821
	* gnu/java/nio/channels/natFileChannelPosix.cc (open): Don't use
	MAXPATHLEN. Format exception message using a StringBuffer instead.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3639&r2=1.3640
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/java/nio/channels/natFileChannelPosix.cc.diff?cvsroot=gcc&r1=1.6&r2=1.7

Comment 4 Alfred M. Szmidt 2005-05-30 16:23:54 UTC
(In reply to comment #2)
> Its easy to fix this for natFileChannelImpl.cc.

Thank you for fixing it!

> For natFilePosix.cc it is not so simple - is there a portable alternative to
> realpath() that does not require the use of MAXPATHLEN / PATH_MAX ?

One can call realpath() with NULL for the second parameter on systems that do
not have MAXPATHLEN/PATH_MAX.  You could also use canonicalize_file_name(), but
this is a GNU C library specific function.

 -- Function: char * realpath (const char *restrict NAME, char
          *restrict RESOLVED)
...
     On systems which define `PATH_MAX'
     this means the buffer must be large enough for a pathname of this
     size.  For systems without limitations on the pathname length the
     requirement cannot be met and programs should not call `realpath'
     with anything but `NULL' for the second parameter.

 -- Function: char * canonicalize_file_name (const char *NAME)
     The `canonicalize_file_name' function returns the absolute name of
     the file named by NAME which contains no `.', `..' components nor
     any repeated path separators (`/') or symlinks.  The result is
     passed back as the return value of the function in a block of
     memory allocated with `malloc'.  If the result is not used anymore
     the memory should be freed with a call to `free'.
Comment 5 Alfred M. Szmidt 2005-10-01 16:35:34 UTC
Created attachment 9856 [details]
Remove arbitrary limit in getCanonicalPath().

Here is a portable way of doing realpath().

libjava/ChangeLog
2005-09-16  Alfred M. Szmidt  <ams@gnu.org>

	* java/io/natFilePosix.cc (getCanonicalPath): Don't assume that
	MAXPATHLEN is defined.	Only declare BUF2 if HAVE_REALPATH is
	defined.
Comment 6 Alfred M. Szmidt 2005-10-01 18:58:38 UTC
Created attachment 9859 [details]
Remove arbitrary limit in File.Java:createTempFile

This removes the last (to my knowledge) MAXPATHLEN issue in Java.

libjava/ChangeLog
2005-10-01  Alfred M. Szmidt  <ams@gnu.org>

	* java/io/natFilePosix.cc (init_native) [!MAXPATHLEN]: Define to 0.
	* java/io/File.java (createTempFile): Don't truncate if the system
	doesn't have a limit on the length of a file name.
Comment 7 Andrew Pinski 2006-07-03 15:04:56 UTC
*** Bug 28234 has been marked as a duplicate of this bug. ***
Comment 8 Andrew Pinski 2007-07-21 18:59:57 UTC
*** Bug 32846 has been marked as a duplicate of this bug. ***
Comment 9 Tom Tromey 2007-07-24 14:36:15 UTC
Sorry I missed this for so long.
Please submit these patches to the java-patches mailing list.
Thanks.
Comment 10 Samuel Thibault 2007-08-04 22:02:54 UTC
It got fixed in CVS.
Comment 11 Andrew Pinski 2007-08-06 05:00:32 UTC
Fixed so closing.