app_server/BitmapManager: fix memory leak caused by missing token remove

`BTokenSpace::NewToken` put all allocated tokens into `fTokenMap` so
`BTokenSpace::RemoveToken` should be called for tokens that become unused to avoid infinite `fTokenMap` growth.

Change-Id: I0aee709234143ceaf4416d63b38fb2a26eb8f891
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7417
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>

app_server memory management fixes: use BReference

Use BReference for more automated reference counting in app_server,
fixing some use-after-free and other problems.

Extracted from https://review.haiku-os.org/c/haiku/+/2695

Change-Id: I141bb248229405896b29feff3338447f7257b0b4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3175
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

PVS V501: redundant checks

There are some more in telnetd and agg but I'm not sure if they are
intentional, the code is so ugly there.

Change-Id: I9cc2bf8a919c3b1d6c68f2ded8622730497b0f91
Reviewed-on: https://review.haiku-os.org/c/1598
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>

Make it possible to reconnect BBitmap to the app_server.
* maintain a list of all BBitmaps
* refactor the client memory allocator class, its possible now to just clone existing client area

CID 5885: Resource leak in error case.


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

* Refactored ServerBitmap a bit: it now inherits from Referenceable instead of
roling its own solution.
* Also removed BitmapManager::DeleteBitmap() - you only call
ServerBitmap::RemoveReference(), and that one will notify the manager if
needed.
* Some more cleanup.


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

* ServerApp's bitmap and picture handling was completely broken, as it ignored
concurrency as well as reference counting, causing occasional crashes and
memory corruption.
* ServerPicture now subclasses Referenceable, and will notify its owner when
it's going to be deleted. This might bring some regressions, although I
couldn't spot anything wrong yet.
* ServerBitmap will now also notify its owner when it's going to be deleted as
well.
* Switched from the former picture/bitmap lists to a std::map. This also solves
the issue of not checking whether or not the bitmap/picture actually belongs
to the ServerApp (before, all apps could access and delete all
pictures/bitmaps)
* Introduced a new fMapLocker that guards the new maps.
* ServerWindow now uses GetBitmap()/GetPicture(), and gives up its reference
after use.


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

* Rewrote screen configuration management: VirtualScreen doesn't have anything
to do with the configurations now, instead, there is a separated
ScreenConfigurations class that maintains all known screen_configurations
per workspace (and the Workspace::Private class has two of them, one for the
current modes, one for the stored modes).
* Added Desktop::{Get|Set}ScreenMode() methods, ServerApp now only calls those.
* Getting and setting of anything else than the current screen is now supported.
* This change also fixes that a temporarily set screen mode was not being
restored on workspace switch.
* Also, the Deskbar now seems to have the wrong location a lot, which is
something that should be easily fixable therefore. I will look into this next.
* Got rid of the unhandy screen_id structure server side, and in BPrivateScreen;
we now just use an int32 - the next API break should definitely replace the
screen_id with a simple typedef.
* Some cleanup.


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

* Deleted overlays were never removed from the fOverlays list, instead they were
added another time (copy&paste bug). This caused #3282.
* Added optional tracing output to Overlay.cpp.


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

* Patch by Fredrik Ekdahl: gcc 4 build fixes (missing headers).
* Added missing header for mountvolume.


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

* Introduced new BBitmap flag B_BITMAP_SCALE_BILINEAR.
* When drawing BBitmaps with scaling in the app_server, use a bilinear
filter when a bitmap has this flag set. (Hope nobody objects, otherwise
I can revert or improve this. Performance can certainly be improved, since
the AGG implementation is too generic. But that goes for the nearest
neighbor implementation as well.)
* Flags are uint32, fix app_server side code to declare them correctly. Use
appropriate link methods in BBitmap and ServerApp.
* Enable the BeOS compatibility mode for B_RGB32 (works just like B_RGBA32
in B_OP_ALPHA mode).


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

* Handle clearing to white on the client. This also makes sure that bitmaps are
cleared which have no app_server link (B_BITMAP_NO_SERVER_LINK).
* Check the allocation of the BWindow in BBitmap for view accepting bitmaps.


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

* view accepting bitmaps are now cleared to white


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

Fixed the overlay I accidently broke with the last commit - sometimes, but only
sometimes, testing seems like a good idea 8-)


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

