Re: C23 thoughts and opinions

On Fri, 31 May 2024 13:55:33 +0100
bart <bc@freeuk.com> 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);
   }
>

No, it does not work like that.
First, copy *exactly* what I said in my previous post.
Only after you reproduced, start to be smart.
_binary_hello_c_size is a link simbol rather than variable.

Declaration:
extern char _binary_hello_c_size[];

Usage:
  printf("%zd\n", (size_t)_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.
 

The tool is not made specifically for ASCII strings, it is more generic.
I don't want it zero-terminated, the same as I don't want output of
fread() zero-terminated.  I want it exactly like it is in the
input file.

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.
 

It recognizes it if lye to objcopy about format.
Specify elf64-x86-64 instead of pe-x86-64 and everything suddenly
works.
It's all was said in my posts from yesterday. It does not sound like you
had read them.

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.