psMemory.c:
pthread_mutex_t   memBlockListMutex = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_t   memIdMutex = PTHREAD_MUTEX_INITIALIZER;

Either these should be declared "static", or there should be namespace
restriction.  Since these are not used outside psMemory.c, probably
the former.


#define ALIGNED(P) ((void *)((long)(P) & ~03) == (P))
This is not machine-independent.


/*
 * Check for memory leaks. Not production quality code
 */
int psMemCheckLeaks(
.....
The comment, I hope, is not appropriate.


Coding standard violations: e.g, curly brackets:
    if (vptr == NULL)
    {
        return NULL;
    }
Due to a bug in astyle.


"Slightly illegal" according to RHL:
#define PS_FREE (void*)1


On nkfb0:
Test driver: tst_psMemory Failed (Return value 256).
Test driver: tst_psStats07 Failed (Return value 34304).

On poiserver0:
--- Executing test driver tst_psFunc01
        Failed - STDOUT difference
76,105c76,105
< Gaussian Deviate [0] is 30.267838
< Gaussian Deviate [1] is 29.823797
< Gaussian Deviate [2] is 33.348816
< Gaussian Deviate [3] is 31.467281
< Gaussian Deviate [4] is 31.995049
< Gaussian Deviate [5] is 27.444996
< Gaussian Deviate [6] is 25.206570
< Gaussian Deviate [7] is 28.641439
< Gaussian Deviate [8] is 29.921818
< Gaussian Deviate [9] is 31.787111
< Gaussian Deviate [10] is 29.964705
< Gaussian Deviate [11] is 27.406887
< Gaussian Deviate [12] is 28.664040
< Gaussian Deviate [13] is 30.363417
< Gaussian Deviate [14] is 31.662102
< Gaussian Deviate [15] is 28.903503
< Gaussian Deviate [16] is 28.723936
< Gaussian Deviate [17] is 30.014177
< Gaussian Deviate [18] is 28.660292
< Gaussian Deviate [19] is 28.344475
< Gaussian Deviate [20] is 31.225000
< Gaussian Deviate [21] is 29.264824
< Gaussian Deviate [22] is 29.421013
< Gaussian Deviate [23] is 28.166250
< Gaussian Deviate [24] is 28.832390
< Gaussian Deviate [25] is 30.129230
< Gaussian Deviate [26] is 30.093487
< Gaussian Deviate [27] is 28.498547
< Gaussian Deviate [28] is 29.711535
< Gaussian Deviate [29] is 32.951122
---
> Gaussian Deviate [0] is 27.723047
> Gaussian Deviate [1] is 31.874863
> Gaussian Deviate [2] is 32.605770
> Gaussian Deviate [3] is 31.492830
> Gaussian Deviate [4] is 32.045048
> Gaussian Deviate [5] is 31.126467
> Gaussian Deviate [6] is 29.192963
> Gaussian Deviate [7] is 32.562622
> Gaussian Deviate [8] is 29.928261
> Gaussian Deviate [9] is 26.550817
> Gaussian Deviate [10] is 30.568424
> Gaussian Deviate [11] is 33.030228
> Gaussian Deviate [12] is 33.261463
> Gaussian Deviate [13] is 26.076645
> Gaussian Deviate [14] is 32.264557
> Gaussian Deviate [15] is 26.738295
> Gaussian Deviate [16] is 29.086100
> Gaussian Deviate [17] is 31.104702
> Gaussian Deviate [18] is 27.956509
> Gaussian Deviate [19] is 31.351622
> Gaussian Deviate [20] is 28.200375
> Gaussian Deviate [21] is 28.058838
> Gaussian Deviate [22] is 31.720587
> Gaussian Deviate [23] is 28.963566
> Gaussian Deviate [24] is 32.100430
> Gaussian Deviate [25] is 28.235241
> Gaussian Deviate [26] is 30.268490
> Gaussian Deviate [27] is 30.099007
> Gaussian Deviate [28] is 32.430271
> Gaussian Deviate [29] is 26.015800
 

On mithrandir:
All 62 Test Drivers Passed with 553 Testpoints.




Problem for tst_psMemory was in the test:
In TPOutOfMemory, want to use the line:
	mem1 = (int*) psAlloc(LONG_MAX);
It basically comes down to different machines using different memory
sizes.

The tst_psStats07 failure seems to be due to memory problems:
2004:06:17 02:29:23Z|nkfb0               |E|       p_psFree|psMemCheckCorruption: memory block 14 is corrupted (buffer overflow)
2004:06:17 02:29:23Z|nkfb0               |A|memProblemCallb|Detected a problem in the memory system at psVector.c:162

I suspect that the problem is somewhere in the histogram code ---
possibly due to freeing vector->data.V when vector->data.S32 was
allocated.
Memory block 14 has:
Start: deadbeef
End: deadbeef
Endpost: 63f100
File: psVector.c
Line: 77

RdS says this test is not ready.


This code is handy:
psMemoryId printMem(const psMemBlock *ptr)
{
        const void* startblock = ptr->startblock;
        //struct psMemBlock* previousBlock = ptr->previousBlock;
        //struct psMemBlock* nextBlock = ptr->nextBlock;
        size_t  userMemorySize = ptr->userMemorySize;
        //const psMemoryId id = ptr->id;
        const char* file = ptr->file;
        const int lineno = ptr->lineno;
        //psReferenceCount refCounter = ptr->refCounter;
        const void* endblock = ptr->endblock;
                                                                                
        fprintf(stderr,"Start: %lx\nEnd: %lx\nEndpost: %lx\nFile: %s\nLine: %d\n",(long)startblock,(long)endblock,(long)(ptr+1+userMemorySize),file,lineno);
        return 0;
}



I suspect the problem on poiserver0, with tst_psFunc01 is due to the
use of a different RNG.  No, actually, a different version of GSL
(1.1.1 vs 1.4).


In psTrace.c, there is a globally-visible struct "Component".


=============================================================================================================

Notes:

psAbort02 produces:
2004:06:18 20:46:57Z|mithrandir          |A|       __LINE__|NO_VALUES
Note the __LINE__ which wasn't replaced?  Not a big deal.


Is the psError functionality implemented as specified?  There is no
psErrorStackPrint, and psError simply does a psLogMsg and then
continues.  SVD says it's the old specification.


psHash: now store the free function when inserting, but also have to specify when calling psHashFree.
psHash01 does the allocate, insert and free.



psBitSet: SVD p21 says it checks that a set of a non-multile of 8 bits can be allocated,
but this is not done:
price@mithrandir:/home/mithrandir/price/psLib/test/collections>grep psBitSetAlloc *.c
tst_psBitSet_01.c:    psBitSet* bs = psBitSetAlloc(24);
tst_psBitSet_02.c:    psBitSet* bs1 = psBitSetAlloc(24);
tst_psBitSet_02.c:    psBitSet* bs2 = psBitSetAlloc(24);
tst_psBitSet_02.c:    psBitSet* outbs = psBitSetAlloc(24);
tst_psBitSet_03.c:    psBitSet* bs1 = psBitSetAlloc(24);
tst_psBitSet_03.c:    psBitSet* bs2 = psBitSetAlloc(24);
tst_psBitSet_03.c:    psBitSet* outbs = psBitSetAlloc(24);
tst_psBitSet_04.c:    psBitSet* bs1 = psBitSetAlloc(24);
tst_psBitSet_04.c:    psBitSet* bs2 = psBitSetAlloc(24);
tst_psBitSet_04.c:    psBitSet* outbs = psBitSetAlloc(24);
tst_psBitSet_05.c:    psBitSet* bs1 = psBitSetAlloc(24);
tst_psBitSet_05.c:    psBitSet* bs2 = psBitSetAlloc(40);
tst_psBitSet_05.c:    psBitSet* outbs = psBitSetAlloc(24);
tst_psBitSet_06.c:    psBitSet* bs1 = psBitSetAlloc(24);
tst_psBitSet_06.c:    psBitSet* bs2 = psBitSetAlloc(24);
tst_psBitSet_06.c:    psBitSet* outbs = psBitSetAlloc(24);
tst_psBitSet_06.c:    psBitSetAlloc(-4);

psBitSet02: SVD says 0xFF AND 0x55, but program is in effect testing 0xFF AND 0xFF,
which is not particularly rigorous.  Similarly with psBitSet0[34].

psLogMsg00:
First test which checks that the levels are working doesn't use psLogMsg but psVLogMsg.
        myLogMsg(__func__, i, "Hello World!  My level is %d %f %s\n", i,
                 (float) i, "beep beep");
instead of psLog(...).

psTrace: is inheritance of a trace level being tested?  It doesn't appear to be in
tst_psTrace02.

tst_psList has no checking for corruption or memory leaks.
Also, it doesn't seem to test for the instance of freeing the last item in a list.

In SVD, testing of sample mean, median, stdev contains "allow for
calculated value to be within a delta" --- no!  Sample statistics are
to be exact.

psStats06: Testing against values that can quickly and easily be evaluated (standard deviation), but
yet, programmer includes the following comment:
    // NOTE: These values were calculated by running the function on the data.
    // A: They must be changed if we adjust the number of data points.
    // B: We don't really know that they are correct.
    float realStdevNoMask   = 4.472136;
    float realStdevWithMask = 2.160247;

tst_psMatrix02: Transpose fails for non-square matrices (deliberately!).

tst_psMatrix03: Test C generates:
	Error: Resulting image is not PS_DIMEN_VECTOR
But this is in the validation, so it passes.... is it an error or not?
Surely the output from the LU solver should be a vector!


tst_psImage, testpoint 548 doesn't check for memory leaks.

Need to look over the polynomial source code.

