The next NDK to take these headers only supports API 21 and later.
Note that this change leaves the _implementation_ of these functions
behind, so that any old apps calling these APIs should continue to work,
you just can't (without declaring the functions yourself) write new ones
that do (and declaring the functions yourself would only work on LP32
anyway, so that's not going to get you very far in 2023).
Test: treehugger
Change-Id: Ie03514e4215b40f6e9feaa6e4bf5df5b16dc8d59
The next NDK to take these headers only supports API 21 and later, but
even if it didn't --- there is no inline!
Test: treehugger
Change-Id: Ibb194e1cbf0a8551bff863d940d92c35ed06a1e1
The next NDK to take these headers only supports API 21 and later, so
clean up some of the trivial cruft.
Test: treehugger
Change-Id: Ib735a776d244cc82858f2ed629dd63a54dbaf650
The next NDK to take these headers only supports API 21 and later, so
clean up some of the trivial cruft.
This doesn't include the remaining "legacy inlines", since they're a bit
more complicated. I'll remove those in later changes.
Test: treehugger
Change-Id: I94c32f6393dd3ae831165917303ea591222baa0d
API level 19 is no longer supported by the NDK.
While I'm here, let's remove the duplicated structure defintion (as
we've already done for `struct stat`).
Test: treehugger
Change-Id: I9d8286f9e7ba803f3131b6dcb0486ff1b0f9d5d1
These cause great confusion, so explicitly point out that apps can't use
one, and probably want the other.
Bug: https://github.com/android/ndk/issues/1255
Test: N/A
Change-Id: I287e820dc45a8446e3c72c9a2e4007db76828e3b
In some cases, the nullability of the pointer argument is too
complicated. Developers have better check relevant manuals or
code before annotating.
Bugs: b/245972273
Test: None
Change-Id: I3589a5080b267d1766cc8ed99868129ac16e4012
We don't need this (any more than arm64 does), because riscv64 is too
new to have had a too-small sigset_t, but it's useful for source code
compatibility with code that needs to build on arm32/x86 too.
Test: treehugger
Change-Id: Ied5f64d9094bc7d31c059f82f9e4ffe9b8ca4061
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Signed-off-by: Xia Lifang <lifang_xia@linux.alibaba.com>
Signed-off-by: Chen Guoyin <chenguoyin.cgy@linux.alibaba.com>
Signed-off-by: Wang Chen <wangchen20@iscas.ac.cn>
Signed-off-by: Lu Xufan <luxufan@iscas.ac.cn>
Test: m
Change-Id: I02cf117f67bda74516e4de8cd6f4c05efdb9a85b
Actually, we don't want to reuse the kernel struct ucontext because its
uc_mcontext has the wrong type, which means the fields within that end
up with the wrong names. Add the call site that made that evident, and
update <sys/ucontext.h> appropriately.
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Signed-off-by: Xia Lifang <lifang_xia@linux.alibaba.com>
Signed-off-by: Chen Guoyin <chenguoyin.cgy@linux.alibaba.com>
Signed-off-by: Wang Chen <wangchen20@iscas.ac.cn>
Signed-off-by: Lu Xufan <luxufan@iscas.ac.cn>
Test: treehugger
Change-Id: If1d079afef0d5953aa22d9b0e049cfb0119c7718
Empty, at least for now. The other libcs seem not to have invented types
here, so let's see whether there's really a call for them before we do.
Test: treehugger
Change-Id: Icbace2c02abc011388edc8e3e238bb64c640feb7
In particular, it contains all the riscv64 definitions we need, and lets
us clear up a lot of our existing ELF headers.
The other two BSDs seem to have errors and/or gaps in their riscv64
constants.
Test: treehugger
Change-Id: I92e48ef56c52c271ff6ed341b82169aa91f11d98
(And all other new architectures.)
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Signed-off-by: Xia Lifang <lifang_xia@linux.alibaba.com>
Signed-off-by: Chen Guoyin <chenguoyin.cgy@linux.alibaba.com>
Signed-off-by: Wang Chen <wangchen20@iscas.ac.cn>
Signed-off-by: Lu Xufan <luxufan@iscas.ac.cn>
Test: treehugger
Change-Id: Iceb2dd16c738302624980179788c4a2e68b797ed
In particular, explain why we don't have process_mremove(), and why
adding this was probably a mistake (lest it be used as precedent for
similar bad decisions in future).
Also add the missing __INTRODUCED_IN().
Test: treehugger
Change-Id: Ic2d7ef32f6e288353b5be2bffd000ad2f501bf39
At the time I added <stdio_ext.h>, I just added what was on the man
page (which matched glibc), not realizing that musl and glibc had
slightly different functionality in their headers.
The toybox maintainer came up with a legitimate use case for this, for
which there is no portable workaround, so I'm adding it here. I'm not
adding the other functions that are in musl but not glibc for lack of a
motivating use case.
Bug: http://lists.landley.net/htdig.cgi/toybox-landley.net/2022-April/020864.html
Test: treehugger
Change-Id: I073baa86ff0271064d4e2f20a584d38787ead6b0
setjmp() and _setjmp() were already correct, but we'd missed
sigsetjmp(). Found while investigating a toybox timeout(1) failure on
macOS, which doesn't annotate _any_ of these functions.
Also add all the missing doc comments while I'm here.
Test: treehugger
Change-Id: I69dc2587d140916d172237173c2bd56547a4ed8a
Kernel headers coming from:
Git: https://android.googlesource.com/kernel/common/
Branch: android-mainline
Tag: android-mainline-5.18
The file bionic/libc/kernel/uapi/linux/android/binder.h had a bug
in the original 5.18 kernel headers. This was fixed upstream, so
add a comment to the structure but leave the incorrect field the
same as the 5.17 kernel headers.
Bug: 234125620
Test: Builds.
Test: All bionic unit tests pass on a coral device.
Test: Able to log in to wembley system.
Change-Id: Ia72cafbe71fd894c599e15aa5334d7bbcbe74778
See:
https://man7.org/linux/man-pages/man2/close_range.2.html
Note: 'man close_range' documents 'flags' as unsigned int,
while glibc unistd.h as just 'int'. Picking 'int' to match glibc,
though it probably doesn't matter.
BYPASS_INCLUSIVE_LANGUAGE_REASON=man is a cli command
Test: TreeHugger
Bug: 229913920
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I1e2d1c8edc2ea28922d60f3ce3e534a784622cd1
This new posix_spawn attribute flag marks all file descriptors
(except stdin/out/err) as close-on-exec before executing any user
registered file actions (posix_spawn_file_actions_addopen/adddup2).
Test: TreeHugger
Bug: 229913920
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: If458100d6a253a9b0348d4e93a9a610225f89615
Clang has its own limits.h which is ahead of ours on the inclusion
path. This header uses include_next to include our header, but only
in hosted mode. This means that in freestanding mode we don't get our
limits.h macro definitions, including LONG_BIT. This ends up causing
our signal.h to produce errors when included in freestanding mode on
32-bit platforms.
Fix the errors by replacing usage of LONG_BIT with (8 * sizeof(long))
in the signal headers.
Change-Id: I18ec7b6876d5f862beae09f0c011128eef97c869
Kernel headers coming from:
Git: https://android.googlesource.com/kernel/common/
Branch: android-mainline
Tag: android-mainline-5.17
Test: Boots on a flame and all bionic unit tests pass.
Change-Id: I7057d7308241f3acfa600597d287994c39ababbc
Bug: http://b/197147102
versioner in aosp/1997532 is built with clang-r445002 and understands
the new attribute.
Test: mmma bionic
Change-Id: Ia3e3c3840e6013446d2679587b72011aff8c50eb
Bug: http://b/197147102
Bug: http://b/214080353
With https://reviews.llvm.org/D77491, clang got stricter when issuing
diagnostics regarding builtin functions.
https://reviews.llvm.org/D112024 adds a diagnose_as_builtin attribute
which lets it diagnose builtins even though their signature is slightly
different. This patch adds diagnose_as_builtin attribute as needed.
Versioner is built with an older clang so it doesn't recognize this
attribute. So this is added with a preprocessor check on clang
versions. We can remove the version check once versioner gets updated
shortly after the compiler update.
Test: mmma bionic/tests with clang-r445002
Change-Id: I3d0d63ecdbea0cffe97eb5110e2d9f2a7595a38e
This was pretty broken. I think anything using this was being given
always-available annotations for everything but 32-bit x86? Treehugger
should complain loudly if this was actually impacting anything though.
I suspect not since the only user of this mode is mainline which
doesn't target far back enough to have arch-specific introduction
guards.
Test: treehugger
Bug: None
Change-Id: I64e96a89d83e64512e661e88915c48a091198992
Definitions for these are provided in libandroid_support for API
levels that do not expose this in the stubs. For the rare cases where
libandroid_support is not being used this will result in a lower
quality diagnostic (undefined reference instead of "not available
until API 21"), but other fixes would also have that behavior because
the libandroid_support headers are *always* available, even if
libandroid_support won't be linked.
Test: Reverted xfailed tests for #1108 and reran tests with this
Bug: https://github.com/android/ndk/issues/1108
Change-Id: I371f5b9d7caeef8dc7c80f2f6d11280ecba119c9
Mbstowcs and wcstombs cannot get correct return value when called in the environment below api 21, and need to raise the API level to solve the problem.
Test: None
fix bug 1108 https://github.com/android/ndk/issues/1108
Change-Id: Iabcf1bff0be087288646687732ef68870630b48a
They're in glibc, though not in musl.
Also add basic doc comments to the whole of <sys/uio.h>.
Bug: http://b/203002492
Test: treehugger
Change-Id: Ic607f7f349e5b7c9bf66c25b7bd68f827da530d6
Bionic currently renames the kernel's __kernel_sockaddr_storage
to sockaddr_storage. We would like to reuse the bionic kernel
headers for musl, but musl defines its own sockaddr_storage,
causing redefinition errors when the musl and kernel headers
are both included.
Give bionic its own definition of sockaddr_storage so the kernel
one can be left as __kernel_sockaddr_storage, avoiding the
conflict in musl.
Some of the structs in netinet/in.h contain sockaddr_storage members.
There are definitions in linux/in.h, but they now use the
__kernel_sockaddr_storage naming. To avoid having to copy the structs
from linux/in.h into netinet/in.h, add some #define hackery to
rename __kernel_sockaddr_storage to sockaddr_storage when including
linux/in.h from netinet/in.h.
Bug: 190084016
Test: m checkbuild
Test: bionic-unit-tests
Change-Id: I8f654511722b3a4a8e0bb146e4418ebcd370305c
Otherwise, since it's `noreturn`, clang will merge multiple call sites
in the same function, destroying information that helps you debug
_which_ call fired from a tombstone.
Bug: https://github.com/android/ndk/issues/1514
Test: treehugger
Change-Id: I7930318a813f6a2220266794f16c0e5e72d32869
FORTIFY'ed functions try to be as close to possible as 'invisible';
having stack protectors detracts from that.
Don't apply this to functions which clang has no chance of inlining
anyway (like variadic functions)
Bug: 182948263
Test: TreeHugger
Change-Id: I08cfec25464b8ea1e070942e3dc76fc84da73dd0
Kernel headers coming from:
Git: https://android.googlesource.com/kernel/common/
Branch: android-mainline
Tag: android-mainline-5.11
Test: Built cuttlefish and flame images. Ran bionic unit tests on both.
Change-Id: Ie60337aafad4bda55af99b6c8fe9f56bf2fa787f
libc++ still depends on these being declared even if they are
unavailable. This results in a worse error message (a link error
rather than a compiler diagnostic) if these functions end up being
used, but without the decl headers like libc++'s math.h can't be
included because it refers to an undeclared function.
For the cases where weak symbols aren't being used, don't annotate
these functions with their availability information.
Also need to avoid using __builtin_available for this case because the
NDK doesn't have __isOSVersionAtLeast yet.
__ANDROID_UNGUARDED_AVAILABILITY__ is being used as a proxy for
"building for the NDK" here because we don't have a good signal for
that which works for both the NDK proper and the NDK-in-the-platform
case.
Test: imported into the NDK, built and tested NDK
Bug: None
Change-Id: I9ef3e19a8fa083bca0be47b80dfef7ba52a94866
Introduces new heap-zero-init API. We've realised that it's better to be
able to individually control MTE and heap zero-init. Having
heap-zero-init not be controllable without affecting MTE affects our
ability to turn off heap-zero-init in zygote-forked applications.
Bug: 135772972
Test: On FVP: atest -s localhost:5555 malloc#zero_init \
Test: malloc#disable_mte heap_tagging_level
Change-Id: I8c6722502733259934c699f4f1269eaf1641a09f
* changes:
crtbegin_static is built with min_sdk_version: "current"
Guard __libc_current_sigrtmin/max with __builtin_available
__INTRODUCED_IN macros add the availability attribute
The two APIs were added for the API level 21 and beyond. Currently, its
existence is tested using the null check which is done regardless of the
min sdk version of the compilation unit. (which in turn required us to
mark the API symbol weak regardless of the min sdk version.)
Now, we have a better way of testing the API availability;
__builtin_available. The null check is replaced with the call to the
compiler-provided macro which determines if the code is running in a
version of OS where the API is known to exist.
Bug: 150860940
Bug: 134795810
Test: m
Change-Id: Ib96c78f8d3cc71d7e755d1eab86051517bbbcc44
__INTRODUCED_IN (and its variants) macro is used to mark the
availability of an API symbol. The macros were used by the versioner
tool for the NDK clients. When the Bionic headers are processed by the
tool, APIs with the macros are guarded with __ANDROID_API__. e.g.,
void foo() __INTRDUCED_IN(30);
is processed into
\#if __ANDROID_API__ >= 30
void foo();
\#endif
by the versioner.
The macros however didn't play a role for other cases, e.g. OS
components.
This is too strict for NDK clients and too loose for the non-NDK
clients. For the former, this completely hides the APIs that are newer
than the min sdk version (__ANDROID_API__). For the latter, a call to
such an API can be made without being guarded.
This change is the first step towards a better way of handling the
native APIs availability. The plan is that every NDK APIs are annotated
with the availability attribute and callers are required to guard their
API calls with a runtime check if the API is newer than the min sdk
version of the caller.
In this change, the macros now emits the availability attribute for the
non-NDK clients (i.e. when not processed by versioner).
Bug: 163288375
Bug: 134795810
Test: m
Change-Id: I6eb2bce2bc2770cbfd69815e6816b6f25b3d6127
These were only available internally via android_mallopt(), but they're
likely to be needed by more code in future, so move them into mallopt().
This change leaves the android_mallopt() options for now, but I plan on
coming back to remove them after I've switched the handful of callers
over to mallopt() instead.
Bug: http://b/135772972
Test: treehugger
Change-Id: Ia154614069a7623c6aca85975a91e6a156f04759
Kernel headers coming from:
Git: https://android.googlesource.com/kernel/common/
Branch: android-mainline
Tag: android-mainline-5.10
Test: Built cuttlefish and flame images. Ran bionic unit tests on both.
Change-Id: I37ffc850970adcce1febbe2269c202632fce763a
They're both obsolescent in POSIX.1-2008, and you really shouldn't be
using them, but since we can't actually delete them...
This change makes them both obey $TMPDIR if set, and fall back to
/data/local/tmp otherwise. That's as good as we've managed for anything
else such as tmpfile(3).
Also add some tests.
Bug: http://b/174682340
Test: treehugger
Change-Id: Ieef99dcc2062f84b2b7cbae046787fdfe975e772
This patch adds support to load BTI-enabled objects.
According to the ABI, BTI is recorded in the .note.gnu.property section.
The new parser evaluates the property section, if exists.
It searches for .note section with NT_GNU_PROPERTY_TYPE_0.
Once found it tries to find GNU_PROPERTY_AARCH64_FEATURE_1_AND.
The results are cached.
The main change in linker is when protection of loaded ranges gets
applied. When BTI is requested and the platform also supports it
the prot flags have to be amended with PROT_BTI for executable ranges.
Failing to add PROT_BTI flag would disable BTI protection.
Moreover, adding the new PROT flag for shared objects without BTI
compatibility would break applications.
Kernel does not add PROT_BTI to a loaded ELF which has interpreter.
Linker handles this case too.
Test: 1. Flame boots
2. Tested on FVP with BTI enabled
Change-Id: Iafdf223b74c6e75d9f17ca90500e6fe42c4c1218
It was originally based on fdlibm, but it's been through two different
projects since then, and `git blame` shows basically nothing remaining
from those days. Seems worth leaving something to explain the unusual
copyright header though!
Test: treehugger
Change-Id: I8e7252a755704b866e7f36c8e97adc021fa3cdad
Except they are the same on arm32/arm64, so we hadn't really noticed. x86
and x86-64 are quite different though, presumably by historical accident.
Fix the definitions and add some static asserts.
Bug: https://github.com/android/ndk/issues/1347
Test: treehugger
Change-Id: Ic27b172066cf3443749463b9b73c912d204f9516
We don't list most of bionic on dac since it would be overwhelming for
the current layout, but this file in particular seems useful,
especially __ANDROID_API__. Unfortunately, c2devsite doesn't include
macro documentation. Until then, it's still useful to include the
functions defined in this header.
I've also elaborated a bit in the __ANDROID_API__ documentation, since
the existing phrasing led to confusion over whether it was closer to
minSdkVersion or compileSdkVersion. In practice these are identical
for the NDK, but if we switch to weakly-linked APIs via the
availability attribute that would change.
Test: built docs, looked at them
Bug: None
Change-Id: I5cf78a6143b5c15790c369bdf888611e4c1189db
(Based on proposal at https://sourceware.org/glibc/wiki/ThreadPropertiesAPI)
This includes API to:
- locate static and dynamic TLS
- register thread-exit and dynamic TLS creation/destruction callbacks
Change-Id: Icd9d29a5b2f47495395645e19d3b2c96826f19c8
Now we're being marked down for our poor coverage, we may as well remove
more broken cruft. Despite the amount of effort that seems to have gone
into pututline(), it wasn't working with the other utmp.h functions (in
particular, utmpname()), and wasn't declared in the header file!
Test: treehugger
Change-Id: I1a583984189c751168c11c01431433f96f8c548b
This was initially just to try on "pty" and "tty" for size, while
discussing with other projects to try to align on vocabulary, but -- in
the implemention and tests at least -- but these work out so well that
I'm tempted to go with them anyway if we can't come to a concensus. We
can always come back and change them again later.
What I really like is that you pass the pty to functions like ptsname()
and grantpt() with a 'p' in the name, and the tty to functions like
ttyname() and tcsetattr() with just 't's.
The use of "parent" and "child" in forkpty() seems helpful too.
Also fix the documentation of forkpty(), which wasn't quite right.
Test: treehugger
Change-Id: Ic010c4b669f6528591c653e3701f4e41e0d0df9e
1) "fix the system properties design" is written for the old protocol,
so we've already changed the design. There are no other further
planned changes.
2) "don't drag in all the macros, just the types." is not likely to
happen or be particularly impactful.
3) "Find a location suitable for these functions ..." is refering to
legacy code. More likely that this code will be removed before we
find a serious reason to fix this TODO.
4) "(73062966) We still don't have a good way ..." is stale; we fixed
this bug and added the appropriate mechanism.
Test: n/a
Change-Id: I23991692cdeb81ad00844a6a1680900ff384208b
Kernel headers coming from:
Git: https://android.googlesource.com/kernel/common/
Branch: android-mainline
Tag: android-mainline-5.6
Add a new method for removing structures. This is to deal with the kernel
headers changing some definitions of timeval to __kernel_old_timeval
and itimerval to __kernel_old_itimerval. Remove the __kernel_old_XX
strutures and change the other structures to the previous definitions.
This only works so long as these structures stay the same, if they
diverge, then a different strategy will need to be implemented.
Test: Booted cuttlefish/walleye.
Test: Ran bionic-unit-tests on cuttlefish/walleye.
Change-Id: I0a61f4fa6e4155c602e0414d9b38c2e1637829af
This was a side-effect of something else I was doing. May as well check
this in now though.
Test: treehugger
Change-Id: Ibe8a3640d309c1980fa6e8ef003d4f255384c9e7
POSIX added these GNU extensions for issue 8.
I've made these always inline without the usual "until API level X"
proviso because they're single instructions that the compiler can inline
and there's really no point providing these if they add function call
overhead --- everyone should just use __builtin_ffs() and friends
instead in that case.
Bug: https://austingroupbugs.net/view.php?id=617
Test: treehugger
Change-Id: I33fc4b8648ea25917329e81c1b4c60eb9a66d667
LLVM now knows how to fold __strlen_chk, so we can make this function a
one-liner.
Also fix strlcat to not double-return while I'm in the area.
Bug: 148189733
Test: TreeHugger
Change-Id: I71ee308defbefe96f3fe6e357a2127309d2f0942
I had hoped that this would then let us remove more of the "introduced
in" annotations, but it looks like that's not really going to happen
until the NDK's minimum supported API is 21.
Also remove a .c file that wasn't referenced anywhere.
Test: treehugger
Change-Id: I8b4a61c082293f8445195a4fa5ee30595d70444e
We've optimized the ctype functions to the point where they're pretty
much all down to one instruction. This change takes the obvious next
step of just inlining them.
On Android these function have only ever been for ASCII. You need the
<wctype.h> functions for non-ASCII.
libc++ currently has its own inlines for the _l variants, so if we want
to just inline them in bionic directly, we'll need to coordinate that.
Bug: http://b/144165498
Test: treehugger plus benchmarks
Change-Id: I4cc8aa96f7994ae710a562cfc9d4f220ab7babd6
Over the last year, LLVM apparently learned how to optimize many
FORTIFY'ed functions. I went through the list of functions it optimizes,
and simplified their implementations here.
This is more than a code health thing; __bos_trivially_ge expands to a
branch that's not eliminated until after inlining, so it can actually
cause some functions (like one of std::string's ctors) to become
uninlineable.
Bug: 148189733
Test: hand-checked the IR we get for each of the changed functions. Many
get optimized to their non-_chk variant when appropriate. Others
will get optimized to non-_chk versions when bos == -1. Bug repro
also now shows all 'inline's.
Change-Id: Ic360818ad9daaeda3958e1282af41087f85122a3
If we remove the mips uapi headers, versioner fails because it assumes
they're available. We'll need a new versioner prebuilt beforre we can
remove the libc/versioner-dependencies/mips* symlinks.
Test: treehugger
Change-Id: Ife6df0cb57938f806a31ec334d648df9694c3d17
Many of our header files are very sensitive to the order in which
their #includes appear...
Bug: N/A
Test: N/A
Change-Id: I2c21cac5e9bd49b7e80620d14971af8fefa17e91
On Android, fcntl is always implemented by fcntl64(2). This means that
an LP32 binary can `fcntl(F_SETLK, struct flock)` (because fcntl64(2)
passes through to the 32-bit fcntl(2) to handle F_SETLK), and it can
also `fcntl(F_SETLK64, struct flock64)`. What it can't do before this
patch is set _FILE_OFFSET_BITS=64 and then `fcntl(F_SETLK, struct
flock)` where that `struct flock` is actually implicitly `struct
flock64`.
Move the kernel uapi structs out of the way, define them ourselves based
on __LP64__ and _FILE_OFFSET_BITS, and fix up the relevant F_ constants.
(Also add a .clang-format to turn off clang-format in libc/include/.)
Bug: N/A
Test: treehugger (and strace!)
Change-Id: Iccd6c83d9133e1efcf93a7b49a6ae0f1bbd3d58b
Until now we've only supported RELR with our own OS-private-use
constants. Add support for the official numbers (while maintaining
support for the historical numbers).
Add tests to ensure we continue to support both indefinitely.
We can't yet flip the build system over to using the official constants
because the old GNU binutils objcopy we still use in most cases (for the
mini-debug section) only supports the historical constants.
Bug: http://b/147452927
Test: treehugger
Change-Id: If214fce7fade4316115947e90b78ab40864b61f2
/system_ext/bin has executable binaries. They must be in the shell
search path.
Bug: 134909174
Bug: 134359158
Test: check PATH in the adb shell
Change-Id: I997a2347fa85c444f2e335bede0d63b7703ba001
This commit adds `__VERSIONER_FORTIFY_INLINE` to fortify overload
functions. Fortified functions are always overloaded and are likely to
be different from `libc.map.txt`.
Bug: 118991081
Test: source development/vndk/tools/header-checker/android/envsetup.sh && \
source build/envsetup.sh && \
lunch aosp_arm64-userdebug && \
m versioner && \
./bionic/tools/versioner/run_tests.py
Change-Id: I28903d0f039d74a07eb2833c754ff017335bac95
