Check for memory allocation errors.
Added limit to maximum flavor format count (300).
No longer crashes when out_format_count is invalid for B_BUFFER_CONSUMER,
or in_format_count is invalid for B_BUFFER_PRODUCER.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24366 a95241bf-73f2-0310-859d-f6bbb57e9c96
%edx) was trashed before passing it to the user debugger. strace shows
the correct return values again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24364 a95241bf-73f2-0310-859d-f6bbb57e9c96
only gets the caller into trouble, since then another signal should be
sent.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24363 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use a member variable for the input media_format
Thx to Ingo for pointing this out
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24362 a95241bf-73f2-0310-859d-f6bbb57e9c96
to take the current effective drawing region of the view, but converted to
local coordinate space. Untested as of yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24361 a95241bf-73f2-0310-859d-f6bbb57e9c96
* More generic supported parameter support, respect the
AUDIO_CAP_AMPLIFIER_OVERRIDE, and AUDIO_CAP_FORMAT_OVERRIDE bits.
* More cleanups.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24360 a95241bf-73f2-0310-859d-f6bbb57e9c96
structure. They are properly inherited and updated on
fork(), load_image(), and exec().
* Implemented the get[e]{u,g}id(), set[[r]e]{u,g}id() family for real.
* getgroups() also calls the kernel now, but only returns the effective
group ID. Supplementary groups support is still missing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24359 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Extended it to support long format as well.
* Extended it to support ranges of widgets (I didn't find those in the standard,
but the FreeBSD and Linux drivers implement them, and my laptop even makes
use of them, too).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24357 a95241bf-73f2-0310-859d-f6bbb57e9c96
* _Alloc() can now preserve the original reference count, only _Clone()
still initializes it to 1. As Karsten pointed out, this is necessary to
preserve the "shareable" status of the private data.
* I hope that's finally it. What happened to our testing suite, anyway? :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24355 a95241bf-73f2-0310-859d-f6bbb57e9c96
back to front copies in Window for updates. When in an update session,
any back to front copies are turned off. When the update session ends,
the whole region is copied at once. This has two effects: For once, it
avoids a lot of unnecessary copies (for example, rendering text copied
the background and then the same area for the text again). But even more
effective, it changes the entire drawing of any Haiku app to be completely
flicker free. Provided it happens in the normal Invalidate()/Draw() cycle.
And of course all this only works for double buffering mode, ie VESA.
Potentially, I might have overlooked something, so that this patch could
result in some drawing glitches, but in my testing, I have seen none yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24354 a95241bf-73f2-0310-859d-f6bbb57e9c96
rectangle area that is touched by a drawing command.
* Added a CopyToFront(BRegion) method which copies a complete region from
the drawing/back buffer to the front buffer.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24353 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Got rid of class ObjFunctionSummand. Both the constraint summands and
the objective function summands are now stored using class Summand.
* Some method names are more BeOS compliant now: SetX instead of ChangeX.
* linprog test code now uses new AddConstraint methods.
* CalculateMinSize and CalculateMaxSize did not free the memory they
allocated.
* Removed inappropriate setter and getter methods.
* Memory allocated in class Constraint is freed now.
* Other small changes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24351 a95241bf-73f2-0310-859d-f6bbb57e9c96
uncommented the meaty lines again. Added one or two more explaining
sentences.
* Created a concise UserBuildConfig.sample with very few comments and
only the most interesting (commented out) example lines for those
people who don't read the UserBuildConfig.ReadMe.
I hope everyone can live with this solution.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24350 a95241bf-73f2-0310-859d-f6bbb57e9c96
* reordered addons alphabetically like we do for all plugins
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24349 a95241bf-73f2-0310-859d-f6bbb57e9c96
_ReplaceAtPositions(), and _DoCharacterEscape() (we don't need to preserve
it, though, as it must be 1).
* Factored out an _Alloc() method which is now always called when the private
data is allocated. It also takes care of correct initialization (and thus
fixes the above problem).
* This fix finally allows turning on reference counting again, thanks Karsten!
* Minor cleanup, renamed "oldAdr"/"newAdr" to "oldString", resp. "newString".
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24348 a95241bf-73f2-0310-859d-f6bbb57e9c96
* _Realloc(), and _Detach[With]() may fail, but that wasn't accounted for
everywhere.
* The Append(), Prepend(), and Insert() char versions all caused their
backends to access invalid data (must use strncpy() instead of memcpy()
here).
* All Append(), Prepend(), and Insert() BString variants used an invalid
check, and would therefore just do nothing in certain situations like this
one:
BString a = "-";
BString b = a;
a.Append(b);
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24347 a95241bf-73f2-0310-859d-f6bbb57e9c96
of BDirectWindows for setups where the app_server uses double buffering mode.
I didn't test the change, but the way the cursor is optionally copied into
the bitmap (which might now be not 32 bpp) looks very flexible.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24346 a95241bf-73f2-0310-859d-f6bbb57e9c96
copy constructors, effectively turning of references completely.
* Since that caused troubles (NetPositive now crashes when started), I
temporarily disabled references by letting _IsShareable() always return
false until the issue is resolved.
* _FreePrivateData() now sets the fPrivateData member to NULL, and is also
safe to be called when fPrivateData is NULL.
* Removed my comment about the threading problem in _Detach() and _DetachWith()
as that just couldn't happen.
* _Clone() must not use memcpy() as the string pointed to by "data" might not
be as long as "length".
* LockBuffer() now marks a string as unshareable.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24345 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
advantages that is supposed to yield, but at least under Linux that
option is enabled.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24343 a95241bf-73f2-0310-859d-f6bbb57e9c96
Added a custom volume id just in case (might be useful for queries to work between mounts).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24342 a95241bf-73f2-0310-859d-f6bbb57e9c96
all FDs in a fork()+exec()ed child open. Makes Perl test
t/run/cloexec.t pass.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24336 a95241bf-73f2-0310-859d-f6bbb57e9c96
as the death entries of a deceased processes that were in this group
and have not yet been reaped hold references to the group, so that it
won't be deleted until the group is empty and all gone group members
have been reaped. This fixes#1799 at last.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24335 a95241bf-73f2-0310-859d-f6bbb57e9c96
programs happy, that do that unconditionally (e.g. some Perl test).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24334 a95241bf-73f2-0310-859d-f6bbb57e9c96
in code that has interrupts disabled. The chunks of memories are queued
and free()d periodically by a kernel daemon.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24332 a95241bf-73f2-0310-859d-f6bbb57e9c96
truncated, if already existing. This problem could be experienced when
saving in Pe.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24329 a95241bf-73f2-0310-859d-f6bbb57e9c96
* It now also supports the common directory path.
* search_module() checked the module paths in the wrong order, ie. it preferred
modules in the system directory over the user directory.
* Clarified comment in vfs_get_module_path().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24323 a95241bf-73f2-0310-859d-f6bbb57e9c96
buffer of the provided "path" argument.
* Applied patch by Vasilis to fix some warnings when build on Linux (missing
const on certain functions). We should probably fix the original
{add|remove}_debugger_command() functions in Haiku as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24322 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
of the resolved ToDo, but could probably be made more efficient. Instead of
transfering the area, the area is cloned into the target teams' address space
and the original is deleted. This generates a new area_id for the transfered
area (as suggested by the ToDo). Updated syscall prototypes according to the
status_t to area_id return type change.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24320 a95241bf-73f2-0310-859d-f6bbb57e9c96
