I think this was a mixup with issue #5. None of his test cases were actually
failing.

It bothers me a little bit that I can't figure out how to free the
parser --- surely that is a thing that the bindings for other
languages need to do --- but storing a pointer to the parser in a
statically-allocated variable, as in base64.c, at least stops valgrind
from reporting the parser as a memory leak.

Obviously we don't care if examples/base64.c leaks memory before
exiting, but things like that are noise that make it hard to tell if
there's a real memory-leak problem somewhere else; it also sets a bad
example for code that someone might write modeled on the example.
This patch ensures that the example frees its allocations as it
should.

xentrac authored 5 years ago and Andrea Shepard committed 5 years ago

It was trying to dump the parse tree even when it was NULL due to parse
failure.  This was particularly a problem since earlier in the file it

In Python 2.x an unprefixed string literal produces a byte string.
In Python 3.x an unprefixed string literal produces a textual string.

To produce a byte string in both a b prefix is needed, e.g. b'foo'.
Since I believe Hammer works predominantly with byte strings I have used
b prefixes throughout.

In Python 3.x

- int and long types are unified. The unified type is called int.
- the text string type (unicode) is renamed to str.
- the byte string type (str) is renamed to bytes.
- chr returns a text string (i.e. str)
- xrange is renamed to range.
- dict.has_key() is removed
-

These have no effect in Python 3.x, they are the default. Enabling them
in Python 2.x, enabling them in Python 2.x allows single source
compatiblity.

This is proof that Hammer can be linked and used in a windows
program!

These are transliterations of the existing C files.
They're not particularly Pythonic or performant, but they're a start.

Example of usage

```
$ echo '  YW55IGNhcm5hbCBwbGVhcw==' | PYTHONPATH=../build/opt/src/bindings/python/ python base64.py
inputsize=27
input=  YW55IGNhcm5hbCBwbGVhcw==
((((89L, 87L, 53L, 53L), (73L, 71L, 78L, 104L), (99L, 109L, 53L, 104L), (98L, 67L, 66L, 119L), (98L, 71L, 86L, 104L)), (99L, 'w', '=', '=')),)
$ echo '  YW55IGNhcm5hbCBwbGVhcw==' | PYTHONPATH=../build/opt/src/bindings/python/ python base64_sem1.py
inputsize=27
input=  YW55IGNhcm5hbCBwbGVhcw==
(97L, 110L, 121L, 32L, 99L, 97L, 114L, 110L, 97L, 108L, 32L, 112L, 108L, 101L, 97L, 115L)
$ echo '  YW55IGNhcm5hbCBwbGVhcw==' | PYTHONPATH=../build/opt/src/bindings/python/ python base64_sem2.py
inputsize=27
input=  YW55IGNhcm5hbCBwbGVhcw==
(97L, 110L, 121L, 32L, 99L, 97L, 114L, 110L, 97L, 108L, 32L, 112L, 108L, 101L, 97L, 115L)
```

Now we can do things like:

# copy-paste from output
ring.<t,L,tie,Cn,M,Ln,I,D,J,Rn,A,K,F,G> = QQ[]
ID = ring.ideal(L - (1*Cn*t),tie - (1*Ln*t),Cn - (1*I + 1*J),M - (1*t^2),Ln - (1*D + 1*L + 1*M),I - (1*Rn*t),D - (1*Rn*t),J - (1*Ln*t),Rn - (1*F + 1*G + 1*K),A - (1*tie),K - (1*t^2),F - (1*Ln*t),G - (1*Cn*t))

# we are interested in tie in terms of t; so we want to remove anything not these two:
ID.elimination_ideal([L,Cn,M,Ln,I,D,J,Rn,A,K,F,G])

# output from this SageMath command is
# Ideal (t^3 + 2*t^2*tie + t*tie - tie) of Multivariate Polynomial Ring in t, L, tie, Cn, M, Ln, I, D, J, Rn, A, K, F, G over Rational Field
# which we can solve for tie to get tie = t^3/(1-t-2*t^2) just as expected

I don't think these actually affect correctness since there's no way for
0x40 or 0x60 to show up in a parse tree anyway, but they're confusing.

effects throughout, including use of inttypes.h/PRI[ud]64 because printf() is
still stuck in a long world, conversion of %lu to %zu for printing values of
type size_t, and changing/renaming the g_check_cmp* family of functions.