Actually the first snippet looks a bit dodgy to me. Why initialize one pointer and not the other? It almost looks like someone just wanted to make his patch look a bit more substantial than it really is.
On Tue, 25 Feb 2025 at 17:45, tom ehlert via Freedos-devel <freedos-devel@lists.sourceforge.net> wrote: > > Hi, > > > Recently, ECM submitted a pair updates to the MEM command "fix search_sd > > returning an uninitialised pointer if empty SD MCB” > > and “fix search_sd omitting last SD sub-MCB if it is empty” the FreeDOS > > GitLab Archive. [1] > > > As far as I know, there is no upstream project for the MEM command. > > > I have no doubt the patches are correct and have merged them into a new > > “unstable” branch in the project sources. [2] > > > However like all base programs, the changes should still be verified. > > > I avoid using C when possible. I much prefer Assembly and Pascal. :-) > > > The commit comments make a note that are still some remaining issues and > > another patch may be needed. > > > Eventually, I will also need someone to provide a version bump and compiled > > binary for the updated version. > > > Thanks, > > > Jerome > > > [1] https://gitlab.com/FreeDOS/base/mem/-/merge_requests/1 > > <https://gitlab.com/FreeDOS/base/mem/-/merge_requests/1> > > [2] https://gitlab.com/FreeDOS/base/mem/-/tree/unstable?ref_type=heads > > <https://gitlab.com/FreeDOS/base/mem/-/tree/unstable?ref_type=heads> > > "On current lDOS, loading things into the HMA or UMA makes it so > that only the DOS-internal UPBs and DPBs are allocated within > the Low Memory Area MCB chain. (BIOCODE and DOSDATA are in front > of the first MCB.) They already use lDOS style S MCBs however. > Therefore, the devmark / SD MCB allocated in the LMA is empty." > > "On current lDOS": Whatever lDOS is, it's most likely not a FreeDOS kernel > issue. > and whatever UPBs and DPBs and lDOS style S MCBs are: can't be that > important. > > > - MINFO *first_child, *mlist; > + MINFO *first_child = NULL, *mlist; > can never be wrong. > > - end=parent->seg + parent->size; > + end=parent->seg + parent->size + 1; > > so what. might be wrong, but then only the wrong size reported. > should be not important. > > Tom > > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
