| Bugs in IDL HDF routines [message #5116] |
Mon, 09 October 1995 00:00  |
rivers
Messages: 228
Registered: March 1991
|
Senior Member |
|
|
I have found a number of serious bugs in IDL's HDF routines. I have informed
RSI about these, but I am posting them here for 2 reasons:
- To prevent others from wasting time tracking down and document these same
bugs.
- To solicit reports of any other bugs other poeple have found in the HDF
routines so that RSI can fix them all at once.
1) Routine HDF_VG_ADDTR does not work at all. It always generates an error.
This routine is used to add various entities (SDS, other Vgroups, etc.) to a
Vgroup.
2) Routine HDF_SD_IDTOREF() is not documented. It is required to be able to
use HDF_VG_ADDTR.
3) Routine HDF_SD_GETDATA crashes IDL when reading an SDS whose data type is
DFNT_CHAR8. The technical support people at NCSA have stated that
DFNT_CHAR8 is a valid data type for an SDS.
4) Routine HDF_SD_ATTRINFO returns corrupted strings when the attribute is of
type DFNT_CHAR8 (character data). The returned strings have a trailing NULL
character which renders them useless in IDL programs.
5) An error occurs under the following conditions:
- Create a Scientific Data Set with HDF_SD_CREATE, specifying a data type.
- Write data to that SDS with HDF_SD_ADDDATA, but pass it an array of a
different data type than that specified in HDF_SD_CREATE.
- HDF_SD_ADDDATA appears to work, but the error message
% Temporary variables are still checked out - cleaning up...
occurs when HDF_SD_END is called.
____________________________________________________________
Mark Rivers (312) 702-2279 (office)
CARS (312) 702-9951 (secretary)
Univ. of Chicago (312) 702-5454 (FAX)
5640 S. Ellis Ave. (708) 922-0499 (home)
Chicago, IL 60637 rivers@cars3.uchicago.edu (Internet)
|
|
|
|
| Re: Bugs in IDL HDF routines [message #5175 is a reply to message #5116] |
Sat, 14 October 1995 00:00  |
rivers
Messages: 228
Registered: March 1991
|
Senior Member |
|
|
In article <1995Oct13.234957.5791@arete.com>, Adam Shane <shane@arete.com arete.com> writes:
> rivers@cars3.uchicago.edu (Mark Rivers) wrote:
>>
>> 4) Routine HDF_SD_ATTRINFO returns corrupted strings when the attribute is of
>> type DFNT_CHAR8 (character data). The returned strings have a trailing NULL
>> character which renders them useless in IDL programs.
>>
>
> This is standard HDF as far as I know (your other problems seem
> to be real bugs). Many character strings written to HDF files
> will be null character terminated strings. IDL has some documentation
> to this effect and there is an example of how to deal with it.
This is not true. The count parameter which is passed to the native HDF
routine SD_setattr and the count parameter one receives back from SD_attrinfo
do NOT include the trailing NULL when the attribute is a string (see the
examples in Chapter 3 of the HDF User's Guide). It would be the C programmer's
responsibility to make sure the receive buffer contains a trailing NULL.
The IDL routine HDF_SD_ATTRINFO correctly returns, in COUNT, the length of the
string without the NULL. IDL should only create a string of this length and
not add a NULL. A C routine would want the trailing NULL, but IDL should not
add it. Doing so corrupts the strings and makes the resulting strings unusable
with the IDL string operators (such as +). It would be easy for IDL to not add
the NULL. I notice that the IDL routines HDF_DFAN_GETLABEL and HDF_DFAN_GETFDS
return NULL terminated strings by defaults, but add a /NONULL keyword to turn
this off. I think this is absolutetly the wrong way to do it. Why make
returning a corrupt IDL string (one which does not work with IDL operators) the
default behavior? Who would ever want an IDL string to be NULL terminated?
____________________________________________________________
Mark Rivers (312) 702-2279 (office)
CARS (312) 702-9951 (secretary)
Univ. of Chicago (312) 702-5454 (FAX)
5640 S. Ellis Ave. (708) 922-0499 (home)
Chicago, IL 60637 rivers@cars3.uchicago.edu (Internet)
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
