From: cr88192@gmail.com   
      
   On 11/29/2025 3:06 PM, Philipp Klaus Krause wrote:   
   > Am 23.11.25 um 16:06 schrieb Michael S:   
   >>   
   >> Upper limit is implementation-defined.   
   >> On both existing implementations the limit (on 64-bit targets) appears   
   >> to be 2**16 or  2**16-1. I don't remember which one.   
   >   
   > Thisis comp.lang.c, not comp.lang.c++. There still are implementations   
   > of C other than GCC and clang. E.g. SDCC has a limit of 64.   
   >   
      
   Yes.   
      
   There are plenty of C compilers other than just GCC and Clang.   
      
   Main ones I am use being   
      GCC and Clang: Make most sense in WSL and similar;   
        GCC works OK as a cross-compiler for RISC-V and similar.   
        But, even then, still some rough edges IME.   
      MSVC, mostly for Windows Native development.   
        But, still lacks most newer features.   
        It took nearly 15 years to start adding C99 stuff.   
          Now at loosely mostly at C99 / C11 levels.   
      BGBCC: Custom compiler mostly for a custom ISA.   
        But can also target RISC-V, albeit using PE/COFF and some wonk.   
        Not meant to address the same use-cases as GCC or similar (*1)   
      
      
   *1: In cases where GCC or Clang serves the use-case, better to just use   
   these. I did my own compiler partly for historical reasons, it continued   
   on mostly as:   
      GCC and Clang are too large and painful to rebuild from source;   
      At the time, LCC wouldn't have really saved any effort.   
      
   Well, and partial reasons it gained RISC-V being:   
      My custom CPU core gained RV64 support;   
      I had already been using RV in a few other contexts;   
      GCC wasn't sufficiently addressing my uses.   
      
      
   Ironically, my compiler lacks an x86 or x86-64 backend mostly because   
   the use-cases I have for it don't really need it (and for what cases are   
   not addressed by MSVC or GCC or Clang or similar, are often addressed   
   well enough by using an ISA emulator; where a sensibly designed ISA can   
   also work well in a VM).   
      
   There was once an x86 backend, but it was lost a long time ago.   
      
      
   Though, for funky reasons, ironically a lot more recent work in the   
   compiler has been going into things like file-conversion and asset   
   packaging stuff (partly as "scope creep" had partly also led to it being   
   used as an asset packager and file converter). Well, and I also   
   sometimes have uses for an asset-packager tool (well, even if, say,   
   arguably a C compiler and asset packager are ideally separate tools, but   
   alas...).   
      
      
   Well, say:   
   It sometimes made sense to include files into the "resource section";   
   The original resource-section had been partly replaced with a WAD   
   variant. Derived from WAD2, just with a self-referencing header and lump   
   offsets based on RVA; the header including a self-reference to make it   
   easier to locate the image/RVA base if given a pointer to the header   
   (though can also locate the header if given the image base RVA). Though,   
   this was because the original resource-section used with PE/COFF kinda   
   sucked, and no real reason to use it if the target is not Windows.   
      
   In this case, it is a descendant of the WAD format used by Doom,   
   differing mostly in that while Doom WADs had 8 character names, WAD2 had   
   16 characters, and a few other features (but not that much fundamentally   
   different).   
      
   But, then one might want to develop an asset in one format (such as PNG)   
   but then put it in a resource in another format (such as 16 or 256 color   
   BMP), so it makes sense to have a converter. And, this is how it starts...   
      
      
   But, then also ended up with a WAD4 format, which was more advanced,   
   could function more like a VFS. Decided not to describe the WAD family   
   tree, but:   
   The basic idea of WAD originated in Doom and related games, and was   
   carried over (in a modified form to Quake 1 and Half-Life). Some of my   
   stuff uses a variant of the WAD2 format (from Quake), with some more   
   advanced scenarios using WAD4; which is in turn, a simpler and lower   
   overhead format if compared with using ZIP (Quake3 and Doom3 and   
   similar, followed by many newer projects, had went to using ZIP for a   
   VFS; but using ZIP in this way is needlessly complicated and expensive).   
      
   Though, in WAD4, it encodes the directory structure piecewise (by   
   organizing lumps into a tree structure), rather than expressing the full   
   path in a single name (as was done in PACK and the ZIP-based PK3 VFS).   
   In some cases, there are merits to breaking things up and using a   
   directory walk rather than a monolithic file path.   
      
   ...   
      
      
      
   > Philipp   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)