* Implemented the overlay suspend/resume protocol on mode changes; not really tested
yet. Also, BBitmap::LockBits() should probably fail when the Bits() are NULL.
* The downside is that many more classes now know of each other.
* Cleaned up the work divided between the BitmapManager and the Overlay class.
* Fixed a memory leak in AS_CREATE_BITMAP in case the bitmap could not be added to
the ServerApp's bitmap list.


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

* Some refactoring: renamed OverlayCookie to Overlay and put it in its own
source file.
* An overlay is now also hidden in case its is removed from the window.


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

* With Rudolf's information about relocating overlays, I changed the way memory
is managed for those bitmaps:
- the shared client memory mechanism is used to allocate a small overlay_client_data
structure that contains the actual buffer and a semaphore that you have acquire in
order to access it.
- LockBits()/UnlockBits() now have a function: you need to call them before accessing
the overlay buffer, and you need to keep that lock until you're done with it.
* The overlay cookie is now an extra member of the ServerBitmap class.
* Removed fInitialized from ServerBitmap - IsValid() now just checks the buffer associated
with the bitmap.
* ViewLayer::Draw() will now handle overlay bitmaps specially and will draw the overlay
color instead of any contents (this is currently in ugly pink, but will become some
dark color later on).
* All what's missing from actually being able to use overlays now is to configure
them so that they are shown on screen. VLC will now show an empty pink window when
overlay video is enabled.


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

* Refined overlay support a bit: we now allow as many overlay bitmaps to be
created as the graphics driver does.
* Also, B_BITMAP_RESERVE_OVERLAY_CHANNEL should now work as expected.
* We're no longer using the B_OVERLAY_COUNT hook anymore - that one really
looks like a misconception to me; I don't see how it can be useful.


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

Implemented some more overlay support - the overlay bitmap is now allocated
via the graphics driver (but not yet shown on screen).
I probably got the meaning of the "overlay count" wrong - I guess that you
can allocate any number of overlay bitmaps, but can only see "overlay count"
on screen at a time (right now, I only allow to create "overlay count" bitmaps).
Stephan?


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

* fixed filling B_CMAP8 bitmaps with white (255 was the wrong
color index)


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

* 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

* B_BITMAP_WILL_OVERLAY bitmaps are currently not
supported. (makes VLC run without changes)
* B_BITMAP_CLEAR_TO_WHITE causes the server to
clear the bitmap to white... :-)
* removed weird comment


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

* Fixed a bug in ServerApp: when a ServerWindow would take too long to quit,
it could crashed the server.
* ViewLayer now deletes the view bitmap on destruction, if any.
* BitmapManager::Delete() now also accepts NULL bitmaps.


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

Implemented reference counting of ServerBitmaps, made constructor and destructor private,
as only the BitmapManager class is allowed to call them.


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

Merged app_server_new_clipping branch changes r15290 to 15418 back into trunk.
Also fixed Jamfile for the test environment.


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

* the app_server now uses a global token space - this should later be changed to
have different token spaces depending on the scope of its objects.
* removed TokenHandler - we're now using BTokenSpace instead.
* removed unused IPoint.cpp - if we ever need it again, it can still easily be
resurrected from the dead.
* some cleanup.


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

Fixes that make Haiku build with gcc 4. Mainly out of the following
categories:
* Missing includes (like <stdlib.h> and <string.h>).
* Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so.
* Local variables shadowing parameters.
* Default parameters in function definitions (as opposed to function
declarations).
* All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported
explicitly from the std:: namespace now.
* "new (sometype)[...]" must read "new sometype[...]", even if sometype is
something like "const char *".
* __FUNCTION__ is no longer a string literal (but a string expression), i.e.
'printf(__FUNCTION__ ": ...\n")' is invalid code.
* A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes"
is an invalid expression.
* "friend class SomeClass" only works when SomeClass is known before.
Otherwise the an inner class with that name is considered as friend.
gcc 4 is much pickier about scopes.
* gcc 4 is generally stricter with respect to type conversions in C.



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

Improved AreaPool to have an initial size as well as well as a name that is
used for new area.
MemPool::AddToPool() now gracefully deals with NULL pointers (or a size of 0).
BitmapManager was deleting the area it transferred to AreaPool before - it
no longer needs an extra area, though.
Minor other cleanup.


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

