Skip to content

Conversation

mudhairless
Copy link
Contributor

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.

@dkl
Copy link
Member

dkl commented Apr 25, 2013

Hi,

the IUP update will surely be welcomed:
http://www.freebasic.net/forum/viewtopic.php?f=14&t=21045

I quickly looked at the updated Lua headers, and they seem to have some issues, for example:

  • According to Lua 5.2.2 sources, the lua_Alloc function pointer typedef should be a function returning any any ptr, not a sub:
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
  • Some of the declarations are mistranslated, for example:
    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

@mudhairless
Copy link
Contributor Author

I guessed as much as they were entirely swig translated and I just added a
couple inclibs. I'll give them a quick look over.
On Apr 25, 2013 4:12 AM, "dkl" notifications@github.com wrote:

Hi,

the IUP update will surely be welcomed:
http://www.freebasic.net/forum/viewtopic.php?f=14&t=21045

I quickly looked at the updated Lua headers, and they seem to have some
issues, for example:

According to Lua 5.2.2 sources, the lua_Alloc function pointer typedef
should be a function returning any any ptr, not a sub:
typedef void * (*lua_Alloc) (void *ud, void *ptr, size_t osize, size_t
nsize);

Some of the declarations are mistranslated, for example:
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


Reply to this email directly or view it on GitHubhttps://github.com//pull/1#issuecomment-16996139
.

@mudhairless
Copy link
Contributor Author

I will also get the def regenerated as the one included is very outdated.
On Apr 25, 2013 4:12 AM, "dkl" notifications@github.com wrote:

Hi,

the IUP update will surely be welcomed:
http://www.freebasic.net/forum/viewtopic.php?f=14&t=21045

I quickly looked at the updated Lua headers, and they seem to have some
issues, for example:

According to Lua 5.2.2 sources, the lua_Alloc function pointer typedef
should be a function returning any any ptr, not a sub:
typedef void * (*lua_Alloc) (void *ud, void *ptr, size_t osize, size_t
nsize);

Some of the declarations are mistranslated, for example:
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


Reply to this email directly or view it on GitHubhttps://github.com//pull/1#issuecomment-16996139
.

@mudhairless
Copy link
Contributor Author

I have looked over the Lua headers and made a few corrections.

@dkl
Copy link
Member

dkl commented May 1, 2013

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:
http://www.freebasic.net/forum/viewtopic.php?p=163128#p163128

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.

@mudhairless
Copy link
Contributor Author

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/.

@mudhairless mudhairless closed this May 2, 2013
jayrm added a commit that referenced this pull request Apr 17, 2022
- 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",&'
jayrm added a commit that referenced this pull request Apr 24, 2022
…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 )
jayrm added a commit that referenced this pull request Apr 29, 2022
…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
dkl added a commit to dkl/fbc that referenced this pull request Jul 18, 2022
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"
dkl added a commit to dkl/fbc that referenced this pull request Jul 18, 2022
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"
dkl added a commit to dkl/fbc that referenced this pull request Jul 18, 2022
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"
dkl added a commit to dkl/fbc that referenced this pull request Jul 18, 2022
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"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants