# HG changeset patch
# User Me@portablequad
# Date 1329167428 28800
# Node ID 9b75ea156895661e29c0c8db2d5eef8c5c2c2e89
# Parent  093cad17d9923e999680681a388c9bbabbc4a922
added pure C brch

diff -r 093cad17d992 -r 9b75ea156895 .brch__default
--- a/.brch__default	Sat Feb 11 18:00:56 2012 -0800
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,1 +0,0 @@
-The default branch is for use with normal C code.  Other branches specialize the library for use with VMS..  they may need VMS header files, and the working directory may be located at various different positions relative to the VMS implementation.
\ No newline at end of file
diff -r 093cad17d992 -r 9b75ea156895 .hgignore
--- a/.hgignore	Sat Feb 11 18:00:56 2012 -0800
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,3 +0,0 @@
-syntax: glob
-
-*.o
diff -r 093cad17d992 -r 9b75ea156895 __brch__pure_C
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/__brch__pure_C	Mon Feb 13 13:10:28 2012 -0800
@@ -0,0 +1,6 @@
+
+This branch is for use in pure C code (*not* inside VMS-based language application code)
+
+There are two versions of the library -- one for pure C use, the other for use inside VMS or within applications written in a VMS-based language (IE, inside a top-level function or a call descendant of a top-level function) -- but only when the VMS is the "MC_shared" version.
+
+The reason is that VMS that uses shared memory on multicores moves the SlaveVPs around among cores.  But, the libC and glibC malloc stores info at the top of the stack (a "clever" hack), for a speed improvement.  So, when VMS manipulates the stack pointer, and/or moves Slaves to different cores, the "free" seg faults (that was FUN to figure out ; )  So, this version of VMS implements its own malloc. 
\ No newline at end of file