[C++ification] Take care of a few warnings and don't use LTO #3873
Conversation
Desktop compilers mis-detect memory allocation size in our bundled property
code if fortified version of `strncpy` is used (even though the size
calculation is correct). Use `memcpy` instead.
LTO doesn't appear to be ready for use just yet. It gives warnings similar to
these:
jni-wrappers.hh(143,41): warning GD616DC71: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807
util.cc(75,8): warning GA5933D32: ‘MEM[(struct timing_point *)&partial_time].ns’ may be used uninitialized in this function [-Wmaybe-uninitialized]
Which, even though well-intentioned (and, technically, correct) are irrelevant
in our case and the compiler+linker diagnostics fail to understand the intention
and usage of the code.
Additionally, fix a few instances where type conversion is different for
different platforms/targets.
| @@ -192,8 +192,8 @@ AndroidSystem::_monodroid__system_property_get (const char *name, char *sp_value | |||
| // ../../../jni/android-system.cc(206,10): warning G20816D19: ‘char* strncpy(char*, const char*, size_t)’ specified bound 93 equals destination size [-Wstringop-truncation] [/home/grendel/vc/xamarin/xamarin-android-worktrees/code-quality-improvements/src/monodroid/monodroid.csproj] | |||
| // strncpy (sp_value, env_value, sp_value_len); | |||
| // | |||
| strncpy (sp_value, env_value, sp_value_len - 1); | |||
| sp_value[sp_value_len] = '\0'; | |||
| strncpy (sp_value, env_value, sp_value_len - 2); | |||
There was a problem hiding this comment.
Given that we're using memcpy() elsewhere, should we just use memcpy() everywhere?
There was a problem hiding this comment.
I'd rather keep using the string functions for string types elsewhere. The size calculations here appear to confuse the compiler which warns about code that is actually valid (on targets which have fortified string manipulation functions, e.g. in desktop builds), so using memcpy was the easiest way to shut the compiler up here.
| @@ -124,7 +136,7 @@ namespace xamarin::android | |||
|
|
|||
| std::lock_guard<std::mutex> lock (sequence_lock); | |||
| if (sequence->dynamic) { | |||
| memset (sequence, 0, sizeof(*sequence)); | |||
| sequence->period.reset (); | |||
There was a problem hiding this comment.
This is odd...and I don't remember this coming up before... but why clear out period if it'll be invalidated on the next delete sequence line? Why is this done? (Same question applies to the original memset(), and I don't remember this being discussed previously with PR #3729.)
In principal, the delete sequence could (should?) "scribble" over *sequence so that if it's reused, it can be more readily detected in a debugger. We'd thus effectively have:
memset (sequence, 0, sizeof (*sequence);
memset (sequence, 0xbb, sizeof (*sequence); // or some other "`free` was here!" constantWhat's the memset()/period.reset() buy us?
There was a problem hiding this comment.
The reason clearing is done is that we don't control the IntPtr used to hold the sequence on the managed side. And clearing the sequence to 0 marks it as (sort of) "unused" should anything in the managed land reuse the pointer (which hopefully never happens). Doing the memset in our implementation of delete would unnecessarily slow things down.
There was a problem hiding this comment.
Doing the
memsetin our implementation ofdeletewould unnecessarily slow things down.
I wasn't advocating that our delete do that. I was just saying that many free()/operator delete() implementations do so.
Desktop compilers mis-detect memory allocation size in our bundled property code if a fortified version of **strncpy**(3) is used (even though the size calculation is correct). Use **memcpy**(3) instead. LTO doesn't appear to be ready for use just yet. It gives warnings similar to these: jni-wrappers.hh(143,41): warning GD616DC71: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807 util.cc(75,8): warning GA5933D32: ‘MEM[(struct timing_point *)&partial_time].ns’ may be used uninitialized in this function [-Wmaybe-uninitialized] Which, even though well-intentioned (and, technically, correct) are irrelevant in our case and the compiler+linker diagnostics fail to understand the intention and usage of the code. Additionally, fix a few instances where type conversion is different for different platforms/targets.
Desktop compilers mis-detect memory allocation size in our bundled property
code if fortified version of
strncpyis used (even though the sizecalculation is correct). Use
memcpyinstead.LTO doesn't appear to be ready for use just yet. It gives warnings similar to
these:
Which, even though well-intentioned (and, technically, correct) are irrelevant
in our case and the compiler+linker diagnostics fail to understand the intention
and usage of the code.
Additionally, fix a few instances where type conversion is different for
different platforms/targets.