search

Interlisp / medley

The main repo for the Medley Interlisp project. Wiki, Issues are here. Other repositories include maiko (the VM implementation) and Interlisp.github.io (web site sources)
https://Interlisp.org
MIT License
370 stars 19 forks source link

trouble with filename with ! in the name #1416

Open masinter opened 10 months ago

masinter commented 10 months ago

UNPACKFILENAME.STRING chokes on filename with ! in the middle... so

./ivy/grapevine/Build.bfs!1_/MesaFont.strike

causes an error trying to CONCATLIST 

("{" DSK "}" ".>ivy>grapevine>Build.bfs!1_" ">" "MesaFont" %. "")

(what happened to the 'strike'?) which gives an error(!)

masinter commented 10 months ago 
(PACKFILENAME.STRING '(HOST DSK BODY "/A/B/C!1_/D.E"))

triggers the error... need to get into the filename mess. The paths through the code to deal with the ! are likely to be the problem -- unlikely to be tested thoroughly because -- who makes filenames with ! anyway?

rmkaplan commented 10 months ago

I don’t get an error with UNPACKFILENAME.STRING, the result looks good except for the STRIKE. The exclamation mark (and also semi-colon) appear to be screwing the extension recognition (the finite-state machine has probably already gone into version mode).

I rewrote UNPACKFILENAME a couple of years ago, this is probably mine.

Note also that if I apply UNPACKFILENAME (not .STRING) to the same input, I get an uninterruptable crash into URAID, trying to build an atom that’s too large.

On Nov 12, 2023, at 8:46 AM, Larry Masinter @.***> wrote:

UNPACKFILENAME.STRING chokes on filename with ! in the middle... so

./ivy/grapevine/Build.bfs!1_/MesaFont.strike

causes an error trying to CONCATLIST

("{" DSK "}" ".>ivy>grapevine>Build.bfs!1_" ">" "MesaFont" %. "") (what happened to the 'strike'?) which gives an error(!)

— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/1416, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJL2UF6TO7YIGDSRO6DYED4QHAVCNFSM6AAAAAA7ID7AAGVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE4DSNBYGQYDEMY. You are receiving this because you are subscribed to this thread.

nbriggs commented 10 months ago

Note also that if I apply UNPACKFILENAME (not .STRING) to the same input, I get an uninterruptable crash into URAID, trying to build an atom that’s too large.

It's trying to deal with the "strike", but passing a block of memory with length -7

Fname is IL:MKATOM
## STACK FX at 0x13680 ##
[cnt = 0 ]
 #alink           0x3612 
 fnhead   0x2f9088 
 nextblock        0x368e 
 pc               0x81 
 nametbl  0x2f98a8 
 #blink           0x36a8 
 #clink           0x86 
  1368a : 0x  2f  0x38b0  
  1368c : 0x  60  0x2ea8  

< f4 
IVAR -------
  136da : 0x  60  0x5e2a  *local* IL:BASE  {IL:\UNBOXEDHUNK7}0x605e2a
  136dc : 0x   e  0x  16  *local* IL:OFFSET  22
  136de : 0x   f  0xfff9  *local* IL:LEN  -7
  136e0 : 0x   0  0x   0  *local* IL:FATP  CL:NIL
  136e2 : 0x   0  0x   0  *local* IL:FATCHARSEENP  CL:NIL

which causes \MAIKO.ALLOCBLOCK to think it needs to allocate 1073741823 cells.

rmkaplan commented 10 months ago

Fixed in PR #1421. Note that UNPACKFILENAME always purported to be sensitive to OSTYPE, defaulting to IFS and allowing ! as version numbers. That was probably never well thought out, but it has been carried along.