From 5d9eab1ecff829d868d28375696bd2fd99d0320c Mon Sep 17 00:00:00 2001 From: Andy McFadden Date: Wed, 26 Oct 2022 20:01:57 -0700 Subject: [PATCH] Update NuFX Addendum --- library/nufx-addendum.htm | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/library/nufx-addendum.htm b/library/nufx-addendum.htm index 31e8005..433beb8 100644 --- a/library/nufx-addendum.htm +++ b/library/nufx-addendum.htm @@ -24,7 +24,7 @@ -
NuFX Addendum - By Andy McFadden - Last revised 2022/10/07
+
NuFX Addendum - By Andy McFadden - Last revised 2022/10/26

This addendum clarifies and extends certain aspects of the NuFX specification. This is not an "official" modification @@ -128,10 +128,12 @@ with filenames in two places

The old way of storing filenames, used by NuLib and old versions of ShrinkIt, was to put the filename in the record header.  To facilitate renaming, the filename was moved into a thread.  Thus, there are two possible locations -where the filename may live, and no guarantee that only one will be used..

Creating: +where the filename may live, and no guarantee that only one will be used. +

Creating: Never put the filename in the record header when creating a new record.  It's okay to leave existing records alone, but if an application has the -opportunity to rewrite the record header, the record filename must be removed.

Extracting: +opportunity to rewrite the record header, the record filename must be removed. +

Extracting: The thread filename takes precedence over the record header filename.

@@ -156,7 +158,7 @@ truncate the filename; if they do, they must be prepared to handle duplicate or filenames.

 

-

File system separator characters

+

Filesystem separator characters

Every record header has a "file system separator" character ("fssep") in the "file_sys_info" word.  This is usually something like ':' for GS/OS or '/' for UNIX.  It's necessary to @@ -254,6 +256,7 @@ so such decisions must be based on the thread class and thread kind.

Filename threads and comment threads are pre-sized.  All other threads are not pre-sized (including other members of the "filename" and "message" classes).

+

 

Proper pre-size for filename threads

ShrinkIt allocates a 32-byte pre-sized buffer for the @@ -262,10 +265,17 @@ the filename exactly.  If renaming files is considered useful, then the buffer should always be slightly larger than is needed to hold the filename.  (Filenames longer than 32 characters are most likely the result of nested directories, so renaming the file itself is inhibited if the buffer -length is an exact match.) -

Side note: GSHK appears to have a bug where it can't deal with +length is an exact match.)

+ +

Side note: the specification does not specify a minimum or maximum length +for a filename. The specification notes that "GS/OS can create +8,000-character filenames", so that seems safe to use as an upper bound. +Zero-length filenames cannot be stored in a record header, because a length +of zero indicates that the filename is in a thread, so it's reasonable to +require that filenames be at least one character long. A zero-length filename +should be treated the same as a missing filename.

Creating: If GS/ShrinkIt compatibility is not important, all filenames should have at least 8 bytes of free space in the filename thread.  For GSHK compatibility, the filename thread compThreadEOF must be the greater of