* 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).