Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Thu, 10 Apr 2025 19:29:12 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <20250410121454.392@kylheku.com>
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>
Injection-Date: Thu, 10 Apr 2025 21:29:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e3007b402d1419a454483462709f55b6";
	logging-data="3827006"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/REKsURvZ5Zc8Ba/Dn0ELCiv5v+py/Dbs="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:gFTSQCAyGu5DFZPlOBFRY8y90AI=
Bytes: 4527

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.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca