On 08/04/2025 09:12, David Brown wrote:
On 07/04/2025 20:31, bart wrote:
On 07/04/2025 19:02, Michael S wrote:
On Mon, 07 Apr 2025 05:45:19 -0700
Of course, proposals for similar feature in other procedural/imperative
language would not be totally different. Pascal is more similar to C
than many other procedural languages, so solution for Pascal would
likely be more similar to C than for example, stackless co-routines
that already exist in such languages like C# (that started current wave
of popularity of the feature) or Python.
However Pascal and C have enough not in common for significant
difference in proposed syntax and implementation. Specifically, in
Pascal:
- heap management is built-n in the language
- non-local goto is built-n in the language
>
That's news to me. But then I only used an educational version.
>
- nested procedures
- everything related to separated compilation of the translation units
is handwaved in the docs rather than strictly specified.
>
I don't think it's that strictly specified in C. Isn't it vaguely left to the implementation?
>
No.
C simply has the requirement for separate compilation of modules. Where does it specify how the implementation does that?
Much of how different units share macros, types, structs and enums isn't part of the language at all AFAICS: it's just a by-product of different modules happening to include the same header files.
>
Linkage is explained in 6.2.2 - only identifiers with external linkage are shared amongst translation units. Macros, types, enums are all have no linkage and are therefore never shared.
From the programmer point of view, they are shared. But the language provides no specific mechanism for that.
The only way to make new non-standard types in C is with "struct", "union" or "enum". Section 6.2.7 of the standard sets out simply and clearly what is required for two types in different translation units to be compatible. (It doesn't make sense to say they are the "same type" in C lingo, since types have no linkage, but compatibility is the important point.)
Sharing a definition in a header file is normally the easiest way to ensure that the types used in different translation files are compatible, but it is not required.
But it could also be done by repeating declarations in each module; it's rather ad hoc.
It is not remotely "ad hoc" - as far as the language is concerned, including a header file /is/ repeating the declaration in the different translation units.
The programmer can achieve the objective in multiple ways; that's what's ad hoc. The implementation itself works by crossing its fingers and hoping that the multiple declarations of the common entity X that are seen by the different translation unit are fully compatible.
But this need not be the case. For example this is module A:
--------------------------
#include <stdio.h>
typedef struct point {float a; float b;} Point;
float dist(Point);
int main(void) {
Point p = {3, 4};
printf("%f\n", dist(p));
}
--------------------------
And this is module B that defines 'dist':
--------------------------
#include <math.h>
typedef float length;
typedef struct _tag {length x, y;} vector;
length dist(vector p) {return sqrt(p.x*p.x + p.y*p.y);}
--------------------------
The types involved are somewhat different, but are compatible enough for it to work.
However, they could also be different enough (in a more elaborate example) for things to superficially work.
This is what I mean by 'ad hoc'.
This is how it looks when there is language support; first module A:
--------------------------
module b # (imports b)
proc main=
point p := (3, 4)
println dist(p)
end
--------------------------
Module B:
--------------------------
global record point = (real32 x, y)
global fun dist(point p)real32 = sqrt(sqr(p.x) + sqr(p.y))
--------------------------
(Example from one of mine, which uses whole-program compilation) Here, unlike C, you need to decide which module owns and exports the type. Then, there is only that one version which is shared.
However similar problems to C can occur when sharing across /programs/, which could be written in different languages (eg. libraries).
I don't know if or how the C standard addresses that, since it can only talk about the C language. For that matter, a single program with independently compiled modules might have only some of those in C.
So there is even more scope for ad hoc-ness.
The way C handles this kind of thing is arguably weaker than in languages that have proper modules (like Ada, or Modula 2), and much more open to mistakes. On the other hand, it is very flexible and simple to understand,
The preprocessor mechanisms available to work with source code are fairly easy to grasp (but may be complex in practice with multiple nested headers spread over a file system).
But I had, and do still have, difficulty with how exactly you import and export entities, even ones with linkage.
How compilers deal with it have changed. But right now, if I put this in a header shared by A and B modules:
int abc;
I get 'multiple definition' of abc (from some compilers; others have no problem).
If I stick 'extern' in front, I get 'undefined reference' of abc. To make it work, 'extern int abc' is shared, and one module must see 'int abc'.
However if I need to initialise the variable:
extern int table[]; // shared
int table[] = (10, 20, 30)
then other modules can't pick up length of the array.
and does not need additional
specialised object files or "interface" files. It is possible to write C code in an "ad hoc" manner (such as declaring an "extern" identifier within a C file rather than a header file), but the language definition is not "ad hoc".
So, what are the rules again for mixing 'extern' and 'static' declarations? Since this passes gcc:
static int def;
static int def;
extern int def;
static int def;
but this doesn't:
extern int def;
static int def;
static int def;
static int def;
Are you sure they aren't ad hoc? Simply saying that the C standard enumerates the legal combinations doesn't make them not so!
do { quit; } else { }
Re: do { quit; } else { }