bug#7146: (make-symbol "") issues

bug#7146: (make-symbol "") issues

[Frank]

;;; "GNU Emacs 23.2.1 (i386-mingw-nt5.1.2600) of 2010-05-08 on G41R2F1"

;; When I byte compile this file and load it and try to evaluate (foo)
;; Emacs will either crash or (foo) returns some odd number on my machine.

(defmacro bar (&rest body)
  (let ((v (make-symbol "")))         ; Crashes with "" as name.
    `(let ((,v (catch :eof
         ,@body)))

       (when (not (eq ,v :eof))
     ,v))))

(defun foo ()
  (bar (message "Hello World!")))


;; (disassemble 'foo)
;;
;; byte code for foo:
;;   args: nil
;; 0    constant  (message "Hello World!")
;; 1    constant  (out-of-range 2)
;; 2    catch
;; 3    dup
;; 4    varbind      #::eof
;; 5    constant  (message "Hello World!")
;; 6    eq
;; 7    not
;; 8    goto-if-nil-else-pop 1
;; 11    varref      #::eof
;; 12:1    unbind      1
;; 13    return
;;
;; Looks like there's a problem in line 4 & 11.

bug#7146: (make-symbol "") issues

[Frank]

Well I further found out that you have to actually (byte-compile-file) 
the above code in order for the bug to show up; compiling via 
(compile-defun) seems to work OK;

bug#7146: (make-symbol "") issues

[Chong Yidong]

Frank <some.frank@gmail.com> writes:

> Well I further found out that you have to actually (byte-compile-file)
> the above code in order for the bug to show up; compiling via
> (compile-defun) seems to work OK;

I can't reproduce this.  Could you detail the *exact* steps you took,
starting with `emacs -Q'?  Your description is too vague.

bug#7146: (make-symbol "") issues

[Frank]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

Chong Yidong schrieb:

>Frank <some.frank@gmail.com> writes:
>
>  
>
>>Well I further found out that you have to actually (byte-compile-file)
>>the above code in order for the bug to show up; compiling via
>>(compile-defun) seems to work OK;
>>    
>>
>
>I can't reproduce this.  Could you detail the *exact* steps you took,
>starting with `emacs -Q'?  Your description is too vague.
>
>  
>
1) Start `emacs -Q'
2) Load the file bug.el into a buffer via the menu
3) <M-x> byte-compile-file
4) <M-x> load-file bug.elc
5) <C-x b> *scratch*
6) (foo) *** emacs crashes or foo returns some odd number ***

(disassemble 'foo) looks like this (done between point 5 and 6)

byte code for foo:
  args: nil
0    constant  (message "Hello World!")
1    constant  (out-of-range 2)
2    catch     
3    dup     
4    varbind      :eof
5    constant  (message "Hello World!")
6    eq     
7    not     
8    goto-if-nil-else-pop 1
11    varref      :eof
12:1    unbind      1
13    return     

I attached the file I used for testing this and also it's byte compilation


[-- Attachment #2: bug.elc --]
[-- Type: application/octet-stream, Size: 775 bytes --]

[-- Attachment #3: bug.el --]
[-- Type: text/plain, Size: 226 bytes --]

(defmacro bar (&rest body)
 (let ((v (make-symbol "")))         ; Crashes with "" as name.
   `(let ((,v (catch :eof
        ,@body)))

      (when (not (eq ,v :eof))
    ,v))))

(defun foo ()
 (bar (message "Hello World!")))

bug#7146: (make-symbol "") issues

[Chong Yidong]

Frank <some.frank@gmail.com> writes:

> 1) Start `emacs -Q'
> 2) Load the file bug.el into a buffer via the menu
> 3) <M-x> byte-compile-file
> 4) <M-x> load-file bug.elc
> 5) <C-x b> *scratch*
> 6) (foo) *** emacs crashes or foo returns some odd number ***

I assume by (foo) you mean typing "(foo)" and doing C-j or C-x C-e.

I'm afraid I don't see any crash.  The number 6 appears in the echo
area, that's all.

bug#7146: (make-symbol "") issues

[Frank]

Chong Yidong schrieb:

