Hi Steve,

I was about to write to you along the same lines.  The copies of nhash.h 
and nhash.c in .../wsjtx_exp/lib have been used only for building the 
executable testmsk, not for wsprx.  I was clearly on the wrong track 
yesterday.

It turns out, I believe, that the problem is entirely elsewhere.  Under 
certain conditions an undefined value for TRperiod could be passed to 
function getfile(), which is used to read *.wav files from disk.  As a 
consequence a big memory segment could be zeroed when this statement 
(line 56 of getfile.cpp) was executed:

   memset(jt9com_.d2,0,2*npts);

I have now protected against this occurrence.  Please try building and 
testing revision 5831.

        -- Joe, K1JT

On 8/30/2015 10:15 AM, Steven Franke wrote:
> Joe -
>
> In perusing the wsjtx_exp code this morning, I noticed two things:
>
> 1. All references to nhash.c in CMakeLists.txt are to the version in 
> /lib/wsprd - so it seems that changes in /lib/nhash.c are not going to make 
> any difference. If this is working for you, then perhaps we can just delete 
> the nhash.c/nhash.h in /lib?
>
> 2. in /lib/nhash.h, length is declared size_t in nhash and uint32_t in 
> nhash_, whereas in /lib/nhash.c is it uint32_t in nhash.c and uint32_t in 
> nhash_
>
> I’m guessing that item 2 is not the problem due to item 1?
>
> I think that we need to resolve the differences between the two nhash.c’s and 
> get rid of one of them.
>
> Steve
>
> ------------------------------------------------------------------------------
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to