[PATCH 1/6] fix implicit typecast for strict compilers

[PATCH 1/6] fix implicit typecast for strict compilers

[Nikolas Garofil]

---
 Src/compat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Src/compat.c b/Src/compat.c
index cc4e876..81a95d5 100644
--- a/Src/compat.c
+++ b/Src/compat.c
@@ -40,7 +40,7 @@ strstr(const char *s, const char *t)
     char *p1, *p2;
 
     for (; *s; s++) {
-        for (p1 = s, p2 = t; *p2; p1++, p2++)
+        for (p1 = (char*)s, p2 = (char*)t; *p2; p1++, p2++)
             if (*p1 != *p2)
                 break;
         if (!*p2)
-- 
1.8.3.2

[PATCH 2/6] strict compilers expect the number of bytes to be a size_t for bcopy

[Nikolas Garofil]

---
 Src/prototypes.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Src/prototypes.h b/Src/prototypes.h
index 00988ac..e3db4f5 100644
--- a/Src/prototypes.h
+++ b/Src/prototypes.h
@@ -130,5 +130,5 @@ extern char *strerror _((int errnum));
 /***************************************************/
 
 #ifndef HAVE_MEMMOVE
-extern void bcopy _((const void *, void *, int));
+extern void bcopy _((const void *, void *, size_t));
 #endif
-- 
1.8.3.2

Re: [PATCH 2/6] strict compilers expect the number of bytes to be a size_t for bcopy

[Bart Schaefer]

On Jun 7,  7:18pm, Nikolas Garofil wrote:
}
} --- a/Src/prototypes.h
} +++ b/Src/prototypes.h
} @@ -130,5 +130,5 @@ extern char *strerror _((int errnum));
}  /***************************************************/
}  
}  #ifndef HAVE_MEMMOVE
} -extern void bcopy _((const void *, void *, int));
} +extern void bcopy _((const void *, void *, size_t));
}  #endif
} -- 

Pardon my paranoia, but are we sure that won't itself break somewhere?
A strict compiler that doesn't have size_t declared in scope, or that
does have bcopy() but it doesn't use size_t for it?

Yes, this is probably pretty unlikely nowadays, but obviously you found
one that doesn't have memmove() which I would have thought less likely.

Re: [PATCH 2/6] strict compilers expect the number of bytes to be a size_t for bcopy

[Nikolas Garofil]

On 06/07/2014 09:20 PM, Bart Schaefer wrote:
> On Jun 7,  7:18pm, Nikolas Garofil wrote:
> }
> } --- a/Src/prototypes.h
> } +++ b/Src/prototypes.h
> } @@ -130,5 +130,5 @@ extern char *strerror _((int errnum));
> }  /***************************************************/
> }
> }  #ifndef HAVE_MEMMOVE
> } -extern void bcopy _((const void *, void *, int));
> } +extern void bcopy _((const void *, void *, size_t));
> }  #endif
> } --
>
> Pardon my paranoia, but are we sure that won't itself break somewhere?
> A strict compiler that doesn't have size_t declared in scope, or that
> does have bcopy() but it doesn't use size_t for it?
>
> Yes, this is probably pretty unlikely nowadays, but obviously you found
> one that doesn't have memmove() which I would have thought less likely.

A check could be added to choose between both implementations

[PATCH 3/6] make sure signal_suspend doesn't return a undefined value

[Nikolas Garofil]

---
 Src/signals.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Src/signals.c b/Src/signals.c
index a6eb803..cb2b581 100644
--- a/Src/signals.c
+++ b/Src/signals.c
@@ -369,7 +369,7 @@ signal_suspend(UNUSED(int sig), int wait_cmd)
 #ifdef POSIX_SIGNALS
 # ifdef BROKEN_POSIX_SIGSUSPEND
     sigprocmask(SIG_SETMASK, &set, &oset);
-    pause();
+    ret = pause();
     sigprocmask(SIG_SETMASK, &oset, NULL);
 # else /* not BROKEN_POSIX_SIGSUSPEND */
     ret = sigsuspend(&set);
-- 
1.8.3.2

[PATCH 4/6] strict compilers don't like pointers that get set but are never used

[Nikolas Garofil]

---
 Src/mem.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Src/mem.c b/Src/mem.c
index a7f11a6..f198177 100644
--- a/Src/mem.c
+++ b/Src/mem.c
@@ -1508,7 +1508,7 @@ zsfree(char *p)
 MALLOC_RET_T
 realloc(MALLOC_RET_T p, MALLOC_ARG_T size)
 {
-    struct m_hdr *m = (struct m_hdr *)(((char *)p) - M_ISIZE), *mp, *mt;
+    struct m_hdr *m = (struct m_hdr *)(((char *)p) - M_ISIZE), *mt;
     char *r;
     int i, l = 0;
 
@@ -1524,10 +1524,10 @@ realloc(MALLOC_RET_T p, MALLOC_ARG_T size)
     /* check if we are reallocating a small block, if we do, we have
        to compute the size of the block from the sort of block it is in */
     for (i = 0; i < M_NSMALL; i++) {
-	for (mp = NULL, mt = m_small[i];
+	for (mt = m_small[i];
 	     mt && (((char *)mt) > ((char *)p) ||
 		    (((char *)mt) + mt->len) < ((char *)p));
-	     mp = mt, mt = mt->next);
+	     mt = mt->next);
 
 	if (mt) {
 	    l = M_BSLEN(mt->len);
-- 
1.8.3.2

[PATCH 5/6] memmove is expected to return dest

[Nikolas Garofil]

---
 Src/zsh_system.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Src/zsh_system.h b/Src/zsh_system.h
index e68fd62..aca76f6 100644
--- a/Src/zsh_system.h
+++ b/Src/zsh_system.h
@@ -708,7 +708,10 @@ struct timezone {
 #endif
 
 #ifndef HAVE_MEMMOVE
-# define memmove(dest, src, len) bcopy((src), (dest), (len))
+void *memmove(void *dest, const void *src, size_t n) {
+	bcopy(src, dest, n);
+	return dest;
+}
 #endif
 
 #ifndef offsetof
-- 
1.8.3.2

Re: [PATCH 5/6] memmove is expected to return dest

[Bart Schaefer]

On Jun 7,  7:18pm, Nikolas Garofil wrote:
}
}  #ifndef HAVE_MEMMOVE
} -# define memmove(dest, src, len) bcopy((src), (dest), (len))
} +void *memmove(void *dest, const void *src, size_t n) {
} +	bcopy(src, dest, n);
} +	return dest;
} +}
}  #endif

