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.
* Fixed issue introduced in hrev38139: restoring from the line
drawing table was hard-coded to UTF8 Ground table. That is wrong:
the table for currently configured encoding must be set back.
Please look on using of _GuessGroundTable() for details;
* Fixed issue introduced in hrev34894: the semantic of convert_xx_utf8
functions requires the destination length to be set equal to the
target buffer size. Pre-hrev34894 usage of "homebrew" conversion
functions was a bit different - destination length was set to 0.
This made any converstions of input data useless and produce no
visual results;
* Private list of supported encodings (Encoding.cpp) was replaced by
using BPrivate::BCharacterSetRoster functionality. That allows to
use centralized info about encodings in unified with other
applications (Mail & StyledEdit for example) way. Most of currently
enumerated in UTF8.h encodings now available in Terminal.
Note that UCS-2 and UTF-16 are temporary (???) excluded from the
list of encodings supported by Terminal.
* The B_UTF16_CONVERSION was added in system-wide UTF8.h declarations.
This character set is available for enumerating by BCharacterSetRoster
but not listed in public API. Looks like it was just missed;
* Special note about "Text Encoding" entry in Preference File:
So known "shortname" of encoding was used in the preferences file.
For details look on the encodings list in previous version of
Encoding.cpp. As result of migrating to BCharacterSet-provided
resources this list was deleted and is not available anymore.
Instead of it the IANA name of the character encoding targeted
to be used for this purposes. Frankly speaking this part looks
like not working at the moment. The value of text encoding is
hardcoded to "UTF-8" now and is not affected by any operations
in Terminal menu. Note that "shortname" for default encoding
was "UTF8" but the saved value is "UTF-8" - and they are looking
not dependent at all. So this change should not introduce any
kind of backward incompatibility.
