Re: C23 thoughts and opinions

On 31/05/2024 13:55, bart wrote:

On 30/05/2024 16:03, Michael S wrote:

On Thu, 30 May 2024 15:48:39 +0100
bart <bc@freeuk.com> wrote:
>

>
Where do the _binary_logo_bmp_start and ...-size symbols come from?
That is, how do they get into the object file.
>

>
objcopy generates names of the symbols from the name of input binary
file. I would think that it is possible to change these symbols to
something else, but I am not sure that it is possible withing the same
invocation of objcopy. It certainly is possible with a second pass.
Lawrence probably can give more authoritative answer.
Or as a last resort you can RTFM.
>

I gave myself the simple task of incorporating the source text of hello.c into a program, and printing it out.
 My C program looked like this to start, as an initial test (ignoring declaring the size as an array, unless I had to):
    #include <stdio.h>
   typedef unsigned char byte;
    extern byte _binary_hello_c_start[];
   extern int _binary_hello_c_size;
    int main(void) {
      printf("%d\n", _binary_hello_c_size);
   }
 One small matter is those ugly, long identifiers. A bigger one in this case is that I really want that embedded text to be zero terminated; here it's unlikely to be.
 However I still have to create the object file with the data. I tried this:
    objcopy -I binary -O pe-x86-64 hello.c hello.obj
 The contents looked about right when I looked inside.
 Now to build my program. Because my C compiler can't link object files itself, I have to get it to generate an object file for the program, then use an external linker:
    C:\c>mcc -c c.c
   Compiling c.c to c.obj
    C:\c>gcc c.obj hello.obj
   hello.obj: file not recognized: file format not recognized
   collect2.exe: error: ld returned 1 exit status
 Unfortunately gcc/ld doesn't recognise the output of objcopy. Even though it accepts the output of mcc which is the same COFF format.
 But even if it worked, you can see it would be a bit of a palaver.
 Here's how builtin embedding worked using a feature of my older C compiler:
    #include <stdio.h>
   #include <string.h>
    char hello[] = strinclude("hello.c");
    int main(void) {
       printf("hello =\n%s\n", hello);
       printf("strlen(hello) = %zu\n", strlen(hello));
       printf("sizeof(hello) = %zu\n", sizeof(hello));
   }
  I build it and run it like this:
    C:\c>bcc c
   Compiling c.c to c.exe
    C:\c>c
   hello =
   #include "stdio.h"
    int main(void) {
       printf("Hello, World!\n");
   }
    strlen(hello) = 70
   sizeof(hello) = 71
    C:\c>dir hello.c
   31/05/2024  13:48                70 hello.c
  It just works; no messing about with objcopy parameters; no long unwieldy names; no link errors due to unsupported file formats; no problems with missing terminators for embedded text files imported as strings; no funny ways of getting size info.
 

Now that is perfect use of the BabyX resource compiler. The programs to incorporate directories as C strings in C programs and mount them  are just going in. And I'm sure that with a bit of work I could set up some sort of system to make it easy to trawl the source tree of a program and icorpoorste its own source into it. Though you do have the problem that the XML of the source tree is itself source, and so of course this has to be excluded , or you get a problem of infinite self-reference.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm