newLISP Fan Club

Forum => newLISP newS => Topic started by: Lutz on May 07, 2012, 07:52:43 AM

Title: newLISP Stable Maintenance Release v.10.4.3
Post by: Lutz on May 07, 2012, 07:52:43 AM
Version 10.4.3 fixes two critical bugs when working with files.



Files and release notes: http://www.newlisp.org/index.cgi?page=Downloads
Title: Re: newLISP Stable Maintenance Release v.10.4.3
Post by: xytroxon on May 08, 2012, 02:32:44 AM
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
Title: Re: newLISP Stable Maintenance Release v.10.4.3
Post by: Lutz on May 08, 2012, 06:02:45 AM
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"
Title: Re: newLISP Stable Maintenance Release v.10.4.3
Post by: xytroxon on May 08, 2012, 03:36:29 PM
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



-- 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 ;>)
Title: Re: newLISP Stable Maintenance Release v.10.4.3
Post by: xytroxon on August 23, 2012, 02:38:41 AM
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



10.  Test Vectors



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



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



   BASE64("fo") = "Zm8="



   BASE64("foo") = "Zm9v"



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



   BASE64("fooba") = "Zm9vYmE="



   BASE64("foobar") = "Zm9vYmFy"



-- xytroxon
Title: Re: newLISP Stable Maintenance Release v.10.4.3
Post by: Lutz on August 23, 2012, 08:10:05 PM
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.