From: Jun T <takimoto-j@kba.biglobe.ne.jp>
To: zsh-workers@zsh.org
Subject: Re: [PATCH 3/3] autoconf: prepare for 2.70
Date: Fri, 9 Apr 2021 13:18:01 +0900 [thread overview]
Message-ID: <6C8E81D3-E859-4C65-97D0-90E614816619@kba.biglobe.ne.jp> (raw)
In-Reply-To: <57530-1617921898.773095@9HdU.NV4Y.7xMR>
> 2021/04/09 7:44, Oliver Kiddle <opk@zsh.org> wrote:
>
> Both this and the preceding part 1 patch look completely fine to me.
> I've read through this and checked against a couple of different systems
> and don't see an issue but I can't claim to be following what is new
> with autoconf 2.70. Unless anyone sees a reason to object, I'll apply
> these.
I also tested on a few systems and fund no problems.
I think mem.c can be further simplified as follows (discard unnecessary macros):
PS
Are there any systems that still require --enable-zsh-mem?
diff --git a/Src/mem.c b/Src/mem.c
index 5951e57ed..fb4be47bf 100644
--- a/Src/mem.c
+++ b/Src/mem.c
@@ -1072,19 +1072,6 @@ zrealloc(void *ptr, size_t size)
# endif
#endif
-#if defined(_BSD) && !defined(STDC_HEADERS)
-# define FREE_RET_T int
-# define FREE_ARG_T char *
-# define FREE_DO_RET
-# define MALLOC_RET_T char *
-# define MALLOC_ARG_T size_t
-#else
-# define FREE_RET_T void
-# define FREE_ARG_T void *
-# define MALLOC_RET_T void *
-# define MALLOC_ARG_T size_t
-#endif
-
/* structure for building free list in blocks holding small blocks */
struct m_shdr {
@@ -1198,8 +1185,8 @@ static struct m_hdr *m_l;
#endif /* ZSH_MEM_DEBUG */
-MALLOC_RET_T
-malloc(MALLOC_ARG_T size)
+void *
+malloc(size_t size)
{
struct m_hdr *m, *mp, *mt;
long n, s, os = 0;
@@ -1226,7 +1213,7 @@ malloc(MALLOC_ARG_T size)
#if 1
size = 1;
#else
- return (MALLOC_RET_T) m_high;
+ return (void *) m_high;
#endif
queue_signals(); /* just queue signals rather than handling them */
@@ -1284,7 +1271,7 @@ malloc(MALLOC_ARG_T size)
#endif
unqueue_signals();
- return (MALLOC_RET_T) sh;
+ return (void *) sh;
}
/* we still want a small block but there were no block with a free
small block of the requested size; so we use the real allocation
@@ -1426,14 +1413,14 @@ malloc(MALLOC_ARG_T size)
#endif
unqueue_signals();
- return (MALLOC_RET_T) (((char *)m) + sizeof(struct m_hdr));
+ return (void *) (((char *)m) + sizeof(struct m_hdr));
}
#ifdef ZSH_MEM_DEBUG
m_m[m->len < (1024 * M_ISIZE) ? (m->len / M_ISIZE) : 1024]++;
#endif
unqueue_signals();
- return (MALLOC_RET_T) & m->next;
+ return (void *) & m->next;
}
/* this is an internal free(); the second argument may, but need not hold
@@ -1640,14 +1627,10 @@ zfree(void *p, int sz)
unqueue_signals();
}
-FREE_RET_T
-free(FREE_ARG_T p)
+void
+free(void *p)
{
zfree(p, 0); /* 0 means: size is unknown */
-
-#ifdef FREE_DO_RET
- return 0;
-#endif
}
/* this one is for strings (and only strings, real strings, real C strings,
@@ -1661,8 +1644,8 @@ zsfree(char *p)
zfree(p, strlen(p) + 1);
}
-MALLOC_RET_T
-realloc(MALLOC_RET_T p, MALLOC_ARG_T size)
+void *
+realloc(void *p, size_t size)
{
struct m_hdr *m = (struct m_hdr *)(((char *)p) - M_ISIZE), *mt;
char *r;
@@ -1673,12 +1656,12 @@ realloc(MALLOC_RET_T p, MALLOC_ARG_T size)
queue_signals();
r = malloc(size);
unqueue_signals();
- return (MALLOC_RET_T) r;
+ return (void *) r;
}
/* and some systems even do this... */
if (!p || !size)
- return (MALLOC_RET_T) p;
+ return p;
queue_signals(); /* just queue signals caught rather than handling them */
@@ -1707,17 +1690,17 @@ realloc(MALLOC_RET_T p, MALLOC_ARG_T size)
free(p);
unqueue_signals();
- return (MALLOC_RET_T) r;
+ return (void *) r;
}
-MALLOC_RET_T
-calloc(MALLOC_ARG_T n, MALLOC_ARG_T size)
+void *
+calloc(size_t n, size_t size)
{
long l;
char *r;
if (!(l = n * size))
- return (MALLOC_RET_T) m_high;
+ return (void *) m_high;
/*
* use realloc() (with a NULL `p` argument it behaves exactly the same
@@ -1729,7 +1712,7 @@ calloc(MALLOC_ARG_T n, MALLOC_ARG_T size)
memset(r, 0, l);
- return (MALLOC_RET_T) r;
+ return (void *) r;
}
#ifdef ZSH_MEM_DEBUG
next prev parent reply other threads:[~2021-04-09 4:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-31 5:41 [PATCH 0/3] Build fixes Felipe Contreras
2020-12-31 5:41 ` [PATCH 1/3] src: fix build warnings Felipe Contreras
2021-01-02 11:22 ` Daniel Shahaf
2021-01-02 16:41 ` Mikael Magnusson
2021-01-02 18:30 ` Felipe Contreras
2021-01-04 5:14 ` Daniel Shahaf
2021-03-27 19:28 ` Lawrence Velázquez
2021-04-04 6:38 ` Jun. T
2020-12-31 5:41 ` [PATCH 2/3] autoconf: remove deprecated functions Felipe Contreras
2021-03-27 19:37 ` Lawrence Velázquez
2021-04-03 15:04 ` Lawrence Velázquez
2020-12-31 5:41 ` [PATCH 3/3] autoconf: prepare for 2.70 Felipe Contreras
2021-03-27 19:38 ` Lawrence Velázquez
2021-04-03 15:44 ` Lawrence Velázquez
2021-04-08 22:44 ` Oliver Kiddle
2021-04-09 4:18 ` Jun T [this message]
2021-04-09 20:08 ` Oliver Kiddle
2021-04-09 20:28 ` Peter Stephenson
2021-04-09 23:04 ` Bart Schaefer
2021-04-09 23:19 ` Mikael Magnusson
2021-04-10 0:37 ` Jun. T
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6C8E81D3-E859-4C65-97D0-90E614816619@kba.biglobe.ne.jp \
--to=takimoto-j@kba.biglobe.ne.jp \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).