* BDate setters don't perform any validation, use with caution.
* BCalendarView setters do perform validation checks, and will adjust
the day so it fits the requested month or year.
* Add tests for the BCalendarView setters.
This reverts commit 34dbbb65fd.
Instead, we can remove thos from HaikuBuildCompatibility and things will work fine, unless one try t build Haiku on BeOS (this isn't
supported anymore) or a very old Haiku which esdon't have those.
Pawel changed the implementation but I see no reason to make those available only from C++, so it must be an oversight.
Fixes building Haiku on Haiku which otherwise hits a mismatch in build compatibility headers.
If GCC knows what these functions are actually doing the resulting
code can be optimized better what is especially noticeable in case of
invocations of atomic_{or,and}() that ignore the result. Obviously,
everything is inlined what also improves performance.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
* The Network Kit now makes use of it for BUrlContext, so we need this
in the public headers.
* Problem caught by the new build bot by compiling the unit tests.
* A problem with our gcc requires adding casts for gcc4 when
the __builtin_bswap functions are used with a format string
* Unlike gcc2, the __builtin_bswap functions do not get disabled
despite using -fno-builtins, hence added compiler check in
runtime_loader/utility.cpp
* Introduced in gcc-4.3 for at least Intel platforms
* On ARM, full support added in gcc-4.8
* Other platforms untested, left as-is
* This introduces a breaking change to the ABI for gcc4
* Previously PE binaries would trigger the "incorrectly
executable" dialog. Now we get a special message for
B_LEGACY_EXECUTABLE and B_UNKNOWN_EXECUTABLE
* Legacy at the moment is a R3 x86 PE binary. This could
be extended to gcc2 binaries someday far, far, down the
road though
* The check for legacy is based on a PE flag I see
set on every R3 binary (that isn't set on dos ones)
* Unknown is something we know *is* an executable, but
can't do anything with (such as an MSDOS or Windows
application)
* No performance drops as we do the PE scan last
* Tested on x86 and x86_gcc2
* get_architectures() returns the primary and the secondary
architectures in one array. That turned out to be convenient.
* Add C++ versions for get[_secondary]_architectures(), returning a
BStringList.
* Add get_architecture(), get_primary_architecture(),
get_secondary_architectures(), guess_architecture_for_path() to get
the caller's architecture, the primary architecture, all secondary
architectures, or the architecture associated with a specified path
respectively.
* Rename the find_path*() functions to find_path*_etc() and add an
optional architecture parameter. Add simplified find_path*()
functions.
* BPathFinder: Add FindPath[s]() versions with an architecture
parameter.
* No need for the atomically changed variables to be declared as
volatile.
* Drop support for atomically getting and setting unaligned data.
* Introduce atomic_get_and_set[64]() which works the same as
atomic_set[64]() used to. atomic_set[64]() does not return the
previous value anymore.
* They used an unsigned int, which led to overflows when trying to set
them to a time before January 1st, 1970 (local time)
* Some things use January 1st, 1970, GMT (or UTC) as a reference point.
In my timezone this leads to such a negative date. An example is cookie
expiration dates which are set to this date to expire them immediately.
Spotted by Opera testsuite.
* This makes the method unuseable for dates after 2036 (signed 32-bit
time_t will overflow then. This gives us just 33 years to switch to a
64-bit time_t. In te meantime, please try using other methods to set the
date and time for BDateTime objects if you need to go this far.
In sake of consistency with other Windows CP encodings:
* print_name is expanded to "Windows Central European (CP 1250)";
* B_MS_WINDOWS_1250_CONVERSION id looks like should be added into UTF8.h;
* mime_name set to NULL as other windows codepages have. That prevents
at least from duplicating too much 1250's in the Terminal, Mail and
StyledEdit encodings menus.
Currently all debugger commands assume 32-bit pointers when formatting their
output. This means that on x86_64 the output is incorrectly formatted. Fixed
this by adding a B_PRINTF_POINTER_WIDTH definition (16 on 64-bit, 8 on
32-bit), and using this to correctly format the output. Not all commands have
been fixed yet, but all VM, slab, VFS, team, thread and image commands should
be correct.
