> Hmm, and can you see "both ends" of tgath_buf and buf (in particular
> tgath_but[curr_len - 1] and buf[curr_len-1])?
(dbx) p tgath_buf[curr_len - 1]
tgath_buf[curr_len-1] = '\0'
(dbx) p buf[curr_len-1]
dbx: cannot access address 0x9f7f6ff
(dbx) p tgath_buf[curr_len - 2]
tgath_buf[curr_len-2] = '\0'
(dbx) p buf[curr_len-2]
dbx: cannot access address 0x9f7f6fe
(dbx)
Something is definitely wrong with this memcpy() operation. I
suppose we'll need some help from the HDF5 folks to figure out
what the buf memory buffer is supposed contain in this case.
> If only to "eliminate from our inquiries", I'd try running CPP over the
> code and see if the full macro expansion (including that from memcpy to
> _memcpy) is working as intended.
After the macro expansion, this code looks like this:
for(curr_seq=0; curr_seq<nseq; curr_seq++) {
curr_len=len[curr_seq];
memcpy ( ( char * ) ( tgath_buf ) , ( const char *
) ( buf + off [curr_seq ] ) , curr_len );
tgath_buf+=curr_len;
}
> I take it that you've already tried compiling the module at maximal
> warning level?
No. We can try that, as well as lint.
Thanks.
-Greg
______________________________________________
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
