Remove 'delete securityContext;' at line 967, since 'securityContext'
will be deleted by ObjectDeleter.
Pointed by clang static analyzer.
Change-Id: Iffcd6e2b293d5614fa15ee108562ff1f5f23ddc9
Reviewed-on: https://review.haiku-os.org/c/1011
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We cannot run if it's not, but at least let's have an understandable
error message.
Fixes#14583
Change-Id: Ibe2e5d7721a1c48f06c2ac37d007a59d80c14bab
Reviewed-on: https://review.haiku-os.org/c/1007
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Since the file system resizing code must reinitialize the block cache,
it is necessary that it is completely empty.
Change-Id: If0df9f8c003edb4ccc65c4b42940512400f8598c
Reviewed-on: https://review.haiku-os.org/c/921
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Clear entire width of interspace between CPU and Memory bars
Fixes issue of artefacts appearing to the left of the memory
bar when adjusting deskbar width, especially on multi-core
systems at large font sizes.
(original code appears to have assumed interspace would not
exceed two pixels in width)
Change-Id: I4183d0337e47573792f35280452455fda584ccaf
Reviewed-on: https://review.haiku-os.org/c/1003
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* This indicates the view will manage whatever scrollbars are targeted
to it.
* Use _B_RESERVED7_ for this. It's been RESERVED since BeOS R5
(I guess it was probably something on some older BeOS version?)
and we don't really care about BeOS R4 ABI compatibility, so
that should be fine.
* Update BScrollView to not touch BScrollBar range/proportion
when the target view has this set.
* Update BListView to set this flag, always.
Fixes#14871.
Change-Id: I17027f3b63ef28da1e735c5393593496c415dce3
Reviewed-on: https://review.haiku-os.org/c/998
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
I wasn't thinking correctly when I made the previous change --
init_term_dyn is compiled into all applications, and so these
functions need to remain in order to not break them.
No "real" functional change, but this causes GCC7 to throw errors when
these functions are declared without the image_id argument, which
in some files they were (as this commit repairs.)
This change is largely inconsequential on x86, but on callee-cleanup-args
targets, leaving out the argument would probably cause stack corruption.
Previously, __haiku_init_before was a symbol that was included in
each (shared) object, and so it could be used to determine what
one we were in. Now, there are no such universal symbols that
are declared private to only the object, so we have to use
a different approach.
__func__ is defined as a const char* at the very beginning of
every function it's used in, set to a string of the function name
only, i.e., the arguments and return type are left off. So while
including that is perhaps not quite optimal, in practice this
definition is used extremely rarely (it was introduced by Haiku,
and it is used in only 2 applications at all that I could find --
WebKit and Canna.)
There really isn't any other way to get a pointer that we know
for certain is within the current object besides this one
without inserting one, but that really isn't merited just for this.
(__builtin_return_address() has problematic semantics wrt. inlining,
including linker-inlining.) So this will have to do.
It is only used as an argument to _kern_load_image directly, not to
any of the load_image functions in image.h, so it belongs in a syscall-
specific header like other such constants.
No functional change intended.
* Adds parser to servers/net/nethost, to check current
settings in resolv.conf before updating
If user has specified DNS settings manually, DHCP derived
settings are appended to resolv.conf, rather than overwriting.
(If no user specified data is present, or in the event of
a badly damaged resolv.conf, DHCP over-writes file in same
manner as prior to this change)
Fixes#11565.
Change-Id: I43464909009d2416d57f66f7bd14d13c81f803e7
Reviewed-on: https://review.haiku-os.org/c/997
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
* Actually check return codes of InitKernelAccess().
* WriteDescriptorChain accesses the memory in the IO vectors, so
we need to PrepareKernelAccess before calling it.
Fixes#14752.
* Add a utility thread_check_permissions(), which takes the target
thread, the calling thread, and whether or not this is a "kernel" call,
and then returns whether the target thread may be legally modified.
* Refactor all calls that operate by sending a signal to the thread
into a single thread_send_signal() utility function, which now uses
thread_check_permissions() appropriately.
* Manually add the permissions checks to other functions as needed.
Solves a bunch of decade+-old TODOs.
* Fix dead links where possible
* Use online instead of local links to the BeBook
Change-Id: I250117dcccc0026925c56545cca7e3b4467f2c78
Reviewed-on: https://review.haiku-os.org/c/811
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Two disk image types added to the mime_db with sniffer rules
1 x-intel-image as a generic type for images using an intel
partition style boot sector
2 x-ntfs-image a specific type for ntfs format image files
Default handler for these types is set to mountvolume, which
handles ntfs and fat images detected by these sniffers,
in the same manner as bfs images detected by x-bfs-image.
Change-Id: I994fa23bcc988c40a098aa106587e75d9e1f9b4b
Reviewed-on: https://review.haiku-os.org/c/964
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
* This iSCSI implementation only worked on PPC big-endian atm.
* We're pretty sure iSCSI support in haiku_loader doesn't make
much sense anymore. iPXE on (on arm,x86,etc EFI/BIOS platforms)
supports iSCSI boot of disks.
* Haiku could use a iSCSI driver add-on, but it would exist much
higher up and likely use standard drivers vs bare-minimum iSCSI
target impementations.
* Leaving TCP and adding to all arches since it could make sense
for haiku's native network disk subsystem or network debugging?
Change-Id: Ic181b93a1d8ffd77f69e00e372b44b79abbddb42
Reviewed-on: https://review.haiku-os.org/c/899
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Our implementation of it now behaves properly after the last commit.
Change-Id: I6bebc91ae0f9512ea07ad6a7a4ccea9ee758e01b
Reviewed-on: https://review.haiku-os.org/c/908
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previously, static initializers were just in ".ctors", which was handled
by GCC's crtbeginS, and that was injected in-between crti and crtn. Now,
however, binutils puts static initializers into init_array/fini_array by
default, which runtime_loader handles, but of course as initialize_after and
terminate_after are supposed to be called *after* all static initializers
are called; and since runtime_loader called init_array after _init, they
were not.
Now, we get rid of the __haiku_init_before/etc. functions, and move their
functionality inside runtime_loader. This is a "soft" ABI breakage,
which is mitigated by adding another ABI breakage (runtime_loader now
returns NULL for the initialize_before/etc. symbols, as otherwise
old applications would have their initialize_before/etc. called twice;
once by runtime_loader, and then once by __haiku_init_before/etc.)
I don't see or know of any reason why an application would want to
get those symbols at runtime, though, so this shouldn't have any
adverse effects.
Change-Id: I42344c63f69c6f8ef260f6c3ca30202b6dfb153e
Reviewed-on: https://review.haiku-os.org/c/907
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Prevent use of uninitialized 'lon' by checking for successful
result prior call
Change-Id: Ifbd649a8c0c0c37f285cda11e307013929cefa12
Reviewed-on: https://review.haiku-os.org/c/958
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