Defining a function in a .h file, especially without declaring it
static, is probably not the best idea.

Perhaps something like

#ifndef HAVE_MEMMOVE
# ifndef memmove
static void *zmm;
# define memmove(dest, src, len) (bcopy((src), zmm = (dest), (len)), zmm)
# endif
#endif

??

[PATCH 6/6] decr and tmp are only used when HAVE_STRFTIME is defined, strict compilers will complain

[Nikolas Garofil]

---
 Src/utils.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/Src/utils.c b/Src/utils.c
index 59b9435..cef2abe 100644
--- a/Src/utils.c
+++ b/Src/utils.c
@@ -2712,8 +2712,11 @@ ztrftimebuf(int *bufsizeptr, int decr)
 mod_export int
 ztrftime(char *buf, int bufsize, char *fmt, struct tm *tm)
 {
-    int hr12, decr;
-#ifndef HAVE_STRFTIME
+    int hr12;
+#ifdef HAVE_STRFTIME
+    int decr;
+    char tmp[4];
+#else
     static char *astr[] =
     {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"};
     static char *estr[] =
@@ -2721,7 +2724,6 @@ ztrftime(char *buf, int bufsize, char *fmt, struct tm *tm)
      "Aug", "Sep", "Oct", "Nov", "Dec"};
 #endif
     char *origbuf = buf;
-    char tmp[4];
 
 
     while (*fmt)
-- 
1.8.3.2

Re: [PATCH 1/6] fix implicit typecast for strict compilers

[Bart Schaefer]

On Jun 7,  7:18pm, Nikolas Garofil wrote:
}
} diff --git a/Src/compat.c b/Src/compat.c
} index cc4e876..81a95d5 100644
} --- a/Src/compat.c
} +++ b/Src/compat.c
} @@ -40,7 +40,7 @@ strstr(const char *s, const char *t)
}      char *p1, *p2;
}  
}      for (; *s; s++) {
} -        for (p1 = s, p2 = t; *p2; p1++, p2++)
} +        for (p1 = (char*)s, p2 = (char*)t; *p2; p1++, p2++)
}              if (*p1 != *p2)
}                  break;
}          if (!*p2)
} -- 


Wouldn't the right thing here be to declare

	const char *p1, *p2;

instead of casting?

-- 
Barton E. Schaefer

Re: [PATCH 1/6] fix implicit typecast for strict compilers

[Nikolas Garofil]

On 06/07/2014 09:04 PM, Bart Schaefer wrote:
> On Jun 7,  7:18pm, Nikolas Garofil wrote:
> }
> } diff --git a/Src/compat.c b/Src/compat.c
> } index cc4e876..81a95d5 100644
> } --- a/Src/compat.c
> } +++ b/Src/compat.c
> } @@ -40,7 +40,7 @@ strstr(const char *s, const char *t)
> }      char *p1, *p2;
> }
> }      for (; *s; s++) {
> } -        for (p1 = s, p2 = t; *p2; p1++, p2++)
> } +        for (p1 = (char*)s, p2 = (char*)t; *p2; p1++, p2++)
> }              if (*p1 != *p2)
> }                  break;
> }          if (!*p2)
> } --
>
>
> Wouldn't the right thing here be to declare
>
> 	const char *p1, *p2;
>
> instead of casting?
>

The p1 and p2 pointers are increased at the end of the line to walk 
through the string so that wouldn't work

Re: [PATCH 1/6] fix implicit typecast for strict compilers

[Bart Schaefer]

On Jun 7,  9:13pm, Nikolas Garofil wrote:
}
} > Wouldn't the right thing here be to declare
} >
} > 	const char *p1, *p2;
} >
} > instead of casting?
} 
} The p1 and p2 pointers are increased at the end of the line to walk 
} through the string so that wouldn't work

The "s" pointer is declared const char * and it's incremented as well.
I'm not suggesting "char * const p1".

Re: [PATCH 1/6] fix implicit typecast for strict compilers

[Nikolas Garofil]

On 06/07/2014 09:36 PM, Bart Schaefer wrote:
> On Jun 7,  9:13pm, Nikolas Garofil wrote:
> }
> } > Wouldn't the right thing here be to declare
> } >
> } > 	const char *p1, *p2;
> } >
> } > instead of casting?
> }
> } The p1 and p2 pointers are increased at the end of the line to walk
> } through the string so that wouldn't work
>
> The "s" pointer is declared const char * and it's incremented as well.
> I'm not suggesting "char * const p1".
Sorry, misread it.
Feel free to make the values constant, it shouldn't give any problems as 
long as the pointers can change.