Thanks Michael,
I hadn't considered there would be an essay in the commit, thanks for that - though it doesn't shed a lot of light on the situation

There seems to be 2 places that mark a Name using the high bit, and only one place that kinda-sorta reads it. 

The Name is 'marked' during populate() which seems to be to mark each name with a '*' and the high-bit, before going through and getting the current names for the processes - adding new ones and replacing the old ones without '*' and high-bit mark.  So items which are double marked are effectively stale/historic.

It is also 'marked' during the find call .. which basically marks the 'found' name if it was not found and then constructed.  The does not appear to be any purpose to this that I can ascertain.

The one place (afaict) it reads the value is in zero() below - the problem is that it looks at the entire top uint32 rather than just that high byte!!   It's hard to work out whether this is just a long-standing bug or whether it is weeding out names > 12 characters as well from being removed.
So this seems to remove an item from the map, but only if it isn't marked (or long) ie if it isn't stale - or been 'seen' I guess?

    bool zero(TaskHandle_t taskid)
      {
      for (int i = 0; i < count; ++i)
        {
        if (map[i].id == taskid)
          {
          if (map[i].name.words[NAMELEN/4-1] > 0)

            return false;
          for (++i ; i < count; ++i)
            {
            map[i-1] = map[i];
            }
          --count;
          return true;
          }
        }
      return false;
      }

Does this help? Any thoughts on what this was meant to do ? I've CCd Stephen with a hope he might chip in?
 
//.


On Wed, 24 Jan 2024 at 15:09, Michael Balzer <dexter@expeedo.de> wrote:
Michael,

Am 21.01.24 um 02:54 schrieb Michael Geddes:
Hey, In working trying to get ESP-IDF 5+ Working, I came across the following fun thing that I'm trying to work out what is going on!! 
This is from main/ovms_module.cpp
I'm not sure why we don't just go through all the words and compare - why the masked compare for the last entry! And why that value?? It might make sense if you masked out the final byte ... I'm just struggling to understand.

From the further accesses to the last word/byte in TaskMap, I'd guess Steve intended using the sign bit on the last byte as some special indicator, but it's not clear to me for what purpose. It also doesn't seem to be relevant anymore.

Steve's commit message is verbose (30d0a403a380e797f9b222b01dab8da791ab388c), and maybe you can find some more explanation in the list archives.

Regards,
Michael

Why am I looking at it?? Well there's a new warning about copy constructors.. and then I ran into a problem where 'Name' is sometimes in memory that can only be accessed 32bit int aligned (which is why the strange implementation in the first place - I get that).

Can anybody shed any light on this?


class Name
  {.......
   inline bool operator==(const Name& a) const
      {
      for (int i = 0; i < NAMELEN/4 - 1; ++i)
        if (a.words[i] != words[i]) return false;
      if (a.words[NAMELEN/4-1] != (words[NAMELEN/4-1] &  0x7FFFFFFF)) return false;
      return true;
      }

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev