[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