build failures from gcc warning about memset
Hi all,
I've been fixing and reverting this locally for the past month or so,
and I'm not sure if anyone else has seen this, but it looks like
there's some static analysis code that's been added to GCC 4.3.3 that
warns about code paths that could produce a call to `memset' with a
size parameter of zero, and which causes the build of `master' to
fail. The exact text of the warning is:
/usr/include/bits/string3.h:82: warning: memset used with constant
zero length parameter; this could be due to transposed parameters
Find attached a tiny patch that adds a check on the size parameter in
`scm_gc_calloc', which seems to satisfy the compiler.
Regards,
Julian
From 92ce32eeac2600704fc643ea5f65bda92b2d3bd9 Mon Sep 17 00:00:00 2001
From: Julian Graham julian.gra...@aya.yale.edu
Date: Sun, 25 Oct 2009 13:00:08 -0400
Subject: [PATCH] Resolve warning in gcc-4.3 about transposed parameters passed to memset
* libguile/gc-malloc.c (scm_gc_calloc): Add explicit check on size parameter
---
libguile/gc-malloc.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/libguile/gc-malloc.c b/libguile/gc-malloc.c
index a96a186..0e60eba 100644
--- a/libguile/gc-malloc.c
+++ b/libguile/gc-malloc.c
@@ -206,7 +206,8 @@ void *
scm_gc_calloc (size_t size, const char *what)
{
void *ptr = scm_gc_malloc (size, what);
- memset (ptr, 0x0, size);
+ if (size)
+memset (ptr, 0x0, size);
return ptr;
}
--
1.6.0.4
Re: Guile web page docs
Hi, Neil Jerram n...@ossau.uklinux.net writes: l...@gnu.org (Ludovic Courtès) writes: Neil Jerram n...@ossau.uklinux.net writes: I noticed that the docs on the Guile web pages are a bit out of date. The 1.8 ones are behind those in 1.8.7 (the latest release). http://www.gnu.org/software/guile/manual/html_node/index.html appears to correspond to 1.8.7. Yes, but amusingly this copy of the manual is only linked from the support for many SRFIs link on http://www.gnu.org/software/guile/guile.html, and from inside Daniel's tutorial. And from http://gnu.org/manual/ . If you follow the more prominent links from http://www.gnu.org/software/guile/, you get to http://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/index.html, which is still at version 1.8.1. So, anyway, I think we agree that this needs sorting out! Indeed. I think I’ve always been updating the one at guile/manual, since it’s the usual way to place GNU manuals, but I must have forgotten to check the links under guile/. I’d be in favor or removing ‘docs-1.8’ and keeping just ‘manual’. What do you think? (BTW, Gnulib has a new script to automate updates to www.gnu.org/software/PROJECT/manual.) Right; I assume you mean gendocs.sh. I was thinking about the ‘gnu-web-doc-update’ module. I hadn't done it so far, mostly because 1.9 is alpha, and I think gnu.org/software/guile/manual should point to the current stable series. That said, perhaps we could put them in a sub-directory. Yes, that's what I had in mind, linked from http://www.gnu.org/software/guile/docs/docs.html. OK. Do you have strong views on whether we should use current Git or the latest pre-release? I don't think it matters much, and current Git is marginally easier. Either way is fine with me. Thank you! Ludo’.
Re: r6rs libraries, round three
Hi Andy, It should work now, though with hacks -- if you manipulate the module-public-interface directly. But perhaps some more baked in support would be useful. Oh, certainly -- as I've learned over these many months, you can do some very interesting things by working with the lower-level module API. And indeed, that was how I did things in my initial implementation back in March. But... Can you explain a use case a bit more? I think having trouble grasping why you would want to do this :) I'm trying to write a macro to convert `library' forms into `define-module' forms. All of the contortions you can put your imported symbols through in R6RS can be flattened into a form that maps quite neatly onto define-module's #:select, but #:export and #:reexport aren't as flexible. Specifically, the use case is implementing the (rename (identifier1 identifier2) ...) form for R6RS library export-specs. Like you said, you can manipulate the public interface directly -- I could, say, insert the code to do this as part of transforming the library body -- but it would be nice if I could leave the management of the interface entirely up to `define-module'. Regards, Julian
