[Ovmsdev] Working on ESP-IDF5 + Have a question about ovms_module 'Name'

[Michael Geddes]

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 at 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;
>       i*f (a.words[NAMELEN/4-1] != (words[NAMELEN/4-1] &  0x7FFFFFFF))
> return false;*
>       return true;
>       }
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://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 at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20240126/5ca8f078/attachment.htm>