Age | Commit message (Collapse) | Author |
|
|
|
The unsigned index arithmetic was problematic in that case.
|
|
|
|
Since LLSDSerialize::SIZE_UNLIMITED is negative, passing that through unsigned
size_t parameters could result in peculiar behavior.
|
|
and use it to replace dubious loops in asLLSD() and trimEmpty().
|
|
|
|
|
|
|
|
Introduce LLSD template constructors and assignment operators to disambiguate
construction or assignment from any integer type to Integer, likewise any
floating point type to Real. Use new narrow() function to validate
conversions.
For LLSD method parameters converted from LLSD::Integer to size_t, where the
method previously checked for a negative argument, make it now check for
size_t converted from negative: in other words, more than S32_MAX. The risk of
having a parameter forced from negative to unsigned exceeds the risk of a
valid length or index over that max.
In lltracerecording.cpp's PeriodicRecording, now that mCurPeriod and
mNumRecordedPeriods are size_t instead of S32, defend against subtracting 1
from 0.
Use narrow() to validate newly-introduced narrowing conversions.
Make llclamp() return the type of the raw input value, even if the types of
the boundary values differ.
std::ostream::tellp() no longer returns a value we can directly report as a
number. Cast to U64.
|
|
|
|
size_t conversions
|
|
conversions
|
|
|
|
llssize is for a function parameter that should accept a size or index
(derived from size_t, which is 64 bits in a 64-bit viewer) but might need to
go negative for flag values. We've historically used S32 for that purpose, but
Xcode 14.1 complains about trying to pass size_t to S32.
narrow() is a template function that casts a wider type (e.g. size_t or
llssize) to a narrower type (e.g. S32 or U32), with validation in
RelWithDebInfo builds. It verifies (using assert()) that the value being
truncated can in fact fit into the target type.
|
|
|
|
It's a little distressing how often we have historically coded S32 or U32 to
pass a length or index.
There are more such assumptions in other viewer subdirectories, but this is a
start.
|
|
DRTVWR-570-maint-Q
|
|
creating an empty LLSDMap type.
|
|
|
|
|
|
|
|
In theory it is fine to do that, in practice it does break gatekeeper in subtle ways
due to https://developer.apple.com/library/archive/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG207
Having bugsplat linked to all executables results in executables with an embedded rpath that is invalid for Gatekeeper. Luckily
it shows this is in the worst possible way. The viewer cannot be started with a non helpful message of teh viewer being unable to
verified. While at the same time spctl and codesign both show no errors at all.
|
|
# Conflicts:
# indra/newview/llfloaterpreference.cpp
# indra/newview/llviewercontrol.cpp
|
|
# Conflicts:
# indra/newview/llnetmap.cpp
# indra/newview/llnetmap.h
|
|
|
|
This partially reverts commit 935c1362a222f192bf913270d01f6c31c16e175b.
Reporting seems to have stoped working, trying the same way mac works.
|
|
|
|
|
|
|
|
|
|
DRTVWR-568_cmake
|
|
|
|
|
|
# Conflicts:
# indra/newview/llmodelpreview.h
|
|
|
|
|
|
|
|
Always search for python3[.exe] instead of plain 'python'. macOS Monterey no
longer bundles Python 2 at all.
Explicitly make PYTHON_EXECUTABLE a cached value so if the user edits it in
CMakeCache.txt, it won't be overwritten by indra/cmake/Python.cmake.
Do NOT set DYLD_LIBRARY_PATH for test executables! That has Bad Effects, as
discussed in https://stackoverflow.com/q/73418423/5533635. Instead, create
symlinks from build-mumble/sharedlibs/Resources -> Release/Resources and from
build-mumble/test/Resources -> ../sharedlibs/Release/Resources. For test
executables in sharedlibs/RelWithDebInfo and test/RelWithDebInfo, this
supports our dylibs' baked-in load path @executable_path/../Resources. That
load path assumes running in a standard app bundle (which the viewer in fact
does), but we've been avoiding creating an app bundle for every test program.
These symlinks allow us to continue doing that while avoiding
DYLD_LIBRARY_PATH.
Add indra/llcommon/apply.h. The LL::apply() function and its wrapper macro
VAPPLY were very useful in diagnosing the problem.
Tweak llleap_test.cpp. This source was modified extensively for diagnostic
purposes; these are the small improvements that remain.
|
|
This anticipates C++17's std::apply(), and in fact once we detect C++17, we'll
just use that. But in C++14 we must still provide our own implementation.
(cherry picked from commit dc2e2cd76f387ea6e80787fb94adcbc269cd1f25)
|
|
|
|
According to bugsplat get_thread_recorder was null
Replaced apr based LLThreadLocalPointer with thread_local
|
|
elision [-Werror=pessimizing-move]
|
|
|
|
# Conflicts:
# doc/contributions.txt
# indra/newview/llviewercontrol.cpp
|
|
|
|
|
|
One important factor in the design of LazyEventAPI was the desire to allow
LLLeapListener to query metadata for an LLEventAPI even if it hasn't yet been
instantiated by LazyEventAPI. That's why LazyEventAPI requires the same
metadata required by a classic LLEventAPI.
Instead of just publicly exposing its data members, give LazyEventAPI a query
API mimicking LLEventAPI / LLEventDispatcher. Protect data members and private
methods.
Adapt lazyeventapi_test.cpp accordingly.
Extend LLLeapListener::getAPIs() and getAPI() to look through LazyEventAPIBase
instances after first checking existing LLEventAPI instances. Because the
query API for LazyEventAPIBase mimics LLEventAPI's, extract getAPI()'s actual
metadata reporting to a new internal template function reportAPI().
While we're touching LLLeapListener, we no longer need BOOST_FOREACH().
|
|
|
|
|
|
A classic LLEventAPI subclass calls LLEventDispatcher::add() methods in its
own constructor. At that point, addMethod() can reliably dynamic_cast its
'this' pointer to the new subclass.
But because of the way LazyEventAPI queues up add() calls, they're invoked in
the (new) LLEventAPI constructor itself. The subclass constructor body hasn't
even started running, and LLEventDispatcher::addMethod()'s dynamic_cast to the
LLEventAPI subclass returns nullptr. addMethod() claims the new subclass isn't
derived from LLEventDispatcher, which is confusing since it is.
It works to change addMethod()'s dynamic_cast to static_cast.
Flesh out lazyeventapi_test.cpp. post() maps with "op" keys to actually try to
engage the registered operation. Give the operation an observable side effect;
use ensure_mumble() to verify. Also verify that LazyEventAPI has captured the
subject LLEventAPI's metadata in a way we can retrieve.
|