diff options
Diffstat (limited to 'community/gsoc/project_ideas/maxpath.mdwn')
-rw-r--r-- | community/gsoc/project_ideas/maxpath.mdwn | 46 |
1 files changed, 46 insertions, 0 deletions
diff --git a/community/gsoc/project_ideas/maxpath.mdwn b/community/gsoc/project_ideas/maxpath.mdwn new file mode 100644 index 00000000..5be8917f --- /dev/null +++ b/community/gsoc/project_ideas/maxpath.mdwn @@ -0,0 +1,46 @@ +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!meta title="Fixing Programs Using PATH_MAX et al Unconditionally"]] + +POSIX describes some constants (or rather macros) like PATH_MAX/MAXPATHLEN and +similar, which may be defined by the system to indicate certain limits. Many +people overlook the *may* though: Systems only should define them if they +actually have such fixed limits. The Hurd, following the GNU Coding Standards, +tries to avoid this kind of arbitrary limits, and consequently doesn't define +the macros. + +Many programs however just assume their presence, and use them unconditionally. +This is simply sloppy coding: not only does it violate POSIX and fails on +systems not defining the macros, but in fact most common use cases of these +macros are simply wrong! (See +<http://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html> for some +hints as to why this is so.) + +There are a few hundred packages in Debian GNU/Hurd failing to build because of +this -- simply grep for the offending macros in the +[list_of_build_failures](http://unstable.buildd.net/buildd/hurd-i386_Failed.html). + +Fixing these issues usually boils down to replacing `char foo[PATH_MAX]` +by `char *foo`, and using dynamic memory allocation, i.e. e.g. a loop +that tries geometrically growing sizes. Sometimes this is tricky, but +more often not very hard. Sometimes it is even trivial because the GNU +system has proper replacements. See the corresponding section of the +[[porting_guidelines_page|hurd/porting/guidelines]] for more details. With a bit of +practice, it should be easily possible to fix several programs per day. + +The goal of this project is to fix the PATH_MAX and related problems in a +significant number of packages, and make the fixes ready for inclusion in +Debian and (where possible) upstream. No Hurd-specific knowledge is needed, nor +any other special knowledge aside from general C programming skills. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Fix the PATH_MAX issues in some Debian package. |