newLISP Stable Maintenance Release v.10.4.3

Started by Lutz, May 07, 2012, 07:52:43 AM

Previous topic - Next topic

Lutz

Version 10.4.3 fixes two critical bugs when working with files.



Files and release notes: http://www.newlisp.org/index.cgi?page=Downloads">http://www.newlisp.org/index.cgi?page=Downloads

xytroxon

#1
This code:



(module "crypto.lsp")
(println (crypto:SHA1 "newLISP"))
(exit)


Crashes on Win 7:



newLISP v.10.4.3 on Win32 IPv4/6 libffi, execute 'newlisp -h' for more info.

Problem signature:
  Problem Event Name: APPCRASH
  Application Name: newlisp.exe
  Application Version: 0.0.0.0
  Application Timestamp: 4fa6cce3
  Fault Module Name: libeay32.dll
  Fault Module Version: 0.9.8.8
  Fault Module Timestamp: 48bef85f
  Exception Code: c0000005
  Exception Offset: 000beb50
  OS Version: 6.1.7600.2.0.0.768.3


--xytroxon
\"Many computers can print only capital letters, so we shall not use lowercase letters.\"

-- Let\'s Talk Lisp (c) 1976

Lutz

#2
It's (crypto:sha1 "newLISP") with lower-case sha1 not SHA1, the lower level imported function, which is only used internally in the module.


> (crypto:sha1 "newLISP")
"554f4c8dedd3ff02db493f328793cca0de5987c1"

xytroxon

#3
Thanks...



I saw in the "cryptp.lsp" source file:



(import library "MD5")
(import library "RIPEMD160")
(import library "SHA1")
(import library "SHA256")


... and missed (the next line ;o):



;; @syntax (crypto:md5 <string> <bool-raw>)


Late night coding and time for larger View panel fonts in FreeCommander!

http://en.wikipedia.org/wiki/FreeCommander">http://en.wikipedia.org/wiki/FreeCommander



-- xytroxon



P.S.



1. Concern that this minor syntax error caused a system hang / newlisp.exe crash and not just issue a newlisp error message.



2. Would be handy to have all the standard module's html pages pre-installed in the Windows distro.

i.e. accessible from the Start -> All Programs -> newLISP  just like "Manual and Reference",  "Code Patterns", etc. are. (We Windows users need all the help we can get ;>)
\"Many computers can print only capital letters, so we shall not use lowercase letters.\"

-- Let\'s Talk Lisp (c) 1976

xytroxon

#4
Hi Lutz!



This problem about drove me crazy, it only showed up rarely when decoding html base64 data strings...



(My previous late night crypto based "torture test" didn't catch it either  ;o)



In PHP, base64 encoding an empty string returns an empty string...



While newLisp returns "===="



>newlisp
newLISP v.10.4.3 on Win32 IPv4/6 libffi, execute 'newlisp -h' for more info.

> (base64-enc "")
"===="
>


From: RFC 4648    

http://tools.ietf.org/html/rfc4648">//http://tools.ietf.org/html/rfc4648



10.  Test Vectors



   BASE64("") = ""  <---- HELLO!!!



   BASE64("f") = "Zg=="



   BASE64("fo") = "Zm8="



   BASE64("foo") = "Zm9v"



   BASE64("foob") = "Zm9vYg=="



   BASE64("fooba") = "Zm9vYmE="



   BASE64("foobar") = "Zm9vYmFy"



-- xytroxon
\"Many computers can print only capital letters, so we shall not use lowercase letters.\"

-- Let\'s Talk Lisp (c) 1976

Lutz

#5
changed in 10.4.4 using an optional flag:


newLISP v.10.4.4 on OSX IPv4/6 UTF-8 libffi, execute 'newlisp -h' for more info.

> (base64-enc "")
"===="
> (base64-enc "" true)  ; new in version 10.4.4
""
> (base64-dec "")
""
> (base64-dec "====")
""
>


Ps: the text-based command interface of the guiserver requires the empty string to be encoded as "====" . Although the test-cases in the RFC translate into "", I believe that "====" as encoding for the empty string is still ok. When decoding base64 padding chars "====" back, you get "" again.