Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Sat, 01 Jun 2024 17:47:31 -0700
Organization: A noiseless patient Spider
Lines: 46
Message-ID: <8634pwp3vg.fsf@linuxsc.com>
References: <v2l828$18v7f$1@dont-email.me> <v30l15$3mcj6$1@dont-email.me> <v30lls$3mepf$1@dont-email.me> <v30sai$3rilf$1@dont-email.me> <v320am$1km5$1@dont-email.me> <v33ggr$e0ph$1@dont-email.me> <v34bne$i85p$1@dont-email.me> <v3758s$14hfp$1@raubtier-asyl.eternal-september.org> <v38of2$1gsj2$1@dont-email.me> <v39v87$1n7bk$1@dont-email.me> <20240530170836.00005fa0@yahoo.com> <v3a3k5$1ntrn$1@dont-email.me> <20240530180345.00003d9f@yahoo.com> <v3chc4$27uij$1@dont-email.me> <20240531161937.000063af@yahoo.com> <20240531162811.00006719@yahoo.com> <20240531164835.00007128@yahoo.com> <v3cldt$28n91$2@dont-email.me> <20240531173437.00003bee@yahoo.com> <v3d3ct$2b5sl$1@dont-email.me> <20240601211131.00001e16@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sun, 02 Jun 2024 02:47:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="487e0958afb8d1cfa0659a77e612b1fd";
	logging-data="3198066"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/+za9fT86Z3Qp3eDmTP55QkU2+6TkdcAc="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:dhbd4Tk+gcOmNzdqGORWjk2/hd8=
	sha1:3KzmGQb16C1zOrM7cNHo92RjN3o=
Bytes: 3883

Michael S <already5chosen@yahoo.com> writes:

> On Fri, 31 May 2024 19:03:10 +0100
> bart <bc@freeuk.com> wrote:
>
>> OK, thanks.  But I forget to ask what results you got from running the
>> program.  Because if I try your code, using hello.c and hello.exe as
>> test binary/source data, I get this output:
>>
>> _binary_test_bi_start                    00007ff6497620e0
>> 140695771160800 _binary_test_bi_end
>> 00007ff649762ae0 140695771163360 _binary_test_bi_size
>>     00007ff509750a00 140690402380288 _binary_bin_to_list_c_start
>>         00007ff649762ae0 140695771163360 _binary_bin_to_list_c_end
>>             00007ff649762b26 140695771163430
>> _binary_bin_to_list_c_size               00007ff509750046
>> 140690402377798
>>
>> The sizes should have been 2560 and 70 respectively;  those values are
>> bit bigger than that.
>
> That's strange.  I got expected results:
> _binary_test_bi_start                    000000013FDD30C0 5366427840
> _binary_test_bi_end                      000000013FDD67AC 5366441900
> _binary_test_bi_size                     00000000000036EC 14060
> _binary_bin_to_list_c_start              000000013FDD67AC 5366441900
> _binary_bin_to_list_c_end                000000013FDD711F 5366444319
> _binary_bin_to_list_c_size               0000000000000973 2419
>
>> However I see that you also have start and end addresses, which
>> sounds a much better way of determining the size.  (In that case, what
>> are those *size symbols for?).
>
> I'd guess, *_size is here for the benefit of less smart compilers that
> can not figure out that *_end - *_start is a connst expression
> and can not compile code like:
>
> static ptrdiff_t bar = _binary_test_bi_end - _binary_test_bi_start;

I wouldn't expect any C compiler to accept that.  It's not a constant
expression under the rules of the C standard, and there is no plausible
way to generate code for it in the context of compiling one translation
unit.  Neither gcc nor clang accepts it, even run without asking for
any standard compliance.  An implementation could allow it as an
extension, but there seems little reason to do so, because it would be
a lot of work to implement, and offers very little utility.