comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: Null terminated strings
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: Null terminated strings [message #28673] Mon, 07 January 2002 18:26 Go to next message
Craig Markwardt is currently offline  Craig Markwardt
Messages: 1869
Registered: November 1996
Senior Member
James Kuyper <kuyper@gscmail.gsfc.nasa.gov> writes:

> I'm reading a string-valued file attribute from an HDF file that was
> created using C code. As seems quite reasonable for C programs, the
> attribute was written with a length that includes a terminating null
> character. When I read it in using IDL, that null character got included
> as well. This causes a number of bizarre effects, most notably:
>
> IDL> print,date
> 2001-10-07
> IDL> print,date+'T12:00:00'
> 2001-10-07'T12:00:0
>
> I can handle this particular case by using strmid(date,0,10), but in
> general a file attribute might contain multiple null-delimited strings,
> of unknown length. Is there an efficient way of converting such a string
> into an IDL string array?

What happens when you swizzle it through a STRING-BYTE-STRING
transformation?

I.e.,

date = string(byte(date))

I believe that STRING will ignore any trailing 0-bytes, hence this may
solve your problem exactly, at the expense of some extra CPU.

Good luck,
Craig

--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
Re: Null terminated strings [message #28765 is a reply to message #28673] Tue, 08 January 2002 07:49 Go to previous message
James Kuyper is currently offline  James Kuyper
Messages: 425
Registered: March 2000
Senior Member
Craig Markwardt wrote:

> James Kuyper <kuyper@gscmail.gsfc.nasa.gov> writes:
>
>
>> I'm reading a string-valued file attribute from an HDF file that was
>> created using C code. As seems quite reasonable for C programs, the
>> attribute was written with a length that includes a terminating null
>> character. When I read it in using IDL, that null character got included
>> as well. This causes a number of bizarre effects, most notably:
>>
>> IDL> print,date
>> 2001-10-07
>> IDL> print,date+'T12:00:00'
>> 2001-10-07'T12:00:0
>>
>> I can handle this particular case by using strmid(date,0,10), but in
>> general a file attribute might contain multiple null-delimited strings,
>> of unknown length. Is there an efficient way of converting such a string
>> into an IDL string array?
>
>
> What happens when you swizzle it through a STRING-BYTE-STRING
> transformation?
>
> I.e.,
>
> date = string(byte(date))
>
> I believe that STRING will ignore any trailing 0-bytes, hence this may
> solve your problem exactly, at the expense of some extra CPU.

Thanks - that worked. It only solves the single-string case, but that's
the case I am currently facing. It saves me the trouble of figuring out
how long the string is, and it does the right thing, whether or not the
string is null-terminated.

I'm still wonder how to best convert a null-delimited list of strings
into an IDL string array (it's just curiousity, I don't have any
immediate need for that ability). My best solution so far is to convert
it to a byte array, find the null delimiting characters with where(),
and then write a loop to convert each subarray into a seperate IDL
string. This should work, but I'm always suspicious of the efficiency of
any solution for an IDL problem that involves an explicit loop.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Re: Finding a structure in a structure
Next Topic: where is idl-fortran.Z by Jeff Valenti

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 19:33:22 PDT 2025

Total time taken to generate the page: 0.00609 seconds