History log of /haiku/src/kits/app/Message.cpp
Revision Date Author Comments
# d761df9f 14-Sep-2019 Adrien Destugues <pulkomandy@pulkomandy.tk>

BMessage: fix NULL pointer dereference in out of memory condition.

Change-Id: I75ba6e5069cda8a92fd88bf7d1e999232359e73c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1864
Reviewed-by: waddlesplash <waddlesplash@gmail.com>


# f7397837 24-May-2019 Augustin Cavalier <waddlesplash@gmail.com>

BMessage: Use assignment operator instead of memcpy().

The only non-POD types the macro is used on are BPoint, BRect, BSize,
and rgb_color, so the first change should essentially be a no-op.

The second change will technically have different behavior,
as the BMessenger copy constructor does not touch the _reserved_
field; but this shouldn't break anything, of course.


# 08a4536b 12-Dec-2017 Axel Dörfler <axeld@pinc-software.de>

BMessage: Added missing [Get|Set]Pointer()

* SetPointer() was declared, but not defined.


# 7f9368ca 09-Dec-2015 looncraz <looncraz@looncraz.net>

Set*UIColor, etc.

The inseparable changes necessary to support live color updating across the
system in a sane, safe, and performant manner.

BView gains:

HasSystemColors()
HasDefaultColors()
AdoptSystemColors()
AdoptParentColors()
AdoptViewColor(BView*)
SetViewUIColor(color_which, float tint)
SetHighUIColor(...
SetLowUIColor(...
ViewUIColor(float* tint)
HighUIColor(...
LowUIColor(...
DelayedInvalidate()

BWindow gains a simple helper method:
IsOffscreenWindow()

BMessage gains:

AddColor()
FindColor()
GetColor()
HasColor() * allegedly this API is deprecated, but I implemented it anyway
ReplaceColor()
SetColor()

Previous private ColorTools methods are made public and moved into GraphicsDefs:

mix_color, blend_color, disable_color

These are fully compatible with BeOS dan0 R5.1 methods and are just code cleanup
of BeOS example code under the OpenTracker license.

In addition, four new colors are created:
B_LINK_TEXT_COLOR
B_LINK_HOVER_COLOR
B_LINK_ACTIVE_COLOR
B_LINK_VISITED_COLOR

These changes are documented in their proper user documentation files.

In addition, due to a history rewrite, B_FOLLOW_LEFT_TOP has been defined and
used in lieu of B_FOLLOW_TOP | B_FOLLOW_LEFT and is included in this commit.

On the app_server side, the following has changed:

Add DelayedMessage - a system by which messages can be sent at a scheduled time,
and can also be merged according to set rules. A single thread is used to service the
message queue and multiple recipients can be set for each message.
Desktop gains the ability to add message ports to a DelayedMessage so that
said messages can target either all applications or all windows, as needed.

Desktop maintains a BMessage which is used to queue up all pending color changes
and the delayed messaging system is used to enact these changes after a short
period of time has passed. This prevents abuse and allows the system to merge
repeated set_ui_color events into one event for client applications, improving
performance drastically.

In addition, B_COLORS_UPDATED is sent to the BApplication, which forwards the message
to each BWindow. This is done to improve performance over having the app_server
independently informing each window.

Decorator changes are live now, which required some reworking.

Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>


# c0c883cf 29-Aug-2015 Michael Lotz <mmlr@mlotz.ch>

BMessage: Fix precedence of KMessage vs. size check.

A KMessage request always needs to be honoured, regardless of the data
size.

KMessage does not currently protect against messages that are too large,
but this needs to be solved in KMessage when it becomes a problem.


# e3114809 15-Apr-2015 Axel Dörfler <axeld@pinc-software.de>

BMessage: fixed reply port race condition.

* When the team that we got the synchronous reply from immediately
terminated afterwards, it might have still owned (and therefore
destroyed) our reply port.
* Make sure it's not added to the pool again, but is recreated instead.


# 45888dab 01-Jul-2015 Philippe Saint-Pierre <stpere@gmail.com>

Crash fix in BMessage::ReplaceData()

The call to _CopyForWrite() invalidated the pointer previously assigned.
There was also an unrelated null-pointer derefence situation in the copy constructor.

Fixes #3074 and CID 610886 and CID 610887.


# 88f90128 22-May-2015 Alexander G. M. Smith <agmsmith@ncf.ca>

BMessage: fix an off-by-one error in SetCurrentSpecifier.

You could set the index to be past the end of the Specifier array.

Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Fixes #12087.


# 5ce80a78 21-Apr-2015 Axel Dörfler <axeld@pinc-software.de>

BMessage: implemented KMessage reply.

* When you receive a message from a KMessage, and reply to it,
it will automatically reply as KMessage, too.
* This allows to communicate with BLoopers from within the kernel
or libroot.so.


# f894ab70 09-Jan-2015 Rene Gollent <anevilyak@gmail.com>

BMessage: Fix #11710.

The refactored version of Unflatten() encapsulated the raw buffer
into a BMemoryIO with a specified size of SIZE_MAX, since the total
size of the messageisn't known up front. On 32-bit this was no problem,
but on x86_64, this would lead to an overflow in BMemoryIO, since it
stores its internal length as a size_t, which on that platform is the same
size as off_t. Consequently, when it would cast its length to off_t to
compare against the requested seek position in ReadAt/WriteAt, this would
overflow to a negative, leading it to reject all requests, which
subsequently caused Unflatten() to fail.


# caf3e27a 06-Jan-2015 Adrien Destugues <pulkomandy@gmail.com>

BMessage: fix unflattening from a KMessage buffer

The BDataIO version of MessagePrivate::Unflatten only handles the R5 and
Dano formats, so we must call the buffer version for KMessages.


# 607dfee2 06-Jan-2015 Adrien Destugues <pulkomandy@gmail.com>

Really fix passing BMessages by area.


# 1bfcb75b 06-Jan-2015 Adrien Destugues <pulkomandy@gmail.com>

BMessage: fix passing messages by area

I missed the fact that the BDataIO based Unflatten didn't handle this.
Restore the code from the recently removed buffer-based unflatten, so
it's possible to pass a message by area again.


# d33e4744 03-Jul-2013 Axel Dörfler <axeld@pinc-software.de>

IMAP: downloading mails is now working.

* Changed the way the attributes are written to make sure that everything
that can be written once is in fact written just once.
* The rename code in BMailProtocol::_ProcessFetchedHeader() was broken,
and caused the hang of the last commit.


# 8705e1f6 22-May-2013 Axel Dörfler <axeld@pinc-software.de>

mail_daemon: cleanup, 30s auto check startup delay.

* Refactored new message retrieval a bit, so that the notification strings
aren't duplicated.
* The daemon now waits 30 seconds before doing the first mail check.


# 46851a74 13-Dec-2012 Axel Dörfler <axeld@pinc-software.de>

BMessage::SetString() was broken.

* We cannot use the macro for this, unfortunately.


# a6943acb 12-Nov-2012 Axel Dörfler <axeld@pinc-software.de>

Added missing BMessage::{Get|Set}String() methods.

* Forgot to add those before accidentally.


# 62ede2e6 05-Jan-2015 Adrien Destugues <pulkomandy@gmail.com>

BMessage: avoid code duplication in Unflatten

The buffer version of Unflatten can be implemented by wrapping the
buffer in a BMemoryIO. This allows sharing more code, and the BDataIO
version of Unflatten has some extra error checks.

Fixes #11670.


# a6f1bc98 24-Dec-2014 Adrien Destugues <pulkomandy@gmail.com>

BMessage::ReplaceData: potential corruption on realloc fail

The method would update the field offsets first, and would not restore
them in case of realloc failure, leaving them pointing to the wrong
place.


# 8007a392 08-Nov-2014 Adrien Destugues <pulkomandy@gmail.com>

BMessage: add AddFlat taking a const BFlattenable

It seems the const was forgotten in the BeOS version. But there is no
reason not to have it.


# a0b6efc8 01-Nov-2014 Michael Lotz <mmlr@mlotz.ch>

BMessage: Check message area is owned by the current team.

When a message is passed by area, the sender is supposed to transfer
area ownership to the target team. If the area is not mapped within
the current team, accessing the area address would be invalid.

Also mark the area as read-only so accidental writes to the area would
become obvious.


# d3344ffc 01-Nov-2014 Michael Lotz <mmlr@mlotz.ch>

BMessage: Check the return of _CopyForWrite().

When a message is passed by area, any modification to the message must
first trigger a copy of the message content. The success of this
operation was not checked however, possibly leading to later reallocs
on non-heap memory.


# be902ac4 11-Jun-2014 John Scipione <jscipione@gmail.com>

App Kit: style changes.

No functional change intended.

Focused on documented classes only.

* Update copyright information.
* whitespace fixes.
* pointer style
* Rename some variables, msg => message, form => what
* Need consistent variable names to make documentation easier,
allows us to use \copydoc or \copydetails instead of repeating
ourselves over and over again.


# cd15d8c3 17-Jul-2013 Philippe Saint-Pierre <stpere@gmail.com>

Style fix, no functional change intended


# cf0a957f 19-Apr-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

BMessage: Add {Add,Find}Strings()

They add a BStringList to/extract it from a B_STRING_TYPE field.


# d2239cb8 13-Dec-2012 Axel Dörfler <axeld@pinc-software.de>

BMessage::SetString() was broken.

* We cannot use the macro for this, unfortunately.


# a2f6e5ac 12-Nov-2012 Axel Dörfler <axeld@pinc-software.de>

Added missing BMessage::{Get|Set}String() methods.

* Forgot to add those before accidentally.


# 762e4eca 04-Nov-2012 Axel Dörfler <axeld@pinc-software.de>

BMessage::Append() is now actually working.


# 6e50e79e 03-Nov-2012 Axel Dörfler <axeld@pinc-software.de>

Added Get*()/Set*() methods like the ones from KMessage.


# 009fd257 26-Oct-2012 Axel Dörfler <axeld@pinc-software.de>

Added BMessage::Append(), and new(std::nothrow_t).

* Append() copies all fields from the specified message.
* The nothrow operator new allows you to add BMessages to a BObjectList.


# 46b619c3 21-Jun-2011 Rene Gollent <anevilyak@gmail.com>

Fix several problems in Flatten() that could potentially lead to overflows
and/or crashes if given a smaller buffer size than the Flatten operation
actually required.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42282 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 3270af3c 22-Jun-2011 Michael Lotz <mmlr@mlotz.ch>

* Check the no-init case consistently, no need to crash when we failed to
allocate the header.
* Code style cleanups: 80-char limit, pointer style of recent additions,
explicit NULL checks, check ports against 0 instead of B_OK, results != B_OK.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42281 a95241bf-73f2-0310-859d-f6bbb57e9c96


# ed55a283 15-Jun-2011 Axel Dörfler <axeld@pinc-software.de>

* The previous solution was needlessly complicated.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42201 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 535453d9 15-Jun-2011 Axel Dörfler <axeld@pinc-software.de>

* Reset the passed string on failure for BeOS compatibility.
* Fixes #7701.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42200 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 54cf3a72 14-Jun-2011 Ingo Weinhold <ingo_weinhold@gmx.de>

Changed sReplyPortInUse type from long to int32, so it be used with
atomic_add() also on 64 bit architectures.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42174 a95241bf-73f2-0310-859d-f6bbb57e9c96


# dc36ea92 24-Feb-2011 Jonas Sundström <jonas@kirilla.com>

CID 6337 SECURE_CODING

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40658 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 2b526613 07-Feb-2011 Stephan Aßmus <superstippi@gmx.de>

Added another GetInfo() variant with which one can retrieve the count and
fixed size flag at once. Not sure if this can be merged into one of the
existing GetInfo() variants without breaking binary compatibility.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40374 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 6e24fc67 16-Aug-2010 Adrien Destugues <pulkomandy@pulkomandy.ath.cx>

CID 1498 (and others) : when deleting a NULL pointer, operator delete is actually called. So, it must not dereference the
given pointer without checking first.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38147 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b1008df2 14-Jul-2010 Stephan Aßmus <superstippi@gmx.de>

Patch by Alex Wilson: Added convenience methods for storing BAlignment and BSize
in BMessages. Also added type codes for them in TypeConstants.h. Closes ticket
#6302. Thanks!


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37511 a95241bf-73f2-0310-859d-f6bbb57e9c96


# e5150e28 08-Jul-2010 Ingo Weinhold <ingo_weinhold@gmx.de>

Patch by Alex Wilson (compilation fixes by myself): Extended the archiving/
unarchiving protocol to support archival of arbitrary object graphs.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37431 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 393127df 06-Apr-2010 Stefano Ceccherini <stefano.ceccherini@gmail.com>

Use %c to print uint8. This avoids a crash. I'm not sure this is a gcc bug,
or we were using the previous form incorrectly. Anyway, this doesn't change
the functionality and fixes ticket #5676.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36052 a95241bf-73f2-0310-859d-f6bbb57e9c96


# e6dc15ca 19-Mar-2010 Stefano Ceccherini <stefano.ceccherini@gmail.com>

int8 and uint8 passed 3 parameters to the printf string,
but only 2 were used, leading to various problems (like bug #5596).
I added another variation of print_type which handles that case.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35911 a95241bf-73f2-0310-859d-f6bbb57e9c96


# a3cd51c7 28-Feb-2010 Rene Gollent <anevilyak@gmail.com>

Cleanup: BMessage::_Reference never hits the case of having to transfer the area since _SendMessage already takes care of this (and transfer_area doesn't allow it to take an area from another team anyways so this code never could have worked).



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35683 a95241bf-73f2-0310-859d-f6bbb57e9c96


# e8e5e0ca 27-Feb-2010 Stephan Aßmus <superstippi@gmx.de>

Strings in BMessages don't necessarily have to be \0 terminated. Use the already
known length to print the stream so printf() doesn't potentially crash when
trying a strlen() on the string. Fixes for example printing B_KEY_DOWN messages,
where such strings are used, in certain conditions.

Review welcome, printf() formatting is not one of my strengths. :-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35629 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 67df6a72 29-Jan-2010 Michael Lotz <mmlr@mlotz.ch>

Cleanup, these aren't necessary anymore.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35337 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 17ec4668 29-Jan-2010 Michael Lotz <mmlr@mlotz.ch>

Printing of basic types was broken when they were part of non fixed size fields.
The size instead of the data would be printed. The fixed/non-fixed handling is
generic though, so no need to special case the always non fixed elements.
Since adding of basic types through their Add*() function always generates fixed
size fields, this would only be visible if the data was added through AddData()
with isFixedSize == false. This is the case in compiled resources for example,
hence you would see it when printing the returned messages of BMimeType::Get*()
functions for pre-installed types.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35336 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 41975f20 25-Nov-2009 Ingo Weinhold <ingo_weinhold@gmx.de>

Fixed gcc 4 32 and 64 bit warnings in the libbe_build code. This time ported
them back to the Haiku versions.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34262 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 59fa665d 23-Oct-2009 Michael Lotz <mmlr@mlotz.ch>

The "was dropped" flag is only used to specify whether or not DropPoint()
returns valid data. Since the data is still valid in the copy, we don't need
to clear the corresponding flag when copying a message. This is most probably
the same behaviour as in R5 as Tracker seems to expect that in the case where
a drop is done after a menu was displayed as in #4757. Thanks to aldeck for
tracking that one down inside Tracker, should fix #4757.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33746 a95241bf-73f2-0310-859d-f6bbb57e9c96


# e0b7c61c 10-Sep-2009 Oliver Tappe <zooey@hirschkaefer.de>

Closing ticket #4465:
Net_server starts services by invoking fork() followed by exec(). If the latter
fails (for instance because the service isn't installed), the forked child is
invoking exit(). This in turn unloads libbe, triggering static cleanup code in
BMessage, which deletes a couple of message ports that were inherited from the
parent during the fork. After that, net_server was desparately missing those
ports and no longer worked reliably.
* in InitTerminateLibBe, we now register an atfork-(child-)handler, which
takes care to re-initialize the static reply ports used by BMessage code
* added BMessage::Private::StaticReInitForkedChild wrapper and
BMessage::_StaticReInitForkedChild() implementation which overwrites the
inherited port IDs with a set of own ports


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33050 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 81147288 11-Aug-2009 Axel Dörfler <axeld@pinc-software.de>

* Added missing space.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32253 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 685a77f9 07-Aug-2009 Michael Lotz <mmlr@mlotz.ch>

Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32187 a95241bf-73f2-0310-859d-f6bbb57e9c96


# a0bfe3ab 31-Jul-2009 Rene Gollent <anevilyak@gmail.com>

gcc4 build fix.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32042 a95241bf-73f2-0310-859d-f6bbb57e9c96


# d7a16b23 31-Jul-2009 Michael Lotz <mmlr@mlotz.ch>

* Fully switch to the Haiku message format so that it is also used for on-disk
storage.
* Remove reduntant information from the header (field_count vs. fields_size).
* Remove checksums previously used to validate the message passing by area
mechanism.
* Move variables that are purely used by the instance out of the header and into
the BMessage object.
* Use more sensible types for the different message fields.
* Reduce some field sizes to realistic values.
* Make size_t values into uint32 values so the message format will not change
when later moving to 64 bits.
* Pack the structures used for flat message storage so it doesn't change
because of padding.
* Fix message passing by area. It never worked because the created area was
never actually filled with any data!
* Some more allocation checks with graceful fallbacks (should be all now).
* Some more checks for negative index values (should also be all now).
* Make printing more inline with how the rest of the class works and make some
of the output more consistent.
* Also add the new unsigned types to PrintToStream() output.
* Fix printing of unknown types and invalid BMessages, it would always have
printed only the first entry respectively the same error.
* Added some clarifying comments.
* Cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32039 a95241bf-73f2-0310-859d-f6bbb57e9c96


# e20dc8a7 22-Jun-2009 Ingo Weinhold <ingo_weinhold@gmx.de>

Added missing convenience methods for unsigned integers.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31187 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 8f73c97d 10-Mar-2009 Stephan Aßmus <superstippi@gmx.de>

In the assignment operator, watch out if the passed message is ourself.
Fixes a crash in WonderBrush when dragging images over the layer list
to import them and triggering auto-scrolling. WonderBrush caches the
drag message and appearantly calls it's own MouseMoved() hood with the
cached message from within the auto-scrolling code.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29464 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 60a068c8 16-Oct-2008 Michael Lotz <mmlr@mlotz.ch>

Fix build. The deep version did use the CompareData of course.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28184 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 3c6372b4 16-Oct-2008 Michael Lotz <mmlr@mlotz.ch>

Rename BMessage::CompareData() to HasSameData() as this makes more sense for the
bool return type. Did I mention this was an unstable Haiku extension?


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28181 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 5b25b917 16-Oct-2008 Michael Lotz <mmlr@mlotz.ch>

Introduce BMessage::CompareData() which is a Haiku API extension. It compares
the data of two BMessages and allows recursive comparison (BMessage inside
BMessage). Note that using this API might require you to recompile your app in
the path to R1.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28174 a95241bf-73f2-0310-859d-f6bbb57e9c96


# f75add61 15-Aug-2008 Michael Lotz <mmlr@mlotz.ch>

Obviously noone ever really used BFlattenable objects with our BMessage, as it
was pretty broken. It would store the address of the buffer in the message
instead of the actual data. Funnily, since it was completely stack based before,
it would have stored the address plus the actual data (minus 4 bytes) as that
did reside directly after the address on the stack and the original buffer
length was still used. This corrupted the data, but still "worked" for MDR
because it has fault tolerance, loosing only part of its flattened StringList.
This broke however when switching to a heap allocated buffer for large sizes,
as then the heap address plus some random heap data was added to the message
instead of the actual buffer. Sure interesting that nobody noticed that before...


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26984 a95241bf-73f2-0310-859d-f6bbb57e9c96


# edc51252 12-Aug-2008 Stephan Aßmus <superstippi@gmx.de>

* A few versions of BMessage::AddXXX and ReplaceXXX did not check the argument
passed to the function against NULL.
* Made BMessage::AddFlat() use an optionally heap allocated buffer versus always
a stack allocated one.
* Small simplification in BMessage::AddMessage(), we can simply compare the
buffer with the stack based buffer to know whether we need to free() it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26943 a95241bf-73f2-0310-859d-f6bbb57e9c96


# d666a89e 31-Jul-2008 Stephan Aßmus <superstippi@gmx.de>

Check for index < 0 too for B_BAD_INDEX. This fixes for example Tracker-Grep
which does

message->GetInfo("field", &type, &count);
while (message->FindBlah("field", --count, &...) == B_OK)
...;



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26695 a95241bf-73f2-0310-859d-f6bbb57e9c96


# d2e55e94 24-May-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

Memory leak in error case. CID 807.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25645 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 6bf15ffc 27-Apr-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

* Changed macros that enable tracing for individual components from
defined/undefined to numeric values (0 for undefined). This allows for
trace levels.
* Set SYSCALL_TRACING_IGNORE_KTRACE_OUTPUT default to 1, since this is
what one usually wants.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25213 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 071f9c3a 27-Mar-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

Build configurations shouldn't be done in svn controlled files, so I
finally created a solution to avoid that: Header files that contain
configuration settings (and nothing else) go to build/config_headers.
To change settings, create a directory build/user_config_headers (which
is ignored by svn), copy the respective header there and modify it at
your leisure. Currently only tracing_config.h has been moved to the new
location, but more files will follow eventually. It is also recommended
to move optional macro definitions in Jamfile (as for BFS) to a config
header instead; the build system will then automatically rebuild on
changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24611 a95241bf-73f2-0310-859d-f6bbb57e9c96


# a433b9fe 09-Mar-2008 Michael Lotz <mmlr@mlotz.ch>

Rewrite and activate message passing by area. Passing by area works now with
the new sematic of transfer_area so a message area is transfered into the right
teams' address space and it does not need to be cloned there anymore. Passing
by area is only used for messages bigger than a certain size (currently
hardcoded to 40KB) which should be somehow bound to the max port message size.
This makes passing large messages (i.e. > the port limit) possible, so for
example copy&paste of long text, image data, etc. should now work.
Got rid of the fClonedArea member as it is not necessary with the new design,
renamed shared_area to message_area in the private message_header, avoid
an unnecessary allocation of the header for the copy constructors, check
allocations in a few more places and some minor cleanup.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24321 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 766c4616 07-Mar-2008 Rene Gollent <anevilyak@gmail.com>

Team debug effort with Michael Lotz:

Tracked down the root cause of the issue worked around in r24228.
The behavior that was occurring in this case was as follows:
Vision created a BInvoker off the heap, containing a BMessage likewise
off the heap. It then called BAlert::Go with this invoker. When any of
the buttons in the BAlert were pushed, _SendMessage would enqueue the
message into the target looper (in this case, Vision's window) and wake
it up with write_port_etc. However, in some cases this would result in
a reschedule such that Vision's looper executed before _SendMessage() was
able to complete all its processing. Upon receiving this message, Vision
destroyed the BInvoker in question, which in turn deleted its owned
BMessage -- which was the message that was still in the middle of _SendMessage()!.
Consequently it would crash a few lines later when it hit IsSourceWaiting() and
tried to check flags off its header off the already destroyed this. To fix this,
we now do the AddMessage/write_port_etc last before returning. Also removed the
sanity checks added in r24228 so we don't mask other problems of similar nature.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24297 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 8c5c17cd 03-Mar-2008 Rene Gollent <anevilyak@gmail.com>

Fixed a crash that would happen sometimes with BInvoker: If an invoker was
set up with a null replyTo, sometimes BMessage would crash
calling IsSourceWaiting() after delivering the message. This appeared
to be because fHeader was NULL, but I'm not entirely certain if this
is actually supposed to be possible, so this may be masking a different
bug. This was observable using the multiline paste spam BAlert in
Vision, which would sometimes but not always crash in Haiku after hitting
any of the buttons to dismiss it, though consistently when calling IsSourceWaiting()
from the private BMessage::_SendMessage().



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24228 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 3ba0ac74 02-Mar-2008 Axel Dörfler <axeld@pinc-software.de>

* Fixed a few problems in AddMessage() (most of them were pointed out by Marcus):
- no need to initialize the buffer on stack
- no need to initialize "buffer" to NULL
- renamed "buf" to stackBuffer
- enlarged buffer on stack to 16384 bytes (we have a minimum of 192 kB of
stack per thread, anyway).
- check the actual size of the stack buffer against the message's flattened
size instead of the one of its pointer.
- check if the allocation of the helper buffer failed, and return B_NO_MEMORY
in this case.
* Moved static helper functions to the top of the file.
* Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24204 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 0f9d90aa 01-Mar-2008 Karsten Heimrich <host.haiku@gmx.de>

* This fixes ticket #1865
* Allocate the buffer to flatten the message on the heap, if it's size is bigger then a given
buffer on the stack. It seem's to exceed the stack size (this might count for AddFlat() too).

Note: With this change one is able to copy the text into the clipboard (1mb), but it
is still impossible to paste it somewhere, as in BClipboard::_DownloadFromSystem()
SendMessage() fails transferring the data back in the reply msg because of the port size limit...



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24196 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 90e3bbf0 31-Jan-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

Added optional kernel tracing for sending BMessages. Currently only the
destination of the message and it's "what" field are stored. It might be
nice to also get some info about its fields -- maybe as an additional
option.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23810 a95241bf-73f2-0310-859d-f6bbb57e9c96


# bfccde1f 13-Nov-2007 Axel Dörfler <axeld@pinc-software.de>

Forwarding did not work anymore for direct targets, since the header::flags
field was not initialized properly, and the reply target was taken from the
wrong header in this case.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22925 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 10ffdaa2 17-Oct-2007 Axel Dörfler <axeld@pinc-software.de>

Added TODO.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22597 a95241bf-73f2-0310-859d-f6bbb57e9c96


# d570f3bf 23-Aug-2007 Michael Lotz <mmlr@mlotz.ch>

* Don't leak buffers when reallocs fail
* Always check the return of the resize function
* Handle resize errors gracefully and ensure that the message stays intact
* Don't crash when printing a message that contains a field with no items (unlikely but possible in low memory situations)
* Fixed renaming fields - was completely broken and would have missed up field names and contents
* Some cleanup

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22047 a95241bf-73f2-0310-859d-f6bbb57e9c96


# ccaa095f 03-Jul-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

<malloc.h> ain't a standard header. Should fix the build on platforms that
don't have it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21546 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 5dc45eb4 27-Jun-2007 Michael Lotz <mmlr@mlotz.ch>

* Unified handling of different BMessage formats into MessageAdapter.cpp
* Removed r5_message.cpp and dano_message.cpp accordingly
* Also moved out KMessage handling from Message.cpp to MessageAdapter.cpp
* Fixed some minor style issues in Message.cpp

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21514 a95241bf-73f2-0310-859d-f6bbb57e9c96


# eb9b1980 03-Mar-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

Fixed gcc 4(.1.2) build problems.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20320 a95241bf-73f2-0310-859d-f6bbb57e9c96


# cd9660c7 06-Feb-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

Moved sending the B_NO_REPLY reply from the destructor to the more
general _Clear(), so that the assignment operator and Flatten() will
trigger such a reply as well.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20083 a95241bf-73f2-0310-859d-f6bbb57e9c96


# c1c0c220 05-Feb-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

* In the BMessage assignment operator we do now clear some of the message
header flags after copying the header of the original message. Before
cloning a message that still needed a reply would result in the clone
also needing a reply, which, in the end, led to two replies being sent,
thus screwing up the cached reply ports used for synchronous messaging.
Fixes bug #1008.
BTW, also clearing the reply info breaks Tracker and Deskbar, so I suppose
R5 keeps it and Tracker and Deskbar rely on that behavior.

* Added a bit of debug code removing and printing spurious messages from a
cached reply port.

* Added TODO in BMessage::~BMessage(). ATM, we only send a B_NO_REPLY in the
destructor, but not in case the message is overwritten using the
assignment operator or Flatten().



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20074 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 9dbe170a 26-Jan-2007 Axel Dörfler <axeld@pinc-software.de>

Implemented direct message passing for local targets; this fixes a deadlock
with PostMessage() in case the message queue is full.
Some notes:
* for synchronous replies, we don't use this mechanism yet, but it could be
extended to do that as well.
* the code looks so complicated because we need a way to access the looper's
queue without locking it (to prevent deadlocks); like Dano's solution, I've
abused BTokenSpace to store a BDirectMessageTarget with a BHandler.
* we also need to decouple the lifetime of a looper's queue from its target,
as we cannot lock the looper, and therefore, can't guarantee it stays valid
as long as we're accessing it outside of BLooper.
* init_clipboard() now needs to be done after the global constructors have
been called - since sending messages now needs gDefaultTokens to be initialized.
Since this is done per image, it shouldn't cause any troubles, though.
* some minor cleanup, removed unused _msg_cache_cleanup_() and friends.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19968 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 67bdea52 10-Jul-2006 Jérôme Duval <korli@users.berlios.de>

hope no one minds with this Dano-like version of BMessage::PrintToStream()


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18089 a95241bf-73f2-0310-859d-f6bbb57e9c96


# d134f892 23-Jun-2006 Axel Dörfler <axeld@pinc-software.de>

* Sending a forwarded message that had required a synchronous reply, can now be sent
again with a synchronous reply - the "reply done" flag wasn't cleared before sending.
* Improved error message in case the buffer for flattening the message couldn't be
allocated. BTW this would be a good place to use the new writev_port() function and
don't do any allocation at all.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17914 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 39207b00 14-Jun-2006 Jérôme Duval <korli@users.berlios.de>

BMessage::GetCurrentSpecifier() set index even if it is a negative one and returns
This would explain why BLooper::resolve_specifier() was misbehaving before I fixed it


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17834 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 7675c75f 13-Jun-2006 Jérôme Duval <korli@users.berlios.de>

avoid adding _previous_ on forwarded synchronous messages
tested with ForwardMessageTest.cpp
well I hope it doesn't break anything :)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17831 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 4b770c6e 13-Jun-2006 Jérôme Duval <korli@users.berlios.de>

reverted to 17808, BLooper::resolve_specifier should be fixed instead


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17820 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 4b25c488 12-Jun-2006 Jérôme Duval <korli@users.berlios.de>

BMessage::GetCurrentSpecifier returns B_OK if current specifier is negative


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17809 a95241bf-73f2-0310-859d-f6bbb57e9c96


# c13a4ddf 07-Jun-2006 Axel Dörfler <axeld@pinc-software.de>

Unflattening R5/Dano messages are both using the TReadHelper class which throws
exceptions in case of an error. Therefore, whenever those methods are called,
we need to surround them with a try/catch block.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17766 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 8780db59 24-May-2006 Axel Dörfler <axeld@pinc-software.de>

* Forwarding message that had someone waiting for a reply did not work correctly;
both messages wanted to reply then, which could get the wrong reply (B_NO_REPLY)
into the reply port. This fixes bug #513, took me some hours to figure that out...
* _SendMessage() no longer allows to forward a message and asking for a synchronous
reply that already has a source waiting for a reply.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17584 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b0bc48fb 19-May-2006 Axel Dörfler <axeld@pinc-software.de>

Some more GCC 4 and PPC fixes.
* Mesa doesn't compile yet, as some PPC specific stuff seems to be
missing, Philippe?
* Cortex and some other stuff has been marked x86-only, although
it's more of a "GCC 2.95.3"-only.
* I'm not sure if it's a bug in GCC 4, or if that's what the C
standard demands, but sizeof(some_type::some_field) is not
valid anymore :-/


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17515 a95241bf-73f2-0310-859d-f6bbb57e9c96


# f2274165 04-May-2006 Michael Lotz <mmlr@mlotz.ch>

Changing AddMessage() and ReplaceMessage() to use R5 message format to ensure compatibility.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17322 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 035eafc5 03-May-2006 Michael Lotz <mmlr@mlotz.ch>

We should never mess with fQueueLink as it's maintained by the BMessageQueue. Small simplification.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17313 a95241bf-73f2-0310-859d-f6bbb57e9c96


# eef81495 11-Apr-2006 Michael Lotz <mmlr@mlotz.ch>

Fixed wrong length calculation for memmove. This should at least fix bug #314 and probably more yet unknown problems with ReplaceData(). Also optimized removing data from the end of the buffer.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17101 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 4ac06083 07-Apr-2006 DarkWyrm <darkwyrm@gmail.com>

Added missing symbol for Gobe Productive


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17036 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 9a44fdc9 18-Mar-2006 Axel Dörfler <axeld@pinc-software.de>

* Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 3bb07059 12-Mar-2006 Axel Dörfler <axeld@pinc-software.de>

Fixed the build for the libbe_test target.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16748 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 641a8290 12-Mar-2006 Michael Lotz <mmlr@mlotz.ch>

Fixed converting KMessages, their target and reply info weren't preserved. Fixes bug 295.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16734 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 1daa34ec 11-Mar-2006 Michael Lotz <mmlr@mlotz.ch>

Fixed two small errors that prevented _NativeFlatten() from working. Should fix at least the Deskbar and shutdown issues of bug 295.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16732 a95241bf-73f2-0310-859d-f6bbb57e9c96


# a45369f0 11-Mar-2006 Michael Lotz <mmlr@mlotz.ch>

Renaming the Message4 magic to Haiku Message Format 1. Now off to real work.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16711 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 2bf8fb3a 11-Mar-2006 Michael Lotz <mmlr@mlotz.ch>

Putting Message4 into place to become the new BMessage implementation. Will cleanup USING_MESSAGE4 now.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16709 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 16ba0dc5 11-Mar-2006 Michael Lotz <mmlr@mlotz.ch>

Removing old BMessage implementation. Message4 will replace it in the next commit.
This will allow to fix message related problems like drag and drop and scripting.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16708 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 9bce8e57 15-Feb-2006 Axel Dörfler <axeld@pinc-software.de>

BMessage::AddString() no longer crashes when the string to add is NULL.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16410 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 05b4b0d7 23-Jan-2006 Axel Dörfler <axeld@pinc-software.de>

Node monitoring didn't work because unflattening KMessages didn't take the
message header into account. It worked before at some point as BLooper was
letting the looper handle messages to invalid targets - they are now just
dropped.
This fixes bug #93.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16045 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 174459d7 20-Nov-2005 Michael Lotz <mmlr@mlotz.ch>

Fix build when not using Message4.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15056 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 9e2023b1 20-Nov-2005 Axel Dörfler <axeld@pinc-software.de>

* Fixed sending/receiving "use preferred handler" messages - it simply didn't
work before.
* Removed the private header fPreferredTarget field.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15047 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 4ceb1e51 20-Nov-2005 Axel Dörfler <axeld@pinc-software.de>

* reverted Adi's premature changes to BWindow and restored _DetermineTarget() and
task_looper() again.
* removed BMessenger::fPreferred - whenever you had to specify "usePreferred" separately,
you don't have to do that anymore - use B_PREFERRED_TOKEN instead.
* fixed BTokenSpace::GetToken() semantics: it will no longer touch the "object" argument
in case of failure.
* Introduced a BWindow::_DistributeMessage() that will be part of the event dispatcher
counterpart to the app_server (the other will be _DetermineTarget()).
* Made it easier to use Michael's Message4 implementation: just add the following line
to your UserBuildConfig:
AppendToConfigVar DEFINES : HAIKU_TOP src : USING_MESSAGE4 : global ;
* Introduced ServerWindow::HandlerMessenger() and FocusMessenger() - the first will
target the client handler, while the other will target the preferred handler of the
client looper (usually the view having focus).
* Fixed dano message unflattening in the Message4 code.
* Changed BMessage::PrintToStream() to no longer use macros in the Message4 implementation.
* I hope that's all - it's a huge change, but it's all connected.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15046 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 1ba67cc8 16-Nov-2005 Axel Dörfler <axeld@pinc-software.de>

* almost rewrote BMessageQueue; simplified code, removed over-extensive documentation,
cleanup.
* made BMessageQueue::IsLocked() const - the non-const version is still provided
for binary compatibility.
* Both BMessageQueue::FindMessage() versions are now thread safe, the queue's BLocker
is now mutable to allow for this.
* renamed BMessage::link to fQueueLink as the "Message4" implementation uses it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14955 a95241bf-73f2-0310-859d-f6bbb57e9c96


# eddf2adc 20-Jul-2005 Jérôme Duval <korli@users.berlios.de>

style change


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13783 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b8b9dc1c 14-Jul-2005 Jérôme Duval <korli@users.berlios.de>

Fix FindPointer (tested with unit tests)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13675 a95241bf-73f2-0310-859d-f6bbb57e9c96


# ea563033 13-Jul-2005 Axel Dörfler <axeld@pinc-software.de>

Same as before, but for Replace*() methods: fixed memory leaks, small
optimazation for ReplaceFlat() (also done for AddFlat() before).
Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13662 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b9dddc39 13-Jul-2005 Axel Dörfler <axeld@pinc-software.de>

Fixed some memory leaks in case of errors (Add*() only).
Some minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13661 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 11889447 13-Jul-2005 Jérôme Duval <korli@users.berlios.de>

Readded TYPE()
Init Messenger, Ref, Message on error


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13659 a95241bf-73f2-0310-859d-f6bbb57e9c96


# ce42d864 13-Jul-2005 Jérôme Duval <korli@users.berlios.de>

Took Axel's remarks into account


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13655 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b0ba19ba 12-Jul-2005 Jérôme Duval <korli@users.berlios.de>

Moved Add* through AddData, Find* through FindData, Replace* through ReplaceData
I think BMessageBody::FindData<>, BMessageBody::AddData<>, BMessageBody::ReplaceData<> could be untemplatized
Works here, not unit tested though
Axel, please review this.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13653 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b1e14283 04-Jul-2005 Axel Dörfler <axeld@pinc-software.de>

The stream was reused later, so it was a dumb idea to not include the
magic in it (it was written twice then, later).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13430 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 749a772b 04-Jul-2005 Axel Dörfler <axeld@pinc-software.de>

Accidently broke BMessage::_SendFlattenedMessage() with the last commit;
the magic is not part of the header anymore when read from a stream (because
BDataIO does not support seeking, and we need to know the magic before actually
reading the header).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13429 a95241bf-73f2-0310-859d-f6bbb57e9c96


# dc9e836b 04-Jul-2005 Axel Dörfler <axeld@pinc-software.de>

*Very* basic read-only Dano/Zeta message support. Only briefly tested.
Not really suited for message sending/retrieval (because target stuff is
missing), but should work more or less with disk based messages.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13428 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 2a862ff0 22-Feb-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

Got rid of the temporary BMessage in BMessage::_send_().


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11450 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 0d0f1600 14-Feb-2005 Jérôme Duval <korli@users.berlios.de>

fixes forwards of BMessages
iroster now works successfully


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11367 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 09b770dd 29-Jan-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

* Added Dump() to BMessage::Header for debugging purposes.
* In BMessage::Header::ReadFrom(DataIO &) the checksum was checked before
the fBodySize field was initialized, which could make
BMessage::Unflatten() fail.
* Calculate the header checksum now by writing the header to a buffer and
checksumming that. This is simpler and avoids problems when something
else is written than is actually stored in the header (e.g. when a
preferred target token is replaced by B_PREFERRED_TOKEN).
While the BMessage unit tests always passed, now the other App Kit tests
pass as well.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11130 a95241bf-73f2-0310-859d-f6bbb57e9c96


# efbea3a0 28-Jan-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

Moved the functionality to flatten and unflatten a BMessage header into
a separate class. This allowed to improve _SendFlattenedMessage() to
deal properly with flattened BMessages as well.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11116 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 534ef684 28-Jan-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

Turned _init_message_(), _delete_message_(), and _clean_msg_cache_() into
proper private static BMessage members and made them accessible through
BMessage::Private. Got rid of unused _reconstruct_message_().


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11106 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 9d0a9900 28-Jan-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

* Updated copyright date and added myself to the authors. :-)
* Removed 1500 lines of unused non-template-madness code. We have version
control to resurrect it, if we ever wish to.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11105 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 37787255 25-Jan-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

* Added support for unflatting from flattened KMessages. At least when
a buffer is given.
* Added method for sending flattened messages. The KMessage support is
complete, but for BMessages this is a bit tricky. We currently unflatten
the BMessages and send those.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11060 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 4b8aafea 25-Jan-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

BMessenger has no friends besides Private anymore.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11023 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 26afdd62 15-Jan-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

* Added more debug output.
* In handle_reply(), in case the port message code is not as expected,
don't return B_OK and let the caller proceed with an uninitialized
BMessage, but return an error.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10762 a95241bf-73f2-0310-859d-f6bbb57e9c96


# c9f9a6b2 11-Jan-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

* fReplyTo.target (the handler token) is internally checked even, if the
preferred handler is addressed. So make sure, it has a usable value in
this case, otherwise ReturnAddress() usually won't work.
* If the message to be read from the port is bigger than the on-stack
buffer, the chunk of memory to be allocated on the heap has to be the
size of the message, not the size of the on-stack buffer. This caused
all kind of nasty, hard-trackable problems.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10677 a95241bf-73f2-0310-859d-f6bbb57e9c96


# cc171626 02-Nov-2004 ejakowatz <ejakowatz@nowhere.fake>

Added clarifying comments and a bit more error checking


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9744 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 059b143a 05-Oct-2004 ejakowatz <ejakowatz@nowhere.fake>

The fWasDelivered member was never getting initialized, so replying to
messages which did not explicitely request a reply would fail. The member
is now initialized if an unflattened message has the MSG_FLAG_INCL_REPLY
flag set.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9193 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 5958205f 07-Sep-2004 ejakowatz <ejakowatz@nowhere.fake>

Fixed bug. There was an issue with unflattening. When moving dataPtr along the buffer to the next variable-size item, the padding was being incorrectly calculated (too large) because the four-byte size header was not being taken into account. E.g., for an 18-byte item, the padding was calculated as 6 bytes, rather than two, placing dataPtr directly past the size header for the next item. An incorrect value would be used as the size for the next item, which could result in anything from a segment violation to an allocation failure.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8891 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b9c2cb3c 24-Aug-2004 ejakowatz <ejakowatz@nowhere.fake>

BMessage now sends B_NO_REPLY on destruction if no reply has been sent.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8637 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 3ceb31b9 30-Jul-2004 DarkWyrm <darkwyrm@gmail.com>

Pahtz's changes from PortLink/BSession/PortMessage/PortQueue to BPortLink


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8519 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 576416d2 29-Jun-2004 Axel Dörfler <axeld@pinc-software.de>

Fixed a warning about the uninitialized use of variable team.
Added a ToDo item because gcc is right and itemSize may be used uninitialized;
someone with a better understanding of this code should fix it.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8233 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 3905fad3 22-Feb-2004 Axel Dörfler <axeld@pinc-software.de>

Added a ToDo comment about the missing reply sending on destruction (as reported by Ingo).
You don't have to check against NULL when deleting an object.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@6674 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b7d3f36e 22-Jan-2004 Axel Dörfler <axeld@pinc-software.de>

"Fixed" the write_port_etc() call: it used a hardcoded 8 instead of B_RELATIVE_TIMEOUT (ts ts ts).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@6234 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b07c31a7 17-Oct-2003 ejakowatz <ejakowatz@nowhere.fake>

Finished up some scripting-related items.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@5080 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 1cfc4961 15-Sep-2003 shatty <shatty@nowhere.fake>

fixed BMessage::Flatten(x) so that it does not crash


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4710 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 66abd4d0 26-Aug-2003 Ingo Weinhold <ingo_weinhold@gmx.de>

Fixed a few warnings.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4381 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 9f01bd91 26-Aug-2003 Ingo Weinhold <ingo_weinhold@gmx.de>

send_message(): B_ANY_TOKEN -> B_PREFERRED_TOKEN. That's the right one.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4380 a95241bf-73f2-0310-859d-f6bbb57e9c96


# d4d9f701 26-Aug-2003 Ingo Weinhold <ingo_weinhold@gmx.de>

flatten_hdr() checks the reply handler token for B_NULL_TOKEN, so it's not wise to use exactly that one as dummy for sending synchronous messages.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4379 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 0ab25acd 25-Aug-2003 ejakowatz <ejakowatz@nowhere.fake>

Fixed bug with fBody not being properly initialized on construction.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4377 a95241bf-73f2-0310-859d-f6bbb57e9c96


# e9e500cb 25-Aug-2003 ejakowatz <ejakowatz@nowhere.fake>

Minor tweak to BHandler::UnlockLooper()
Added calls to _init_message_(), _delete_message_(), and
_msg_cache_cleanup() to InitTerminateLibBe.cpp
Finished first implementation of BMessage::SendReply(), BMessage::_send_(),
and BMessage::_send_message()
Add BMessage to app.src, removed BBlockCache from support.src.
New BMessage::Private class has functions for twiddling BMessage internals


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4371 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 0cc48ce6 03-Jun-2003 ejakowatz <ejakowatz@nowhere.fake>

Unit tests to ensure robust handling of bogus params to convenience funcs
plus fixes for the bugs they exposes.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3416 a95241bf-73f2-0310-859d-f6bbb57e9c96


# df1b8782 02-Jun-2003 ejakowatz <ejakowatz@nowhere.fake>

Fixes for bugs in BFlattenable convenience functions (revealed by the new
unit tests).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3404 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 67833f26 29-May-2003 ejakowatz <ejakowatz@nowhere.fake>

Fixed adding pointers. BMessage::AddPointer() was specifying const void*
as the template param (where everything else was using void*) and
BMessage::AddData() was adding the pointer to the pointer as the data.
Unit tests save the day again!


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3385 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 80e96696 23-May-2003 ejakowatz <ejakowatz@nowhere.fake>

Little tweaks and fixes too numerous to count, but mostly involved with
adding entry_refs and BMessages. Lots of stuff for specifiers and also for
sending replies (with thanks to Mike Nordell).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3295 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 74d92165 19-Mar-2003 ejakowatz <ejakowatz@nowhere.fake>

New tests for Add/Find/Replace/HasRef, and tweak in MessageTest.cpp to use
it. Also, minor fix in entry_ref handling in BMessage::AddData().


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@2967 a95241bf-73f2-0310-859d-f6bbb57e9c96


# e60c601e 19-Mar-2003 ejakowatz <ejakowatz@nowhere.fake>

Tweaks to make the tests work correctly and properly scope a BMessage
function.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@2966 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 9895f0ea 19-Mar-2003 ejakowatz <ejakowatz@nowhere.fake>

Some clean up and tweaks to the specifier handling code, plus the
beginnings of SendReply() functionality.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@2958 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 9abaf1df 18-Mar-2003 ejakowatz <ejakowatz@nowhere.fake>

Resolved conflict. DarkWyrm tweaked the old version (which I had #if 0'd
out all over the place). There is now a giant
#ifdef USING_TEMPLATE_MADNESS
separating the two versions. At some point, the common code should be
reconciled.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@2953 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 53ea435d 16-Mar-2003 DarkWyrm <darkwyrm@gmail.com>

Multiple fixes and added to build. Not yet complete, but close


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@2925 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 80a604c9 28-Jul-2002 ejakowatz <ejakowatz@nowhere.fake>

All things BMessage; initial check in.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@503 a95241bf-73f2-0310-859d-f6bbb57e9c96


# c0c883cf8e35433ce0b89bd160741446302efa9e 29-Aug-2015 Michael Lotz <mmlr@mlotz.ch>

BMessage: Fix precedence of KMessage vs. size check.

A KMessage request always needs to be honoured, regardless of the data
size.

KMessage does not currently protect against messages that are too large,
but this needs to be solved in KMessage when it becomes a problem.


# e31148095d0467de1c10d794b54c1289d92356a9 15-Apr-2015 Axel Dörfler <axeld@pinc-software.de>

BMessage: fixed reply port race condition.

* When the team that we got the synchronous reply from immediately
terminated afterwards, it might have still owned (and therefore
destroyed) our reply port.
* Make sure it's not added to the pool again, but is recreated instead.


# 45888dab835677c5ca7081f38d93927db242f556 01-Jul-2015 Philippe Saint-Pierre <stpere@gmail.com>

Crash fix in BMessage::ReplaceData()

The call to _CopyForWrite() invalidated the pointer previously assigned.
There was also an unrelated null-pointer derefence situation in the copy constructor.

Fixes #3074 and CID 610886 and CID 610887.


# 88f9012805a53f3067a6da849b5628b3bcb32981 22-May-2015 Alexander G. M. Smith <agmsmith@ncf.ca>

BMessage: fix an off-by-one error in SetCurrentSpecifier.

You could set the index to be past the end of the Specifier array.

Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Fixes #12087.


# 5ce80a78c976c96d3afe4e9bd9eb473cb54c362c 21-Apr-2015 Axel Dörfler <axeld@pinc-software.de>

BMessage: implemented KMessage reply.

* When you receive a message from a KMessage, and reply to it,
it will automatically reply as KMessage, too.
* This allows to communicate with BLoopers from within the kernel
or libroot.so.


# f894ab70eae60fd72f26403f8ff50d821705fa10 09-Jan-2015 Rene Gollent <anevilyak@gmail.com>

BMessage: Fix #11710.

The refactored version of Unflatten() encapsulated the raw buffer
into a BMemoryIO with a specified size of SIZE_MAX, since the total
size of the messageisn't known up front. On 32-bit this was no problem,
but on x86_64, this would lead to an overflow in BMemoryIO, since it
stores its internal length as a size_t, which on that platform is the same
size as off_t. Consequently, when it would cast its length to off_t to
compare against the requested seek position in ReadAt/WriteAt, this would
overflow to a negative, leading it to reject all requests, which
subsequently caused Unflatten() to fail.


# caf3e27a081048bf721a271db3ca63efd0e3ae4c 06-Jan-2015 Adrien Destugues <pulkomandy@gmail.com>

BMessage: fix unflattening from a KMessage buffer

The BDataIO version of MessagePrivate::Unflatten only handles the R5 and
Dano formats, so we must call the buffer version for KMessages.


# 607dfee24c7cd6f64c3743d74e9e37b6c990ad80 06-Jan-2015 Adrien Destugues <pulkomandy@gmail.com>

Really fix passing BMessages by area.


# 1bfcb75b292142bbbd2ac65a5e90d194bfdbe0f8 06-Jan-2015 Adrien Destugues <pulkomandy@gmail.com>

BMessage: fix passing messages by area

I missed the fact that the BDataIO based Unflatten didn't handle this.
Restore the code from the recently removed buffer-based unflatten, so
it's possible to pass a message by area again.


# d33e4744df1542a1350f55c25ce7b691560d7345 03-Jul-2013 Axel Dörfler <axeld@pinc-software.de>

IMAP: downloading mails is now working.

* Changed the way the attributes are written to make sure that everything
that can be written once is in fact written just once.
* The rename code in BMailProtocol::_ProcessFetchedHeader() was broken,
and caused the hang of the last commit.


# 8705e1f6e7fcc9892785d1406b2d0c0e530d0e11 22-May-2013 Axel Dörfler <axeld@pinc-software.de>

mail_daemon: cleanup, 30s auto check startup delay.

* Refactored new message retrieval a bit, so that the notification strings
aren't duplicated.
* The daemon now waits 30 seconds before doing the first mail check.


# 46851a74af0277d0fe96325969c83ed7270f5875 13-Dec-2012 Axel Dörfler <axeld@pinc-software.de>

BMessage::SetString() was broken.

* We cannot use the macro for this, unfortunately.


# a6943acbe043e34f97b5f26f72ba194a5533fbd4 12-Nov-2012 Axel Dörfler <axeld@pinc-software.de>

Added missing BMessage::{Get|Set}String() methods.

* Forgot to add those before accidentally.


# 62ede2e6a215a2858333453a52cb81d37b80614b 05-Jan-2015 Adrien Destugues <pulkomandy@gmail.com>

BMessage: avoid code duplication in Unflatten

The buffer version of Unflatten can be implemented by wrapping the
buffer in a BMemoryIO. This allows sharing more code, and the BDataIO
version of Unflatten has some extra error checks.

Fixes #11670.


# a6f1bc984d9217836f2bb3f4fbfdda00205937b2 24-Dec-2014 Adrien Destugues <pulkomandy@gmail.com>

BMessage::ReplaceData: potential corruption on realloc fail

The method would update the field offsets first, and would not restore
them in case of realloc failure, leaving them pointing to the wrong
place.


# 8007a392cf1512972cb9e92ba64923c58e60d12b 08-Nov-2014 Adrien Destugues <pulkomandy@gmail.com>

BMessage: add AddFlat taking a const BFlattenable

It seems the const was forgotten in the BeOS version. But there is no
reason not to have it.


# a0b6efc8c0229a31cc2fbb9fad83412c5861ed09 01-Nov-2014 Michael Lotz <mmlr@mlotz.ch>

BMessage: Check message area is owned by the current team.

When a message is passed by area, the sender is supposed to transfer
area ownership to the target team. If the area is not mapped within
the current team, accessing the area address would be invalid.

Also mark the area as read-only so accidental writes to the area would
become obvious.


# d3344ffccf8c1ce2340a2ad1aa32e8f30f4355a9 01-Nov-2014 Michael Lotz <mmlr@mlotz.ch>

BMessage: Check the return of _CopyForWrite().

When a message is passed by area, any modification to the message must
first trigger a copy of the message content. The success of this
operation was not checked however, possibly leading to later reallocs
on non-heap memory.


# be902ac4db5c9d0be72f6d54aa67b66e3dcc7eca 11-Jun-2014 John Scipione <jscipione@gmail.com>

App Kit: style changes.

No functional change intended.

Focused on documented classes only.

* Update copyright information.
* whitespace fixes.
* pointer style
* Rename some variables, msg => message, form => what
* Need consistent variable names to make documentation easier,
allows us to use \copydoc or \copydetails instead of repeating
ourselves over and over again.


# cd15d8c3d01530e300da951b76899e1782025900 17-Jul-2013 Philippe Saint-Pierre <stpere@gmail.com>

Style fix, no functional change intended


# cf0a957ff6c0dea52e5790a67a8fd6a179e77fe2 19-Apr-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

BMessage: Add {Add,Find}Strings()

They add a BStringList to/extract it from a B_STRING_TYPE field.


# d2239cb8b9f1e594173e41d4afe2b6949bb53609 13-Dec-2012 Axel Dörfler <axeld@pinc-software.de>

BMessage::SetString() was broken.

* We cannot use the macro for this, unfortunately.


# a2f6e5ac9c3f022f1c2afb29e6cc616e08d3adca 12-Nov-2012 Axel Dörfler <axeld@pinc-software.de>

Added missing BMessage::{Get|Set}String() methods.

* Forgot to add those before accidentally.


# 762e4ecaffb1bbaa3fef83ea8fc2b14554aa1c1b 04-Nov-2012 Axel Dörfler <axeld@pinc-software.de>

BMessage::Append() is now actually working.


# 6e50e79e543b83ed2983b23a018abd3caa93efaf 03-Nov-2012 Axel Dörfler <axeld@pinc-software.de>

Added Get*()/Set*() methods like the ones from KMessage.


# 009fd2571533728ad3b0da9430341b4b7cff46e8 26-Oct-2012 Axel Dörfler <axeld@pinc-software.de>

Added BMessage::Append(), and new(std::nothrow_t).

* Append() copies all fields from the specified message.
* The nothrow operator new allows you to add BMessages to a BObjectList.


# 46b619c39d7304493a550270adf92be3147b3878 21-Jun-2011 Rene Gollent <anevilyak@gmail.com>

Fix several problems in Flatten() that could potentially lead to overflows
and/or crashes if given a smaller buffer size than the Flatten operation
actually required.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42282 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 3270af3ca74804bfc95594f8e7bb7ea8fd728ae6 22-Jun-2011 Michael Lotz <mmlr@mlotz.ch>

* Check the no-init case consistently, no need to crash when we failed to
allocate the header.
* Code style cleanups: 80-char limit, pointer style of recent additions,
explicit NULL checks, check ports against 0 instead of B_OK, results != B_OK.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42281 a95241bf-73f2-0310-859d-f6bbb57e9c96


# ed55a28368deb40f6ef0e73f23160387d9228fed 15-Jun-2011 Axel Dörfler <axeld@pinc-software.de>

* The previous solution was needlessly complicated.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42201 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 535453d97d6452edabc729d3c0e7882e30c15e46 15-Jun-2011 Axel Dörfler <axeld@pinc-software.de>

* Reset the passed string on failure for BeOS compatibility.
* Fixes #7701.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42200 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 54cf3a72ba9b942fbe71fe4b3443c51ac0e4af01 14-Jun-2011 Ingo Weinhold <ingo_weinhold@gmx.de>

Changed sReplyPortInUse type from long to int32, so it be used with
atomic_add() also on 64 bit architectures.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42174 a95241bf-73f2-0310-859d-f6bbb57e9c96


# dc36ea92be720e848d59fe27150975ec21f1c784 24-Feb-2011 Jonas Sundström <jonas@kirilla.com>

CID 6337 SECURE_CODING

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40658 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 2b526613151fb42f35f8a5b9da7e8cf66127a00a 07-Feb-2011 Stephan Aßmus <superstippi@gmx.de>

Added another GetInfo() variant with which one can retrieve the count and
fixed size flag at once. Not sure if this can be merged into one of the
existing GetInfo() variants without breaking binary compatibility.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40374 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 6e24fc677f0ccc70de765726bc9d43a26ba99bed 16-Aug-2010 Adrien Destugues <pulkomandy@pulkomandy.ath.cx>

CID 1498 (and others) : when deleting a NULL pointer, operator delete is actually called. So, it must not dereference the
given pointer without checking first.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38147 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b1008df2c2007091bdda65b6dbb8ba9362ffbd09 14-Jul-2010 Stephan Aßmus <superstippi@gmx.de>

Patch by Alex Wilson: Added convenience methods for storing BAlignment and BSize
in BMessages. Also added type codes for them in TypeConstants.h. Closes ticket
#6302. Thanks!


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37511 a95241bf-73f2-0310-859d-f6bbb57e9c96


# e5150e28472204582c41b3d3cd5b4eabdbef323e 08-Jul-2010 Ingo Weinhold <ingo_weinhold@gmx.de>

Patch by Alex Wilson (compilation fixes by myself): Extended the archiving/
unarchiving protocol to support archival of arbitrary object graphs.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37431 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 393127df0f49d93eefed6e0c13d9f0b8a885a81f 06-Apr-2010 Stefano Ceccherini <stefano.ceccherini@gmail.com>

Use %c to print uint8. This avoids a crash. I'm not sure this is a gcc bug,
or we were using the previous form incorrectly. Anyway, this doesn't change
the functionality and fixes ticket #5676.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36052 a95241bf-73f2-0310-859d-f6bbb57e9c96


# e6dc15ca688d88677415e70429abda1503f52612 19-Mar-2010 Stefano Ceccherini <stefano.ceccherini@gmail.com>

int8 and uint8 passed 3 parameters to the printf string,
but only 2 were used, leading to various problems (like bug #5596).
I added another variation of print_type which handles that case.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35911 a95241bf-73f2-0310-859d-f6bbb57e9c96


# a3cd51c725cfb02d55eda999437bb1a8d84ec268 28-Feb-2010 Rene Gollent <anevilyak@gmail.com>

Cleanup: BMessage::_Reference never hits the case of having to transfer the area since _SendMessage already takes care of this (and transfer_area doesn't allow it to take an area from another team anyways so this code never could have worked).



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35683 a95241bf-73f2-0310-859d-f6bbb57e9c96


# e8e5e0caa009d2d129b8110ec9167ff95a61daa9 27-Feb-2010 Stephan Aßmus <superstippi@gmx.de>

Strings in BMessages don't necessarily have to be \0 terminated. Use the already
known length to print the stream so printf() doesn't potentially crash when
trying a strlen() on the string. Fixes for example printing B_KEY_DOWN messages,
where such strings are used, in certain conditions.

Review welcome, printf() formatting is not one of my strengths. :-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35629 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 67df6a72c35083d2f2fd7858c2632995095bec6f 29-Jan-2010 Michael Lotz <mmlr@mlotz.ch>

Cleanup, these aren't necessary anymore.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35337 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 17ec4668b2768d4bd04763d6f828ee880cb0ab0c 29-Jan-2010 Michael Lotz <mmlr@mlotz.ch>

Printing of basic types was broken when they were part of non fixed size fields.
The size instead of the data would be printed. The fixed/non-fixed handling is
generic though, so no need to special case the always non fixed elements.
Since adding of basic types through their Add*() function always generates fixed
size fields, this would only be visible if the data was added through AddData()
with isFixedSize == false. This is the case in compiled resources for example,
hence you would see it when printing the returned messages of BMimeType::Get*()
functions for pre-installed types.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35336 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 41975f20f06aba8438a5fe5679cfbe7d85b12dd5 25-Nov-2009 Ingo Weinhold <ingo_weinhold@gmx.de>

Fixed gcc 4 32 and 64 bit warnings in the libbe_build code. This time ported
them back to the Haiku versions.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34262 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 59fa665d53b737d01cc4a76c13a0f350cba60db6 23-Oct-2009 Michael Lotz <mmlr@mlotz.ch>

The "was dropped" flag is only used to specify whether or not DropPoint()
returns valid data. Since the data is still valid in the copy, we don't need
to clear the corresponding flag when copying a message. This is most probably
the same behaviour as in R5 as Tracker seems to expect that in the case where
a drop is done after a menu was displayed as in #4757. Thanks to aldeck for
tracking that one down inside Tracker, should fix #4757.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33746 a95241bf-73f2-0310-859d-f6bbb57e9c96


# e0b7c61c46c65f6cdc85c3b8240b282f2d045f49 10-Sep-2009 Oliver Tappe <zooey@hirschkaefer.de>

Closing ticket #4465:
Net_server starts services by invoking fork() followed by exec(). If the latter
fails (for instance because the service isn't installed), the forked child is
invoking exit(). This in turn unloads libbe, triggering static cleanup code in
BMessage, which deletes a couple of message ports that were inherited from the
parent during the fork. After that, net_server was desparately missing those
ports and no longer worked reliably.
* in InitTerminateLibBe, we now register an atfork-(child-)handler, which
takes care to re-initialize the static reply ports used by BMessage code
* added BMessage::Private::StaticReInitForkedChild wrapper and
BMessage::_StaticReInitForkedChild() implementation which overwrites the
inherited port IDs with a set of own ports


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33050 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 81147288e5e720bcd3b80cb551ab0387d11a2682 11-Aug-2009 Axel Dörfler <axeld@pinc-software.de>

* Added missing space.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32253 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 685a77f9050b8b6608ff78acc2b6f58dee34f5ef 07-Aug-2009 Michael Lotz <mmlr@mlotz.ch>

Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32187 a95241bf-73f2-0310-859d-f6bbb57e9c96


# a0bfe3ab9db79a13e4cd37941add94f5f345f393 31-Jul-2009 Rene Gollent <anevilyak@gmail.com>

gcc4 build fix.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32042 a95241bf-73f2-0310-859d-f6bbb57e9c96


# d7a16b238f2207547080ea7eb0f4c430b6f25049 31-Jul-2009 Michael Lotz <mmlr@mlotz.ch>

* Fully switch to the Haiku message format so that it is also used for on-disk
storage.
* Remove reduntant information from the header (field_count vs. fields_size).
* Remove checksums previously used to validate the message passing by area
mechanism.
* Move variables that are purely used by the instance out of the header and into
the BMessage object.
* Use more sensible types for the different message fields.
* Reduce some field sizes to realistic values.
* Make size_t values into uint32 values so the message format will not change
when later moving to 64 bits.
* Pack the structures used for flat message storage so it doesn't change
because of padding.
* Fix message passing by area. It never worked because the created area was
never actually filled with any data!
* Some more allocation checks with graceful fallbacks (should be all now).
* Some more checks for negative index values (should also be all now).
* Make printing more inline with how the rest of the class works and make some
of the output more consistent.
* Also add the new unsigned types to PrintToStream() output.
* Fix printing of unknown types and invalid BMessages, it would always have
printed only the first entry respectively the same error.
* Added some clarifying comments.
* Cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32039 a95241bf-73f2-0310-859d-f6bbb57e9c96


# e20dc8a7b7be013af204c9deaa3d7bef6f65943d 22-Jun-2009 Ingo Weinhold <ingo_weinhold@gmx.de>

Added missing convenience methods for unsigned integers.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31187 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 8f73c97d4222e32f20d7faf96f1fb388970a247d 10-Mar-2009 Stephan Aßmus <superstippi@gmx.de>

In the assignment operator, watch out if the passed message is ourself.
Fixes a crash in WonderBrush when dragging images over the layer list
to import them and triggering auto-scrolling. WonderBrush caches the
drag message and appearantly calls it's own MouseMoved() hood with the
cached message from within the auto-scrolling code.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29464 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 60a068c8a46ae6cc00d52dcc50299ba65666b193 16-Oct-2008 Michael Lotz <mmlr@mlotz.ch>

Fix build. The deep version did use the CompareData of course.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28184 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 3c6372b44a0ee5f9f1d00977b442cbd844478c1e 16-Oct-2008 Michael Lotz <mmlr@mlotz.ch>

Rename BMessage::CompareData() to HasSameData() as this makes more sense for the
bool return type. Did I mention this was an unstable Haiku extension?


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28181 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 5b25b917f9716d088424b5602a6c5c3a7d3f4997 16-Oct-2008 Michael Lotz <mmlr@mlotz.ch>

Introduce BMessage::CompareData() which is a Haiku API extension. It compares
the data of two BMessages and allows recursive comparison (BMessage inside
BMessage). Note that using this API might require you to recompile your app in
the path to R1.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28174 a95241bf-73f2-0310-859d-f6bbb57e9c96


# f75add6173425eca63d8c858c436267005d3d489 15-Aug-2008 Michael Lotz <mmlr@mlotz.ch>

Obviously noone ever really used BFlattenable objects with our BMessage, as it
was pretty broken. It would store the address of the buffer in the message
instead of the actual data. Funnily, since it was completely stack based before,
it would have stored the address plus the actual data (minus 4 bytes) as that
did reside directly after the address on the stack and the original buffer
length was still used. This corrupted the data, but still "worked" for MDR
because it has fault tolerance, loosing only part of its flattened StringList.
This broke however when switching to a heap allocated buffer for large sizes,
as then the heap address plus some random heap data was added to the message
instead of the actual buffer. Sure interesting that nobody noticed that before...


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26984 a95241bf-73f2-0310-859d-f6bbb57e9c96


# edc51252d36da166d60a301fb9eac0ccc841de66 12-Aug-2008 Stephan Aßmus <superstippi@gmx.de>

* A few versions of BMessage::AddXXX and ReplaceXXX did not check the argument
passed to the function against NULL.
* Made BMessage::AddFlat() use an optionally heap allocated buffer versus always
a stack allocated one.
* Small simplification in BMessage::AddMessage(), we can simply compare the
buffer with the stack based buffer to know whether we need to free() it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26943 a95241bf-73f2-0310-859d-f6bbb57e9c96


# d666a89e8fd1d371e75f08b45f3624138a6a6780 31-Jul-2008 Stephan Aßmus <superstippi@gmx.de>

Check for index < 0 too for B_BAD_INDEX. This fixes for example Tracker-Grep
which does

message->GetInfo("field", &type, &count);
while (message->FindBlah("field", --count, &...) == B_OK)
...;



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26695 a95241bf-73f2-0310-859d-f6bbb57e9c96


# d2e55e94c011f197d9382b727b83e4f5b3970585 24-May-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

Memory leak in error case. CID 807.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25645 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 6bf15ffcdcfc62c39948e0e9449064e65b7f13bd 27-Apr-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

* Changed macros that enable tracing for individual components from
defined/undefined to numeric values (0 for undefined). This allows for
trace levels.
* Set SYSCALL_TRACING_IGNORE_KTRACE_OUTPUT default to 1, since this is
what one usually wants.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25213 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 071f9c3aa2c2215feaa56a8ff59557dd00b27f37 27-Mar-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

Build configurations shouldn't be done in svn controlled files, so I
finally created a solution to avoid that: Header files that contain
configuration settings (and nothing else) go to build/config_headers.
To change settings, create a directory build/user_config_headers (which
is ignored by svn), copy the respective header there and modify it at
your leisure. Currently only tracing_config.h has been moved to the new
location, but more files will follow eventually. It is also recommended
to move optional macro definitions in Jamfile (as for BFS) to a config
header instead; the build system will then automatically rebuild on
changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24611 a95241bf-73f2-0310-859d-f6bbb57e9c96


# a433b9febfc466a18f81d297fd60c21e0d0e4690 09-Mar-2008 Michael Lotz <mmlr@mlotz.ch>

Rewrite and activate message passing by area. Passing by area works now with
the new sematic of transfer_area so a message area is transfered into the right
teams' address space and it does not need to be cloned there anymore. Passing
by area is only used for messages bigger than a certain size (currently
hardcoded to 40KB) which should be somehow bound to the max port message size.
This makes passing large messages (i.e. > the port limit) possible, so for
example copy&paste of long text, image data, etc. should now work.
Got rid of the fClonedArea member as it is not necessary with the new design,
renamed shared_area to message_area in the private message_header, avoid
an unnecessary allocation of the header for the copy constructors, check
allocations in a few more places and some minor cleanup.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24321 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 766c46166c26b46ac25cac0b06c8caab76a36cc7 07-Mar-2008 Rene Gollent <anevilyak@gmail.com>

Team debug effort with Michael Lotz:

Tracked down the root cause of the issue worked around in r24228.
The behavior that was occurring in this case was as follows:
Vision created a BInvoker off the heap, containing a BMessage likewise
off the heap. It then called BAlert::Go with this invoker. When any of
the buttons in the BAlert were pushed, _SendMessage would enqueue the
message into the target looper (in this case, Vision's window) and wake
it up with write_port_etc. However, in some cases this would result in
a reschedule such that Vision's looper executed before _SendMessage() was
able to complete all its processing. Upon receiving this message, Vision
destroyed the BInvoker in question, which in turn deleted its owned
BMessage -- which was the message that was still in the middle of _SendMessage()!.
Consequently it would crash a few lines later when it hit IsSourceWaiting() and
tried to check flags off its header off the already destroyed this. To fix this,
we now do the AddMessage/write_port_etc last before returning. Also removed the
sanity checks added in r24228 so we don't mask other problems of similar nature.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24297 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 8c5c17cdbcf4f1decb95ffa7f057a84005c6638f 03-Mar-2008 Rene Gollent <anevilyak@gmail.com>

Fixed a crash that would happen sometimes with BInvoker: If an invoker was
set up with a null replyTo, sometimes BMessage would crash
calling IsSourceWaiting() after delivering the message. This appeared
to be because fHeader was NULL, but I'm not entirely certain if this
is actually supposed to be possible, so this may be masking a different
bug. This was observable using the multiline paste spam BAlert in
Vision, which would sometimes but not always crash in Haiku after hitting
any of the buttons to dismiss it, though consistently when calling IsSourceWaiting()
from the private BMessage::_SendMessage().



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24228 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 3ba0ac742d2e866db209bb29dc92a4c5a8e4a0ca 02-Mar-2008 Axel Dörfler <axeld@pinc-software.de>

* Fixed a few problems in AddMessage() (most of them were pointed out by Marcus):
- no need to initialize the buffer on stack
- no need to initialize "buffer" to NULL
- renamed "buf" to stackBuffer
- enlarged buffer on stack to 16384 bytes (we have a minimum of 192 kB of
stack per thread, anyway).
- check the actual size of the stack buffer against the message's flattened
size instead of the one of its pointer.
- check if the allocation of the helper buffer failed, and return B_NO_MEMORY
in this case.
* Moved static helper functions to the top of the file.
* Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24204 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 0f9d90aa24d539e08b751fec6ea633c852fc7e17 01-Mar-2008 Karsten Heimrich <host.haiku@gmx.de>

* This fixes ticket #1865
* Allocate the buffer to flatten the message on the heap, if it's size is bigger then a given
buffer on the stack. It seem's to exceed the stack size (this might count for AddFlat() too).

Note: With this change one is able to copy the text into the clipboard (1mb), but it
is still impossible to paste it somewhere, as in BClipboard::_DownloadFromSystem()
SendMessage() fails transferring the data back in the reply msg because of the port size limit...



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24196 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 90e3bbf0cb1b904a7e0edd46e880aa26b245a1c6 31-Jan-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

Added optional kernel tracing for sending BMessages. Currently only the
destination of the message and it's "what" field are stored. It might be
nice to also get some info about its fields -- maybe as an additional
option.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23810 a95241bf-73f2-0310-859d-f6bbb57e9c96


# bfccde1f6a6f8c59e650ecab599396e0bf9a8368 13-Nov-2007 Axel Dörfler <axeld@pinc-software.de>

Forwarding did not work anymore for direct targets, since the header::flags
field was not initialized properly, and the reply target was taken from the
wrong header in this case.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22925 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 10ffdaa294bb1a385ed6e03f6abd587a98329a45 17-Oct-2007 Axel Dörfler <axeld@pinc-software.de>

Added TODO.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22597 a95241bf-73f2-0310-859d-f6bbb57e9c96


# d570f3bf79e3bf5dd9a6bdecb4839a7f0c9edbb4 23-Aug-2007 Michael Lotz <mmlr@mlotz.ch>

* Don't leak buffers when reallocs fail
* Always check the return of the resize function
* Handle resize errors gracefully and ensure that the message stays intact
* Don't crash when printing a message that contains a field with no items (unlikely but possible in low memory situations)
* Fixed renaming fields - was completely broken and would have missed up field names and contents
* Some cleanup

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22047 a95241bf-73f2-0310-859d-f6bbb57e9c96


# ccaa095f9c7260a3dc8980b6612c4bb8c80cc1e8 03-Jul-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

<malloc.h> ain't a standard header. Should fix the build on platforms that
don't have it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21546 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 5dc45eb4fe439d5f272bbc04f2eae2a31ef9de92 27-Jun-2007 Michael Lotz <mmlr@mlotz.ch>

* Unified handling of different BMessage formats into MessageAdapter.cpp
* Removed r5_message.cpp and dano_message.cpp accordingly
* Also moved out KMessage handling from Message.cpp to MessageAdapter.cpp
* Fixed some minor style issues in Message.cpp

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21514 a95241bf-73f2-0310-859d-f6bbb57e9c96


# eb9b19800b63d6384fe0937791cb8dd087373e13 03-Mar-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

Fixed gcc 4(.1.2) build problems.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20320 a95241bf-73f2-0310-859d-f6bbb57e9c96


# cd9660c79a5739c39707c1ab3b0518a673c8287b 06-Feb-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

Moved sending the B_NO_REPLY reply from the destructor to the more
general _Clear(), so that the assignment operator and Flatten() will
trigger such a reply as well.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20083 a95241bf-73f2-0310-859d-f6bbb57e9c96


# c1c0c220912dc1a11786ca0a3c119942fdb31e08 05-Feb-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

* In the BMessage assignment operator we do now clear some of the message
header flags after copying the header of the original message. Before
cloning a message that still needed a reply would result in the clone
also needing a reply, which, in the end, led to two replies being sent,
thus screwing up the cached reply ports used for synchronous messaging.
Fixes bug #1008.
BTW, also clearing the reply info breaks Tracker and Deskbar, so I suppose
R5 keeps it and Tracker and Deskbar rely on that behavior.

* Added a bit of debug code removing and printing spurious messages from a
cached reply port.

* Added TODO in BMessage::~BMessage(). ATM, we only send a B_NO_REPLY in the
destructor, but not in case the message is overwritten using the
assignment operator or Flatten().



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20074 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 9dbe170a694e59988263a752b746b6a82a5ff277 26-Jan-2007 Axel Dörfler <axeld@pinc-software.de>

Implemented direct message passing for local targets; this fixes a deadlock
with PostMessage() in case the message queue is full.
Some notes:
* for synchronous replies, we don't use this mechanism yet, but it could be
extended to do that as well.
* the code looks so complicated because we need a way to access the looper's
queue without locking it (to prevent deadlocks); like Dano's solution, I've
abused BTokenSpace to store a BDirectMessageTarget with a BHandler.
* we also need to decouple the lifetime of a looper's queue from its target,
as we cannot lock the looper, and therefore, can't guarantee it stays valid
as long as we're accessing it outside of BLooper.
* init_clipboard() now needs to be done after the global constructors have
been called - since sending messages now needs gDefaultTokens to be initialized.
Since this is done per image, it shouldn't cause any troubles, though.
* some minor cleanup, removed unused _msg_cache_cleanup_() and friends.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19968 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 67bdea52ced05be62a2fc1410e430d30f2202253 10-Jul-2006 Jérôme Duval <korli@users.berlios.de>

hope no one minds with this Dano-like version of BMessage::PrintToStream()


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18089 a95241bf-73f2-0310-859d-f6bbb57e9c96


# d134f89267ec0d41f1d10fd29e79126c5c0caa3c 23-Jun-2006 Axel Dörfler <axeld@pinc-software.de>

* Sending a forwarded message that had required a synchronous reply, can now be sent
again with a synchronous reply - the "reply done" flag wasn't cleared before sending.
* Improved error message in case the buffer for flattening the message couldn't be
allocated. BTW this would be a good place to use the new writev_port() function and
don't do any allocation at all.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17914 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 39207b00f8e52f6e1733ed54a4d012f0ddab46a1 14-Jun-2006 Jérôme Duval <korli@users.berlios.de>

BMessage::GetCurrentSpecifier() set index even if it is a negative one and returns
This would explain why BLooper::resolve_specifier() was misbehaving before I fixed it


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17834 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 7675c75fa107e9c023708e51354656d3949fde85 13-Jun-2006 Jérôme Duval <korli@users.berlios.de>

avoid adding _previous_ on forwarded synchronous messages
tested with ForwardMessageTest.cpp
well I hope it doesn't break anything :)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17831 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 4b770c6e785961f6af02f94476228e11b7c8d463 13-Jun-2006 Jérôme Duval <korli@users.berlios.de>

reverted to 17808, BLooper::resolve_specifier should be fixed instead


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17820 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 4b25c4885355d944d7befc2da5388b5746873db3 12-Jun-2006 Jérôme Duval <korli@users.berlios.de>

BMessage::GetCurrentSpecifier returns B_OK if current specifier is negative


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17809 a95241bf-73f2-0310-859d-f6bbb57e9c96


# c13a4ddf0f4bfd0e980b799f3d089f6e4df3e84b 07-Jun-2006 Axel Dörfler <axeld@pinc-software.de>

Unflattening R5/Dano messages are both using the TReadHelper class which throws
exceptions in case of an error. Therefore, whenever those methods are called,
we need to surround them with a try/catch block.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17766 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 8780db592a950c2cc94870a7d03474568b596934 24-May-2006 Axel Dörfler <axeld@pinc-software.de>

* Forwarding message that had someone waiting for a reply did not work correctly;
both messages wanted to reply then, which could get the wrong reply (B_NO_REPLY)
into the reply port. This fixes bug #513, took me some hours to figure that out...
* _SendMessage() no longer allows to forward a message and asking for a synchronous
reply that already has a source waiting for a reply.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17584 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b0bc48fbd360f10cee1856e03393c63dcbdd180f 19-May-2006 Axel Dörfler <axeld@pinc-software.de>

Some more GCC 4 and PPC fixes.
* Mesa doesn't compile yet, as some PPC specific stuff seems to be
missing, Philippe?
* Cortex and some other stuff has been marked x86-only, although
it's more of a "GCC 2.95.3"-only.
* I'm not sure if it's a bug in GCC 4, or if that's what the C
standard demands, but sizeof(some_type::some_field) is not
valid anymore :-/


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17515 a95241bf-73f2-0310-859d-f6bbb57e9c96


# f2274165dd0f678cbe3ee0e3078c6367ae8142cb 04-May-2006 Michael Lotz <mmlr@mlotz.ch>

Changing AddMessage() and ReplaceMessage() to use R5 message format to ensure compatibility.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17322 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 035eafc5f32de98f0735233b50938c3b1ebfcb58 03-May-2006 Michael Lotz <mmlr@mlotz.ch>

We should never mess with fQueueLink as it's maintained by the BMessageQueue. Small simplification.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17313 a95241bf-73f2-0310-859d-f6bbb57e9c96


# eef81495829519b42379c28e137c53fc2490f01b 11-Apr-2006 Michael Lotz <mmlr@mlotz.ch>

Fixed wrong length calculation for memmove. This should at least fix bug #314 and probably more yet unknown problems with ReplaceData(). Also optimized removing data from the end of the buffer.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17101 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 4ac06083f454b1afd6edf42d0f9766b06c65f43c 07-Apr-2006 DarkWyrm <darkwyrm@gmail.com>

Added missing symbol for Gobe Productive


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17036 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 9a44fdc97c4c91b6be039ac5125a618c8fd268cc 18-Mar-2006 Axel Dörfler <axeld@pinc-software.de>

* Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 3bb07059a46dadf20dab3f9a5e32f0422cb9a514 12-Mar-2006 Axel Dörfler <axeld@pinc-software.de>

Fixed the build for the libbe_test target.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16748 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 641a8290a7db57cf2c61fe2e57eb742e9c1e7d88 12-Mar-2006 Michael Lotz <mmlr@mlotz.ch>

Fixed converting KMessages, their target and reply info weren't preserved. Fixes bug 295.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16734 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 1daa34ec2c0d7a2980a610b144de0e146776b8f0 11-Mar-2006 Michael Lotz <mmlr@mlotz.ch>

Fixed two small errors that prevented _NativeFlatten() from working. Should fix at least the Deskbar and shutdown issues of bug 295.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16732 a95241bf-73f2-0310-859d-f6bbb57e9c96


# a45369f00a9dcf0cf8aaec6afb0717fa6f700e54 11-Mar-2006 Michael Lotz <mmlr@mlotz.ch>

Renaming the Message4 magic to Haiku Message Format 1. Now off to real work.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16711 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 2bf8fb3a96fb88396d466474b6c66888168376f7 11-Mar-2006 Michael Lotz <mmlr@mlotz.ch>

Putting Message4 into place to become the new BMessage implementation. Will cleanup USING_MESSAGE4 now.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16709 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 16ba0dc5ca98127d39c627ae8888ea61d907efc8 11-Mar-2006 Michael Lotz <mmlr@mlotz.ch>

Removing old BMessage implementation. Message4 will replace it in the next commit.
This will allow to fix message related problems like drag and drop and scripting.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16708 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 9bce8e570a39d0ea688b918383e45310d329c0fd 15-Feb-2006 Axel Dörfler <axeld@pinc-software.de>

BMessage::AddString() no longer crashes when the string to add is NULL.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16410 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 05b4b0d7ce55e971021f39195f50fb122b7c0732 23-Jan-2006 Axel Dörfler <axeld@pinc-software.de>

Node monitoring didn't work because unflattening KMessages didn't take the
message header into account. It worked before at some point as BLooper was
letting the looper handle messages to invalid targets - they are now just
dropped.
This fixes bug #93.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16045 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 174459d7034ce46ad3adef524fa4686f5884b7e7 20-Nov-2005 Michael Lotz <mmlr@mlotz.ch>

Fix build when not using Message4.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15056 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 9e2023b10b3749d241e36d21ffe6f99a9190e0b1 20-Nov-2005 Axel Dörfler <axeld@pinc-software.de>

* Fixed sending/receiving "use preferred handler" messages - it simply didn't
work before.
* Removed the private header fPreferredTarget field.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15047 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 4ceb1e519c0447147b1d8b54a324bb7fedd3a606 20-Nov-2005 Axel Dörfler <axeld@pinc-software.de>

* reverted Adi's premature changes to BWindow and restored _DetermineTarget() and
task_looper() again.
* removed BMessenger::fPreferred - whenever you had to specify "usePreferred" separately,
you don't have to do that anymore - use B_PREFERRED_TOKEN instead.
* fixed BTokenSpace::GetToken() semantics: it will no longer touch the "object" argument
in case of failure.
* Introduced a BWindow::_DistributeMessage() that will be part of the event dispatcher
counterpart to the app_server (the other will be _DetermineTarget()).
* Made it easier to use Michael's Message4 implementation: just add the following line
to your UserBuildConfig:
AppendToConfigVar DEFINES : HAIKU_TOP src : USING_MESSAGE4 : global ;
* Introduced ServerWindow::HandlerMessenger() and FocusMessenger() - the first will
target the client handler, while the other will target the preferred handler of the
client looper (usually the view having focus).
* Fixed dano message unflattening in the Message4 code.
* Changed BMessage::PrintToStream() to no longer use macros in the Message4 implementation.
* I hope that's all - it's a huge change, but it's all connected.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15046 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 1ba67cc8c65656c3ada7f150a3138cebc01a7f66 16-Nov-2005 Axel Dörfler <axeld@pinc-software.de>

* almost rewrote BMessageQueue; simplified code, removed over-extensive documentation,
cleanup.
* made BMessageQueue::IsLocked() const - the non-const version is still provided
for binary compatibility.
* Both BMessageQueue::FindMessage() versions are now thread safe, the queue's BLocker
is now mutable to allow for this.
* renamed BMessage::link to fQueueLink as the "Message4" implementation uses it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14955 a95241bf-73f2-0310-859d-f6bbb57e9c96


# eddf2adc8a1311e0bd8ffd953eb8a4b161b00626 20-Jul-2005 Jérôme Duval <korli@users.berlios.de>

style change


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13783 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b8b9dc1c248486beb6f8c8ba564a3b65dbebd06a 14-Jul-2005 Jérôme Duval <korli@users.berlios.de>

Fix FindPointer (tested with unit tests)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13675 a95241bf-73f2-0310-859d-f6bbb57e9c96


# ea563033b2b35ee9e0dfecf4270652728489a8c2 13-Jul-2005 Axel Dörfler <axeld@pinc-software.de>

Same as before, but for Replace*() methods: fixed memory leaks, small
optimazation for ReplaceFlat() (also done for AddFlat() before).
Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13662 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b9dddc39f383d5a0d97894fbccd09cf10f488da5 13-Jul-2005 Axel Dörfler <axeld@pinc-software.de>

Fixed some memory leaks in case of errors (Add*() only).
Some minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13661 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 1188944790c13337518025e0230047bd7ba62e52 13-Jul-2005 Jérôme Duval <korli@users.berlios.de>

Readded TYPE()
Init Messenger, Ref, Message on error


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13659 a95241bf-73f2-0310-859d-f6bbb57e9c96


# ce42d864eeab3e511553553d59223c993f0abf8f 13-Jul-2005 Jérôme Duval <korli@users.berlios.de>

Took Axel's remarks into account


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13655 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b0ba19ba3a3af56de3318e27b72751e9c3d8d230 12-Jul-2005 Jérôme Duval <korli@users.berlios.de>

Moved Add* through AddData, Find* through FindData, Replace* through ReplaceData
I think BMessageBody::FindData<>, BMessageBody::AddData<>, BMessageBody::ReplaceData<> could be untemplatized
Works here, not unit tested though
Axel, please review this.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13653 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b1e14283b4bbf738ad804fddfef7e6f134510970 04-Jul-2005 Axel Dörfler <axeld@pinc-software.de>

The stream was reused later, so it was a dumb idea to not include the
magic in it (it was written twice then, later).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13430 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 749a772b9734d6d02a2b36ad32dd04806cb90d67 04-Jul-2005 Axel Dörfler <axeld@pinc-software.de>

Accidently broke BMessage::_SendFlattenedMessage() with the last commit;
the magic is not part of the header anymore when read from a stream (because
BDataIO does not support seeking, and we need to know the magic before actually
reading the header).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13429 a95241bf-73f2-0310-859d-f6bbb57e9c96


# dc9e836b3543e2a83968255cc96906311beac891 04-Jul-2005 Axel Dörfler <axeld@pinc-software.de>

*Very* basic read-only Dano/Zeta message support. Only briefly tested.
Not really suited for message sending/retrieval (because target stuff is
missing), but should work more or less with disk based messages.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13428 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 2a862ff06f6b172ff8238b215b370bd71c1894cf 22-Feb-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

Got rid of the temporary BMessage in BMessage::_send_().


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11450 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 0d0f1600ef590af73ad66e72190ae90114e6c386 14-Feb-2005 Jérôme Duval <korli@users.berlios.de>

fixes forwards of BMessages
iroster now works successfully


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11367 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 09b770dd5021214a7a799242322b8896876006d4 29-Jan-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

* Added Dump() to BMessage::Header for debugging purposes.
* In BMessage::Header::ReadFrom(DataIO &) the checksum was checked before
the fBodySize field was initialized, which could make
BMessage::Unflatten() fail.
* Calculate the header checksum now by writing the header to a buffer and
checksumming that. This is simpler and avoids problems when something
else is written than is actually stored in the header (e.g. when a
preferred target token is replaced by B_PREFERRED_TOKEN).
While the BMessage unit tests always passed, now the other App Kit tests
pass as well.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11130 a95241bf-73f2-0310-859d-f6bbb57e9c96


# efbea3a07a535a8460afc7ca455a11f8d0923cbf 28-Jan-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

Moved the functionality to flatten and unflatten a BMessage header into
a separate class. This allowed to improve _SendFlattenedMessage() to
deal properly with flattened BMessages as well.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11116 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 534ef684d970a6b8fdd6bd273b0ac00ffaa35433 28-Jan-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

Turned _init_message_(), _delete_message_(), and _clean_msg_cache_() into
proper private static BMessage members and made them accessible through
BMessage::Private. Got rid of unused _reconstruct_message_().


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11106 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 9d0a9900f09887ead153e3964ffc9544e3fea9c9 28-Jan-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

* Updated copyright date and added myself to the authors. :-)
* Removed 1500 lines of unused non-template-madness code. We have version
control to resurrect it, if we ever wish to.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11105 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 377872556ddb395fd885a3c2096c4e005e18b866 25-Jan-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

* Added support for unflatting from flattened KMessages. At least when
a buffer is given.
* Added method for sending flattened messages. The KMessage support is
complete, but for BMessages this is a bit tricky. We currently unflatten
the BMessages and send those.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11060 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 4b8aafea9fea87431ca453d510fc619fac2a30fc 25-Jan-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

BMessenger has no friends besides Private anymore.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11023 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 26afdd622eeeb17c2917eb73941d9698a720b5e1 15-Jan-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

* Added more debug output.
* In handle_reply(), in case the port message code is not as expected,
don't return B_OK and let the caller proceed with an uninitialized
BMessage, but return an error.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10762 a95241bf-73f2-0310-859d-f6bbb57e9c96


# c9f9a6b20d3973397a4101bd1ffc22c5d2a5bdb7 11-Jan-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

* fReplyTo.target (the handler token) is internally checked even, if the
preferred handler is addressed. So make sure, it has a usable value in
this case, otherwise ReturnAddress() usually won't work.
* If the message to be read from the port is bigger than the on-stack
buffer, the chunk of memory to be allocated on the heap has to be the
size of the message, not the size of the on-stack buffer. This caused
all kind of nasty, hard-trackable problems.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10677 a95241bf-73f2-0310-859d-f6bbb57e9c96


# cc171626152c298c4057bdb22f41dc2994b656d6 02-Nov-2004 ejakowatz <ejakowatz@nowhere.fake>

Added clarifying comments and a bit more error checking


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9744 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 059b143a706dc1c4728afc8a0f3cf8a7c96cc29e 05-Oct-2004 ejakowatz <ejakowatz@nowhere.fake>

The fWasDelivered member was never getting initialized, so replying to
messages which did not explicitely request a reply would fail. The member
is now initialized if an unflattened message has the MSG_FLAG_INCL_REPLY
flag set.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9193 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 5958205f6c15d485af130365f89247b857c032ac 07-Sep-2004 ejakowatz <ejakowatz@nowhere.fake>

Fixed bug. There was an issue with unflattening. When moving dataPtr along the buffer to the next variable-size item, the padding was being incorrectly calculated (too large) because the four-byte size header was not being taken into account. E.g., for an 18-byte item, the padding was calculated as 6 bytes, rather than two, placing dataPtr directly past the size header for the next item. An incorrect value would be used as the size for the next item, which could result in anything from a segment violation to an allocation failure.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8891 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b9c2cb3cd18f7ec7b16e698730870c079d79040a 24-Aug-2004 ejakowatz <ejakowatz@nowhere.fake>

BMessage now sends B_NO_REPLY on destruction if no reply has been sent.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8637 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 3ceb31b96aefa3601ccc51e415da557b00155d4f 30-Jul-2004 DarkWyrm <darkwyrm@gmail.com>

Pahtz's changes from PortLink/BSession/PortMessage/PortQueue to BPortLink


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8519 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 576416d2d76c30f982e60e38a0aa24dcdfd5fdf1 29-Jun-2004 Axel Dörfler <axeld@pinc-software.de>

Fixed a warning about the uninitialized use of variable team.
Added a ToDo item because gcc is right and itemSize may be used uninitialized;
someone with a better understanding of this code should fix it.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8233 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 3905fad39d24d9226ba784bbeb780ec2baa7540b 22-Feb-2004 Axel Dörfler <axeld@pinc-software.de>

Added a ToDo comment about the missing reply sending on destruction (as reported by Ingo).
You don't have to check against NULL when deleting an object.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@6674 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b7d3f36edc73c31b1679dc9377145126fb0cf5a4 22-Jan-2004 Axel Dörfler <axeld@pinc-software.de>

"Fixed" the write_port_etc() call: it used a hardcoded 8 instead of B_RELATIVE_TIMEOUT (ts ts ts).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@6234 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b07c31a73fa621d0e407e0912e016dbf1f4b4d73 17-Oct-2003 ejakowatz <ejakowatz@nowhere.fake>

Finished up some scripting-related items.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@5080 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 1cfc49614fe5e1475fa8990029bd81345c9b6d19 15-Sep-2003 shatty <shatty@nowhere.fake>

fixed BMessage::Flatten(x) so that it does not crash


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4710 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 66abd4d0a6e5f7cf9c41bca61b88d2f15bc18ca1 26-Aug-2003 Ingo Weinhold <ingo_weinhold@gmx.de>

Fixed a few warnings.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4381 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 9f01bd91976c360875020c26aabb583b92142b2a 26-Aug-2003 Ingo Weinhold <ingo_weinhold@gmx.de>

send_message(): B_ANY_TOKEN -> B_PREFERRED_TOKEN. That's the right one.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4380 a95241bf-73f2-0310-859d-f6bbb57e9c96


# d4d9f7015a660c83cf1fa69b9ddadbb4fc1bb422 26-Aug-2003 Ingo Weinhold <ingo_weinhold@gmx.de>

flatten_hdr() checks the reply handler token for B_NULL_TOKEN, so it's not wise to use exactly that one as dummy for sending synchronous messages.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4379 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 0ab25acded49968da58d9feff37b8db4720f7b1e 25-Aug-2003 ejakowatz <ejakowatz@nowhere.fake>

Fixed bug with fBody not being properly initialized on construction.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4377 a95241bf-73f2-0310-859d-f6bbb57e9c96


# e9e500cb9eaa5061ac383f5093d08bbb65b142f8 25-Aug-2003 ejakowatz <ejakowatz@nowhere.fake>

Minor tweak to BHandler::UnlockLooper()
Added calls to _init_message_(), _delete_message_(), and
_msg_cache_cleanup() to InitTerminateLibBe.cpp
Finished first implementation of BMessage::SendReply(), BMessage::_send_(),
and BMessage::_send_message()
Add BMessage to app.src, removed BBlockCache from support.src.
New BMessage::Private class has functions for twiddling BMessage internals


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4371 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 0cc48ce6f908a17b367c5c76fd3bd6ac3b76b461 03-Jun-2003 ejakowatz <ejakowatz@nowhere.fake>

Unit tests to ensure robust handling of bogus params to convenience funcs
plus fixes for the bugs they exposes.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3416 a95241bf-73f2-0310-859d-f6bbb57e9c96


# df1b8782c7bde3bbf1d3cb77f8a7ad135bad178a 02-Jun-2003 ejakowatz <ejakowatz@nowhere.fake>

Fixes for bugs in BFlattenable convenience functions (revealed by the new
unit tests).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3404 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 67833f26bc6cef8c2257a57238343c2d4537307e 29-May-2003 ejakowatz <ejakowatz@nowhere.fake>

Fixed adding pointers. BMessage::AddPointer() was specifying const void*
as the template param (where everything else was using void*) and
BMessage::AddData() was adding the pointer to the pointer as the data.
Unit tests save the day again!


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3385 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 80e966963f0265e159d6f964ecb4de54ee1dd678 23-May-2003 ejakowatz <ejakowatz@nowhere.fake>

Little tweaks and fixes too numerous to count, but mostly involved with
adding entry_refs and BMessages. Lots of stuff for specifiers and also for
sending replies (with thanks to Mike Nordell).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3295 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 74d92165442e2ea0941385d954bf96ae7ba3137d 19-Mar-2003 ejakowatz <ejakowatz@nowhere.fake>

New tests for Add/Find/Replace/HasRef, and tweak in MessageTest.cpp to use
it. Also, minor fix in entry_ref handling in BMessage::AddData().


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@2967 a95241bf-73f2-0310-859d-f6bbb57e9c96


# e60c601e2d12770c060d3b4500dfbb1bd799bd9c 19-Mar-2003 ejakowatz <ejakowatz@nowhere.fake>

Tweaks to make the tests work correctly and properly scope a BMessage
function.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@2966 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 9895f0ea8a5c9dc600bd3340faccb1cee42652b6 19-Mar-2003 ejakowatz <ejakowatz@nowhere.fake>

Some clean up and tweaks to the specifier handling code, plus the
beginnings of SendReply() functionality.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@2958 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 9abaf1dfa742ded57034c4f1208ece3eb126a9a9 18-Mar-2003 ejakowatz <ejakowatz@nowhere.fake>

Resolved conflict. DarkWyrm tweaked the old version (which I had #if 0'd
out all over the place). There is now a giant
#ifdef USING_TEMPLATE_MADNESS
separating the two versions. At some point, the common code should be
reconciled.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@2953 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 53ea435d7b7e6f53fee714ebf14c03845f347252 16-Mar-2003 DarkWyrm <darkwyrm@gmail.com>

Multiple fixes and added to build. Not yet complete, but close


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@2925 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 80a604c999182c6eb569b78fab13f4e83b6775f5 28-Jul-2002 ejakowatz <ejakowatz@nowhere.fake>

All things BMessage; initial check in.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@503 a95241bf-73f2-0310-859d-f6bbb57e9c96