[Info-vax] Hard links on VMS ODS5 disks
John Reagan
xyzzy1959 at gmail.com
Thu Jul 20 11:49:24 EDT 2023
And looking at GEM sources (no Macro code), I see way more things like
LOCAL SYM : REF GEM_SYMBOL_NODE INITIAL(0);
and uses of
RETURN .GEM_TB_IS_DECIMAL_TYPE[.SYM[GEM_SYM_DATA_TYPE]]
I don't see many random "pointers to integer" or "pointer to char"" (which isn't
easy to write in BLISS, you end up with REF VECTOR[,LONG] or REF VECTOR[,BYTE]
but have to keep using [0] all over the place)
And the C code has things like
GEM_ENTRY *entry = (GEM_ENTRY*) elfst_entry->Node();
if (entry == NULL) return NULL;
if (entry->Kind() != GEM_NODE_K_SYMBOL) return NULL;
if (entry->Subkind() != GEM_SYM_K_ENTRY) return NULL;
return entry->EntrySignature();
Neither have any size/position dependencies (other than BLISS-32 only does
32-bit values and switching to BLISS-64 sometimes can be tricky)
I do see several
GEM_UINT32*
declarations in the C code. Writing in C does "encourage" things like pointer to
int or pointer to char more than BLISS does (at least in my opinion)
More information about the Info-vax
mailing list