Fixed some style related functions and other oddities in FontServer.
Also applied our style guide on that class.
Renamed some public globals to match our style guide.
Made BitmapManager inherit from BLocker instead of duplicating its
functionality (incorrectly, did not check for B_INTERRUPTED) locally.
Some more cleanup.


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

clean up, bug fixes and more robustness

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

Moved app_server files to app/.


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

Make it possible to reconnect BBitmap to the app_server.
* maintain a list of all BBitmaps
* refactor the client memory allocator class, its possible now to just clone existing client area

CID 5885: Resource leak in error case.


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

* Refactored ServerBitmap a bit: it now inherits from Referenceable instead of
roling its own solution.
* Also removed BitmapManager::DeleteBitmap() - you only call
ServerBitmap::RemoveReference(), and that one will notify the manager if
needed.
* Some more cleanup.


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

* ServerApp's bitmap and picture handling was completely broken, as it ignored
concurrency as well as reference counting, causing occasional crashes and
memory corruption.
* ServerPicture now subclasses Referenceable, and will notify its owner when
it's going to be deleted. This might bring some regressions, although I
couldn't spot anything wrong yet.
* ServerBitmap will now also notify its owner when it's going to be deleted as
well.
* Switched from the former picture/bitmap lists to a std::map. This also solves
the issue of not checking whether or not the bitmap/picture actually belongs
to the ServerApp (before, all apps could access and delete all
pictures/bitmaps)
* Introduced a new fMapLocker that guards the new maps.
* ServerWindow now uses GetBitmap()/GetPicture(), and gives up its reference
after use.


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

* Rewrote screen configuration management: VirtualScreen doesn't have anything
to do with the configurations now, instead, there is a separated
ScreenConfigurations class that maintains all known screen_configurations
per workspace (and the Workspace::Private class has two of them, one for the
current modes, one for the stored modes).
* Added Desktop::{Get|Set}ScreenMode() methods, ServerApp now only calls those.
* Getting and setting of anything else than the current screen is now supported.
* This change also fixes that a temporarily set screen mode was not being
restored on workspace switch.
* Also, the Deskbar now seems to have the wrong location a lot, which is
something that should be easily fixable therefore. I will look into this next.
* Got rid of the unhandy screen_id structure server side, and in BPrivateScreen;
we now just use an int32 - the next API break should definitely replace the
screen_id with a simple typedef.
* Some cleanup.


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

* Deleted overlays were never removed from the fOverlays list, instead they were
added another time (copy&paste bug). This caused #3282.
* Added optional tracing output to Overlay.cpp.


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

* Patch by Fredrik Ekdahl: gcc 4 build fixes (missing headers).
* Added missing header for mountvolume.


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

* Introduced new BBitmap flag B_BITMAP_SCALE_BILINEAR.
* When drawing BBitmaps with scaling in the app_server, use a bilinear
filter when a bitmap has this flag set. (Hope nobody objects, otherwise
I can revert or improve this. Performance can certainly be improved, since
the AGG implementation is too generic. But that goes for the nearest
neighbor implementation as well.)
* Flags are uint32, fix app_server side code to declare them correctly. Use
appropriate link methods in BBitmap and ServerApp.
* Enable the BeOS compatibility mode for B_RGB32 (works just like B_RGBA32
in B_OP_ALPHA mode).


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

* Handle clearing to white on the client. This also makes sure that bitmaps are
cleared which have no app_server link (B_BITMAP_NO_SERVER_LINK).
* Check the allocation of the BWindow in BBitmap for view accepting bitmaps.


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

* view accepting bitmaps are now cleared to white


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

Fixed the overlay I accidently broke with the last commit - sometimes, but only
sometimes, testing seems like a good idea 8-)


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

* Implemented the overlay suspend/resume protocol on mode changes; not really tested
yet. Also, BBitmap::LockBits() should probably fail when the Bits() are NULL.
* The downside is that many more classes now know of each other.
* Cleaned up the work divided between the BitmapManager and the Overlay class.
* Fixed a memory leak in AS_CREATE_BITMAP in case the bitmap could not be added to
the ServerApp's bitmap list.


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

