
-h- bugs	Tue Jan 20 11:02:55 1987	bugs

In <401.pixar.UUCP>, good@pixar gives us a nifty toy called "ncode".  I've 
recently hacked at it so it runs on VAXen under VMS 4.2.  We have version 2.2 
of the VAX/VMS C compiler.  I don't know if ncode.c will compile with any 
earlier versions.


There are some differences between the VMS version and the UNIX version.

As you may know, VMS is uses a record-oriented file system, rather than a 
stream-oriented one like UNIX.  If you look in init(), you'll see that
the UNIX code eats input files in one big gulp, while the VMS code takes
smaller bites.

Good@pixar sent me a change to allow you to put \'s in your output.  Just
preceed them with a |.  E.g.  printf("foo|\n"); in your input should come
out as printf("foo\n");

When I was testing this puppy, I wasn't sure it was reading the groups 
correctly, so I introduced another command-line option to help confirm or deny
my suspicions.  ncode -d codefile prints the groups and their contents before 
giving you the usual ncode output.

There are some bugs in my version.  I don't know if they exist in the original
version or not.

	1. It doesn't ignore blank lines.  They become part of a group.

	2. It treats multiple %'s as names of groups.  E.g.
			:
			:
		%
		#include ncode.sample2
		%
		CODE
			:
			:
		%
	   introduces a  group called "%" if the file ncode.sample2 ends in a %.

	3. The VAX/VMS linker spewls forth the following complaint.  I quote:
	  %LINK-W-MULPSC, conflicting attributes for psect DATA
		  in module SHELL$FIX_TIME file SYS$COMMON:[SYSLIB]VAXCRTL.OLB;1
	  %LINK-W-OVRALI, conflicting alignment on overlayed psect DATA
		  in module SHELL$FIX_TIME file SYS$COMMON:[SYSLIB]VAXCRTL.OLB;1

	   My system manager says it's DEC's fault, not mine.

