hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (05/10/89)
I am converting a set of programs containing a total of about
60,000 line of "standard" fortran code written for a VAX computer. The
following is typical of several hundred diagnostics I have encountered:
DOUBLE PRECISION NAME,NAMA,JTYPM,ISPEC
DATA IDNA,IRNA,ISPEC/4HD ,4HR ,8H$SPECIAL /
98. *********** DATA IDNA,IRNA,ISPEC/4HD ,4HR ,8H$SPECIAL / <===
***** Error number 78 in line 98 of file nucgen.for *****
***** Type conflict in DATA statement *****
VMS fortran allows a user to enter character data typed as logical,
byte, integer, real, double precision, dimension, probably complex and
the proper character type "character." VMS fortran allows character
data to be assigned to these alias types by arithmetic assignment or by
a data statement or non character functions or by using the read
statement.
The use of these Satanic extensions by the VMS implementation of Fortran
scores a 9.73 in the Fortran demolition derby; it is a robust attempt to
demolish the concept of typing! My compiler quite logically expects
character data to be typed "character." It is real shame that FORTRAN
is not a standardized language!
Being philosophical about this, I am reminded of the opening words in
"The Tale of Two Cities" by Charles Dickens: "It was the best of times,
it was the worst of times, ..." VMS fortran is the best of
compilers, it is the worst of compilers; a language standard is
intended to promote portability, it is intended to promote
profitability, ...
The VAX implementation gives new meaning to the term garbage collection.
Mixing good standards with bad and ugly non standard statements
scrounged from old compilers is an example of misoneism. It will
compiles everybodies old code. The basic idea is valid; however,
the incorporation of the garbage collector in a standards conforming
compiler is not. What is needed is an Exorcist section appended to
the standard. For example, I could have used an exorcism that
retyped the logical, real, double precision, and byte aliases for
character variables as truly character--not an easy task. The
Exorcist should produce a new source deck.
I think that it would be easier to depreciate old features from
a language if an Exorcist existed to do the job; especially a
public domain Exorcist.
----------------------------------------------------------------------
Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl
Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah
University of Maryland CoSy: ahybl
School of Medicine
Baltimore, MD 21201 Phone: (301) 328-7940 (Office)
----------------------------------------------------------------------weyrich@csun1.UUCP (Orville Weyrich) (05/11/89)
From article <592@mbph.UUCP>, by hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM): > VMS fortran allows a user to enter character data typed as logical, > byte, integer, real, double precision, dimension, probably complex and > the proper character type "character." VMS fortran allows character > data to be assigned to these alias types by arithmetic assignment or by > a data statement or non character functions or by using the read > statement. > > The use of these Satanic extensions by the VMS implementation of Fortran > scores a 9.73 in the Fortran demolition derby; it is a robust attempt to > demolish the concept of typing! My compiler quite logically expects > character data to be typed "character." It is real shame that FORTRAN > is not a standardized language! What you describe was correct FORTRAN-66, before a character data type existed. The VMS compiler would probably reject the program if you used the /STANDARD switch on the compiler. FORTRAN is a permisive standard that stresses what is required to be supported. It does not prohibit the support of extensions or anachronisms as long as they do not directly conflict with required features. I agree that a filter program that removes anachronisms would be nice, and I have played around with such things. But it is not an easy task. Consider for example one old program that I had the misfortune (more positively, the experience :-) of porting: It had an array of double precision values which was used for a symbol table. Some elements of the array stored character data and other elements stored double precision values. No way that that program could be redone using only standard FORTRAN-77 without completely rewriting the symbol table code (and this code was developed when the idea of data abstraction and information hiding etc. was not in vogue :-( ). Another problem is that automatic conversions often obfusacate the code even worse than it already is. For example, how would you translate arithmetic IF's, computed GOTO's, and assigned GOTO's without adding still more goto's and more IF ELSEIF ELSE statements? On the other hand, I would expect that it would be very easy to write a filter that "tokenized" FORTRAN source code so that a future revision of FORTRAN could do away with the archaic "blanks not significant" syntax. Unfortunately, this might break some existing preprocessors. You can't please everyone. -- Orville R. Weyrich, Jr. | UUCP : ...gatech!csun1!weyrich Department of Computer Science | INTERNET: weyrich@csun1.cs.uga.edu University of Georgia | Athens, GA 30602 USA | MA BELL : (404) 542-1082
hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (05/13/89)
From article <177@csun1.UUCP> by weyrich@csun1.UUCP (Orville Weyrich): > What you describe was correct FORTRAN-66, ... FORTRAN is a permissive > standard that stresses what is required to be supported. It does not > prohibit the support of extensions or anachronisms as long as they do > not directly conflict with required features. The ANSI X3.9-1978 FORTRAN language standard is explicit in the definition of integer, real, double precision and character types. Nowhere in the X3.9 standard is there any hint that integer, real or double precision variables can serve as character aliases. Indeed, to do so would directly contravene the type definitions. The standard has been in place for more than ten year. The character type statement was intended to supplant the multitude of aliases used in the then existing FORTRAN compilers. Do you think that the following program will will produce the answer: '120_miles' ? It compiles without diagnostics on a VAX! :-( double precision distance, time, speed time='2_hours' speed='60_mph' distance=time*speed print *, distance end The programs I am porting bear dates 1984-1986 not 1974. Perusal of the colorful VAX VMS FORTRAN Language Reference Manual divulges a description _with examples_ on how to use the Satanic character aliases. The description is not relegated to an appendix nor does it discourage the continued use of such coding. The implementors of the VAX VMS FORTRAN should be excoriated for promoting the perpetuation of such anachronistic coding practices. The _NEW WORLD DICTIONARY_ defines "standard" as (1) any figure or object, esp, a flag or banner, used as an emblem or symbol of a leader, people, military unit, [fortran language implementor], etc ... (2) something established for use as a rule or basis of comparison in measuring or judging capacity, quantity, content, extent, value, quality, [portability, readability, maintainability] ... Do you think that the second definition applies to the X3.9 FORTRAN language standard? Then read the following snippet. It was carefully crafted by the acolytes of Mammon. Although it provides me with the opportunity to rate different FORTRAN implementations in a demolition derby, it is the cause of the poor portability of FORTRAN programs. The X3J3 committee scores a perfect 10.00 for allowing implementors to add his/her flag to their products. Have you tried to install a VWvan wheel or glow plug on an International Harvester Travelall? : 1.3.2. _Exclusions_. This standard does not specify: : [...] : (4) The results when the rules of this standard fail : to establish an interpretation. : and: : 1.4. _Conformance_ : [...] : A processor conforms to this standard if it executes : standard-conforming programs in a manner that fulfills the : interpretations prescribed herein. A standard-conforming : processor may allow additional forms and relationships : provided that such additions do not conflict with the : standard forms and relationships. [...] >I agree that a filter program that removes anachronisms would be >nice, ... But it is not an easy task. ... Would it be challenging as a computer science project? I think I would like to see several user selectable exorcisms. They should be written in a portable language--like C, awk, SNOBOL or ICON :-)/2 ---------------------------------------------------------------------- Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah University of Maryland CoSy: ahybl School of Medicine Baltimore, MD 21201 Phone: (301) 328-7940 (Office) ----------------------------------------------------------------------
brainerd@unmvax.unm.edu (Walt Brainerd) (05/13/89)
In article <594@mbph.UUCP>, hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: > ... The X3J3 committee scores > a perfect 10.00 for allowing implementors to add his/her flag > to their products. > > : 1.3.2. _Exclusions_. This standard does not specify: > : [...] > : (4) The results when the rules of this standard fail > : to establish an interpretation. > : and: > : 1.4. _Conformance_ > : [...] > : A processor conforms to this standard if it executes > : standard-conforming programs in a manner that fulfills the > : interpretations prescribed herein. A standard-conforming > : processor may allow additional forms and relationships > : provided that such additions do not conflict with the > : standard forms and relationships. [...] > As usual, there are two sides to the coin. These items have been present in the Fortran standards from the beginning for very good reasons. It allows implementors (not just IBM and DEC, but people doing all kinds of experimental projects into which they want to embed Fortran) to add things to the language and still be standard. The standards committee is attacked frequently for "inventing new stuff" (it usually is not put this politely). This extension scheme allows "new stuff" to be tried out in real implementations providing a better chance of getting it right when it is standardized. Nice examples of extensions that didn't come primarily from major vendors occurred in the multitude of preprocessors in the 1970s. Their existence allowed me to argue (successfuly, of course) for putting the IF...ELSE IF..ELSE.. END IF into Fortran 77. Otherwise, it would not be there now. Of course, this puts the burden on the programmer to know what is standard and what is portable, but vendors are getting a little better about shading nonstandard things in their manuals. To help balance things a bit, the proposed 8x says a processor must contain "the ability to detect and report the use within a submitted program unit of an additional form or relationship that is not permitted by the numbered syntax rules or their constraints." Also a processor must have the capability of detecting obsolescent features. How this is done is _not_ specified; presumably it will be with a compiler option.
seibel@cgl.ucsf.edu (George Seibel) (05/13/89)
In article <594@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes:
]From article <177@csun1.UUCP> by weyrich@csun1.UUCP (Orville Weyrich):
]> What you describe was correct FORTRAN-66, ... FORTRAN is a permissive
]> standard that stresses what is required to be supported. It does not
]> prohibit the support of extensions or anachronisms as long as they do
]> not directly conflict with required features.
]
][the following] compiles without diagnostics on a VAX! :-(
]
] double precision distance, time, speed
] time='2_hours'
] speed='60_mph'
] distance=time*speed
] print *, distance
] end
]
]The programs I am porting bear dates 1984-1986 not 1974. Perusal
]of the colorful VAX VMS FORTRAN Language Reference Manual divulges
]a description _with examples_ on how to use the Satanic character
]aliases. The description is not relegated to an appendix nor does
]it discourage the continued use of such coding. The implementors
]of the VAX VMS FORTRAN should be excoriated for promoting the
]perpetuation of such anachronistic coding practices.
Well, Al, I gotta come clean here. The Satanic program came out
of our lab here at UCSF. Quite some while ago, I suggested in a
group meeting that we dump the Hollerith stuff. The response was
(a now infamous quote) "Hollerith was a great man. He should be
honored". Along with some laughter. What this really meant was
that no one felt like going through 40000 lines of code and doing it.
Some of the code dates back to the FORTRAN 66 days, and that's why it
looks the way it does. The '84-86 dates were just revisions.
I fully agree with you that the DEC VMS Fortran compiler is responsible
for some real porting headaches. When the orange manual actively
encourages the use of extensions, many of which have functional ANSI
equivalents, it is pretty clear to me that DEC hopes to keep you as
a customer. Nearly ALL compilers are extended in a variety of subtle
ways. This is understandably done because quite frankly the market demands
it. I do wish, however that vendors would clearly mark their language
manuals to indicate which language constructs are nonstandard. Some
vendors (e.g. Cray) do this. This to me is an indication of the high
ethical standard of that firm.
BTW, if you're willing to wait a couple of months, I'll be releasing
a new revision of Amber with avoidable machine dependencies removed.
The unavoidable ones will be well isolated. The remaining Hollerith
data will be of a form that most compilers will swallow (no guarantees,
though - I don't get paid for this).
And yes, I'll even fix the Satanic Nucgen :^)
George Seibel, UCSFhybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (05/30/89)
In article <92@unmvax.unm.edu> from brainerd@unmvax.unm.edu (Walt Brainerd) writes: >> ... The >> standards committee not the vendors must be responsive to market >> pressures--that is, if we want a _portable_ standard. > >One thing the vendors should understand better than >anyone else is market pressure > One thing the Army knows better than anyone else is warfare, but they are not allowed to declare WAR. One thing the our police know better than anyone else is crime, but they are not allowed to write criminal law. One thing that vendors could do is assist clients lobby the Standards Organization rather then running a NRA-like campaign for their own sub rosa agenda. >> ... Sections >> 1.3.2.(4) and 1.4 guarantee that the objective of portability will >> never be achieved! > >It can be achieved only (in the case of Fortran) by intelligent >programmers sticking to standard code with the help of the (new >in Fortran 8x) requirement on the processor to flag nonstandard >syntax, when requested to do so, and help in the form of shading >of nonstandard stuff in the vendor's manuals. > This is an excellent example of a calumniatory sentence. Notice the innuendo--ONLY STUPID PROGRAMMERS USE VENDOR EXTENSIONS! Those who crafted and espouse that statement want FORTRAN programmers to engage in internecine name calling. Let me restate: "Perusal of the colorful VAX VMS FORTRAN Language Reference Manual divulges a description _with examples_ on how to use the Satanic character aliases. The description is not relegated to an appendix nor does it discourage the continued use of such coding. The implementors of the VAX VMS FORTRAN should be excoriated for promoting the perpetuation of such anachronistic coding practices." Those who provided the programs I am porting should not interpret my pasquinading of the X3.9-1978 FORTRAN language standard in any way a criticism of their programming technique. In article <3728@s.cc.purdue.edu> from ags@s.cc.purdue.edu (Dave Seaman), writes: >Old-timers may recall that around 30 years ago, a satirical work >known as "The Computer Programmer's Coloring Book" was popular. > >On one of the pages was a picture of a stick man, with the caption: > > This is a FORTRANner. Color him naive. > Are you vaccinia naive? Let me rephrase:--Have you ever been given a smallpox vaccination? The objective of vaccination is to provide immunity to a specific disease by causing the formation of antibodies. Immunity can also be acquired by contracting and surviving an attach by the disease. Thirty years ago I was a naive FORTRANner working as a Post Doctoral student at Iowa State University. Programmers zealously tried to economize memory or reduce execution time. IBM provided FORTRANners an extension call Symbolic Assembly Procedures. By putting an "S" in column one, we could include a machine language instruction in-line along with a symbolic reference to an appropriate variable. That was a terrific idea. Symbolic Assembly Procedures invaded our code like a retrovirus attaching its victim. After about a year, Iowa State University acquired a new computer; its FORTRAN compiler did not provide Symbolic Assembly Procedures. The sudden withdrawal was painful and accompanied by distressing side effects; I woke up to the fact that IBM had made a _SAP_ of me. That is how I acquired the misoextension antibodies that help protect me against vendor extensions. I hope my experience will help others to understand why FORTRAN should be a portable language and not a plethora of vendor experiments. ---------------------------------------------------------------------- Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah University of Maryland CoSy: ahybl School of Medicine Baltimore, MD 21201 Phone: (301) 328-7940 (Office) ----------------------------------------------------------------------
hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (05/31/89)
In article <592@mbph.UUCP> from hybl@mbph.UUCP (Albert Hybl) writes ]I am converting a set of programs containing a total of about ]60,000 line of "standard" fortran code written for a VAX computer. ] While in article <11596@cgl.ucsf.EDU> from seibel@cgl.ucsf.edu, (George Seibel) writes >Well, Al, I gotta come clean here. The Satanic program came out >of our lab here at UCSF. Quite some while ago, I suggested in a >group meeting that we dump the Hollerith stuff. The response was >(a now infamous quote) "Hollerith was a great man. He should be >honored". Along with some laughter. ... >I fully agree with you that the DEC VMS Fortran compiler is responsible >for some real porting headaches. > George, I did not say and do not think that AMBER is Satanic. Indeed, I think it is an important contribution applicable to the study of molecular structure. I am infuriated because the X3.9-1978 standard has failed to provide us with a portable computer language and the tools with which to filter obsolete features. My quixotic rebuke was intended to be directed at the suicide clauses in the X3.9-1978 standard and the unhelpful contributions from the vendors. > ... What this really meant was >that no one felt like going through 40000 lines of code and doing it. Hmmm, why do I count 60,000 lines? The following table lists the subdirectories of Amber along with the line count for the source code files (*.ftn), the #include files (*.h) and the Makefiles. Where do we differ? *.ftn *.h Makefile anal 8072 24 91 dmin 5130 23 86 dyn 6182 38 89 edit 4825 67 85 etc 1592 7 77 link 2748 94 77 mdanal 8923 131 85 min 5503 32 93 nmode 4489 17 60 parm 2685 119 68 pol 4910 37 75 prep 2986 41 66 ========================== 58045 630 952 Total 59627 ~ 60,000 >BTW, if you're willing to wait a couple of months, I'll be releasing >a new revision of Amber with avoidable machine dependencies removed. Now you tell me--I've already converted most of it into a more portable format. ---------------------------------------------------------------------- Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah University of Maryland CoSy: ahybl School of Medicine Baltimore, MD 21201 Phone: (301) 328-7940 (Office) ----------------------------------------------------------------------
brainerd@unmvax.unm.edu (Walt Brainerd) (05/31/89)
In article <598@mbph.UUCP>, hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: > > One thing the Army knows better than anyone else is warfare, > but they are not allowed to declare WAR. > True, but maybe not relevant. If you are trying to make an analogy with the Fortran standards activity, you would be proposing that generals not sit on councils that advise people who declare war. Are you proposing that no vendors be allowed on standards committees? I don't see any way that could happen under our current system of standards making by ANSI, although, given what has happened to X3J3 over the last few years, it seems tempting. These years have convinced me that something should change, but I am not sure I have any specific proposals that are politically feasible. Would love to hear some. Incidentally, some of the vendors on X3J3 have been very supportive of the efforts and have made execellent contributions to the technical work. > This is an excellent example of a calumniatory sentence. Notice > the innuendo--ONLY STUPID PROGRAMMERS USE VENDOR EXTENSIONS! Wrong! IGNORANT programmers also use vendor extensions (there is a lot of difference). Also INTELLIGENT programmers use extensions when they need them to get a special job done. I believe there are some very useful things that do not belong in the standard (one reason being that they are not portable). Perhaps the user-defined character facility I mentioned previously is a good example. It is useful to certain groups of programmers, but is _not_ portable, and therefore does not belong in the standard. We seem to have two proposals (please don't anyone say these are MY proposals): 1) No vendors should be allowed on standards committees. If there is some more mellow variation of this, that might be interesting to hear. 2) The Fortran standard should state that the processor does not conform to the standard if it accepts extensions. I would like to see some rational discussion of these issues by other readers of these items. Another point to keep in mind is that adoption of (2) means that the standard would not be upward compatible with the previous standard. Remember what happened when we tried to schedule deletion of some important redundant features for the year 2030? Walt Brainerd brainerd@unmvax.unm.edu 505/275-0800
usenet@saturn.ucsc.edu (Usenet News Account) (05/31/89)
Organization: University of California, Santa Cruz; UCO/Lick Observatory Keywords: Compiler Warning Messages From: mongo@helios (Mongo Package) Path: helios!mongo In article <100@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: >In article <598@mbph.UUCP>, hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: >> the innuendo--ONLY STUPID PROGRAMMERS USE VENDOR EXTENSIONS! >IGNORANT programmers also use vendor extensions (there is a lot of >difference). Also INTELLIGENT programmers use extensions .... >We seem to have two proposals (please don't anyone say these are MY proposals): >1) No vendors should be allowed on standards committees. >2) The Fortran standard should state that the processor does not > conform to the standard if it accepts extensions. If the Fortran 8x standard ends up *requiring* that a Fortran compiler be able to generate Warning messages, then things are headed in the right direction. With such warnings, anyone who writes code that might ever be compiled by a different compiler can know about it. I would even prefer it if the warnings were ON by default. I make rather liberal use of the non-standard "include" statement in FORTRAN 77. I do this knowing that I would write a Pre-Processor to duplicate the "include" functionality if I were using a compiler which did not have it. The utility of "include" to me is sufficient that I would not mind having to watch Warning statements roll past on the screen. I prefer to think that this does not make me STUPID or IGNORANT. Finally, I personally think that any Fortran/FORTRAN compilers that accept Hollerith should be required to *ALWAYS* print a warning message. When an extension has been specifically DISALLOWED, the programmers should be forced to notice this Every Time the code is compiled. Vendors should look upon this as providing a service. Steve Allen No, my employer may not share these opinions.
hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (06/01/89)
In article <1515@hudson.acc.virginia.edu> from gl8f@bessel.acc.Virginia.EDU (Greg Lindahl), "A challenge" >If you can come up with an ANSI-Standard Approved Nutritious Scheme for >writing character data into binary files with real numbers, or putting >character data into commons with other data, let me know. ... ]khb%chiba@Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS) ]in message <105811@sun.Eng.Sun.COM> responds: ]?? this is perfectly allowed; viz. ] write(10) character*10,real*8,character*10 ]is legal in x3.9-1978. ] ], or putting ]>character data into commons with other data, let me know ] ]this (and equivalence) is what was disallowed. ] From the porting trenches, let me ask: can we read/write character information to and from a real array? First, let's answer: WHY DO IT? Scientist use names for the molecules with which they're working; they attach names to the residues from which the molecules are built; they assign names to the the atoms from which the residues are built; they identify the atom type with a atomic symbol. Because of the unpredictable size of a problem, the authors of the programs I am porting implemented a dynamic storage scheme that uses two large arrays--one REAL*4 and the other INTEGER*2. Since many of the names are four characters long, they were stashed into the REAL*4 array along with the atomic coordinates and all the other real REAL parameters. Ok, now lets see how this can be done without rewriting the dynamic storage scheme and without choking a standards conforming compiler. Let's try: CHARACTER*4 NAME REAL X(10) NAME = 'Na+ ' OPEN (UNIT=10,FORM='UNFORMATTED',FILE='F10',STATUS='NEW') WRITE (UNIT=10) NAME REWIND (UNIT=10) READ (UNIT=10) X(4) WRITE (*,FMT='(1X,A4)') X(4) ! Probably not standard and * is used here only for testing. CLOSE (UNIT=10,STATUS='DELETE') END This is, of course, an over simplified example. The binary write could be in a different program unit or a different program from the unit that does the binary read. The binary file is not portable between differing hardware types but is the source code? My SVS-fortran compiler think it's ok. The binary WRITE has expunged the character identification from the variable NAME; it becomes just a bit string. If the length of the bit string is compatible with the length of a REAL*4 variable, the READ binary stashes the bits into the REAL array element. -- We did it -- Right ??? .... Maybe not--from a private communication, I learned that there exists hardware specifically designed for floating point operations. Certain floating point registers will immediately normalize the values loaded into them because that is what they were designed to do. NORMALIZATION OF A REAL VARIABLE CONTAINING STASHED CHARACTER INFORMATION CAN DESTROY THE CHARACTER DATA! The FORTRAN compiler can be written to suppress the use of these registers when no floating point calculations are specified thus allowing a programmer to move character data around by using REAL or DOUBLE PRECISION variables. But will the next compiler you use be so thoughtful? The moral is: DON'T USE CHARACTER ALIASES! ---------------------------------------------------------------------- Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah University of Maryland CoSy: ahybl School of Medicine Baltimore, MD 21201 Phone: (301) 328-7940 (Office) ----------------------------------------------------------------------
hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (06/01/89)
In article <597@mbph.UUCP> from hybl@mbph.UUCP (Albert Hybl) I sited the following reference: >[See Hybl (1987) _Fortec Forum_ Vol 6, No 6 Pages 10-11]. ^ |_ wrong The reference should read: >[See Hybl,A. (December 1987) _Fortec Forum_ Vol 6, No 3 Pages 10-11]. Sorry. ---------------------------------------------------------------------- Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah University of Maryland CoSy: ahybl School of Medicine Baltimore, MD 21201 Phone: (301) 328-7940 (Office) ----------------------------------------------------------------------
zdenko@csd4.milw.wisc.edu (Zdenko Tomasic) (06/01/89)
Real/double precision/complex types are susceptable to normalization but integer ones are not, i.e. if you really must store characters in noncharacter types use integer type. On the other hand the integer size is implementation dependent, so doing the above is nonportable (there are machines with 2,4,6,8,10,.. etc bytes per integer). It is exactly for the latter reason that the CHARACTER type is invented. It pushes implementation part of the problem onto the compiler writer, so the source does appear implementation independent, i.e. portable (e.g. CHARACTER*11 will always behave as storing 11 characters regardless of the underlying word size). -- ___________________________________________________________________ Zdenko Tomasic, UWM, Chem. Dept., P.O. Box 413, Milwaukee, WI 53201 UUCP: uwvax!uwmcsd1!uwmcsd4!zdenko ARPA: zdenko@csd4.milw.wisc.edu