xiaoxiang781216 commented on code in PR #1114:
URL:
https://github.com/apache/incubator-nuttx-apps/pull/1114#discussion_r842886367
##########
system/sched_note/note_main.c:
##########
@@ -83,6 +83,36 @@ static FAR const char *g_statenames[] =
* Private Functions
************************************************************************************/
+/************************************************************************************
+ * Name: trace_dump_unflatten
+
************************************************************************************/
+
+static void trace_dump_unflatten(FAR void *dst,
+ FAR uint8_t *src, size_t len)
+{
+ switch (len)
+ {
+#ifdef CONFIG_HAVE_LONG_LONG
+ case 8:
+ *(uint64_t *)dst = ((uint64_t)src[7] << 56)
+ + ((uint64_t)src[6] << 48)
+ + ((uint64_t)src[5] << 40)
+ + ((uint64_t)src[4] << 32);
+#endif
+ case 4:
+ *(uint32_t *)dst = ((uint64_t)src[3] << 24)
+ + ((uint64_t)src[2] << 16);
+ case 2:
+ *(uint16_t *)dst = ((uint64_t)src[1] << 8);
+ case 1:
+ *(uint8_t *)dst = src[0];
+ break;
Review Comment:
> @xiaoxiang781216 I think you misunderstood my comment. I sill point the
think more clear:
>
> 1. The merged code performs cast to `(uint64_t)` even if
`CONFIG_HAVE_LONG_LONG` is not set. I think this is wrong
Ok, I focus on "tmp and memcpy". For "((uint64_t)src[3] << 24)...", it's
better to change to "((uint32_t)src[3] << 24)..." @anchao .
> 2. In case of 8, 4 or 2 byte values we get a mess based on different
endianess at `dst` because `dst` is not update and `=` is used. For for example
of 4 byte value the `dst` byte 0, 1, 2 and 3 will be set to `0, 0, src[3],
src[4]` or to `src[4], src[3], 0, 0` and then due to fall-thru to `case 2:` and
`case 1:` the part will be overwritten by `src[1]` and `src[0]`. So this code
seems to be working on little-endian archs only.
If so, sched_note_flatten has the similar issue, @anchao please take a look.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
