The existing HTTP header date format handling code is employed
rather than using specific logic for HD. Also the "Location"
header handling is changed to work better for non-absolute
URLs arriving in this header value on a redirect. Both
suggestions from Adrien.
As discussed in 2008
(http://www.freelists.org/post/haiku-development/BString-on-GCC4,1),
this class was not efficient because of lack of inlining. Implement the
suggested solution of a SetCharAt method instead. Also add a CompareAt
which covers a specific use case in KeyboardLayout.cpp.
Adjust all places which were using this feature to safer APIs.
Also fixes a copypaste error in FormattingConventions.cpp.
It is used by the media kit, which created a dependency from libmedia to
libbnetapi to openssl.
It is not entirely specific to the network kit, there are some use cases
that don't involve network at all.
Also print the locker sem (for manual name lookup) and the involved
threads. It was also missing the line terminator which messed up the
following output.
Also fix a typo in a comment.
Since a BLocker can be unlocked from other threads than the one holding
the lock, it can also be further unlocked even when already unlocked.
This caused the recursive count to become negative. The first lock then
needs to reinitialize the count to 1 for the lock balance to work again.
Just incrementing the negative recursive count lead to it never
counting back down from one to zero in the unlock case, which made the
BLocker impossible to unlock.
This makes the Haiku BLocker behave exactly like the BeOS one, including
the negative recursive count and reinitialization, as evidenced by its
debugging features showing the internal counts.
Alternatively to reinitializing the recursive count it could be
prevented from going below zero in the first place, but I don't see why
we should deviate from BeOS there while allowing its awkward unlock
behaviour.
This makes some more exotic use cases work like the BGLView <-> SDL
combination that previously would always just hang. While these abuses
should be reviewed/corrected, just hanging the BLocker doesn't seem
useful.
* A dependent job was requeued even if it wasn't part of the queue
before. The code relied on dependent jobs being already enqueued;
but that cannot be guaranteed.
* If a job failed, its dependent jobs are now also set to failed, so
that they won't be requeued at a later point.
* This caused some of the "Launching xxx failed: Operation not allowed"
messages in the boot process. Those actually weren't harmless, and
could mess up the natural job order.
* Was leaking fQueuedJobs on destruction.
* fHaveRunnableJobSem implementation was not completed; it was never
released.
* Added Pop() variant that is a bit more flexible, and allows for a
timeout as well as waiting even when the queue is empty, and can
return a status code.
* Put it in the BSupportKit namespace, following the style introduced
with the package kit for now.
* The BSupportKit::BJob class no longer knows about the package kit's
Context class. However, the BPackageKit::BJob class does.
* Due to the namespace juggling, a lot of files had to be touched.
* The JobQueue class remains private.
* Due to the way Haiku is built on itself, you cannot build this change
under Haiku with an older release.
Calling Debugger here causes issues with some software (mainly Mesa).
Only print a warning, this is enough for developers to see the problem,
and not as annoying for users.
* In this case, fSize would have been set incorrectly, ignoring the error
completely, but open the possibility to read from uninitialized or even
unmapped memory.
BeOS did allow other threads than the owner to unlock a BLocker (the be
book says so). We did not, and silently ignored the unlock attempt in
this case, probably resulting in a deadlock of applications using the
feature.
Call debugger instead so:
* The problem is made visible for such apps
* The debugger call is continuable so the app can be run, still
Will help making a decision on what to do here (follow BeOS or change
behavior) and make a final decision for #6400.
* 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.
* Use a reference rather than a pointer for the output string, removing
the need for NULL checks (which were missing, anyway)
* Adjust callers to that change
* Add new Format variant taking a BDate argument
instead or additionally to string.h, in preparation for functions move.
* moves str[n]casecmp() functions and others to strings.h.
* strings.h doesn't include string.h anymore.
* this solves #10949
* BCompressionAlgorithm is a base class for classes that provide
compression/decompression functionality. There are methods for
compressing/decompressing a single buffer and factory methods for
a compressing/decompressing input/output BDataIO.
* BZlibCompressionAlgorithm is a BCompressionAlgorithm implementation
using zlib.
* In C++03 and earlier, the sign of the modulo result is implementation
defined (this was fixed in C++11).
* Setting a negative time is not what we want here, so make sure we use
the proper value.
Variable length arrays of non-PODs are not part of the C++ standard, but
a GNU extension that never worked correctly. Instead, BStackOrHeap array
is used now, which makes sure that it's not too big for the stack, calls
all constructors and is valid C++.
It's not possible to use these from the network kit otherwise, as it
would create a circular dependency (mail > bnetapi > mail).
Is there a better way to solve this problem?
* 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.
* 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.
