public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jsm28 at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug libc/13712] Add Type Cast to Main and Exec Calls Date: Tue, 21 Feb 2012 03:14:00 -0000 [thread overview] Message-ID: <bug-13712-131-f4s6AVlzwe@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-13712-131@http.sourceware.org/bugzilla/> http://sourceware.org/bugzilla/show_bug.cgi?id=13712 Joseph Myers <jsm28 at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID --- Comment #4 from Joseph Myers <jsm28 at gcc dot gnu.org> 2012-02-21 03:14:10 UTC --- There is a difference in POSIX between filenames, defined as "A name consisting of 1 to {NAME_MAX} bytes used to name a file. The characters composing the name may be selected from the set of all character values excluding the <slash> character and the null byte.", and portable filenames. glibc and most filesystems on POSIX systems support all valid filenames, not just portable filenames. http://austingroupbugs.net/view.php?id=251 is a proposal for disallowing newlines in filenames, as the most problematic characters - all other characters can be handled in shell scripts significantly more easily. There has been a huge amount written on that subject on the Austin Group mailing list over the past couple of years, and anyone seriously interested in addressing such issues needs to digest the previous discussion and engage with the main forum where they are discussed, which is the Austin Group - you need to argue how a new C API should be part of the solution. In any case, it is not possible to implement such a feature in glibc without the underlying kernel interfaces supplementing execve, so having a well-defined and accepted kernel interface would be required for a meaningful request to implement such a feature in glibc. Bug trackers are simply not an appropriate place for designing features involving multiple components because they do not support discussion of the interactions between those components. Thus, if you wish to discuss this further, please do not do it here; raise it on appropriate mailing lists that deal with those interactions. In practice the Austin Group lists would be the best place; for changes specific to GNU/Linux, you could consider the linux-api list which deals with the kernel/userspace interface. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
next prev parent reply other threads:[~2012-02-21 3:14 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-02-20 3:29 [Bug libc/13712] New: " oiaohm at gmail dot com 2012-02-20 23:39 ` [Bug libc/13712] " oiaohm at gmail dot com 2012-02-20 23:50 ` jsm28 at gcc dot gnu.org 2012-02-21 2:44 ` oiaohm at gmail dot com 2012-02-21 3:14 ` jsm28 at gcc dot gnu.org [this message] 2012-02-22 5:22 ` oiaohm at gmail dot com 2014-06-26 15:21 ` fweimer 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=bug-13712-131-f4s6AVlzwe@http.sourceware.org/bugzilla/ \ --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: linkBe 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).