>Frank <some.frank@gmail.com> writes:
>
>  
>
>>1) Start `emacs -Q'
>>2) Load the file bug.el into a buffer via the menu
>>3) <M-x> byte-compile-file
>>4) <M-x> load-file bug.elc
>>5) <C-x b> *scratch*
>>6) (foo) *** emacs crashes or foo returns some odd number ***
>>    
>>
>
>I assume by (foo) you mean typing "(foo)" and doing C-j or C-x C-e.
>
>I'm afraid I don't see any crash.  The number 6 appears in the echo
>area, that's all.
>
>  
>
Yes I type (foo) in the *scratch* buffer and then <C-x C-e>

Well if everything runs good then "Hello World" should appear in the 
echo area, everything else is wrong!!!

As I said sometimes it crashes, sometimes it returns some number!

bug#7146: (make-symbol "") issues

[Juanma Barranquero]

On Sun, Oct 3, 2010 at 06:05, Chong Yidong <cyd@stupidchicken.com> wrote:

> I'm afraid I don't see any crash.  The number 6 appears in the echo
> area, that's all.

I see it on Windows, with the current trunk.

    Juanma


Program received signal SIGSEGV, Segmentation fault.
0x0102bfb6 in find_symbol_value (symbol=2) at data.c:1059
1059      switch (sym->redirect)
(gdb) bt
#0  0x0102bfb6 in find_symbol_value (symbol=2) at data.c:1059
#1  0x0102c150 in Fsymbol_value (symbol=2) at data.c:1082
#2  0x01038edf in Feval (form=2) at eval.c:2231
#3  0x01036eef in internal_catch (tag=53471294, func=0x1038eb2
<Feval>, arg=2) at eval.c:1204
#4  0x01283183 in Fbyte_code (bytestr=74807729, vector=50925637,
maxdepth=12) at bytecode.c:854
#5  0x0103c9e7 in funcall_lambda (fun=50106437, nargs=0,
arg_vector=0x88f1b0) at eval.c:3174
#6  0x0103c41d in apply_lambda (fun=50106437, args=48474138,
eval_flag=1) at eval.c:3100
#7  0x01039eed in Feval (form=74931054) at eval.c:2394
#8  0x0103bb72 in Ffuncall (nargs=2, args=0x88f3f4) at eval.c:2990
#9  0x0128285f in Fbyte_code (bytestr=21103025, vector=21103077,
maxdepth=12) at bytecode.c:679
#10 0x0103c9e7 in funcall_lambda (fun=21102989, nargs=1,
arg_vector=0x88f624) at eval.c:3174
#11 0x0103c0f9 in Ffuncall (nargs=2, args=0x88f620) at eval.c:3036
#12 0x0128285f in Fbyte_code (bytestr=21103369, vector=21103421,
maxdepth=12) at bytecode.c:679
#13 0x0103c9e7 in funcall_lambda (fun=21103341, nargs=1,
arg_vector=0x88f8a4) at eval.c:3174
#14 0x0103c0f9 in Ffuncall (nargs=2, args=0x88f8a0) at eval.c:3036
#15 0x01281929 in Fcall_interactively (function=49029794,
record_flag=48474138, keys=48495365) at callint.c:849
#16 0x0103bcb2 in Ffuncall (nargs=4, args=0x88fb30) at eval.c:2996
#17 0x0103b10f in call3 (fn=48643962, arg1=49029794, arg2=48474138,
arg3=48474138) at eval.c:2820
#18 0x0102294e in Fcommand_execute (cmd=49029794,
record_flag=48474138, keys=48474138, special=48474138) at
keyboard.c:10330
#19 0x0100863d in command_loop_1 () at keyboard.c:1737
#20 0x010374d0 in internal_condition_case (bfun=0x1007058
<command_loop_1>, handlers=48527722, hfun=0x100678d <cmd_error>) at
eval.c:1460
#21 0x01006c63 in command_loop_2 (ignore=48474138) at keyboard.c:1338
#22 0x01036eef in internal_catch (tag=48525842, func=0x1006c40
<command_loop_2>, arg=48474138) at eval.c:1204
#23 0x01006c1b in command_loop () at keyboard.c:1317
#24 0x01005e7f in recursive_edit_1 () at keyboard.c:940
#25 0x010063a3 in Frecursive_edit () at keyboard.c:1002
#26 0x010026af in main (argc=2, argv=0xb72c50) at emacs.c:1718

Lisp Backtrace:
"foo" (0x88f1b0)
"eval" (0x88f3f8)
"eval-last-sexp-1" (0x88f624)
"eval-last-sexp" (0x88f8a4)
"call-interactively" (0x88fb34)
(gdb)

bug#7146: (make-symbol "") issues

[Johan Bockgård]

Chong Yidong <cyd@stupidchicken.com> writes:

> Frank <some.frank@gmail.com> writes:
>
>> 1) Start `emacs -Q'
>> 2) Load the file bug.el into a buffer via the menu
>> 3) <M-x> byte-compile-file
>> 4) <M-x> load-file bug.elc
>> 5) <C-x b> *scratch*
>> 6) (foo) *** emacs crashes or foo returns some odd number ***
>
> I assume by (foo) you mean typing "(foo)" and doing C-j or C-x C-e.
>
> I'm afraid I don't see any crash.  The number 6 appears in the echo
> area, that's all.