* Some refactoring: renamed OverlayCookie to Overlay and put it in its own
source file.
* An overlay is now also hidden in case its is removed from the window.


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

* With Rudolf's information about relocating overlays, I changed the way memory
is managed for those bitmaps:
- the shared client memory mechanism is used to allocate a small overlay_client_data
structure that contains the actual buffer and a semaphore that you have acquire in
order to access it.
- LockBits()/UnlockBits() now have a function: you need to call them before accessing
the overlay buffer, and you need to keep that lock until you're done with it.
* The overlay cookie is now an extra member of the ServerBitmap class.
* Removed fInitialized from ServerBitmap - IsValid() now just checks the buffer associated
with the bitmap.
* ViewLayer::Draw() will now handle overlay bitmaps specially and will draw the overlay
color instead of any contents (this is currently in ugly pink, but will become some
dark color later on).
* All what's missing from actually being able to use overlays now is to configure
them so that they are shown on screen. VLC will now show an empty pink window when
overlay video is enabled.


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

* Refined overlay support a bit: we now allow as many overlay bitmaps to be
created as the graphics driver does.
* Also, B_BITMAP_RESERVE_OVERLAY_CHANNEL should now work as expected.
* We're no longer using the B_OVERLAY_COUNT hook anymore - that one really
looks like a misconception to me; I don't see how it can be useful.


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

Implemented some more overlay support - the overlay bitmap is now allocated
via the graphics driver (but not yet shown on screen).
I probably got the meaning of the "overlay count" wrong - I guess that you
can allocate any number of overlay bitmaps, but can only see "overlay count"
on screen at a time (right now, I only allow to create "overlay count" bitmaps).
Stephan?


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

* fixed filling B_CMAP8 bitmaps with white (255 was the wrong
color index)


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

* 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

* B_BITMAP_WILL_OVERLAY bitmaps are currently not
supported. (makes VLC run without changes)
* B_BITMAP_CLEAR_TO_WHITE causes the server to
clear the bitmap to white... :-)
* removed weird comment


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

* Fixed a bug in ServerApp: when a ServerWindow would take too long to quit,
it could crashed the server.
* ViewLayer now deletes the view bitmap on destruction, if any.
* BitmapManager::Delete() now also accepts NULL bitmaps.


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

Implemented reference counting of ServerBitmaps, made constructor and destructor private,
as only the BitmapManager class is allowed to call them.


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

Merged app_server_new_clipping branch changes r15290 to 15418 back into trunk.
Also fixed Jamfile for the test environment.


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

* the app_server now uses a global token space - this should later be changed to
have different token spaces depending on the scope of its objects.
* removed TokenHandler - we're now using BTokenSpace instead.
* removed unused IPoint.cpp - if we ever need it again, it can still easily be
resurrected from the dead.
* some cleanup.


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

Fixes that make Haiku build with gcc 4. Mainly out of the following
categories:
* Missing includes (like <stdlib.h> and <string.h>).
* Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so.
* Local variables shadowing parameters.
* Default parameters in function definitions (as opposed to function
declarations).
* All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported
explicitly from the std:: namespace now.
* "new (sometype)[...]" must read "new sometype[...]", even if sometype is
something like "const char *".
* __FUNCTION__ is no longer a string literal (but a string expression), i.e.
'printf(__FUNCTION__ ": ...\n")' is invalid code.
* A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes"
is an invalid expression.
* "friend class SomeClass" only works when SomeClass is known before.
Otherwise the an inner class with that name is considered as friend.
gcc 4 is much pickier about scopes.
* gcc 4 is generally stricter with respect to type conversions in C.



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

Improved AreaPool to have an initial size as well as well as a name that is
used for new area.
MemPool::AddToPool() now gracefully deals with NULL pointers (or a size of 0).
BitmapManager was deleting the area it transferred to AreaPool before - it
no longer needs an extra area, though.
Minor other cleanup.


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

Fixed some style related functions and other oddities in FontServer.
Also applied our style guide on that class.
Renamed some public globals to match our style guide.
Made BitmapManager inherit from BLocker instead of duplicating its
functionality (incorrectly, did not check for B_INTERRUPTED) locally.
Some more cleanup.


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

clean up, bug fixes and more robustness

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

Moved app_server files to app/.


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