Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Fri, 11 Apr 2025 00:02:24 +0100
Organization: A noiseless patient Spider
Lines: 104
Message-ID: <vt9im1$1rdm$1@dont-email.me>
References: <vspbjh$8dvd$1@dont-email.me> <8634enhcui.fsf@linuxsc.com>
 <vsph6b$ce6m$5@dont-email.me> <86ldsdfocs.fsf@linuxsc.com>
 <20250406161323.00005809@yahoo.com> <86ecy5fjin.fsf@linuxsc.com>
 <20250406190321.000001dc@yahoo.com> <86plhodtsw.fsf@linuxsc.com>
 <20250407210248.00006457@yahoo.com> <vt15lq$bjs0$3@dont-email.me>
 <vt2lp6$1qtjd$1@dont-email.me> <vt31m5$2513i$1@dont-email.me>
 <vt3d4g$2djqe$1@dont-email.me> <vt3iqh$2ka99$1@dont-email.me>
 <868qoaeezc.fsf@linuxsc.com> <vt3oeo$2oq3p$1@dont-email.me>
 <86mscqcpy1.fsf@linuxsc.com> <vt48go$35hh3$2@dont-email.me>
 <86iknecjz8.fsf@linuxsc.com> <vt4del$3a9sk$1@dont-email.me>
 <86o6x5at05.fsf@linuxsc.com> <vt712u$1m84p$1@dont-email.me>
 <20250409170901.947@kylheku.com> <vt88bk$2rv8r$1@dont-email.me>
 <20250410092409.825@kylheku.com> <vt9334$3hhr8$1@dont-email.me>
 <20250410121454.392@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 11 Apr 2025 01:02:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="dd2082d654358406b52b51744c06eb0c";
	logging-data="60854"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+C5H22BVd1yos8Nq7+E4L6"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:SQxXcX3Ee1R72Tk7UFX7aNEXTHk=
Content-Language: en-GB
In-Reply-To: <20250410121454.392@kylheku.com>
Bytes: 6510

On 10/04/2025 20:29, Kaz Kylheku wrote:
> On 2025-04-10, bart <bc@freeuk.com> wrote:
>> ATEOTD, to share such a type across two or more translation units, means
>> each one seeing its own definition of it. Nothing stops you having
>> somewhat different versions of it, as I had above, so this part has to
>> be taken on trust. This was part of my broader point that sharing
>> non-linkage named entities across modules in C was ad hoc.
> 
> Nothing stops you because struct types are de-facto non-linkage
> entities in the toolchain technology that is in widespread use.
> 
> Nothing stops an implementation from recording, into object files, info
> that can be used to implement stricter type checking among
> translation units at link time.
> 
> Here is one possible implementation.
> 
> All file-scope struct/union types are compiled in some kind of
> struct/union table in the object file.
> 
> Those struct/union types are included which have been used as follows,
> either directly or via nesting:
> 
> - in a parameter type of an external linkage function;
> - in the return type of an external linkage function; or
> - in the type of an object declared with external linkage.
> 
> In the table we have entries, say, consisting of the tag and, say,
> tag name and, say, a 32 bit hash of the structure shape, taken over
> all the members: their names, types, alignment and everything else
> that influences compatibility.
> 
> Then, when linking, we merge all of the struct/union tables together.
> Whenever we see a tag that has a different 32 bit hash, that's a
> conflict, and we report those two files with the different hashes as
> conflicting on their definition of the type indicated by the tag name.
> 
> The diagnostic dcould be given in tabular form, e.g:
> 
>    error: 3 incompatible definitions of "struct foo" exist:
> 
>    1: foo.o foo-helper.o
>    2: bar.o
>    3: stack.o queue.o
> 
> The rules for which types are included in the tables allow uses
> where the types are not depended upon to be compatible.
> 
> Two mdoules can have a different "struct foo { ... }" at file scope,
> which they each only use locally: neither module passes an
> instance of its foo to the other module where it is interpreted
> as that module's foo.
> 
> These exchanges happen via the arguments of external functions,
> via global variables and via function returns. That's why we
> suspect those places.
> 
> The rules could give rise to false positives, like when the
> foo module has helper functions that take "struct foo *" and
> are not called from outside of the module, but the helpers have not been
> declared static, and another module does the same thing, creating a
> clash in the table entries.
> 
> That diagnostic would then be misleading; but it would still
> indicate that something is not tidy in the program.

That sounds quite ambitious, and lot of work for something that may or 
may detect type issues - at link time.

It involves a compiler infering the types that may be exported from a 
module, and writing it to a, presumably, standard format object file (I 
guess as some kind of extra global variable).

But then you want to get a linker to do the checking. Existing ones 
won't know anything about this.

If you're going to be doing heavyweight changes to an implementation, 
then it could worth think more deeply about what can be possible.

However this is going to be hamstrung by the language: non-linkage 
entities like macros, enumerations and types don't have any means to 
indicate that they are exported or imported. Especially macros which 
don't really exist after lexing, but which could be an essential part of 
some API.

Importing wouldn't actually be a thing at all; duplicates of the 
definitions that exist in the exporting modules must also exist in this 
translation unit.

I'm not entirely convinced by your scheme to detect candidates that 
might be exported, which is only for certain types anyway, and which 
ought to include function signatures. At present only function names are 
exported and imported.

(I'm aware of the C++ scheme that encodes signatures within function 
names; that sounds hacky. However that could conceivably be used to 
check passed struct types too.)

In short, I don't think it buys you enough for the effort. The schemes 
I'd be interested in would wrap or augment the language. They would 
provide error detection in the compiler. They would allow genuine 
sharing (a entity is defined in one place only).

Unless ... you've already implemented your proposal?