The problem is that there is no read syntax for a symbol with an empty
name, so it can't reliably be printed to a string (file) and read back.

  (symbol-name (aref [#: x] 0)) => "x" ; This is what happens in the report.

  but (symbol-name (aref [#:] 0)) => ""

You could change the reader to somehow recognize the first case. The
problem would come back if you changed `make-symbol' to `intern',
though, since it really prints as nothing at all.

bug#7146: (make-symbol "") issues

[Chong Yidong]

Johan Bockgård <bojohan@gnu.org> writes:

> The problem is that there is no read syntax for a symbol with an empty
> name, so it can't reliably be printed to a string (file) and read back.
>
>   (symbol-name (aref [#: x] 0)) => "x" ; This is what happens in the report.
>
>   but (symbol-name (aref [#:] 0)) => ""
>
> You could change the reader to somehow recognize the first case. The
> problem would come back if you changed `make-symbol' to `intern',
> though, since it really prints as nothing at all.

I guess we could make intern and make-symbol signal errors for the empty
string.

bug#7146: (make-symbol "") issues

[Stefan Monnier]

> I guess we could make intern and make-symbol signal errors for the empty
> string.

No, we should make them write some non-empty representation.


        Stefan

bug#7146: (make-symbol "") issues

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I guess we could make intern and make-symbol signal errors for the empty
>> string.
>
> No, we should make them write some non-empty representation.

Even though this is obscure, this is a bug that can crash (some builds
of) Emacs.  So I rather think this should be fixed.  Was any work done
towards adding a printed representation of empty-string symbols?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#7146: (make-symbol "") issues

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Even though this is obscure, this is a bug that can crash (some builds
> of) Emacs.  So I rather think this should be fixed.  Was any work done
> towards adding a printed representation of empty-string symbols?

What would be a good mnemonic?  We need two different representations
(interned and uninterned), perhaps ## and #= ?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#7146: (make-symbol "") issues

[Stefan Monnier]

>> Even though this is obscure, this is a bug that can crash (some builds
>> of) Emacs.  So I rather think this should be fixed.  Was any work done
>> towards adding a printed representation of empty-string symbols?
> What would be a good mnemonic?  We need two different representations
> (interned and uninterned), perhaps ## and #= ?

"#:" is the obvious choice for the uninterned representation.
It already works for printing, but is not understood by the reader.

CommonLisp has a |....| syntax for interned symbols which trivially
allows empty symbols, and some Scheme iumplementations adopted it as
well, although R6RS didn't (it did add a \xNNNN notation which allows
for non-ASCII chars, but it doesn't seem to include a notation for empty
symbols).


        Stefan

bug#7146: (make-symbol "") issues

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> "#:" is the obvious choice for the uninterned representation.
> It already works for printing, but is not understood by the reader.

That works now.

> CommonLisp has a |....| syntax

I don't think it is a good idea to add a new special character, so ##
would still be my choice.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#7146: (make-symbol "") issues

[Stefan Monnier]

>> CommonLisp has a |....| syntax
> I don't think it is a good idea to add a new special character, so ##
> would still be my choice.

Another approach is to follow the same idea as with "#:" ("#: is
immediately followed by <sym> so if it's followed by something that's
not appropriate it means <sym> is empty").
I.e. "#N=" could be used for the empty interned symbol.


        Stefan

bug#7146: (make-symbol "") issues

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> CommonLisp has a |....| syntax
>> I don't think it is a good idea to add a new special character, so ##
>> would still be my choice.
>
> Another approach is to follow the same idea as with "#:" ("#: is
> immediately followed by <sym> so if it's followed by something that's
> not appropriate it means <sym> is empty").
> I.e. "#N=" could be used for the empty interned symbol.

This is inconvenient to implement with the current print_object code,
and anyway #N= is not a good conceptual match with empty symbols.

I don't have any objection to using ##.

bug#7146: (make-symbol "") issues

[Andreas Schwab]

Chong Yidong <cyd@stupidchicken.com> writes:

> I don't have any objection to using ##.

This is now implemented.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#7146: (make-symbol "") issues

[David De La Harpe Golden]

On 17/07/11 04:16, Stefan Monnier wrote:

> "#:" is the obvious choice for the uninterned representation.
> It already works for printing, but is not understood by the reader.
>

Is it? If you mean just a "#:" on its own it looks a bit odd to me, but 
as usual I'm coming from CL.

> CommonLisp has a |....| syntax for interned symbols which trivially
> allows empty symbols,

That's not just for interned symbols.  #:|| is read as an uninterned 
empty-string named symbol in common lisp, #:|hello world| as an 
uninterned symbol with a space in the name etc.

bug#7146: (make-symbol "") issues

[MON KEY]

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\

bug#7146: (make-symbol "") issues

[Chong Yidong]

MON KEY <monkey@sandpframing.com> writes:

> 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?

The only reason is that it can lead to a crash.  There are plenty of
reasons to shoot yourself in the foot in Lisp in you're determined to do
so; it's not profitable to address them unless a real world problem
surfaces.

bug#7146: (make-symbol "") issues

[MON KEY]

On Sun, Oct 3, 2010 at 2:56 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> MON KEY <monkey@sandpframing.com> writes:
>
>> 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?
>

> The only reason is that it can lead to a crash.

So the potential for a crashed Emacs is rationale enough, whereas
potential for an inexplicably hung and thoroughly corrupted Emacs is
just grist for the mill?

>  There are plenty of
> reasons to shoot yourself in the foot in Lisp in you're determined to do

And a good deal of these apply equally even for the undetermined and
un-intentioned, not to mention the ill-intentioned.

> so; it's not profitable to address them unless a real world problem
> surfaces.
>

OK.

--
/s_P\