Re: C23 thoughts and opinions

On 01/06/2024 02:25, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

Little of this seems to work, sorry. You guys keep saying, do this, do
that, no do it that way, go RTFM, but nobody has shown a complete
program that correctly shows the -size symbol to be giving anything
meaningful.
>
If I run this:
>
     printf("%p\n", &_binary_hello_c_start);
     printf("%p\n", &_binary_hello_c_end);
     printf("%p\n", &_binary_hello_c_size);
>
I get:
>
     00007ff6ef252010
     00007ff6ef252056
     00007ff5af240046
>
I can see that the first two can be subtracted to give the sizes of the
data, which is 70 or 0x46. 0x46 is the last byte of the address of
_size, so what's happening there? What's with the crap in bits 16-47?
>
I can extract the size using:
>
    printf("%d\n", (unsigned short)&_binary_hello_c_size);
>
But something is not right. I've also asked what is the point of the
-size symbol if you can just do -end - -start, but nobody has explained.

 $ cat /tmp/m.c
#include <stdio.h>
#include <stdint.h>
 extern uint64_t _binary_main_cpp_size;
extern uint8_t *_binary_main_cpp_start;
extern uint8_t *_binary_main_cpp_end;
 int main()
{
     printf("%p\n", &_binary_main_cpp_size);
     printf("%p\n", &_binary_main_cpp_start);
     printf("%p\n", &_binary_main_cpp_end);
     return 0;
}
$ objcopy -I binary -B i386 -O elf64-x86-64 main.cpp /tmp/test.o
$ cc -o /tmp/m /tmp/m.c /tmp/test.o
$ /tmp/m
0x30e2
0x601034
0x604116
$ nm /tmp/m | grep _binary_main
0000000000604116 D _binary_main_cpp_end
00000000000030e2 A _binary_main_cpp_size
0000000000601034 D _binary_main_cpp_start
$ wc -c main.cpp
12514 main.cpp
$ printf 0x%x\n 12514
0x30e2
 The size symbol requires no space in the resulting
executable memory image, and it's more convenient than
having to do the math (at run time, since the compiler
can't know the actual values).

Here's my transcript:
-------------------------------------
C:\c>copy hello.c main.cpp         # create main.cpp, here it's 70 bytes
         1 file(s) copied.
C:\c>type m.c                      # exact same code as yours
#include <stdio.h>
#include <stdint.h>
extern uint64_t _binary_main_cpp_size;
extern uint8_t *_binary_main_cpp_start;
extern uint8_t *_binary_main_cpp_end;
int main()
{
     printf("%p\n", &_binary_main_cpp_size);
     printf("%p\n", &_binary_main_cpp_start);
     printf("%p\n", &_binary_main_cpp_end);
     return 0;
}
C:\c>objcopy -I binary -O elf64-x86-64 main.cpp test.o  # make test.o
C:\c>gcc m.c test.o -o m.exe       # build m executable
C:\c>m                             # run m.exe
00007ff5d5480046                   # and the size is ...
00007ff715492010
00007ff715492056
-------------------------------------
Maybe Windows is at fault? I'll try it under WSL:
-------------------------------------
root@DESKTOP-11:/mnt/c/c# objcopy -I binary -O elf64-x86-64 main.cpp test.o
root@DESKTOP-11:/mnt/c/c# gcc m.c test.o -o m
root@DESKTOP-11:/mnt/c/c# ./m
0x55effc9f2046
0x55effc9f6010
0x55effc9f6056
-------------------------------------
Nope, same thing. This doesn't inspire much confidence. With values shown, the actual size IS contained within the _size value, but only as the last 16 bits of the value.
gcc versions were 10.3.0 and 9.4.0 respectively; the latter is what is provided by Windows 11.
You also brought up the fact that the size is not known to the compiler anyway, which means a few things are not possible, like using the size in a static context.