Re: question about linker

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