Path: ...!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Wed, 4 Dec 2024 10:54:14 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vipcck$36qpd$1@paganini.bofh.team>
References: <vi54e9$3ie0o$1@dont-email.me>   <20241129161517.000010b8@yahoo.com> <vicque$15ium$2@dont-email.me> <vid110$16hte$1@dont-email.me> <87mshhsrr0.fsf@nosuchdomain.example.com> <vidd2a$18k9j$1@dont-email.me> <8734j9sj0f.fsf@nosuchdomain.example.com> <vihhkj$2er60$1@dont-email.me> <vihjaj$2f79m$2@dont-email.me> <vihs4s$2hgg1$2@dont-email.me> <20241201185740.00004c30@yahoo.com> <viia55$2mrc9$1@dont-email.me> <vinftq$2sv5n$1@paganini.bofh.team> <vipap2$po6v$3@dont-email.me>
Injection-Date: Wed, 4 Dec 2024 10:54:14 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="3369773"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 4726
Lines: 77

David Brown <david.brown@hesbynett.no> wrote:
> On 03/12/2024 18:42, Waldek Hebisch wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 01/12/2024 17:57, Michael S wrote:
>>>> On Sun, 1 Dec 2024 15:34:04 +0100
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>>
>>>>> I can see some advantages in a language being happy with any order of
>>>>> function definition, without requiring forward declarations to use a
>>>>> function before it is defined.  But C is not like that, and I cannot
>>>>> honestly say it bothers me one way or the other.  And apparently, it
>>>>> does not particularly bother many people - there is, I think, no
>>>>> serious impediment or backwards compatibility issue that would
>>>>> prevent C being changed in this way.  Yet no one has felt the need
>>>>> for it - at least not strongly enough to fight for it going in the
>>>>> standard or being a common compiler extension.
>>>>>
>>>>>
>>>>>
>>>>
>>>> I think, arguing in favor of such change would be easier on top of
>>>> the changes made in C23.
>>>> Before C23 there were, as you put it "no serious impediment or
>>>> backwards compatibility issue". After C23 we could more categorical
>>>> claim that there are no new issues.
>>>>
>>>
>>> Does that mean there was something that you think was allowed in C
>>> before C23, but not after C23, that would potentially be a problem here?
>>>
>>> What, specifically, are you thinking of?
>> 
>> Michael probably meant 'constexpr'.  AFAICS the are on troubles with
                                                       ^^
                                                       no
>> automatic reordering of "pure" declarations.  But variable declarations
>> may have initialization and 'constexpr' allows not entirely trivial
>> expressions for initialization.  And C wants to be compatible with
>> C++, where even now initialization is much more "interesting".
>> 
>> So, reordering variable declarations is problematic due to
>> initalization and it would be ugly to have special case for
>> function declarations.
>>    
> 
> Prior to C23 you could have non-trivial expressions for initialisations 
> that depend on the order of the declarations in the code:
> 
>        enum { a = 1, b = 10, c = 100 };
>        const int y = (a * b) - (c / 10);
> 
> constexpr in C23 gives you a lot of flexibility to do more here, using 
> different types (not just "int").  Prior to C23, people would use 
> #define'd macros:
> 
>        #define pi 3.14159265359
>        const double zeta_2 = (pi * pi) / 6;
> 
> constexpr does not actually change the principles here, it just makes 
> them clearer and neater.
> 
> 
> Since macros are not scoped, and can be undefined and redefined, they 
> will always be an issue for any re-ordering of code.  Replacing such 
> "literal" macros with constexpr declarations would make it a lot easier 
> to support a single wide file-level scope where declaration order does 
> not matter, rather than making it harder.

From point of view of C standard, since macro expansion is logically
a separate pass, it poses no problem, simply macros should be expanded
before any possible reordering.

Concerning C23 versus earlier C, C23 confirmed earlier direction,
but already in earlier C reordering of function declarations
would create significant inconsistency.

-- 
                              Waldek Hebisch