Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!npeer.as286.net!npeer-ng0.as286.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: bart Newsgroups: comp.lang.c Subject: Re: C23 thoughts and opinions Date: Fri, 31 May 2024 22:15:54 +0100 Organization: A noiseless patient Spider Lines: 90 Message-ID: References: <20240530170836.00005fa0@yahoo.com> <20240530180345.00003d9f@yahoo.com> <20240531161937.000063af@yahoo.com> <20240531162811.00006719@yahoo.com> <20240531164835.00007128@yahoo.com> <20240531173437.00003bee@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Fri, 31 May 2024 23:15:53 +0200 (CEST) Injection-Info: dont-email.me; posting-host="eda9dc02d5cf6a1fd0c2e2f4ee7a7703"; logging-data="2526180"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19tD991LmoYJwM+8b6keXwJ" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:TuDaMQYXQzKS4FUad6QqT4rOpdc= Content-Language: en-GB In-Reply-To: Bytes: 4399 On 31/05/2024 19:36, Scott Lurndal wrote: > bart writes: >> On 31/05/2024 15:34, Michael S wrote: >>> On Fri, 31 May 2024 15:04:46 +0100 >>> bart wrote: > >> Instead of one compiler, here I used two compilers, a tool 'objcopy' >> (which bizarrely needs to generate ELF format files) and lots of extra >> ugly code. I also need to disregard whatever the hell _binary_..._size does. > > $ objcopy -I binary -O elf64-x86-64 main.cpp /tmp/test.o > > $ objdump -x /tmp/test.o > > /tmp/test.o: file format elf64-little > /tmp/test.o > architecture: UNKNOWN!, flags 0x00000010: > HAS_SYMS > start address 0x0000000000000000 > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .data 000030e2 0000000000000000 0000000000000000 00000040 2**0 > CONTENTS, ALLOC, LOAD, DATA > SYMBOL TABLE: > 0000000000000000 l d .data 0000000000000000 .data > 0000000000000000 g .data 0000000000000000 _binary_main_cpp_start > 00000000000030e2 g .data 0000000000000000 _binary_main_cpp_end > 00000000000030e2 g *ABS* 0000000000000000 _binary_main_cpp_size > > $ ls -l main.cpp > -rw-rw-r--. 1 scott scott 12514 May 9 2022 main.cpp > $ printf '%u\n' $(( 0x30e2 )) > 12514 > > The value of the symbol _binary_main_cpp_size is the > number of bytes in the file. > > (in other words, > > _binary_main_cpp_size = _binary_main_cpp_end - _binary_main_cpp_start > > ) > > In C code: > > extern uint8_t _binary_main_cpp_size; > > const size_t embed_size = &_binary_main_cpp_size; Did you see the output from my version of Michael S's program? The size is just an address. If I do what you do: extern unsigned char _binary_hello_c_size; ..... size_t size = &_binary_hello_c_size; printf("size: %zu\n", size); It produces: size: 140697695027270 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.