From Newsgroup: comp.lang.c

On 16/05/2026 23:03, fir wrote:

the fact that in c a language/compiler sees only functions or variables
that are up in code is a disaster

it is a disaster becouse it dont alow you to split code on N files
each file has realted functions and variables and not to care on the
global order of it

Are you talking about symbol conflicts when converting internal linkage
symbols to external linkage?

It is common among toolchain providers to give one the means to do that.
GCC, for example, has symbol visibility extensions.

You can also use a toolchain's linker to rename symbols, for example to
give them a namespace prefix, or use a C macro for extern linkage
symbols instead of literal identifiers throughout.
--
Tristan Wibberley

The message body is Copyright (C) 2026 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 17/05/2026 01:08, Bart wrote:

On 16/05/2026 23:03, fir wrote:

the fact that in c a language/compiler sees only functions or
variables that are up in code is a disaster

it is a disaster becouse it dont alow you to split code on N files
each file has realted functions and variables and not to care on the
global order of it

I mentioned something like this a week ago, suggesting that in C it was harder work than necessary to split one source file up into two or more.

However, some of the regulars here seemed to think it was a non-problem:

I've done it on the basis that when a subsystem is for a small program
(or is the entire program) it is a non-problem, when it is for a big
program then one may have bee selected or trained to account for the
pitfalls at the start or one may be writing anew with a boundary already analysed into one's work-package or (perhaps unknowingly) feeding into a toolchain that provides the necessary transparent modularity.

I can see how "developing" a program - ie, evolving from small
subsystems in small programs to large subsystems in large programs -
will have pitfalls and yet is obviously valuable.

I expect that has been solved with toolchains in the past because
linkers have, for a long time, had symbol rewriting features - and
curiously no corresponding debug rewriting - from which I infer they're
used at a delivery-integration in a development structure where
subsystem and unit test-cases against external linkage symbols are
distilled out of user defect-reports.
--
Tristan Wibberley

The message body is Copyright (C) 2026 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.
--- Synchronet 3.22a-Linux NewsLink 1.2