At least as far as I can tell, the template parameters are actually exported
as part of the DIESubprogram name itself, and don't need to be separately
retrieved.
* add DPBridge encoder flag and set during connector detection
* if external bridge found, do external DDC setup
* pass connectorIndex vs displayIndex to encoder_*_setup
* some of the DP AUX channel stuff should go into accelerant
common code some day like i2c.
* remove posix return
* pass GPIO hwLine through vs connector index
* variable scope cleanup
* make lowest level dp aux AtomBIOS call static, non-public
as it is always called by connector code
When retrieving modifiers, we're actually pulling them off the type
in reverse order. Consequently we need to build the type's modifier string
similarly.
If the first modifier is a const, prepend it to type name instead.
The fModes array is realloc'ed as needed when adding modes. Therefore
the fModes pointer handed in to AddModes() becomes invalid once
_MakeSpace() returns in that function causing a freed memory block to
be used as input.
To avoid that we make a copy of the base mode list and then use that to
add the modes for each color space.
The file content isn't normally 0 terminated, so making a string out of
it would usually result in reading beyond the allocated buffer to find
the string length, possibly leading to a crash.
* clean up previously changed error returns in 8c01b4. For
some reason I thought B_ERROR was the only non-positive
status.
* add VESA DisplayPort defines. Only a subset so it's local
to radeon_hd for now.
* this completes basic AUX transaction code, still untested
When asked for a fully qualified DIE name, we now add the parameters
of functions as well. This allows them to show up in, e.g. the function
list view. Still needs some work but basically functional.
In the case of variables that refer to static members of compound types,
the specification will be a reference to a DIEMember rather than a
DIEVariable in DWARF3. Relax our restrictions accordingly.
It turns out,this is an old method added by Be, and is not really related to BView::InvalidateLayout(bool). In fact BMenu::InvalidateLayout() does something separate, but related to the BView method. I was wrong to delete this method, since it needs to have action taken each time it is called, so moving these actions into LayoutInvalidated() only worked sometimes (when the BView was considered to have a valid layout).
I have added a comment for future hackers so that they don't delete this method.
* this will help break apart some of the sources
* display bus communications really don't belong with GPU operations
* rename functions to better describe their actions
- Add accesor to CompoundType to expose the particular compound kind.
- Implement aforementioned accessor in DwarfCompoundType, and ensure
DwarfTypeFactory populates it appropriately.
- Modify GlobalTypeLookup to make use of the address and compound
subtype kinds when trying to match a type.
Due to the lack of matching against the subtype, we would previously wind
up matching anonymous compound types against those of their parents, resulting
in the wrong type getting assigned to their value nodes.
Fixes#8190.
The operator const char*() automatically converts to the needed type
so the explicit BString::String() call isn't needed here. Thanks to
Clemens for pointing that out.
The previous solution had various issues where argv pointed to stack-based
objects that had potentially been destroyed/overwritten already. Fixes
#8173.
- Modify _SetupGDBArguments() to return an error code and check for it
accordingly.
The previous solution had various issues where argv pointed to stack-based
objects that had potentially been destroyed/overwritten already. Fixes
#8173.
- Modify _SetupGDBArguments() to return an error code and check for it
accordingly.
The guarded heap uses mprotect() to protect freed/unallocated pages so
that any access to such a page results in a segfault. It also installs
a segfault handler that in such an event prints some info about the
accessed page and then calls the debugger with a meaningful message.
It implements the same interface as the debug heap so it can simply be
swapped out by changing the Jamfile. As it doesn't support most of the
extra debug features (wall checking is obviously superfluous, but it
also doesn't help in leak checking) and as it is hugely space
inefficient I left it disabled for now.
The BString is destroyed when the function returns and takes the
storage pointed to by BString::String() with it, so returning such a
pointer is bogus. Instead the return type is now a BString which takes
over ownership of the string.
* This tool was created and implemented in draft during GCI 2011
by Aleksas Pantechovskis, <alexp.frl@gmail.com>;
* Later it was heavily refactored and optimized to Haiku Coding
Standards by Siarzhuk Zharski;
* Icons support still missing;
* Thank you for the contribution, Aleksas!
Signed-off-by: Siarzhuk Zharski <zharik@gmx.li>
* We may get non-terminated strings so we need to use the
UTF8NextCharLen() version that works with a length. Previously we may
have read beyond buffers, possibly leading to crashes.
* Also the length parameter is used as an actual length and not as
buffer size. The length check was wrong before, which resulted in the
function returning too early if an offset was supplied.
* Added a comment about the guaranteed 0 termination in one case.
* Minor cleanup.
This one works with non-terminated strings that we may need to handle.
It also validates that the sequence is valid UTF-8 so it results in
the same behaviour as the version that is used when converting to
codes (syncing the enumeration and drawing behaviour).
The string that is built for hashing the escapements for missing
chars was not 0 terminated, leading to accesses past the string.
Depending on what followed an allocation that could lead to too long
strings being sent to the app_server for evaluation (where, due to
defensive, programming nothing bad would actually happen). In the
unfortunate case that nothing followed the allocation (i.e. end of
heap area), it could also lead to an application crash.
Therefore ensure 0 termination of the string, check for allocation
failure and use memcpy() instead of a for loop to copy the bytes from
one string to the other.
