From: bc@freeuk.com   
      
   On 25/10/2025 12:04, David Brown wrote:   
   > On 24/10/2025 20:50, bart wrote:   
      
   > You are getting worked up about some text output that scrolled   
   > "endlessly" for a minute and a half?   
      
   You don't know when it's happening how long it will end up taking.   
      
   In the past, and on a slower machine with a spinning hard drive, some   
   builds have taken the best part of an hour (one for a binary that would   
   have been only 0.5MB).   
      
   But on the same machine, my stuff still worked more or less instantly.   
      
      
   >> If I was directly building it myself, then I would use -s with gcc.   
   >> But since the process is automatic via makefiles, I assumed it would   
   >> give me a working, production version, not a version needing to be   
   >> debugged!   
   >>   
   >   
   > Actually, on closer checking (not because /I/ care, but because /you/   
   > apparently care) it was not debugging information, but all the linking   
   > and symbolic information that is a normal part of elf format files when   
   > they are built (allowing for incremental linking, using the files as   
   > static libraries for other programs, tracing the programs, fault-   
   > finding, etc.).   
      
    From looking at the C sources which are 50Kloc (68Kloc with headers),   
   I'd expect an executable for x64 to be upwards of 500KB. I think 600KB   
   was mentioned as the stripped size.   
      
   This is one way of spotting if an executable is unreasonably large. This   
   can be important, even if you have vast amounts of storage. For example,   
   it might have been tampered with somehow. In any case, it is suspicious   
   and worth investigating.   
      
   >> CDECL translates a single C type specification into linear LTR form.   
   >> Or vice versa. That's what nearly everyone needs it for, and why it   
   >> exists. Why, what other stuff does it do?   
   >>   
   >   
   > RTFM.   
      
   OK, it does rather more than the --help summary suggests. It includes   
   defining typedefs for example (I haven't tried it).   
      
   For my purposes, CDECL has always been buggy in the past and not so   
   useful (I used the online version).   
      
   In any case, sometimes you want to 'explain' some complex type in   
   someone else's code, which involves macros and/or typedefs defined 1000s   
   of lines earlier, or in some nested header.   
      
   Then you can't just extract the line and give it to CDECL.   
      
   This is why my older compiler included special directives that could be   
   temporarily inserted into the code, and would generate the info during   
   compilation.   
      
      
   >> So, it's a hundred times bigger than necessary due to C++. That   
   >> explains that then. (Sorry, 20 times bigger because whoever provided   
   >> the build system decided it should include debug info to make it 5   
   >> times as big for no reason.)   
   >   
   > It is not a program for expanding or explaining C declarations.  It is a   
   > program for expanding or explaining C and C++ declarations.  C++ is not   
   > "unnecessary", it is part of what it does.   
      
      
   This is another matter. The CDECL docs talk about C and C++ type   
   declarations being 'gibberish'.   
      
   What do you feel about that, and the *need* for such a substantial tool   
   to help understand or write such declarations?   
      
   I would rather have put some effort into fixing the syntax so that such   
   tools are not necessary!   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)