Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!ubc-cs!alberta!uqv-mts!Al_Dunbar
From: userAKDU@ualtamts.BITNET (Al Dunbar)
Newsgroups: comp.lang.fortran
Subject: Re: length of a character string
Message-ID: <2475@ualtamts.BITNET>
Date: 20 Sep 89 14:31:38 GMT
References: <18585@ut-emx.UUCP> <18603@ut-emx.UUCP>
Organization: University of Alberta (MTS)
Lines: 56

In article <MAINE.89Sep19132931@altair.dfrf.nasa.gov>, maine@elxsi.dfrf.nasa.gov (Richard Maine) writes:
>In article <18585@ut-emx.UUCP> reeder@ut-emx.UUCP (William P. Reeder) writes:
>
>>  Anyway, I need to check for a null string in variable "ncarg".  I thought
--- text deleted ---
>
>In fact, FORTRAN 77 has no concept of variable-length strings at all
>(niether does 8x, if I recall correctly).  ...
 
Correct! However, the German representatives to WG5 proposed such a thing.
Rather than putting it directly into  the  standard  at  this  late  date,
however,  a compromise was reached. The concept of "non-advancing I/O" was
added to 8X as a feature  that  would  facilitate  the  development  of  a
"standard  module"  that  could  provide  "varying  character" capability.
Without being party to the discussions that produced this proposal,  I  am
forced to conclude that it seems poorly thought out. It SHOULD have been a
more complete implementation of  "stream  I/O",  preferably  allowing  for
asynchronous,  character  at  a  time I/O with serial devices. The idea of
adding a marginally useful feature to the language just  to  simplify  the
development  of  a  useful  extension,  rather  than  adding the extension
itself, seems a particulary poor approach to the standardization process.
 
In article <18603@ut-emx.UUCP>, reeder@ut-emx.UUCP (William P. Reeder) writes:
>In article <18585@ut-emx.UUCP>, I wrote:
--- text deleted ---
>length with blanks.  So, all I have to do is change
>        if (ncar.eq."") then
>with
>        if (ncar.eq.' ') then
>and everything is hunky-dory and standard conforming (except for those
>lower-case letters :-).
 
That  is what I would have suggested to you. Unfortunately, there are some
situations in which the absence of  a  string  is  NOT  the  same  as  the
presence of a blank one. A case in point is the "environment variables" of
PC/MS-DOS and other systems. The code  you  suggest  would  be  unable  to
differentiate between the non- existence of the variable and its existence
with a "blank" value. To do that would require an interface to getenv that
provided  the  length  of the returned string. Alternately, you _might_ be
able to look for the null character terminating the string  returned  (IFF
that is how the string is indeed returned):
 
lencar = index( ncar, char(0) ) - 1
if (lencar .eq. 0) then
write (*,*) 'null string'
elseif(lencar .gt. 0) then
write (*,*) 'len=', lencar, ', string=(', ncar(:lencar), ')'
else
write (*,*) 'no null terminator'
endif
 
-------------------+-------------------------------------------
Alastair Dunbar    | Edmonton: a great place, but...
Edmonton, Alberta  | before Gretzky trade: "City of Champions"
CANADA             | after Gretzky trade: "City of Champignons"
-------------------+-------------------------------------------