-
Notifications
You must be signed in to change notification settings - Fork 155
Updated headers #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Hi, the IUP update will surely be welcomed: I quickly looked at the updated Lua headers, and they seem to have some issues, for example:
typedef void * (*lua_Alloc) (void *ud, void *ptr, size_t osize, size_t nsize);
type lua_Alloc as sub cdecl(byval as any ptr, byval as any ptr, byval as size_t, byval as size_t)
type lua_Alloc as function cdecl(byval as any ptr, byval as any ptr, byval as size_t, byval as size_t) as any ptr
LUA_API size_t (lua_rawlen) (lua_State *L, int idx);
declare function size_t cdecl alias "size_t" (byval as lua_rawlen) as LUA_API
should be more like:
declare function lua_rawlen cdecl alias "lua_rawlen"(byval L as lua_State ptr, byval idx as integer) as size_t |
|
I guessed as much as they were entirely swig translated and I just added a
|
|
I will also get the def regenerated as the one included is very outdated.
|
|
I have looked over the Lua headers and made a few corrections. |
There theoretically were instances where the value would be uinitialized. The build errors only affect certain gcc versions and the way implemented should not interfere with a working compiler.
|
I merged the header updates and updated the Lua headers to 5.2.2. Also, the (only) Lua example we have needed adjustment to work with Lua 5.2 where lua_open() was removed. Besides that, the updated IUP headers needed some adjustment to fix case-insensitivity conflicts. I tested them on Win32 (only) with the tabs example from here: Do we really need the *.def files? The IUP MinGW lib download contains import libs already, so we don't need to bother making our own. As for Lua, I have built static lib and DLL+import lib versions of it for the next FB release, it's easy enough to get the build to produce an import lib when making the DLL, so I think we don't need this one either. About the others (CD/IM library bindings), I don't know yet, could you try and provide some information on them (such as homepage and purpose) on the http://www.freebasic.net/wiki/wikka.php?wakka=ExtLibTOC wiki page, please? Also, we should have some changelog.txt entries for the updated and added headers. I can do that for Lua and IUP at least. |
|
I saw you removed the def files, i'm all for it if they're easily available. I was attempting to add the CD and IM bindings information to the wiki but it gives me the 404. Basically CD is a canvas like cairo, makes drawing stuff pretty easy and cross platform http://www.tecgraf.puc-rio.br/cd/, IM is for image loading / manipulation http://www.tecgraf.puc-rio.br/im/. |
- related to sf.net # 953 - detect and report bad syntax in 'input #1, "T"' => error 14: Expected identifier in 'input #1, "T"' - improve positional information For example: input #1, "T",& error 14: Expected identifier, found '&' in 'input #1, "T",&' Is now: error 14: Expected identifier, before ',' in 'input #1, "T",&'
…er for ZSTRING/WSTRING PTR - new syntax is 'LINE INPUT #1, variable [, max-length]' to allow specifying maximum length available in the input buffer - not applicable to fixed length STRING or ZSTRING or WSTRING - fbc 1.07.1 fixed some potential wstring buffer overflows. As a consequence, LINE INPUT does not read line fully if size of the wstring buffer is unknown - applies to zstring ptr's also - where max-length is the maximum number of characters available in the buffer including the NULL terminator - on windows maxchars is actually number of UTF16 code units - i.e. unicode code points greater than 0xffff are stored as more than one code unit Example: const maxlength = 1024 '' (max 1023 [w]chars plus 1 NULL [w]char) dim w as wstring ptr = callocate( sizeof(wstring) * maxlength ) open "file.txt" for input as #1 while not eof(1) '' length of w buffer is unknown at compile time - maxlength is needed line input #1, *w, maxlength print *w wend close #1 deallocate( w )
…evant length argument - throw a compile error if LINE INPUT has incorrect length argument (either missing or irrelevant) - LINE INPUT [#1] requires length parameter if destination variable is a w|zstring pointer - LINE INPUT [#1] may not have length parameter if destination variable is a var-len string or fixed-len w|zstring - fix and add to syntax tests
CLEAR takes the "object" to clear by reference, not an address by value. The extra @ (address-of) lead to clearing a temp var on stack (and likely overflowing it) instead of clearing the wanted variable, i.e. undefined behaviour. Reported at: freebasic#382 gcc AddressSanitizer finds this issue aswell: ==279298==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffb16875e8 at pc 0x7fb7f4a01c23 bp 0x7fffb16874a0 sp 0x7fffb1686c48 WRITE of size 200 at 0x7fffb16875e8 thread T0 #0 0x7fb7f4a01c22 in __interceptor_memset ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:799 freebasic#1 0xa3fb11 in TESTS::FBC_TESTS::UDT_WSTRING_::MIDSTMT::ASCII() (/home/daniel/fb/fbc/tests/fbc-tests+0xa3fb11) freebasic#2 0xcc536c in FBCU::RUN_TESTS(bool, bool) src/fbcunit.bas:649 freebasic#3 0xcc134e in main (/home/daniel/fb/fbc/tests/fbc-tests+0xcc134e) freebasic#4 0x7fb7f4506d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 freebasic#5 0x7fb7f4506e3f in __libc_start_main_impl ../csu/libc-start.c:392 freebasic#6 0x413364 in _start (/home/daniel/fb/fbc/tests/fbc-tests+0x413364) Fixes: 135f364 "udt-wstring: MID statement will accept UDT as Z|WSTRING"
Given
dim e1 as wstring * BUFFERSIZE
dim n1 as integer = BUFFERSIZE
then e1[n1] is an out-of-bounds access. I'm not entirely sure if the
change is sane with regards to the intent of the code (maybe e1 is
supposed to be BUFFERSIZE + 1?), but least it's not overflowing anymore.
Found with gcc AddressSanitizer:
[...]
==325124==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd6b7ecd28 at pc 0x000000b97cfb bp 0x7ffd6b7ec800 sp 0x7ffd6b7ec7f0
WRITE of size 4 at 0x7ffd6b7ecd28 thread T0
#0 0xb97cfa in TESTS::FBC_TESTS::WSTRING_::MIDSTMT::ASCII() wstring/midstmt.bas:86
freebasic#1 0xc56259 in FBCU::RUN_TESTS(bool, bool) src/fbcunit.bas:649
freebasic#2 0xc52533 in main (/home/daniel/fb/fbc/tests/fbc-tests+0xc52533)
freebasic#3 0x7fe4d3ddad8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
freebasic#4 0x7fe4d3ddae3f in __libc_start_main_impl ../csu/libc-start.c:392
freebasic#5 0x4082e4 in _start (/home/daniel/fb/fbc/tests/fbc-tests+0x4082e4)
Address 0x7ffd6b7ecd28 is located in stack of thread T0 at offset 1000 in frame
#0 0xb97420 in TESTS::FBC_TESTS::WSTRING_::MIDSTMT::ASCII() wstring/midstmt.bas:70
This frame has 8 object(s):
[32, 100) 'DST$1'
[144, 212) 'SRC$1'
[256, 456) 'W1$8'
[528, 728) 'W2$8'
[800, 1000) 'E1$8' <== Memory access at offset 1000 overflows this variable
[1072, 1272) 'W1$10'
[1344, 1544) 'W2$10'
[1616, 1816) 'E1$10'
[...]
Fixes: 135f364 "udt-wstring: MID statement will accept UDT as Z|WSTRING"
CLEAR takes the "object" to clear by reference, not an address by value. The extra @ (address-of) lead to clearing a temp var on stack (and likely overflowing it) instead of clearing the wanted variable, i.e. undefined behaviour. Reported at: freebasic#382 gcc AddressSanitizer finds this issue aswell: ``` ==279298==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffb16875e8 at pc 0x7fb7f4a01c23 bp 0x7fffb16874a0 sp 0x7fffb1686c48 WRITE of size 200 at 0x7fffb16875e8 thread T0 #0 0x7fb7f4a01c22 in __interceptor_memset ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:799 freebasic#1 0xa3fb11 in TESTS::FBC_TESTS::UDT_WSTRING_::MIDSTMT::ASCII() (/home/daniel/fb/fbc/tests/fbc-tests+0xa3fb11) freebasic#2 0xcc536c in FBCU::RUN_TESTS(bool, bool) src/fbcunit.bas:649 freebasic#3 0xcc134e in main (/home/daniel/fb/fbc/tests/fbc-tests+0xcc134e) freebasic#4 0x7fb7f4506d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 freebasic#5 0x7fb7f4506e3f in __libc_start_main_impl ../csu/libc-start.c:392 freebasic#6 0x413364 in _start (/home/daniel/fb/fbc/tests/fbc-tests+0x413364) ``` Fixes: 135f364 "udt-wstring: MID statement will accept UDT as Z|WSTRING"
Given
dim e1 as wstring * BUFFERSIZE
dim n1 as integer = BUFFERSIZE
then e1[n1] is an out-of-bounds access. I'm not entirely sure if the
change is sane with regards to the intent of the code (maybe e1 is
supposed to be BUFFERSIZE + 1?), but least it's not overflowing anymore.
Found with gcc AddressSanitizer:
```
==325124==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd6b7ecd28 at pc 0x000000b97cfb bp 0x7ffd6b7ec800 sp 0x7ffd6b7ec7f0
WRITE of size 4 at 0x7ffd6b7ecd28 thread T0
#0 0xb97cfa in TESTS::FBC_TESTS::WSTRING_::MIDSTMT::ASCII() wstring/midstmt.bas:86
freebasic#1 0xc56259 in FBCU::RUN_TESTS(bool, bool) src/fbcunit.bas:649
freebasic#2 0xc52533 in main (/home/daniel/fb/fbc/tests/fbc-tests+0xc52533)
freebasic#3 0x7fe4d3ddad8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
freebasic#4 0x7fe4d3ddae3f in __libc_start_main_impl ../csu/libc-start.c:392
freebasic#5 0x4082e4 in _start (/home/daniel/fb/fbc/tests/fbc-tests+0x4082e4)
Address 0x7ffd6b7ecd28 is located in stack of thread T0 at offset 1000 in frame
#0 0xb97420 in TESTS::FBC_TESTS::WSTRING_::MIDSTMT::ASCII() wstring/midstmt.bas:70
This frame has 8 object(s):
[32, 100) 'DST$1'
[144, 212) 'SRC$1'
[256, 456) 'W1$8'
[528, 728) 'W2$8'
[800, 1000) 'E1$8' <== Memory access at offset 1000 overflows this variable
[1072, 1272) 'W1$10'
[1344, 1544) 'W2$10'
[1616, 1816) 'E1$10'
[...]
```
Fixes: 135f364 "udt-wstring: MID statement will accept UDT as Z|WSTRING"
Ahoy hoy! I've ran the latest headers for IUP, CD, IM and Lua through SWIG and thought they should be included with fbc proper.