iraf.net

Between CDL release 1.6 and 1.7, the body of the function was changed from


to


The code has basically stayed the same since. What is the intended purpose of the call to imd_readCursor() here? It's buggy because wcs is uninitialized and imd_readCursor() basically just passes its address to com_readCursor() which then dereferences the (uninitialized) address as the z-register argument in a com_whdr() call.

Long story short, cdl_getFrame() doesn't work because of this change.

Cheers,
Jason

This turns out to be a false alarm caused by another issue. The uninitialized dereference is made when the "sample" option is on, and the wcs value should be able to be junk in that situation without harm.

The other issue helped cause the above to be misinterpreted as an error. The problem is with the return value of cdl_readCursor(). The CDL library partly assumes that the return value is OK or ERR (like almost every other CDL function) but it also partly assumes that the return is the keypress character from the cursor read.

Here are the details. The declaration is "char cdl_readCursor()" and sans error it returns "*key" and on error it returns ERR. (It returns key even though this value is also available to the caller through the passed key pointer so there's a redundancy there.) What it should be is "int cdl_readCursor()" and the sans error value should be OK and the user should get the key value from the passed pointer if they need it. Some test and example programs were actually using the returned char value directly while other code was assuming cdl_readCursor" returned only OK or ERR to detect an error. Since a key character evaluates as true, it was throwing the error message on normal cursor reads. LUCKILY, the situation is not as complicated as it sounds and easily fixed. The bug didn't effect the library itself but only the example and test programs, which are also easily changed to use a "int cdl_readCursor()" prototype/declaration.

Jason