Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Aug 4, 2015
  1. @dkl
  2. @dkl

    inc: winapi: Translate CHAR/WCHAR typedefs as byte/wchar_t again

    dkl authored
    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
Commits on Aug 2, 2015
  1. @dkl
  2. @dkl
Commits on Aug 1, 2015
  1. @dkl

    Merge branch 'fix-763' of https://github.com/thrimbor/fbc

    dkl authored
    Conflicts:
    	changelog.txt
Commits on Jul 31, 2015
  1. @dkl

    win32 rtlib: Open Com: Ensure to pass dwShareMode=0 to CreateFile()

    dkl authored
    http://www.freebasic.net/forum/viewtopic.php?p=210239#p210239
    
    MSDN says the dwShareMode parameter must be 0 (exclusive access) when
    opening COM ports.
  2. @dkl
  3. @dkl
Commits on Jul 27, 2015
  1. @dkl

    Change FileAttr() to return Integer and make fbFileAttrHandle work on…

    dkl authored
    … 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.
Commits on Jul 26, 2015
  1. @dkl

    Adjust compiler to not rely on boolean support itself

    dkl authored
    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.
Commits on Jul 25, 2015
  1. @dkl
  2. @dkl

    Merge Boolean support

    dkl authored
    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
Commits on Jul 24, 2015
  1. @dkl

    inc: winapi: Rename BOOLEAN => WINBOOLEAN, and maybe provide BOOLEAN

    dkl authored
    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.
  2. @dkl
  3. @dkl
  4. @dkl

    inc: Change various NULL declarations back to just "0"

    dkl authored
    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/
Commits on Jul 23, 2015
  1. @dkl
Commits on Jul 22, 2015
  1. @dkl
Commits on Jul 13, 2015
  1. @dkl
  2. @dkl

    C backend: Fix emitting of packed structs containing non-packed UDT f…

    dkl authored
    …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.
Commits on Jul 12, 2015
  1. @dkl

    tests: Fix override test to work on 64bit too

    dkl authored
    LongInt and Integer are considered compatible on 64bit, causing the test
    case to compile. But it was intended to check mismatching types, so now
    switching it to Byte should do that safely.
  2. @dkl

    tests: Fix redundant constants test case to work on x86_64

    dkl authored
    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.
  3. @dkl

    tests: Fix inline ASM syntax test case to use __FB_ASM__ correctly

    dkl authored
    It's only defined for x86/x86_64 currently, so the __FB_ARM__ case should
    be checked first.
  4. @dkl

    Define __FB_ASM__ also on x86_64

    dkl authored
    Since the -asm command line option applies to x86 and x86_64,
    __FB_ASM__ should be defined for both of them aswell.
Commits on Jul 11, 2015
  1. @dkl

    boolean: Add some changelog entries about the new features

    dkl authored
    (I probably missed something though, so not finished yet)
  2. @dkl
  3. @dkl
  4. @dkl
  5. @dkl

    Allow redundant float constants too

    dkl authored
    (thanks for the tip with byte-by-byte comparison!)
  6. @dkl

    internal: symbReuseOrAddConst(): Remove string debugging code

    dkl authored
    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.
  7. @dkl
  8. @dkl

    internal: C backend: Move conversion handling code back out of exprNe…

    dkl authored
    …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.
  9. @dkl
  10. @dkl

    boolean: C backend: Fix boolean immediates part 2

    dkl authored
    (this one actually does make a difference)
  11. @dkl
Something went wrong with that request. Please try again.