(see also 8eb9af9)
Generally, CHAR typedefs are intended to refer to single bytes, while it's typedefs like LPSTR that refer to strings. Besides the typedefs, this also changes various fields/parameters. For example, all fields/parameters named sz* are now translated as strings. In some cases (e.g. oleauto.bi) some fields/parameters are turned to CHAR instead of string because they're only intended to point to a single CHAR. http://www.freebasic.net/forum/viewtopic.php?f=17&t=23739
http://www.freebasic.net/forum/viewtopic.php?p=210239#p210239 MSDN says the dwShareMode parameter must be 0 (exclusive access) when opening COM ports.
… 64bit To support 64bit, FileAttr() needs to return an Integer instead of a Long, because it wants to return pointers/handlers. Internally, the old code dereferenced through the various internal structs starting at FB_FILE.opaque. I've changed this to use the structs explicitly instead of assuming int's everywhere. Just changing it to assume ssize_t's everywhere would be wrong, because for example the LINUX_SERIAL_INFO stores its OS handle (a file descriptor) as a 32bit int, even on 64bit.
This allows a fully working compiler to be bootstrapped using an older version without boolean support. Previously the compiler relied on a boolean-capable str() to fully work (but this only caused problems in the test suite, not when rebuilding the compiler). Besides that, it's also a chance to remove the use of cbool(). It's not really needed anyways, since we don't use the boolean type anywhere in the compiler code.
This adds the built-in Boolean data type (size is 1 byte, stores 0/1 in memory, making it gcc-compatible, but becomes 0/-1 when converted to integers, to be compatible with FB logic operations), the True/False built-in constants, and the CBool() keyword for casting. Note that the compiler needs to be rebuilt with itself before it passes all the tests. We think it's ready to be merged: all the basic implentation details are long solved. Support for Boolean in Print, Input, etc. is added too. The tests are passing with the ASM and C backends. There are only a few points left in todo.txt regarding Boolean. With regards to bindings: The conflict with winapi's BOOLEAN typedef should be solved by 3c225c7 fairly well. The conflicts with TRUE/FALSE constants existing in some bindings aren't solved yet though. Conflicts: changelog.txt
With the addition of a built-in boolean type to FB, it makes sense to rename the BOOLEAN typedef from the WinAPI headers, to avoid collision. This should mostly work, because FB's boolean and winapi's BOOLEAN will be mostly compatible (at least they have the same size, and store 0/1 in memory). Renaming to WINBOOLEAN means this typedef can be used next to FB's boolean, if wanted. On the other hand, this patch also adds a block like this: #ifndef BOOLEAN type BOOLEAN as WINBOOLEAN #endif which allows users to #undef FB's built-in boolean type before #including the winapi headers, and then get BOOLEAN to refer to WINBOOLEAN, meaning that old code using winapi's BOOLEAN will compile as before the addition of the boolean type to FB. This isn't 100% perfect, because existing code can be broken if users don't add the #undef, but it's probably the best we can do, while adding the built-in boolean to FB. The alternative would be to have the WinAPI binding (and perhaps others) silently override the built-in boolean type, making it impossible to use FB's boolean once windows.bi was #included, or to trigger a compiler error and force the user to explicitly decide everytime, but neither of these seem like good ideas. By default, one would probably expect "boolean" to refer to the language's built-in type, even if windows.bi was #included.
The point is that traditionally, NULL has just been a 0 integer in FB headers, and that allows NULL to be passed to things like WPARAM/LPARAM (winapi) directly without warning. This isn't even possible with the C headers, but in FB it has worked like that since 10 years and now people expect it. http://sourceforge.net/p/fbc/bugs/779/
…ields http://www.freebasic.net/forum/viewtopic.php?p=209543#p209543 If the field is non-packed, then symbGetUDTAlign() will be zero (while FIELD=N would make it N). This must be checked, otherwise it would be seen as being packed even though it isn't.
There currently seems to be a problem with number literals on x86_64, &hFFFFFFFFFFFFFFFF is a LongInt instead of an Integer, that caused the I3 constant declarations in this test case to have different dtype.
It's only defined for x86/x86_64 currently, so the __FB_ARM__ case should be checked first.
(I probably missed something though, so not finished yet)
It was partially broken by c4a4dcf, because now it will even be reached in case the constant values are different, causing the assert()'s to fire during the log-tests. But these asserts() don't seem useful anymore anyways (no point checking that the symbol has the same string data if we know it's the same symbol anyways), so it's probably best to just remove them completely.
…wCAST This partially reverts commit 3c911e0. exprNewCAST should only be used to represent C casts that should be emitted into the generated code, but not to handle "high-level" emitting tasks.