I wrote the initial hal port code. there is no reason that I know of why it is required. I was following what I saw in other hal code without really knowing if it was needed.
Rip it out! If the tests pass it's probably fine. I run components daily that depends upon hal_port so I'll catch it (and help with fallout / fixing ) if something goes wrong. -Curt On Fri, Nov 29, 2024, 10:53 AM Bertho Stultiens <l...@vagrearg.org> wrote: > Hi, > > The C++20 standard has deprecated a lot of volatile use. Therefore, a > lot of warnings pop-up in the compile, especially in hal/hal.h: > warning: ‘volatile’-qualified parameter is deprecated [-Wvolatile] > in lines 869, 879, 890, 900, 905,910, 915, 921 > Same warning in hal/hal_priv.h:489. > > The warnings originate from the typedef of hal_port_t (an offset into > shared memory) in hal/hal.h:323: > typedef volatile int hal_port_t; > > The volatile modifier is used in the function prototypes' arguments, > which now emits the warning. > > > I do not understand /why/ volatile is used /at all/. The port, > apparently, always gets converted to a pointer using SHMPTR(), which > returns a *non-volatile* pointer-type. So there is no point in having > the argument declared volatile when all subsequent use drops the > modifier by forcefully having cast'ed it into something else. > > If there should be any use of volatile, then it would be the > pointer-deref type returned by SHMPTR() because that addresses shared > memory (which may be altered concurrently). But volatile isn't used for > the actual target address and I cannot see how declaring the pre-cast > variable as volatile can have any effect on a post-cast non-volatile > dereference. Therefore, in my opinion, it does not work as intended. > > I think it should be fixed by removing the volatile modifier from the > typedefs (hal/hal.h:318-323). Then the casts into shared memory should > add the volatile modifier so that reads and writes to shared memory are > performed when the code says it should be (non-cache'able in the program). > > > Any thoughts or insights from hal code veterans? > > > -- > Greetings Bertho > > (disclaimers are disclaimed) > > > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
