The "generic" files are actually not generic at all. They were
imported for the PowerPC port and assume a matching format for float.
However, x86 uses a different format as the values are stored with 80
bit precision in the FPU. Therefore the generic implementation is
not appropriate whenever it does bit manipulations.
The glibc implementation uses the same sourcecode as the x86 version
for atan2, and there is no reason for us not to do the same.
Should fix #14933
Change-Id: I9addcfdf8b0f980c8842480885b59c0133866756
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2067
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
For #15515
As mentionned in the ticket, we may also want to hide the symbols
altogether from libroot for newer API/ABI versions, unless we still want
to provide C89/C99/C++98/C++11 compatibility, in which case we still
need them around.
Change-Id: I0ee267fb6c4c2f4bae9b1ba6f68e2bcefc399a7f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This patch fixes a bug in the BMemoryIO unit tests that made them
fail and adds an additional test case for read-only buffers.
The failing test case invokes BMemoryIO::WriteAt() with the position
parameter set to -10, which is invalid and should result in a return
value of B_BAD_VALUE. And it does, but the test fails because it was
testing for the return value 5, as in 5 bytes copied.
An additional test case is added for read-only BMemoryIO objects. If
the BMemoryIO(const void*, size_t) constructor is used then it will be
marked as read-only, so writes should fail with B_NOT_ALLOWED.
Change-Id: Icf4b837c77fba2be958f9d3e4b3adb18a23b037f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2066
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This allows to have all the tools (resizefs, fs_shell, etc) merged, and
split out the remaining BFS resize changes in a way that makes some
sense. We can easily merge all the basic infrastructure (ioctls, etc)
without any of the actual resizing code (I'll leave that to
professionals).
libprint had a very conservative size limitation (4MB) for the bitmap it
allocates. This leads to splitting a page to print in several "bands"
(about 5 in my testing). However, these may still be too large for the
printer driver to handle, which means the driver may be further slicing
things up, or other drivers may need the full page anyway and recompose
it in some way.
Instead of an hardcoded limit, now try to allocate a bitmap for the
whole page, and if that doesn't work, progressively increase the number
of bands until we manage to allocate a bitmap. Stop when we have split
the page in 256 bands, as it seems rather pointless to be that far. Call
debugger when this happens, as there doesn't seem to be a way to do
better error handling here (the code used to raise std::bad_alloc if
BBitmap allocation failed, or just return an invalid bitmap and view).
Change-Id: Iba690f68c748d20828709244a23e82a08185390e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1922
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
There is a section of the spec that dictates how TRBs need to be
sized within a TD, and we were not following that. This should
bring us into compliance.
See inline comments for more details.
This is useful for example on the eeePC 701, where the EDID/DDC lines
from the LCD display are not wired to the video card as expected (I
confirmed this by downloading the eeePC schematics, the LCD is somehow
wired to what would normally be a PS/2 port on the embedded controller).
In this case, there is no way we can get the EDID data from the usual
means, however, we still know the panel resolution by looking it up in
the VESA BIOS, and if we found it there, there has to be an LVDS panel,
so we can configure it.
Should fix #14066.
6c67c7d63 was attempting to fix a leak caught by a static analysis
tool, but it actually just introduced a double-free bug. Running
`UnitTester BString` will result in a crash.
The original code was correct because, in the event that realloc()
fails in BString::_Resize(), the value of fPrivateData is still
retained. It will be freed by the destructor of BString only if
fPrivateData is not shared by another BString instance, since BStrings
are copy-on-write.
Note that while the change in 6c67c7d63 caused tests to fail, that
doesn't mean those tests are ideal. They only trigger
BString::_Resize() to fail because they depend on implementation
details of hoard2 which limits allocations via malloc() to
1GB. Most malloc() implementations will allow allocations of arbitrary
sizes using anonymous mappings (mmap on Linux, or create_area() in
Haiku). This is a much bigger change, so for now I'm just adding some
comments so that we can revisit these tests if we make a change to the
allocator.
Change-Id: I208c1c7a76b6b4409d237b911c62bb3198e49dab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2060
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
In hrev53618 I swapped both the LVDS and SVDO limits for i9xx to be in
the same order (always use "min" for the smallest value and "max" for
the largest, both for dividers and multipliers). But I missed the fact
that P2 is not searched for values in the range as are the other
parameters.
So, the code that picks the appropriate P2 value needs to be adjusted
accordingly. Now that this is clear, put the values always in the same
order (smallest value in "min", largest value in "max") and adjust the
code to comute P2.
Fixes #15573.
Even if we are still not so sure about the veracity of other
filesystem drivers, the BFS driver has had no reported corruption
bugs for quite some time (almost 2 years I think). In fact the
only real corruption issues heard of recently are from KDLs,
which are also a vanishing issue.
So, disabling the warning entirely for BFS partitions probably makes
sense at this point.
Change-Id: I5470c956d57b90ea00b647bf15299ba606ba01c4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1822
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Declare loop variables before the for loops to be compatible with C89.
Fixes #15583.
Change-Id: If2a3b4447a88bb2e65c5ff4166f32df1b26fd859
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2058
Reviewed-by: Alexander G. M. Smith <agmsmith@ncf.ca>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
They have generic names and are likely to conflict with other things. In
particular, there is another BPrivate::TitleView in BColumnListView,
which results in weird behavior (and me wasting days debugging things
and scratching my head) when one links libmedia before libcolumnlistview
and the wrong one ends up being called.
The PCI enumeration functions are not implemented in the compat layer,
so we need a glue function that performs the Haiku equivalent here.
This code existed in the old Haiku-native driver, so it's just
copied from there.
The within-an-attempt timeout did not successfully break up
deadlocks that occur on a system with a lot of USB transfers
going, as we may never hit 2 seconds in between wake-ups,
but the size requested may be un-fulfillable regardless.
So, now we have a 2-second overall timeout. This fixes
the system freeze in #15569, but now attached USB disk
drives enter a Stall state, making the system unusable
anyway.
In hrev53370, leavengood refactored this function out of
PackageVolumeInfo::SetTo(). Inside that function, there
is a "state" variable which is initialized to the first,
default state, which is always the head state.
Refactoring it out of there and changing this to NULL meant
that GetNext would always return a NULL state, so the
states would never be initialized, and booting from an
old state would thus not be possible.
Fixes #15380.
The labels were never actually translated, only marked for use in
catalogs. Moreover, all the keys were sent as a single string, which is
unconvenient for translation and requires useless parsing in the code.
Use an array of strings instead, which is simpler.
There is a change to the archiving format, instead of storing the whole
keymap, only its name is stored. For backwards compatibility, if we
detect "ln" at the start of the string we use scientific mode.
Change-Id: I566d8d51e8ac6e780fc25207aad1dfa7ff737988
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2049
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Drop gnu-efi
Change-Id: Ib601fc8ced49b18281b6b98cf861a5aef1b9c065
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2026
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
enable to check whether a shutdown process is in progress.
Change-Id: I8efdddb3caa80e9fd188f202b6e92a888a7608e5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2042
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The base problem was, that every time I opened KeyMap while a Terminal
was opened too, it eventually crashed. I followed along the trace and
found that the code first frees the keymap and keymapchars in the
_UpdateKeymap() and then calls SetKeymap for every tab opened which
also tries to free the old keymap and keymapchars.
TermWindow's _UpdateKeymap() method first frees the old keymap and keymapchars:
delete fKeymap;
delete[] fKeymapChars;
and then calls SetKeyMap for every tab which tries to free the old keymap and keymapchars again:
for (int32 i = 0; i < fTabView->CountTabs(); i++) {
TermView* view = _TermViewAt(i);
view->SetKeymap(fKeymap, fKeymapChars);
}
So TermView simply is not responsible for the memory, it merily has a pointer.
Fixes #15502.
Change-Id: Id08c863d811fbb72cce9be4c8fff2d3eb5f0064f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2037
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Pascal Abresch
Adrien Destugues