From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.bugs Subject: bug#7146: (make-symbol "") issues Date: Sun, 3 Oct 2010 14:45:39 -0400 Message-ID: References: <4CA6B2BE.7070705@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1286133119 6994 80.91.229.12 (3 Oct 2010 19:11:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 3 Oct 2010 19:11:59 +0000 (UTC) Cc: Chong Yidong To: 7146@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 03 21:11:52 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1P2TyM-0001ee-Os for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 Oct 2010 21:11:47 +0200 Original-Received: from localhost ([127.0.0.1]:38827 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P2TyL-0001dU-Ra for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 Oct 2010 15:11:45 -0400 Original-Received: from [140.186.70.92] (port=33704 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P2TyF-0001dK-Ia for bug-gnu-emacs@gnu.org; Sun, 03 Oct 2010 15:11:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P2TyE-0001Nv-62 for bug-gnu-emacs@gnu.org; Sun, 03 Oct 2010 15:11:39 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47022) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P2TyE-0001No-09 for bug-gnu-emacs@gnu.org; Sun, 03 Oct 2010 15:11:38 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1P2TWY-00012B-69; Sun, 03 Oct 2010 14:43:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <4CA6B2BE.7070705@gmail.com> Resent-From: MON KEY Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 Oct 2010 18:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7146 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7146-submit@debbugs.gnu.org id=B7146.12861313593969 (code B ref 7146); Sun, 03 Oct 2010 18:43:02 +0000 Original-Received: (at 7146) by debbugs.gnu.org; 3 Oct 2010 18:42:39 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P2TWB-00011y-3Q for submit@debbugs.gnu.org; Sun, 03 Oct 2010 14:42:39 -0400 Original-Received: from mail-ww0-f46.google.com ([74.125.82.46]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P2TW8-00011t-94 for 7146@debbugs.gnu.org; Sun, 03 Oct 2010 14:42:37 -0400 Original-Received: by wwb31 with SMTP id 31so5437458wwb.15 for <7146@debbugs.gnu.org>; Sun, 03 Oct 2010 11:45:39 -0700 (PDT) Original-Received: by 10.216.165.16 with SMTP id d16mr6797989wel.0.1286131539597; Sun, 03 Oct 2010 11:45:39 -0700 (PDT) Original-Received: by 10.216.67.195 with HTTP; Sun, 3 Oct 2010 11:45:39 -0700 (PDT) X-Google-Sender-Auth: ZG8GO2N4Q41qDSE9_z5zhkfBZUw X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 03 Oct 2010 14:43:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:40679 Archived-At: Chong Yidong wrote: > I guess we could make intern and make-symbol signal errors for the empty > string. That would be great! So, IIUC is the rationale for doing this is that there aren't really any particularly good reasons to intern the empty string given that the reader is incapable of reading it correctly? If so, maybe, along similar (inverted) lines the forms: (make-symbol "nil")/(intern-soft "nil")(intern "nil") should signal errors as well? I.e as it's impossible to correctly re-intern (with read or otherwise) an uninterned `nil' there should be no reason that one should need to make-symbol/intern-soft/intern "nil" either? Note however there is this: bug#5672: 23.1; (intern-soft "") returns non-nil (URL `http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-03/msg00026.html') Which may not comport with your decision to have `intern'/`make-symbol' signal error. In bug#5672 Stefan states that interning the empty string is not a bug because it might not always be done purposefully (IIUC). But note there is this more recent discussion: Date: Sat, 11 Sep 2010 19:33:07 -0400 Subject: Save `nil' from the mutant void, preserve the truth of falsehood, prevent the falsehood of truth (URL `http://lists.gnu.org/archive/html/emacs-devel/2010-09/msg00464.html') Where it is pointed out that `intern-soft'ing the emtpy string with e.g.: (prog1 #1=(intern-soft "") (unintern #1#)) is potentially problematic (at either compile or runtime). Note that the new `unintern' semantics requiring provision of an `obarray' account for some part of the problem. (This said, IMHO I still consider the form above a source of myriad potential security holes and abuse, new obarray semantics or no.) Whatever, b/c is difficult to prove formally that these potentialities for abuse exist without dialogue them publicly and b/c doing so is currently an exercise in self-flagellation given the absence of a willingness for honest public examination of the shortcomings of the Elisp reader the best one can do is hint at their possible implementation and home someone "gets it"... >From from the same thread: (URL `http://lists.gnu.org/archive/html/emacs-devel/2010-09/msg00494.html') There is also this example (relevant to the current bug) which provides an illustration of the vagaries of `intern-soft' w/re the empty string. The more salient portion included below for completeness: ,---- | | > since `intern' only takes a string rather than a symbol. | | Yeah, but again there is the weird corner case of interning the 0 | length string. Which, as shown in previous mail causes additional | headaches when attempting to re-intern a symbol. | | | emacs -Q | | (prin1 | (let ((s1 (intern (symbol-name (make-symbol "")))) | (s2 (intern (symbol-name '#:))) | cmp) | (setq cmp `((,#1=s1 ,#1#) (,#2=s2 ,#2#))) | `(:S1-LEN ,(length (car cmp)) | :S1-LEN ,(length (cadr cmp)) | :S1-IS-S1 ,(eq (caar cmp) (car (cdar cmp))) | :S2-IS-S2 ,(eq (car (cadr cmp)) (cadr (cadr cmp))) | :CAR-S1-IS-CAR-S2 ,(eq (caar cmp) (car (cadr cmp))) | :CADR-S1-IS-CADR-S2 ,(eq (car (cdar cmp)) (cadr (cadr cmp))) | :S1-IDENTITY ,(identity s1) | :S1-IDENTITY ,(identity s1) | :S1-SYM-NAME ,(symbol-name s1) | :S2-SYM-NAME ,(symbol-name s2) | :S2-UNINTD ,(unintern (car (cadr cmp))) | :S1-UNINTD ,(unintern (caar cmp)))) | (current-buffer)) | | (:S1-LEN 2 :S1-LEN 2 | :S1-IS-S1 t :S2-IS-S2 t | :CAR-S1-IS-CAR-S2 t :CADR-S1-IS-CADR-S2 t | :S1-IDENTITY :S1-IDENTITY ;; <- Note, that _is_ an identity | :S1-SYM-NAME "" :S2-SYM-NAME "" | :S2-UNINTD t :S1-UNINTD nil) | `---- Maybe too, `make-symbol' and `intern' should also have mandatory obarray arguments in keeping with the new semantics for `unintern'? -- /s_P\