| Message ID | 8963c6fa625bbaf5153990939ea06742304ddcd2.1653351786.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 98cdb61cab6cff3df9fc6b48b99df61965a1588c |
| Headers | show |
| Series | ci: fix windows-build with GCC v12.x | expand |
On Tue, May 24 2022, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin <johannes.schindelin@gmx.de> > > GCC v12.x complains thusly: > > compat/nedmalloc/nedmalloc.c: In function 'DestroyCaches': > compat/nedmalloc/nedmalloc.c:326:12: error: the comparison will always > evaluate as 'true' for the address of 'caches' > will never be NULL [-Werror=address] > 326 | if(p->caches) > | ^ > compat/nedmalloc/nedmalloc.c:196:22: note: 'caches' declared here > 196 | threadcache *caches[THREADCACHEMAXCACHES]; > | ^~~~~~ > > ... and it is correct, of course. > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > --- > compat/nedmalloc/nedmalloc.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/compat/nedmalloc/nedmalloc.c b/compat/nedmalloc/nedmalloc.c > index edb438a7776..2c0ace7075a 100644 > --- a/compat/nedmalloc/nedmalloc.c > +++ b/compat/nedmalloc/nedmalloc.c > @@ -323,7 +323,6 @@ static NOINLINE void RemoveCacheEntries(nedpool *p, threadcache *tc, unsigned in > } > static void DestroyCaches(nedpool *p) THROWSPEC > { > - if(p->caches) > { > threadcache *tc; > int n; This seems sensible, I thought "why not submit it to upstream", i.e. see: https://github.com/ned14/nedmalloc/blob/master/nedmalloc.c#L1298 But that repository was last updated in 2014, I wonder if it's just because nobody's submitted a patch since then, or if it's inactive. Have you tried making Njall Douglas (the nedmalloc author) aware of this issue?
Am 24.05.22 um 10:00 schrieb Ævar Arnfjörð Bjarmason: > > This seems sensible, I thought "why not submit it to upstream", > i.e. see: > https://github.com/ned14/nedmalloc/blob/master/nedmalloc.c#L1298 > > But that repository was last updated in 2014, I wonder if it's just > because nobody's submitted a patch since then, or if it's inactive. Have > you tried making Njall Douglas (the nedmalloc author) aware of this > issue? > https://github.com/ned14/nedmalloc says at the top: "This repository has been archived by the owner. It is now read-only.". René
Hi René, On Tue, 24 May 2022, René Scharfe wrote: > Am 24.05.22 um 10:00 schrieb Ævar Arnfjörð Bjarmason: > > > > This seems sensible, I thought "why not submit it to upstream", > > i.e. see: > > https://github.com/ned14/nedmalloc/blob/master/nedmalloc.c#L1298 > > > > But that repository was last updated in 2014, I wonder if it's just > > because nobody's submitted a patch since then, or if it's inactive. Have > > you tried making Njall Douglas (the nedmalloc author) aware of this > > issue? > > > > https://github.com/ned14/nedmalloc says at the top: "This repository has > been archived by the owner. It is now read-only.". Indeed, maintenance of nedmalloc has stopped a few years ago (see e.g. https://github.com/ned14/nedmalloc/issues/20#issuecomment-343432314). About five years ago I tried to upgrade us to the latest nedmalloc version but ran into a performance regression that I was unable to justify the time to investigate further. Ciao, Dscho
On Tue, May 24 2022, Johannes Schindelin wrote: > Hi René, > > On Tue, 24 May 2022, René Scharfe wrote: > >> Am 24.05.22 um 10:00 schrieb Ævar Arnfjörð Bjarmason: >> > >> > This seems sensible, I thought "why not submit it to upstream", >> > i.e. see: >> > https://github.com/ned14/nedmalloc/blob/master/nedmalloc.c#L1298 >> > >> > But that repository was last updated in 2014, I wonder if it's just >> > because nobody's submitted a patch since then, or if it's inactive. Have >> > you tried making Njall Douglas (the nedmalloc author) aware of this >> > issue? >> > >> >> https://github.com/ned14/nedmalloc says at the top: "This repository has >> been archived by the owner. It is now read-only.". > > Indeed, maintenance of nedmalloc has stopped a few years ago (see e.g. > https://github.com/ned14/nedmalloc/issues/20#issuecomment-343432314). The author says: nedmalloc is pretty much EOL. Happy to accept patches, but unwilling to fix. The "Happy to accept patches" seems to suggest that they're willing to take a PR, just not willing to do spend time on it themselves. Anyway, I see that we've accumulated quite a few patches on top, and given... > About five years ago I tried to upgrade us to the latest nedmalloc version > but ran into a performance regression that I was unable to justify the > time to investigate further. ...perhaps it's not worth it. Maybe someone should get to updating the readme we carry from it to change the first line from: nedalloc v1.05 15th June 2008: To: Git's (perma-)fork & local hacks on top of nedalloc v1.05 15th June 2008: Or something :)
diff --git a/compat/nedmalloc/nedmalloc.c b/compat/nedmalloc/nedmalloc.c index edb438a7776..2c0ace7075a 100644 --- a/compat/nedmalloc/nedmalloc.c +++ b/compat/nedmalloc/nedmalloc.c @@ -323,7 +323,6 @@ static NOINLINE void RemoveCacheEntries(nedpool *p, threadcache *tc, unsigned in } static void DestroyCaches(nedpool *p) THROWSPEC { - if(p->caches) { threadcache *tc; int n;