[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua 5.1.3 bug in string.byte
- From: Mike Pall <mikelu-0806@...>
- Date: Tue, 3 Jun 2008 18:09:09 +0200
Jürgen Hötzel wrote:
> Also there is an invalid cast to size_t which changes a negative end
> index to an positive value.
Not sure whether the ptrdiff_t cast will do the right thing in all
cases. On 32/64 bit platforms this is just a matter of signedness.
But most 16 bit platforms usually have ptrdiff_t = int32_t and
size_t = uint16_t.
The cases with size_t len >= 2GB are broken anyway, since i and n
are (signed) int, i.e int32_t on all commonly used 32/64 bit
platforms. It may be tricky to create such a large string on 32
bit platforms, but it's no problem on 64 bit platforms.
There are more cases with dubious implicit and explicit casts and
mixup of signedness in the standard libraries (there's a post in
the archive with warnings from an extra picky compiler).
For LuaJIT 2.x I've finally thrown in the towel and removed all
mentions of size_t, replaced it with int32_t and made sure that
all data structures are properly limited at 2GB (minus a small
safety margin). I do not think it's that useful to have such large
objects _inside_ the VM. It's much more common to have a pointer
inside a userdata to such a structure, managed outside of the VM
(e.g. a mmap'ed file).
I've also converted over everything to C99 types and provide a
stdint.h replacement for the few remaining non-C99-compliant
compilers (MSVC in particular). Made many things much easier ...