IBIS meeting, resolution on CASE issue

From: Kellee Crisafulli, HyperLynx
To: IBIS All and Paul
Re: Resolution of the Case issue at the meeting on Friday, 3-17-95

We agreed that the some changes are needed to the new IBIS parser before
final release.

We also agreed that Paul should receive additional compensation for making
these changes.

The following changes are required in the new IBIS parser:
1) After a file name is read from the command line the file extesion should
   be tested to see if it is either .ibs or .IBS, if so attempt to open the
   file using the name as typed on the command line.
   If this fails because a file with this name is not present, convert the
   name and file extension to lower case and attempt to open the file again.
   If this fails because a file with this name is not present, convert the
   name and file extension to uppoer case and try again.
   If this fails, then report file not found.
   If any one of the three attempts to open the file succeed, then proceed
   to parse and check the file.

2) The program shall include a compiler switch to perform the following:

   1) If the file opens, and the name typed in on the command line is not
lower case
      and the parser was compiled for anything other than a DOS file system
computer,
      than the parser shall reported a warning to the user indicating the
file name
      should be lower case. (how is that for a long sentence).

   2) If the parser was compiled for a DOS file system computer than no warning
      should occur.

3) The above also applies to any file names referenced from within the file
   for example .pkg files in version 2.x IBIS. So three attempts to open the
   pkg file should be made, first as entered in the file, then as lower
case, then
   as upper case.

4) File names specified within the .ibs file must be lower case. This includes
   both the .ibs and .pkg file names. If they are not lower case a warning
should
   be issued indicating that file names should be lower case.
   (I believe we already have this warning. Paul please verify.)

5) The parser should issue ONE warning if any tab characters are found in
the file. The
   Warning should inform the user that 'IBIS files should not contain tab
characters'.
   This is to prevent problems with editors expanding tabs differently and
ending up
   with files with lines over 80 characters because tabs were expanded with
say 8
   characters instead of say 3 as the author intended.

6) The parser should also read files from either DOS or UNIX enviroments
without error.
   This probably requires the files to be opened in binary mode and a
special 'gets'
   function to be written which recognizes any of the following as an end of
line character:
     0x0d
     0x0a
     0x0d followed by 0a
     0x0a followed by 0d
   It was noted that files have been found which contain the following as an
end of line
   character: 0d0a for dos, or 0a for Unix and this causes the parser to
reject correct files.

7) The DOS end of file character 0x1a (control Z) should be ignored. This
is a problem for
   Unix versions of the parser reading a file from a DOS enviorment which
was transported without
   stripping the end of file character.

8) If a tab is found in an IBIS file it should be treated as ONE 0x20(space)
character. This
   applies both to counting the total number of characters on the line and
treating it as a
   a white space character. (I think the parser already does this. Paul
please verify).

Have a great day...Kellee Crisafulli, HyperLynx Inc.
Received on Fri Mar 17 23:50:53 1995