rewriting config_*, xmalloc_fget*

[Paul Smith]

On Thu, 2011-06-16 at 15:13 -0400, Rich Felker wrote:
> On Thu, Jun 16, 2011 at 03:16:38PM -0400, Paul Smith wrote:
> > PS. Interestingly, there's a move afoot to remove newline from the set
> >     of acceptable characters in a POSIX-compliant filename...
> 
> Do you have details on this? It's interesting because aside from the
> '/' (which is granted special meaning) POSIX only specifies which
> characters are portable and guaranteed to be supported in filenames,
> but does not forbid any characters. Would this mean interfaces that
> create files "shall" fail if given a name contain a newline? It would
> be a welcome change, but I can see many folks resisting...

I believe anonymous access to the Austin Group bugtracker is available.
The proposal is here:

http://austingroupbugs.net/view.php?id=251

In addition there've been a number of long threads on this in the
mailing list which aren't completely reflected in the bug, including how
real implementations might handle migration to the new standard when
there could be existing filenames which are suddenly illegal.

The original proposal was that ALL characters with ASCII codes 0 through
31 would be forbidden.  The fallback position, should that prove too
unpalatable, is just to restrict newline and possible a couple of other
bad actors like TAB and ESC.

The proposal suggests a new errno code (ENAME) be returned by filename
handling functions when an invalid filename is received.

The wording suggested is:

        Vol. 1, Page 60, line 1782-1784:
        Change:
         "The characters composing the name may be selected
          from the set of all character values excluding the <slash> character
          and the null byte."
        to:
         "The characters composing the name may be selected
          from the set of all character values excluding the <slash> character,
          the null byte, and character values 1 through 31 inclusive.
          Attempts to create filenames containing bytes 1 though 31 must be rejected,
          and conforming implementations
          must not return such filenames to applications or users."
        
        
        Vol. 1, Page 77, append after 2199:
        The set of character values 1 through 31, inclusive, are expressly forbidden.
         Attempts to create such filenames must be rejected, and conforming implementations
         must not return such filenames to applications or users.
        
        Vol. 2, page 480,
        [ENAME]
         The path name is not a permitted name, e.g., it contains bytes 1 through 31 (inclusive).

Note this is still under review and active discussion so who knows if it
will go anywhere.

When I first read it my knee-jerk reaction was "no way!  This is UNIX!"
but now that I've lived with it for a while I actually like it.  I see
zero benefit to the current behavior, other than some abstract,
arbitrary concept of "purity" and even though I've been hacking shell
scripts, etc. for an embarrassing number of years, I still run into
these issues (or, more likely, just document that the script doesn't
work with ill-formed filenames).