* bug in scm_arrray_handle_[srfi tag]_elements [not found] <0JCC00MW3LBEPQ@imap0.epfl.ch> @ 2010-01-11 18:49 ` Daniel Llorens del Río 2010-01-11 23:22 ` Andy Wingo 0 siblings, 1 reply; 6+ messages in thread From: Daniel Llorens del Río @ 2010-01-11 18:49 UTC (permalink / raw) To: guile-devel Hello, That function and the _writable_elements() version are broken for shared arrays because they return a pointer to the beginning of the enclosing array instead of a pointer to their own beginning. This patch against master fixes the issue for me. Cf. the implementation of scm_array_handle_uniform_writable_elements() in uniform.c. --- libguile/srfi-4.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libguile/srfi-4.c b/libguile/srfi-4.c index 4b7eadc..f38fbcf 100644 --- a/libguile/srfi-4.c +++ b/libguile/srfi-4.c @@ -119,13 +119,13 @@ { \ if (h->element_type != ETYPE (TAG)) \ scm_wrong_type_arg_msg (NULL, 0, h->array, #tag "vector"); \ - return h->elements; \ + return h->elements+h->base*scm_array_handle_uniform_element_size (h);\ } \ ctype* scm_array_handle_##tag##_writable_elements (scm_t_array_handle *h) \ { \ if (h->element_type != ETYPE (TAG)) \ scm_wrong_type_arg_msg (NULL, 0, h->array, #tag "vector"); \ - return h->writable_elements; \ + return h->writable_elements+h- >base*scm_array_handle_uniform_element_size(h); \ } \ const ctype *scm_##tag##vector_elements (SCM uvec, \ scm_t_array_handle *h, \ -- Thanks, Daniel ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: bug in scm_arrray_handle_[srfi tag]_elements 2010-01-11 18:49 ` bug in scm_arrray_handle_[srfi tag]_elements Daniel Llorens del Río @ 2010-01-11 23:22 ` Andy Wingo 2010-01-11 23:49 ` Daniel Llorens del Río 0 siblings, 1 reply; 6+ messages in thread From: Andy Wingo @ 2010-01-11 23:22 UTC (permalink / raw) To: Daniel Llorens del Río; +Cc: guile-devel Hi Daniel, On Mon 11 Jan 2010 19:49, Daniel Llorens del Río <daniel.llorens@bluewin.ch> writes: > That function and the _writable_elements() version are broken for shared > arrays because they return a pointer to the beginning of the enclosing > array instead of a pointer to their own beginning. I've fixed the issues compiling e.g. #@2(1 2 3) and the like, and applied this patch as well. Thanks for the reports. Anything else? :) Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug in scm_arrray_handle_[srfi tag]_elements 2010-01-11 23:22 ` Andy Wingo @ 2010-01-11 23:49 ` Daniel Llorens del Río 2010-01-12 0:54 ` Daniel Llorens del Río 2010-01-12 19:16 ` Andy Wingo 0 siblings, 2 replies; 6+ messages in thread From: Daniel Llorens del Río @ 2010-01-11 23:49 UTC (permalink / raw) To: Andy Wingo; +Cc: guile-devel On 12 Jan, 2010, at 0:22, Andy Wingo wrote: > I've fixed the issues compiling e.g. #@2(1 2 3) and the like, Thanks for the great support. > and applied this patch as well. Thanks for the reports. > > Anything else? :) Yeah… your patch is wrong :) - return h- >elements; \ + return ((const ctype*) h->elements) + h- >base; \ I wrote it this way at first, too, but it doesn't work for c32/c64 because ctype for those is float/double. Calling the element size function as I did is clunky, since the type is already known, but maybe one could access the table in uniform.c directly or something. Regards, Daniel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug in scm_arrray_handle_[srfi tag]_elements 2010-01-11 23:49 ` Daniel Llorens del Río @ 2010-01-12 0:54 ` Daniel Llorens del Río 2010-01-12 19:16 ` Andy Wingo 1 sibling, 0 replies; 6+ messages in thread From: Daniel Llorens del Río @ 2010-01-12 0:54 UTC (permalink / raw) To: Andy Wingo; +Cc: guile-devel On 12 Jan, 2010, at 0:49, Daniel Llorens del Río wrote: > - return h- > >elements; \ > + return ((const ctype*) h->elements) + h- > >base; \ > > I wrote it this way at first, too, but it doesn't work for c32/c64 > because ctype for those is float/double. Or maybe hardcode the sizes in the macro call, it's not like they are not already in two places. Regards, Daniel. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug in scm_arrray_handle_[srfi tag]_elements 2010-01-11 23:49 ` Daniel Llorens del Río 2010-01-12 0:54 ` Daniel Llorens del Río @ 2010-01-12 19:16 ` Andy Wingo 2010-01-12 19:48 ` Daniel Llorens del Río 1 sibling, 1 reply; 6+ messages in thread From: Andy Wingo @ 2010-01-12 19:16 UTC (permalink / raw) To: Daniel Llorens del Río; +Cc: guile-devel On Tue 12 Jan 2010 00:49, Daniel Llorens del Río <daniel.llorens@bluewin.ch> writes: > On 12 Jan, 2010, at 0:22, Andy Wingo wrote: > >> Anything else? :) > > Yeah… your patch is wrong :) Damn. I actually was thinking of this as I woke up, before I got to your message. I gave it another go; please take a look at it :) Cheers, Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug in scm_arrray_handle_[srfi tag]_elements 2010-01-12 19:16 ` Andy Wingo @ 2010-01-12 19:48 ` Daniel Llorens del Río 0 siblings, 0 replies; 6+ messages in thread From: Daniel Llorens del Río @ 2010-01-12 19:48 UTC (permalink / raw) To: Andy Wingo; +Cc: guile-devel On 12 Jan, 2010, at 20:16, Andy Wingo wrote: > I gave it another go; please take a look at it :) Looks good! I had not noticed the other two cases. Thanks, Daniel ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-01-12 19:48 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <0JCC00MW3LBEPQ@imap0.epfl.ch> 2010-01-11 18:49 ` bug in scm_arrray_handle_[srfi tag]_elements Daniel Llorens del Río 2010-01-11 23:22 ` Andy Wingo 2010-01-11 23:49 ` Daniel Llorens del Río 2010-01-12 0:54 ` Daniel Llorens del Río 2010-01-12 19:16 ` Andy Wingo 2010-01-12 19:48 ` Daniel Llorens del Río
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 read-only IMAP folder(s) and NNTP newsgroup(s).