OpenEuphoria

2. Re: Bug in std/base64.e

• Posted by ghaberek (admin) 1 month ago
• 1731 views

We track tickets here: https://openeuphoria.org/ticket/ I would like to move them to GitHub but to my knowledge there's no good way to do that and preserve the ticket numbers and original user information. I'm open to suggestions on that if anyone knows how.

I'm not seeing how this is a bug? Not trying to be pedantic; just want to make sure you didn't leave out some unexpected behavior you're experiencing when using the library. I agree it needs improvement. Looking at the code I see several ways we could make this better.

Calling trim_tail(str, '=') makes an unnecessary copy of the sequence that you're then discarding, just to get its length. Also I would use the types library instead of regex. I love regular expressions but they're a bit heavy for checks like this.

include std/base64.e 
include std/types.e 
 
-- Returns 1 if all characters are in the allow range(s) 
type t_base64(object test_data) 
    return types:char_test(test_data, { 
        {'0','9'}, -- [0-9] 
        {'A','Z'}, -- [A-Z] 
        {'a','z'}, -- [a-z] 
        {'+','+'}, -- [+] 
        {'/','/'}  -- [/] 
    }) 
end type 
 
-- Returns the number of times 'ch' appears at the end of 's' 
function count_at_end(sequence s, integer ch) 
    integer n = length(s) 
    while n != 0 and s[n] = ch do 
        n -= 1 
    end while 
    return length(s) - n 
end function 
 
-- Base64 decode  
-- ... 
function base64_decode(sequence str) 
    -- Error if more than 2 pad trailing characters 
    atom pad_length = count_at_end(str, '=') 
    if pad_length > 2 then 
        return -1 
    end if 
 
    -- Remove trailing pad characters 
    str = str[1..$-pad_length] 
 
    -- Error if invalid Base64 characters 
    if not t_base64(str) then 
        return -1 
    end if 
 
    -- Use Base64 decode library function 
    return base64:decode(str) 
end function 

If you're using encode() as well, you might want to also check that it's only receiving valid bytes:

function base64_decode(sequence str) 
    -- Error of anything but valid bytes (0..255) 
    if not types:string(str) then 
        return -1 
    end if 
 
    -- Use Base64 encode library function 
    return base64:encode(str) 
end function 

I don't think we have an official contributing guide and anything found in the wiki is likely outdated and still references Mercurial and SCM. If you're interested in contributing (which is great! we very much need some help around here) I can try to put something together.

But basically, once you make your changes, add or update the relevant unit tests (in this case t_base64.e) and make sure they pass with eutest. You can also include the -all parameter to see the tests' status. This helps to ensure your new test(s) are actually running.

$ eutest tests/t_base64.e 
 
interpreting tests/t_base64.e: 
 
Test results summary: 
Files (run: 1) (failed: 0) (100% success) 

-Greg

4. Re: Bug in std/base64.e

• Posted by ghaberek (admin) 1 month ago
• 1670 views

Fair enough. It should indeed not be doing that.

-Greg

6. Re: Bug in std/base64.e

• Posted by rzuckerm 1 month ago
• 1647 views

Never mind. I have to run the tests with -i $(pwd)/include.

8. Re: Bug in std/base64.e

• Posted by ghaberek (admin) 1 month ago
• 1609 views

Full disclosure: I have not touched the vscode-euphoria extension in a while so I'm not sure what state it's in.

As I recall, any further improvements required writing a language server which hasn't been high on my priority list.

Yep. By default your interpreter is going to be using the include files it's pointing to in eu.cfg where it's installed.

So if your interpreter is /usr/local/euphoria/bin/eui there should be eu.cfg that contains -i /usr/local/euphoria/include

When you build Euphoria, the configure script creates a new eu.cfg in the build directory that points to the include directory next to source.

So if you're building in /home/rzuckerm/euphoria/source/build, that eu.cfg should contain -i /home/rzuckerm/euphoria/include

Excellent! So am I. Actually it looks like I'm on Ubuntu 24.04. But I've been using WSL as my primary development environment for a while now. At least since WSL2 came out in 2019.

All of the checks passed, so that's good. Although currently that just means the builds completed. I don't have the actions running unit tests because many of the tests need correcting to pass. Yet another thing that needs some attention around here.

I have merged your PR. Thanks!

-Greg

10. Re: Bug in std/base64.e

• Posted by ghaberek (admin) 1 month ago
• 1570 views

Good catch! I've merged that PR now as well. Thanks again.

-Greg