Andy, I'm a reasonable C/C++ programmer as well. I'd be willing to be a hunting partner if you want to go bug hunting together. Did you build on a fresh OS install?
Jared On Thu, Feb 10, 2022, 4:50 PM Andy Howell <a...@gamubaru.com> wrote: > > On 2/10/22 06:10, Steffen Möller wrote: > > > > On 10.02.22 07:28, Phill Carter wrote: > >> > >>> On 10 Feb 2022, at 4:14 pm, Andy Howell <a...@gamubaru.com> wrote: > >>> > >>> > >>> On 2/9/22 14:46, andy pugh wrote: > >>>> On Wed, 9 Feb 2022 at 20:21, Andy Howell <a...@gamubaru.com> wrote: > >>>> > >>>>> My background is in c/c++ development under UNIX/Linux. I know bit of > >>>>> python. I don't have the experience to work on the low level > >>>>> internals. > >>>> How about this one? > >>>> https://github.com/LinuxCNC/linuxcnc/issues/1438 > >>>> > >>>> A text search on the pin name would find the right part of the code, > >>>> and would let you find where the associated internal variable is > >>>> updated. > >>>> > >>>> (This is internals, but with code to copy from) > >>> Thanks. That sounds like a good problem to start with. I will have a > >>> look at the code and comment under the issue. > >> I do have a PR ready to submit but I am happy to hold off. > > That sounds so nice and so wrong at the same time. I suggest to submit > > the PR and you have already found a reviewer. > > > > @Andy, I am currently on a mission to render the C/C++ sources > > cppcheck-clean. You see a few PRs on this already - and one issue that I > > could not solve with a quick patch that I think is a bug. I personally > > use this to get acquainted with the code base a bit more - have started > > with src/hal/* and src/emc/* and have just about completed that, I > > think. But there is more. > > > > Many thanks and greetings > > Steffen > > > Steffen, > > I could certainly work on that. I just compiled LinuxCNC for the first > time in a very long time. There were lots of compiler warnings, > particularly around strncpy and snprintf. I think those would be worth > looking into. It would be nice to fix the code to remove the warnings, > or turn warnings off where needed when they are clearly a false > positive. For example, > > hal/user_comps/mb2hal/mb2hal_init.c:187:55: warning: ‘%02d’ directive > output may be truncated writing between 2 and 10 bytes into a region of > size 7 [-Wformat-truncation=] > 187 | snprintf(section, sizeof(section)-1, "TRANSACTION_%02d", > mb_tx_num); > | ^~~~ > hal/user_comps/mb2hal/mb2hal_init.c:187:42: note: directive argument in > the range [0, 2147483647] > 187 | snprintf(section, sizeof(section)-1, "TRANSACTION_%02d", > mb_tx_num); > | ^~~~~~~~~~~~~~~~~~ > > The local 'section' buffer there is 20 bytes. Although it might never be > an issue in practice, increasing the buffer size will make sure it never > is and remove the warning. Maybe we can get to a point where we can > treat warnings as errors. > > Does that sound worth pursuing? > > > > > _______________________________________________ > > 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 > _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers