43fef5fad8
Byte streams transcoding to :ucs-2 and :ucs-4 don't call ecl_set_stream_elt_type effectively not initializing .byte_buffer. Moreover functions seq_in_read_byte8 and seq_out_write_byte8 assume the vector type to be an octet based, and they increment the stream position and test for its limit according to that. That means that ecl_binary_read_byte and ecl_binary_write_byte calls would segfault when seq_in_read_byte8 and seq_out_write_byte8 are called. Both conditions could be easily mitigated by initializing .byte_buffer manually and fixing seq_*_*_byte8 functions to account for the byte size, but there is no need for that, because for these streams we are not using ecl_binary_*_byte ecl_eformat_*_byte so byte8 functions are not called and .byte_buffer is not used. |
||
|---|---|---|
| contrib | ||
| examples | ||
| msvc | ||
| src | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| appveyor.yml | ||
| CHANGELOG | ||
| configure | ||
| COPYING | ||
| INSTALL | ||
| LICENSE | ||
| Makefile.in | ||
| README.md | ||
ECL stands for Embeddable Common-Lisp. The ECL project aims to produce an implementation of the Common-Lisp language which complies to the ANSI X3J13 definition of the language.
The term embeddable refers to the fact that ECL includes a Lisp to C compiler, which produces libraries (static or dynamic) that can be called from C programs. Furthermore, ECL can produce standalone executables from Lisp code and can itself be linked to your programs as a shared library. It also features an interpreter for situations when a C compiler isn't available.
ECL supports the operating systems Linux, FreeBSD, NetBSD, DragonFly BSD, OpenBSD, Solaris (at least v. 9), Microsoft Windows (MSVC, MinGW and Cygwin) and OSX, running on top of the Intel, Sparc, Alpha, ARM and PowerPC processors. Porting to other architectures should be rather easy.