From Newsgroup: comp.lang.c

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

you should not care becouse it has no sense those separate files are
then like in parralel dimensions and that is good (they will not go in conflict as it had to have unique names anyway)

the thing that yu need to care is some kind of bad annoying design flaw
as those historic goto abuse or other like that

So the solution is give at least compiler extension that would allow you
to have it changed that it see up and down

the fact thet this switch is not present is another flaw..so you have
two flaws here
--- Synchronet 3.22a-Linux NewsLink 1.2

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

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:

Keith Thompson:

If you have something to say about splitting a C translation unit

(something I don't think I've ever had a need to do), perhaps because
you've had difficulties doing so yourself, feel free to elaborate.

Scott Lurndal:

I don't recall refactoring existing code, primarily because the

original programmers used multiple translation units logically
dividing the code into functionly related segments, where necessary,
from the start.

Tim Rentch:

Having said that, I don't remember it ever being a big deal. If

some source file needs to be subdivided, you simply subdivide it
and move on.

Somebody never had to do it; somebody else said they get the perfect
split right from the start; and yet another said it was not a big deal.

So nobody is that bothered (or people are just conditioned to oppose
anything I say).

you should not care becouse it has no sense those separate files are
then like in parralel dimensions and that is good (they will not go in conflict as it had to have unique names anyway)

the thing that yu need to care is some kind of bad annoying design flaw
as those historic goto abuse or other like that

So the solution is give at least compiler extension that would allow you
to have it changed that it see up and down

the fact thet this switch is not present is another flaw..so you have
two flaws here

The context a week ago was that a module scheme would make refactoring
across files simpler. But you still need to manage visibility across the
new set of files.

Adding such a scheme to C would be a huge change.

However, doing away with forward references for functions within one
file, so that no local prototypes are needed, is doable and would be a significant convenience.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart <bc@freeuk.com> writes:

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.

And you offered no evidence for your claim, not even telling us
that you had tried it and found it difficult.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sun, 17 May 2026 00:03:40 +0200, fir wrote:

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

Back in those days, languages that needed multipass compilers (e.g.
Algol 68) were considered complicated and expensive to implement.
ThatrCOs why C went for a single-pass language design, like Pascal. And
like Pascal, it has forward declarations to mitigate this somewhat.

You need some kind of use-before-define facility in any realistic
language, if you want to allow recursion, and in particular mutual
recursion.

ItrCOs amusing to think that C++, that behemoth that, in terms of sheer complexity, leaves old-style monsters like Algol 68 or PL/I in the
dust, is still essentially a single-pass language design.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 17/05/2026 06:50, Lawrence DrCOOliveiro wrote:

On Sun, 17 May 2026 00:03:40 +0200, fir wrote:

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

Back in those days, languages that needed multipass compilers (e.g.
Algol 68) were considered complicated and expensive to implement.
ThatrCOs why C went for a single-pass language design, like Pascal. And
like Pascal, it has forward declarations to mitigate this somewhat.

You need some kind of use-before-define facility in any realistic
language, if you want to allow recursion, and in particular mutual
recursion.

ItrCOs amusing to think that C++, that behemoth that, in terms of sheer complexity, leaves old-style monsters like Algol 68 or PL/I in the
dust, is still essentially a single-pass language design.

The way it works in Python is peculiar. This fails for example:

def F():
G()

F()

def G():
print("G")

But it works if that F() call is moved to the end, even though G is
defined after F.

This is because 'def' is an executable statement, so executing 'def G'
before doing F() is sufficient to get G into the global symbol table.

All languages I develop have out-of-order definitions so this stuff is
never a problem.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 17/05/2026 02:21, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

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.

And you offered no evidence for your claim, not even telling us
that you had tried it and found it difficult.

Everyone here will know what is involved. But nobody wants to admit that
it can be onerous.

Here is a very simple example of one 'module', which involves two source files, 'a.h' and 'a.c':

====================
//a.h:

T C();
T D();

====================
// a.c:

#include a.h

static T A();
static T B();
static T E();
static T F();

T A(){}
T B(){}
T C(){}
T D(){}
T E(){}
T F(){}
====================

In this file, let's say that each function can call any other, so that
those forward declarations are needed. Two functions are also exported
to other 'source files'.

Suppose now I want to split 'a.c' into two files, a.c and b.c, exactly
in the middle so that A B C stay in a.c, and D E F go in b.c. You now
have to shuffle things around like this, ending up with 4 source files:

====================
//a.h:

T A();
T B();
T C();

====================
//a.c:
#include a.h
#include b.h

T A(){}
T B(){}
T C(){}

====================
//b.h:
T D()
T E()
T F()

====================
//b.c:

#include a.h
#include b.h

T D(){}
T E(){}
T F(){}
====================

I've kept it simple by having only functions, and ignoring variables,
types, enumerations, macros and #includes (maybe some functions need
that include, but not all).

Other files that previously included 'a.h', /may/ now also need 'b.h'
(if they call D, E or F). Or maybe they can drop 'a.h' if they don't
call A, B or C).

There may also be new global name clashes to sort out, say if A() was
already exported from elsewhere.

So, it's a bit messy. In my language with its module scheme, the
equivalent 'a' module might be:

====================
#a.m:

func A:T = end # (real code needs a suitable return value)
func B:T = end
global func C:T = end
global func D:T = end
func E:T = end
func F:T = end
====================

After the same split, you get these two files instead of one:

====================
#a.m:
global func A:T = end
global func B:T = end
global func C:T = end

====================
#b.m:
global func D:T = end
global func E:T = end
global func F:T = end
====================

The lead module needs this line added to project info: "module b".

There could also be clashes here with an existing A() for example, which
can either be renamed, or namespace qualifiers used (needed at all call-sites); or the two new modules can form their own private group.

(In that case, C and D need 'export' scope to be visible from outside as before.)

In this languages, variables, types, enumerations and macro are handled
with the exact same mechanism.

So, yes, I believe a decent module scheme means stuff like this is less
work than in C.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart pisze:

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.

ye i remember we afair both agree on that point even few years ago (that
it is bed - the fact you need to bother if it is up makes DEPENDENCY
more worse it is a CURSED DEPENDENCY

in this post above hovever i mentioned slightly other thing - that not
only this is bad (which was talken already) but that there is real need
for compiler extension/switch - i know it would violate standard c, but
there is a need a switch that violates c imo - for practicel reasons of
get rid of this annoyance
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart pisze:

static T A();
static T B();
static T E();
static T F();

T A(){}
T B(){}
T C(){}
T D(){}

imo the variables (call if file variables or block of code variables)
makes probably more problem than functions

good way of design is imo to have few functions and variables/arrays who
work on this together - like in small c file...in another file you make another set of functions and variables...bad design is to split those
variables out of its functions, and today i would need move the
variables like up (enforcing BAD DESIGN) of make extern declarations for visibility (enforcing even more BAD DESIGN imo) it also involves CODE
JUMPING which is BAD

solution - add this f**kin switch to compiler...what i said is
mathematical (logical) proof its bad design
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

Bart pisze:

static T A();
static T B();
static T E();
static T F();

T A(){}
T B(){}
T C(){}
T D(){}

imo the variables (call if file variables or block of code variables)
makes probably more problem than functions

good way of design is imo to have few functions and variables/arrays who work on this together - like in small c file...in another file you make another set of functions and variables...bad design is to split those variables out of its functions, and today i would need move the
variables like up (enforcing BAD DESIGN) of make extern declarations for visibility (enforcing even more BAD DESIGN imo) it also involves CODE JUMPING which is BAD

solution - add this f**kin switch to compiler...what i said is
mathematical (logical) proof its bad design

facing such proof its totally not important if
Keith Thompson, Scott Lurndal, Tim Rentch have different opinion, a
proof is a proof

and either youre burdened with bad design or you at leas make compiler
switch to take it out your back/neck :/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart <bc@freeuk.com> writes:

On 17/05/2026 02:21, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

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.

And you offered no evidence for your claim, not even telling us
that you had tried it and found it difficult.

Everyone here will know what is involved. But nobody wants to admit
that it can be onerous.

It could be onerous. The point is, in actual practice it almost
never is onerous.

Here is a very simple example [...]

The example is not evidence but a strawman argument. It just
doesn't match the experience of actual practice of other C
developers (speaking for myself, and other developers I have
known personally, and the comments of other newsgroup folks who
have participated in the conversation).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

Bart pisze:

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.

ye i remember we afair both agree on that point even few years ago (that
it is bed - the fact you need to bother if it is up makes DEPENDENCY
more worse it is a CURSED DEPENDENCY

in this post above hovever i-a mentioned slightly other thing - that not only this is bad (which was talken already) but that there is real need
for compiler extension/switch - i know it would violate standard c, but there is a need a switch that violates c imo - for practicel reasons of
get rid of this annoyance

note such dependencies are terrible becouse clen code is with minimal
clan dependencies (minimally needed) and also minimal code jumping


other important flaw is lack of what i call (not sure if proper)
aspect programming

if yu write a module/pice of code you need somewhat to integrate it with system..amd very often this integration is to add call to it in proper
place or two

it is annoying that you must travel there and add it it would be much
much more good if you could add this locally in the pice you write


its like

MainLoop()
[
//some things

.. <- you need to add function all here
}

so in language you need to define this point


MainLoop()
[
//some things

#bots
}

update_duck() @ bots
{

}

something like that though how it should look like exactly i dont know yet

i mention it here becouse there are some resemblances of bad design -
you need to have it to have good design imo (some culd say that having a
point where you dont see exlicitely what is called here is bad but imo
its worth and needed)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sun, 17 May 2026 06:48:06 -0700, Tim Rentsch wrote:

Bart <bc@freeuk.com> writes:

On 17/05/2026 02:21, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

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

fir, "You are doing it wrong".

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.

Bart, in reality, a smart developer almost never has to "split one source
file up into two or more". Instead, they /plan/ for isolation and encapsulation of the functional parts of their code, and /intentionally/ develop
multiple source files from the start. That's the way professionals do it.

You, for instance, might write the parser, calling external functions
to generate output code. For your purposes, those external functions
can be debugging stubs in a separate source or object module.
Fir, OTOH, might write the code generator functions, with a simple
debugging driver as a separate source or object module. Once both of
you have tested your parts to success, you can combine your two works,
with fir supplying the code generator and you the parser, to create a
single compiler program. None of this has to be "onerous". The hard
part is agreeing on the contract between your code and fir's code, and
that's part of what a professional does /before/ (s)he starts coding.

And you offered no evidence for your claim, not even telling us
that you had tried it and found it difficult.

Everyone here will know what is involved. But nobody wants to admit
that it can be onerous.

It could be onerous. The point is, in actual practice it almost
never is onerous.

Here is a very simple example [...]

The example is not evidence but a strawman argument. It just
doesn't match the experience of actual practice of other C
developers (speaking for myself, and other developers I have
known personally, and the comments of other newsgroup folks who
have participated in the conversation).

Agreed. Bart and fir have a "special" view of coding, which is
at odds with my 30+ years experience in the profession (and
my 20+ years of post-professional (amateur) programming.
--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Am 17.05.2026 um 07:50 schrieb Lawrence DrCOOliveiro:

ItrCOs amusing to think that C++, that behemoth that, in terms of sheer complexity, leaves old-style monsters like Algol 68 or PL/I in the
dust, is still essentially a single-pass language design.

Not absolutelty true because of this f.e.:

struct Class
{
int sum() { return a + b; }
int a, b;
}

This requires the compiler to do multiple passes.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 17/05/2026 15:43, Lew Pitcher wrote:

On Sun, 17 May 2026 06:48:06 -0700, Tim Rentsch wrote:

Bart <bc@freeuk.com> writes:

On 17/05/2026 02:21, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

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

fir, "You are doing it wrong".

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.

Bart, in reality, a smart developer almost never has to "split one source file up into two or more". Instead, they /plan/ for isolation and encapsulation
of the functional parts of their code, and /intentionally/ develop
multiple source files from the start. That's the way professionals do it.

You, for instance, might write the parser, calling external functions
to generate output code. For your purposes, those external functions
can be debugging stubs in a separate source or object module.
Fir, OTOH, might write the code generator functions, with a simple
debugging driver as a separate source or object module. Once both of
you have tested your parts to success, you can combine your two works,
with fir supplying the code generator and you the parser, to create a
single compiler program. None of this has to be "onerous". The hard
part is agreeing on the contract between your code and fir's code, and
that's part of what a professional does /before/ (s)he starts coding.

None of that is about taking one source file and splitting it, or taking multiple sources and combining them, which is where module support would
help.

Your example is simply about modular programming.

And you offered no evidence for your claim, not even telling us
that you had tried it and found it difficult.

Everyone here will know what is involved. But nobody wants to admit
that it can be onerous.

It could be onerous. The point is, in actual practice it almost
never is onerous.

Here is a very simple example [...]

The example is not evidence but a strawman argument. It just
doesn't match the experience of actual practice of other C
developers (speaking for myself, and other developers I have
known personally, and the comments of other newsgroup folks who
have participated in the conversation).

Agreed. Bart and fir have a "special" view of coding, which is
at odds with my 30+ years experience in the profession (and
my 20+ years of post-professional (amateur) programming.

I can't speak for fir. But it is very common in my work to start with a
module that does a specific job, and find it gets too large. Or I find
it is really two or more kinds of tasks, or task that can be segregated.
Both may demand a split.

It is also common to find some modules end up with not much in them and
can combined with each or each incorporated into another.

Yet another situation is where certain modules export functions for an
API, and it is convenient to combine all such functions into the same
module.

Or there might be a set of helper functions across modules, which can be combined into one support module.

Or, I want to port my app to another OS, and decide to collect
OS-specific routines into a dedicated OS-specific module which is easier
to swap with another.

Or I want to have multiple configurations of my app, and I want to
arrange it so that, switching configuration means swapping one
self-contained module for another.

There, you want common functions to stay within the main program (so no duplication).

An actual example from two of the my projects, is where I have a
compiler and an assembler, both generate EXEs and initially maintained
their own backends. I wanted them to share backend modules, but this
meant a lot of refactoring so that the assembler backend didn't see
references to the compiler front end and vice versa.


But I guess no amount of examples will cut any ice because your
experience is different, and that's the one that counts?

You always know right from the start of any project exactly what needs
to go where.

So, if your project is 50Kloc, say, split over 50 modules and 1000
functions, you write all 50K lines, including all the functions, data
types, global data, enumerations, imports, macros etc, before you even
submit it to a compiler.

Oh, you don't do that? So your projects can gradually evolve, converge
and diverge, make 3 steps forward and two back, algorithms etc can
change, just like everyone else's?

But you still know the exact layout from the outset!

Please accept that other people especially sole developers have
different working practices.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Lew Pitcher pisze:

On Sun, 17 May 2026 06:48:06 -0700, Tim Rentsch wrote:

Bart <bc@freeuk.com> writes:

On 17/05/2026 02:21, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

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

fir, "You are doing it wrong".

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.

Bart, in reality, a smart developer almost never has to "split one source file up into two or more". Instead, they /plan/ for isolation and encapsulation
of the functional parts of their code, and /intentionally/ develop
multiple source files from the start. That's the way professionals do it.

You, for instance, might write the parser, calling external functions
to generate output code. For your purposes, those external functions
can be debugging stubs in a separate source or object module.
Fir, OTOH, might write the code generator functions, with a simple
debugging driver as a separate source or object module. Once both of
you have tested your parts to success, you can combine your two works,
with fir supplying the code generator and you the parser, to create a
single compiler program. None of this has to be "onerous". The hard
part is agreeing on the contract between your code and fir's code, and
that's part of what a professional does /before/ (s)he starts coding.

And you offered no evidence for your claim, not even telling us
that you had tried it and found it difficult.

Everyone here will know what is involved. But nobody wants to admit
that it can be onerous.

It could be onerous. The point is, in actual practice it almost
never is onerous.

Here is a very simple example [...]

The example is not evidence but a strawman argument. It just
doesn't match the experience of actual practice of other C
developers (speaking for myself, and other developers I have
known personally, and the comments of other newsgroup folks who
have participated in the conversation).

Agreed. Bart and fir have a "special" view of coding, which is
at odds with my 30+ years experience in the profession (and
my 20+ years of post-professional (amateur) programming.

were talking here about pices of c code..name it c files for example

say you have N of such pices - when i code my app i got the pices just
as i sait ..one is for example setup_window.c another is timer.c another
is blitter.c and so on

each have set of functions and "global" variables related to
them..mostly to them but some of them also may be accesed by other
pices/files

if you have such system that those functions in each pice see all other
pieces up and down its ideal and proper situation becouse all thise
files like orthogonal one to another and thus like separated only they
see other by names


adding a rigiud constrain that you must keep that files in artifical
linear order from up to down ias absolute crazyy becuose

1) naturally given order dont exist
2) ist absolutly sill and tiresome to manage such stupid order


its absolute FLAW and its a disaster

bartc simplyhas a dose of intelligence to see it too (though such things
some may see in different extent..with time im even more angry than
before (when i was writing on this many years ago)

c also has other flaws (also mentioned) - language should be designed
such way not to make code jumping and unnecessary dependencies which
kill codes making work on it more tiresome and stupid
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 17/05/2026 17:24, fir wrote:

Lew Pitcher pisze:

Agreed. Bart and fir have a "special" view of coding, which is
at odds with my 30+ years experience in the profession (and
my 20+ years of post-professional (amateur) programming.

were talking here about pices of c code..name it c files for example

say you have N of such pices - when i code my app i got the pices just
as i sait ..one is for example setup_window.c another is timer.c another
is blitter.c and so on

each have set of functions and "global" variables related to
them..mostly to them but some of them also may be accesed by other pices/files

if you have such system that those functions in each pice see all other pieces up and down its ideal and proper situation becouse all thise
files like orthogonal one to another and thus like separated only they
see other by names

adding a rigiud constrain that you must keep that files in artifical
linear order from up to down ias absolute crazyy becuose

1) naturally given order dont exist
2) ist absolutly sill and tiresome to manage such stupid order

C does allow you to have them in arbitrary order.

But it means writing and maintaining function prototypes at the top of
the file. That is what's tiresome.

its absolute FLAW and its a disaster

bartc simplyhas a dose of intelligence to see it too (though such things some may see in different extent..with time im even more angry than
before (when i was writing on this many years ago)

c also has other flaws (also mentioned) - language should be designed
such way not to make code jumping and unnecessary dependencies which
kill codes making work on it more tiresome and stupid

My personal language allows anything to be defined in any order,
including types, variables, enums and macros, at module scope or inside
a function.

So if you wanted, you could define all local variables at the end of a function rather than at the top; in C syntax:

void GF() {
F(&x, &y, &z);
...
int x, y, z;
}

This doesn't look that useful at first, but in a current project where I
am generating code in that language, it is invaluable, as I don't know
exactly how many tempory variables need to be defined until I'm done generating code for the body.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart pisze:

On 17/05/2026 17:24, fir wrote:

Lew Pitcher pisze:

Agreed. Bart and fir have a "special" view of coding, which is
at odds with my 30+ years experience in the profession (and
my 20+ years of post-professional (amateur) programming.

were talking here about pices of c code..name it c files for example

say you have N of such pices - when i code my app i got the pices just
as i sait ..one is for example setup_window.c another is timer.c
another is blitter.c and so on

each have set of functions and "global" variables related to
them..mostly to them but some of them also may be accesed by other
pices/files

if you have such system that those functions in each pice see all
other pieces up and down its ideal and proper situation becouse all
thise files like orthogonal one to another and thus like separated
only they
see other by names


adding a rigiud constrain that you must keep that files in artifical
linear order from up to down ias absolute crazyy becuose

1) naturally given order dont exist
2) ist absolutly sill and tiresome to manage such stupid order

C does allow you to have them in arbitrary order.

But it means writing and maintaining function prototypes at the top of
the file. That is what's tiresome.

i know it as you for sure know i know it

if i wuld guess what is more nonsense keeping all in this up-down
artificil order (and constant trouble of managing it) or the adding
thos redundant not neede declaration (and this dependency)
i dont know but probably those declarations are even worse

1. you need to write them, move them up etc and this a lot of work
2. it spoils the fact that then you dont know which file this variable naturally belong
3. there could be differences between declaration and function and that
makes error

so
I. artifical up - down order is hell
II. artifical declarations are hell

no need to say more imo, case closed i would say, some should make this flag.switch that i could turn it on in compiler and stop to worry with
this up down shit

its absolute FLAW and its a disaster

bartc simplyhas a dose of intelligence to see it too (though such
things some may see in different extent..with time im even more angry
than before (when i was writing on this many years ago)

c also has other flaws (also mentioned) - language should be designed
such way not to make code jumping and unnecessary dependencies which
kill codes making work on it more tiresome and stupid

My personal language allows anything to be defined in any order,
including types, variables, enums and macros, at module scope or inside
a function.

So if you wanted, you could define all local variables at the end of a function rather than at the top; in C syntax:

-a-a void GF() {
-a-a-a-a-a-a F(&x, &y, &z);
-a-a-a-a-a-a ...
-a-a-a-a-a-a int x, y, z;
-a-a }

This doesn't look that useful at first, but in a current project where I
am generating code in that language, it is invaluable, as I don't know exactly how many tempory variables need to be defined until I'm done generating code for the body.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sun, 17 May 2026 14:43:28 -0000 (UTC), Lew Pitcher wrote:

Bart, in reality, a smart developer almost never has to "split one
source file up into two or more". Instead, they /plan/ for isolation
and encapsulation of the functional parts of their code, and
/intentionally/ develop multiple source files from the start. That's
the way professionals do it.

Meanwhile, back in the real world, programs evolve and need to adapt
to changes in the problems they were written to solve.

What starts out as one source file might later grow to two or more.
For instance, I start out with one program for performing the main
functions of my time-and-billing system, then later discover the need
for additional utilities driven by the same config settings: so this necessitates breaking out some common routines into a new module that
is common to all the executables.

ItrCOs called rCLrefactoringrCY.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <10uc81u$1kd2r$1@dont-email.me>, Bart <bc@freeuk.com> wrote:

On 17/05/2026 02:21, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

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.

And you offered no evidence for your claim, not even telling us
that you had tried it and found it difficult.

Everyone here will know what is involved. But nobody wants to admit that
it can be onerous.

Here is a very simple example of one 'module', which involves two source >files, 'a.h' and 'a.c':

[snip]

So, yes, I believe a decent module scheme means stuff like this is less
work than in C.

The example is you have two files, a.h and a.c; a.c has (say) a
bunch of `static`-qualified functions; obviously these are
file-scope, but have internal linkage. They can call each
other.

Now you split the file into two, and these functions need
external linkage and prototypes in a header file. Instead of
just creating a new `.c` file, you've got to change some stuff
in a header file (possibly newly created) as well.

I'll admit: you have a valid point.

Yes, this happens. I do it pretty frequently. It's a chore,
though I don't think it's quite as bad as you are making it out
to be; annoying, certainly, but probably not in my list of top
10, 15, or 20 annoyances about C.

But it is an annoyance, nonetheless.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 17/05/2026 18:56, Bart wrote:

On 17/05/2026 17:24, fir wrote:

Lew Pitcher pisze:

Agreed. Bart and fir have a "special" view of coding, which is
at odds with my 30+ years experience in the profession (and
my 20+ years of post-professional (amateur) programming.

were talking here about pices of c code..name it c files for example

say you have N of such pices - when i code my app i got the pices just
as i sait ..one is for example setup_window.c another is timer.c
another is blitter.c and so on

each have set of functions and "global" variables related to
them..mostly to them but some of them also may be accesed by other
pices/files

if you have such system that those functions in each pice see all
other pieces up and down its ideal and proper situation becouse all
thise files like orthogonal one to another and thus like separated
only they
see other by names


adding a rigiud constrain that you must keep that files in artifical
linear order from up to down ias absolute crazyy becuose

1) naturally given order dont exist
2) ist absolutly sill and tiresome to manage such stupid order

C does allow you to have them in arbitrary order.

But it means writing and maintaining function prototypes at the top of
the file. That is what's tiresome.

/If/ you want to write your functions in an arbitrary order, then you
need to declare your static functions before you use them. That is
certainly true.

But remember this is a personal preference for the way you want to write
code - arbitrary order of declarations and definitions is /not/
necessarily a good thing. I accept that you like it, and I appreciate
that you are not alone in that. But other people have different
preferences. I /like/ having a fixed order. I almost never declare
static functions, and when programming in a language that allows
arbitrary order (such as Python), I still order my code bottom-up. This
means when you look at my code, if you want to know the definition of an identifier, you only need to look in one direction - upwards.

I am not saying that this ordering is somehow universally or objectively better than arbitrary order. But I am saying that arbitrary order is
not universally or objectively better in a programming language.
Flexibility has its downsides, and there's a lot of personal opinion and preferences involved.

But I agree that if you use a language that has a "declare before use"
rule (as many languages do), and you want to write in an arbitrary
order, then it will involve extra effort. Such effort may be annoying,
but it is entirely self-imposed.

its absolute FLAW and its a disaster

bartc simplyhas a dose of intelligence to see it too (though such
things some may see in different extent..with time im even more angry
than before (when i was writing on this many years ago)

c also has other flaws (also mentioned) - language should be designed
such way not to make code jumping and unnecessary dependencies which
kill codes making work on it more tiresome and stupid

My personal language allows anything to be defined in any order,
including types, variables, enums and macros, at module scope or inside
a function.

So if you wanted, you could define all local variables at the end of a function rather than at the top; in C syntax:

-a-a void GF() {
-a-a-a-a-a-a F(&x, &y, &z);
-a-a-a-a-a-a ...
-a-a-a-a-a-a int x, y, z;
-a-a }

This doesn't look that useful at first, but in a current project where I
am generating code in that language, it is invaluable, as I don't know exactly how many tempory variables need to be defined until I'm done generating code for the body.

It does not just look useless at first sight, it looks horrible. But I
write my code myself, for the most part - generated code does not need
to be as easily read and understood. (I can't imagine how this
"feature" is useful for generating code - surely it would be negligible
effort to build up your list of variables as you build up the generated statements, and output the whole function in one lump. You are no
longer trying to fit this into a few KB of ram on a Z80.)

Much better, IMHO, is to use a language that lets you mix declarations
and statements as needed. I see declaring your local variables in a
list at the top of a function - or, far worse, at the bottom - as
archaic style.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/05/2026 01:30, Lawrence DrCOOliveiro wrote:

On Sun, 17 May 2026 14:43:28 -0000 (UTC), Lew Pitcher wrote:

Bart, in reality, a smart developer almost never has to "split one
source file up into two or more". Instead, they /plan/ for isolation
and encapsulation of the functional parts of their code, and
/intentionally/ develop multiple source files from the start. That's
the way professionals do it.

Meanwhile, back in the real world, programs evolve and need to adapt
to changes in the problems they were written to solve.

What starts out as one source file might later grow to two or more.
For instance, I start out with one program for performing the main
functions of my time-and-billing system, then later discover the need
for additional utilities driven by the same config settings: so this necessitates breaking out some common routines into a new module that
is common to all the executables.

ItrCOs called rCLrefactoringrCY.

Yes, I think some people have been overstating their claims that they
rarely or never split a source file into two or more parts. Certainly
with good planing you reduce the likelihood of having to split code
later, but it's rare that you start a project with a clear enough specification and that never changes during the lifetime of the code.

But I also think Bart is wildly overstating his claims of how much of an effort it is. Usually it's just something you do, without needing much
extra effort or risk - the thought and planning effort going in to how
you are doing your re-structure is the time-consuming part, not the
mechanical copy-and-paste or adding a couple of extern declarations to a
new header.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 17/05/2026 12:26, Bart wrote:

On 17/05/2026 06:50, Lawrence DrCOOliveiro wrote:

On Sun, 17 May 2026 00:03:40 +0200, fir wrote:

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

Back in those days, languages that needed multipass compilers (e.g.
Algol 68) were considered complicated and expensive to implement.
ThatrCOs why C went for a single-pass language design, like Pascal. And
like Pascal, it has forward declarations to mitigate this somewhat.

You need some kind of use-before-define facility in any realistic
language, if you want to allow recursion, and in particular mutual
recursion.

ItrCOs amusing to think that C++, that behemoth that, in terms of sheer
complexity, leaves old-style monsters like Algol 68 or PL/I in the
dust, is still essentially a single-pass language design.

The way it works in Python is peculiar.

No, the way Python works is quite simple. You declare things before you
use them. You just have to understand what "using" something means in
Python.

This fails for example:

-a def F():
-a-a-a-a-a G()

This declares "F", but does run the body of the code - so there is no
lookup of "G".

-a F()

Now you are trying to run "F()", and now "G" is found missing.

-a def G():
-a-a-a-a print("G")

But it works if that F() call is moved to the end, even though G is
defined after F.

Python is a "declare before use" language, like most imperative
languages. It just has a different meaning of "use" from C.

This is because 'def' is an executable statement, so executing 'def G' before doing F() is sufficient to get G into the global symbol table.

All languages I develop have out-of-order definitions so this stuff is
never a problem.

It's not a problem.

Your languages have oddities and unusual behaviour not commonly found in
other languages. If you like them, fine - that's your choice. But that
does not mean languages that do otherwise are a "problem".



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sun, 17 May 2026 17:56:03 +0100, Bart wrote:

C does allow you to have them in arbitrary order.

But it means writing and maintaining function prototypes at the top
of the file. That is what's tiresome.

Niklaus Wirth created a successor to Pascal which removed this
requirement. It was designed as a two-pass language, with declarations processed on the first pass and function/procedure bodies (statements)
on the second pass. So no forward declarations necessary, and mutual
recursion worked fine.

It was called Modula-2.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-05-18 08:56, David Brown wrote:

[...]

Much better, IMHO, is to use a language that lets you mix declarations
and statements as needed.

Indeed. But not "mixing" as a value per se, but to keep declarations
locally is a good thing, IMO.

I see declaring your local variables in a
list at the top of a function - or, far worse, at the bottom - as
archaic style.

Well, "archaic" expresses a time-related qualification. But even in
earlier times we saw, depending on the actual programming language,
both styles existing.

Anyway we need forward declarations or other means (e.g. multi-pass)
to make mutual recursions or circular data structures possible.

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-05-18 09:02, David Brown wrote:

On 18/05/2026 01:30, Lawrence DrCOOliveiro wrote:

[...]

ItrCOs called rCLrefactoringrCY.

Yes, I think some people have been overstating their claims that they
rarely or never split a source file into two or more parts.-a Certainly
with good planing you reduce the likelihood of having to split code
later, but it's rare that you start a project with a clear enough specification and that never changes during the lifetime of the code.

In C++ I had usually written a class first in one source file, tested
its basic function, and then separated the declaration in a header and
the implementation in a separate implementation file. It was just for convenience, and no issue at all, or rather trivial, to separate the
parts. That was no refactoring, though.

In real refactoring projects I've done _complex transformation_ tasks,
not just the mundane and trivial task of separating code across files.

But I also think Bart is wildly overstating his claims of how much of an effort it is.-a Usually it's just something you do, without needing much extra effort or risk - the thought and planning effort going in to how
you are doing your re-structure is the time-consuming part, not the mechanical copy-and-paste or adding a couple of extern declarations to a
new header.

Indeed. - Actually I'm unsure whether he's making up these statements
because he really has a mental problem and difficulties handling that,
or whether he has some satisfaction in making up peculiar claims just
for the sake of an argument.

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

David Brown pisze:

On 18/05/2026 01:30, Lawrence DrCOOliveiro wrote:

On Sun, 17 May 2026 14:43:28 -0000 (UTC), Lew Pitcher wrote:

Bart, in reality, a smart developer almost never has to "split one
source file up into two or more". Instead, they /plan/ for isolation
and encapsulation of the functional parts of their code, and
/intentionally/ develop multiple source files from the start. That's
the way professionals do it.

Meanwhile, back in the real world, programs evolve and need to adapt
to changes in the problems they were written to solve.

What starts out as one source file might later grow to two or more.
For instance, I start out with one program for performing the main
functions of my time-and-billing system, then later discover the need
for additional utilities driven by the same config settings: so this
necessitates breaking out some common routines into a new module that
is common to all the executables.

ItrCOs called rCLrefactoringrCY.

Yes, I think some people have been overstating their claims that they
rarely or never split a source file into two or more parts.-a Certainly
with good planing you reduce the likelihood of having to split code
later, but it's rare that you start a project with a clear enough specification and that never changes during the lifetime of the code.

But I also think Bart is wildly overstating his claims of how much of an effort it is.-a Usually it's just something you do, without needing much extra effort or risk - the thought and planning effort going in to how
you are doing your re-structure is the time-consuming part, not the mechanical copy-and-paste or adding a couple of extern declarations to a
new header.

some people here may live in 70-ties or 80-ties...

the splitinc code on small obj files was afait viable/apt
in 70 ties when compilations are probably thousnd times slower

now in 2026 on my not much stron pc i complile 400kb .c code
split in files (which is 20k lines and it was generated in 1-2 weeks
of work thanx to ai) in less than a second...

so reasons to split code on separate compilation units still may
are but for a codes possibly at least of size of few MB of source
- so very many cases there is a bit nonsense to split projects on
separate compilation units

so it may be seen that some here probably talk bulshit (if they talk it
as im not much reading into what who states precisely)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/05/2026 09:22, Janis Papanagnou wrote:

On 2026-05-18 08:56, David Brown wrote:

[...]

Much better, IMHO, is to use a language that lets you mix declarations
and statements as needed.

Indeed. But not "mixing" as a value per se, but to keep declarations
locally is a good thing, IMO.

Yes - it is not the mixing itself that is good, it is what it allows.
You get to keep your scopes small, you don't need to declare variables
until you have an initial value for them (who cares if reading an uninitialised variable is UB if you never have them!), and you can often declare your variables as const. That means it's easy to know what the variable holds because it is only set once, and never changed.

I see declaring your local variables in a list at the top of a
function - or, far worse, at the bottom - as archaic style.

Well, "archaic" expresses a time-related qualification. But even in
earlier times we saw, depending on the actual programming language,
both styles existing.

Sure. But in the C world, pre-C99 code is often written in a style with
local variables all declared at the top of the function - after C99, it
is common to declare them when you need them. So as a C programmer, I
see declaring local variables in one clump together as archaic.

(Of course there are situations where it makes sense to declare local variables without initial values.)

Anyway we need forward declarations or other means (e.g. multi-pass)
to make mutual recursions or circular data structures possible.

Of course.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-05-18 10:35, David Brown wrote:

[...]-a But in the C world, pre-C99 code is often written in a style with local variables all declared at the top of the function - after C99, it
is common to declare them when you need them.-a So as a C programmer, I
see declaring local variables in one clump together as archaic.

Ah, I forgot, even though I've learned "C" from K&R. - As soon as
it became possible I had switched to the local style; a no-brainer.

Janis

[...]

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/05/2026 08:38, Janis Papanagnou wrote:

On 2026-05-18 09:02, David Brown wrote:

On 18/05/2026 01:30, Lawrence DrCOOliveiro wrote:

[...]

ItrCOs called rCLrefactoringrCY.

Yes, I think some people have been overstating their claims that they
rarely or never split a source file into two or more parts.-a Certainly
with good planing you reduce the likelihood of having to split code
later, but it's rare that you start a project with a clear enough
specification and that never changes during the lifetime of the code.

In C++ I had usually written a class first in one source file, tested
its basic function, and then separated the declaration in a header and
the implementation in a separate implementation file. It was just for convenience, and no issue at all, or rather trivial, to separate the
parts. That was no refactoring, though.

In real refactoring projects I've done _complex transformation_ tasks,
not just the mundane and trivial task of separating code across files.

But I also think Bart is wildly overstating his claims of how much of
an effort it is.-a Usually it's just something you do, without needing
much extra effort or risk - the thought and planning effort going in
to how you are doing your re-structure is the time-consuming part, not
the mechanical copy-and-paste or adding a couple of extern
declarations to a new header.

Indeed. - Actually I'm unsure whether he's making up these statements
because he really has a mental problem and difficulties handling that,
or whether he has some satisfaction in making up peculiar claims just
for the sake of an argument.

Most modern languages allow out-of-order function definitions without
needing a forward declaration to make it possible. (Go which I just
tried also allows it with global variables at least.)

So lots of other people thought that was a jolly good idea.

Does that make /them/ mentally unstable? I guess they must have thought
the C model was lacking.

Do you think it is reasonable for me to suggest that you lot are
masochists for lightly dismissing the inconveniences of C?

Meanwhile C allows this:

void F(int c, int d);
void F(int a, int b) {}
void F(int, int a);
void F(int x, int y);
void F(int32_t z, int32_t);

int a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a;

Nothing to see here; please move on!

BTW, that last example is interesting:

static int a;
void F() {a;}

static int a;
void G() {a;}

Here the intention was that each function uses a private global
variable, but a mistake is made and they have identical names.

However, that is not an error in C. Maybe, at one point, each pair was
in a different source file, and then they were combined.

So is this a valid criticism of the way C works, or do you still think
I'm round the bend?

FWIW, I think you're the one who needs to see somebody; I mean,
constantly with the personal insults. What the hell is it with you?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/05/2026 02:22, Dan Cross wrote:

In article <10uc81u$1kd2r$1@dont-email.me>, Bart <bc@freeuk.com> wrote:

On 17/05/2026 02:21, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

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.

And you offered no evidence for your claim, not even telling us
that you had tried it and found it difficult.

Everyone here will know what is involved. But nobody wants to admit that
it can be onerous.

Here is a very simple example of one 'module', which involves two source
files, 'a.h' and 'a.c':

[snip]

So, yes, I believe a decent module scheme means stuff like this is less
work than in C.

The example is you have two files, a.h and a.c; a.c has (say) a
bunch of `static`-qualified functions; obviously these are
file-scope, but have internal linkage. They can call each
other.

Now you split the file into two, and these functions need
external linkage and prototypes in a header file. Instead of
just creating a new `.c` file, you've got to change some stuff
in a header file (possibly newly created) as well.

I'll admit: you have a valid point.

Yes, this happens. I do it pretty frequently. It's a chore,
though I don't think it's quite as bad as you are making it out
to be; annoying, certainly, but probably not in my list of top
10, 15, or 20 annoyances about C.

So you admit you have a list too! Mine had 100 items.

But it is an annoyance, nonetheless.

It would have been around 2013 that I decided to write my first big C
program. Still, I found the syntax unpalatable enough that I needed some
help. Macros couldn't do everything I wanted, so I decided to use a
script to convert annotated C code (ie. a thin syntax wrapper) to pure C.

Source files had a .cc extension. A file prog.cc might look like this:

#include "prog.cl"

global func int F(int a, b) =
switch (a)
when 1, 2 then
when 3 then
elsesw
endsw
end

proc G(int a, b) =
end

The generated .c file had to match lines 1:1 with the original so that
error reports from the C compiler would have the same .cc file number.

Three files were generated:

* prog.c which is submitted to the C compiler

* prog.cl which contained prototypes of all local functions (this
allows functions in any order), which is included in this file

* prog.cx containing prototypes of exported functions (included
in a project-wide header)

The output file prog.c from my example might look like this:

#include "prog.cl"

int F(int a, b) {
switch (a) {
break; case 1:case 2:
break; case 3:
break; default:
}
}

void G(int a, b) {
}

This is prog.cl:

static void G(int a, b);

And prog.cx:

extern int F(int a, b);

So, no manual writing of forward declarations. No manual maintainence of
a function signature in two places.

The scheme worked well enough for my 20Kloc application. But it only
fixed 10% of my grievances with C. In the end I decided (again) to
perservere with my language.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/05/2026 07:56, David Brown wrote:

On 17/05/2026 18:56, Bart wrote:

But it means writing and maintaining function prototypes at the top of
the file. That is what's tiresome.

/If/ you want to write your functions in an arbitrary order, then you
need to declare your static functions before you use them.-a That is certainly true.

-a I accept that you like it, and I appreciate
that you are not alone in that.-a But other people have different preferences.-a I /like/ having a fixed order.-a I almost never declare static functions, and when programming in a language that allows
arbitrary order (such as Python), I still order my code bottom-up.-a This means when you look at my code, if you want to know the definition of an identifier, you only need to look in one direction - upwards.

I am not saying that this ordering is somehow universally or objectively better than arbitrary order.-a But I am saying that arbitrary order is
not universally or objectively better in a programming language.
Flexibility has its downsides, and there's a lot of personal opinion and preferences involved.

But I agree that if you use a language that has a "declare before use"
rule (as many languages do), and you want to write in an arbitrary
order, then it will involve extra effort.-a Such effort may be annoying,
but it is entirely self-imposed.

In my C compiler project, there are nearly 3000 top-level functions, variables, types, enumerations, named constants and macros. That is,
declared at module scope, and including local and exported names.

(My non-C compiler generates that list which is picked up by my IDE.)

I really don't want the extra hassle of managing a dependency order. In
any case, there are also mutual out of order references.

So it is a necessity. Once you use such a language yourself, C will seem archaic.

So if you wanted, you could define all local variables at the end of a
function rather than at the top; in C syntax:

-a-a-a void GF() {
-a-a-a-a-a-a-a F(&x, &y, &z);
-a-a-a-a-a-a-a ...
-a-a-a-a-a-a-a int x, y, z;
-a-a-a }

This doesn't look that useful at first, but in a current project where
I am generating code in that language, it is invaluable, as I don't
know exactly how many tempory variables need to be defined until I'm
done generating code for the body.

It does not just look useless at first sight, it looks horrible.-a But I write my code myself, for the most part - generated code does not need
to be as easily read and understood.-a (I can't imagine how this
"feature" is useful for generating code - surely it would be negligible effort to build up your list of variables as you build up the generated statements, and output the whole function in one lump.-a You are no
longer trying to fit this into a few KB of ram on a Z80.)

It is for simplicity. I don't want an extra pass generating internal
data structures when I can just generate source text as I go. But then
some details are not known until later.

There are ways of injecting new text into an earlier spot, but they are
hairy. Since the target language has this feature, then why not use it?

Since either it has 'out-of-order' definitions, or it hasn't. In this
case it has.

Much better, IMHO, is to use a language that lets you mix declarations
and statements as needed.-a I see declaring your local variables in a
list at the top of a function - or, far worse, at the bottom - as
archaic style.

I allow definitions anywhere, including mixed with executable statements.

But I prefer to keep executable code clean and free of type-related
clutter, and to have separate summary of locals in one place.

This also allows easier transitioning between my static language, which
needs type annotations, and my dynamic one, which doesn't. Or porting to
other languages where details of my algorithm are relevant, but language specific types aren't.

I don't routinely declare locals at the end of a function. Especially if
they are initialised, as that assignment takes place at that spot. So
then placement is important.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <10uepa5$2dpee$1@dont-email.me>, Bart <bc@freeuk.com> wrote:

On 18/05/2026 02:22, Dan Cross wrote:

In article <10uc81u$1kd2r$1@dont-email.me>, Bart <bc@freeuk.com> wrote:

On 17/05/2026 02:21, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

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.

And you offered no evidence for your claim, not even telling us
that you had tried it and found it difficult.

Everyone here will know what is involved. But nobody wants to admit that >>> it can be onerous.

Here is a very simple example of one 'module', which involves two source >>> files, 'a.h' and 'a.c':

[snip]

So, yes, I believe a decent module scheme means stuff like this is less
work than in C.

The example is you have two files, a.h and a.c; a.c has (say) a
bunch of `static`-qualified functions; obviously these are
file-scope, but have internal linkage. They can call each
other.

Now you split the file into two, and these functions need
external linkage and prototypes in a header file. Instead of
just creating a new `.c` file, you've got to change some stuff
in a header file (possibly newly created) as well.

I'll admit: you have a valid point.

Yes, this happens. I do it pretty frequently. It's a chore,
though I don't think it's quite as bad as you are making it out
to be; annoying, certainly, but probably not in my list of top
10, 15, or 20 annoyances about C.

So you admit you have a list too! Mine had 100 items.

Of course. I never said that I did not.

Indeed, no one I've seen engage with you seriously recently has
suggested that they think C is perfect; most have said there are
things they wish were different about C.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/05/2026 12:57, Bart wrote:

On 18/05/2026 07:56, David Brown wrote:

On 17/05/2026 18:56, Bart wrote:

But it means writing and maintaining function prototypes at the top
of the file. That is what's tiresome.

/If/ you want to write your functions in an arbitrary order, then you
need to declare your static functions before you use them.-a That is
certainly true.

-a I accept that you like it, and I appreciate that you are not alone
in that.-a But other people have different preferences.-a I /like/
having a fixed order.-a I almost never declare static functions, and
when programming in a language that allows arbitrary order (such as
Python), I still order my code bottom-up.-a This means when you look at
my code, if you want to know the definition of an identifier, you only
need to look in one direction - upwards.

I am not saying that this ordering is somehow universally or
objectively better than arbitrary order.-a But I am saying that
arbitrary order is not universally or objectively better in a
programming language. Flexibility has its downsides, and there's a lot
of personal opinion and preferences involved.

But I agree that if you use a language that has a "declare before use"
rule (as many languages do), and you want to write in an arbitrary
order, then it will involve extra effort.-a Such effort may be
annoying, but it is entirely self-imposed.

In my C compiler project, there are nearly 3000 top-level functions, variables, types, enumerations, named constants and macros. That is, declared at module scope, and including local and exported names.

(My non-C compiler generates that list which is picked up by my IDE.)

I really don't want the extra hassle of managing a dependency order. In
any case, there are also mutual out of order references.

So it is a necessity. Once you use such a language yourself, C will seem archaic.

You are simply incorrect.

You have a personal style that is somewhat anarchic and you prefer to be
able to jumble your declarations around. Okay, I accept that's what you
like. But you are wrong to think it is somehow an objectively better
way to organise code or an objectively good language feature. You are
wrong to guess what I or anyone else might think or prefer.

You really need to stop assuming that you have found some kind of
nirvana of programming. All you have found is what you happen to like - nothing more than that.

So if you wanted, you could define all local variables at the end of
a function rather than at the top; in C syntax:

-a-a-a void GF() {
-a-a-a-a-a-a-a F(&x, &y, &z);
-a-a-a-a-a-a-a ...
-a-a-a-a-a-a-a int x, y, z;
-a-a-a }

This doesn't look that useful at first, but in a current project
where I am generating code in that language, it is invaluable, as I
don't know exactly how many tempory variables need to be defined
until I'm done generating code for the body.

It does not just look useless at first sight, it looks horrible.-a But
I write my code myself, for the most part - generated code does not
need to be as easily read and understood.-a (I can't imagine how this
"feature" is useful for generating code - surely it would be
negligible effort to build up your list of variables as you build up
the generated statements, and output the whole function in one lump.
You are no longer trying to fit this into a few KB of ram on a Z80.)

It is for simplicity. I don't want an extra pass generating internal
data structures when I can just generate source text as I go. But then
some details are not known until later.

I don't care. This is a limitation of your own making, and there is no
good technical reason for that limitation. So your "solution" to your
own invented problem does not provide any evidence or justification for
why declaring after usage is a useful feature in a language. Of course
you can make your own language the way you prefer, and use it the way
you want - but don't imagine that it is "better" in any sense, or that
others would also like it. Similarly, I don't claim to know that others
would /not/ like it - I can only answer for myself. And I can only
point to the strong bias of real-world imperative languages where
"declare before use" is the norm as an indication that people see that
as a better way for a language to work.

There are ways of injecting new text into an earlier spot, but they are hairy. Since the target language has this feature, then why not use it?

Since either it has 'out-of-order' definitions, or it hasn't. In this
case it has.

Much better, IMHO, is to use a language that lets you mix declarations
and statements as needed.-a I see declaring your local variables in a
list at the top of a function - or, far worse, at the bottom - as
archaic style.

I allow definitions anywhere, including mixed with executable statements.

But I prefer to keep executable code clean and free of type-related
clutter, and to have separate summary of locals in one place.

This also allows easier transitioning between my static language, which needs type annotations, and my dynamic one, which doesn't. Or porting to other languages where details of my algorithm are relevant, but language specific types aren't.

I don't routinely declare locals at the end of a function. Especially if they are initialised, as that assignment takes place at that spot. So
then placement is important.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Dan Cross pisze:

In article <10uepa5$2dpee$1@dont-email.me>, Bart <bc@freeuk.com> wrote:

On 18/05/2026 02:22, Dan Cross wrote:

In article <10uc81u$1kd2r$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >>>> On 17/05/2026 02:21, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

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.

And you offered no evidence for your claim, not even telling us
that you had tried it and found it difficult.

Everyone here will know what is involved. But nobody wants to admit that >>>> it can be onerous.

Here is a very simple example of one 'module', which involves two source >>>> files, 'a.h' and 'a.c':

[snip]

So, yes, I believe a decent module scheme means stuff like this is less >>>> work than in C.

The example is you have two files, a.h and a.c; a.c has (say) a
bunch of `static`-qualified functions; obviously these are
file-scope, but have internal linkage. They can call each
other.

Now you split the file into two, and these functions need
external linkage and prototypes in a header file. Instead of
just creating a new `.c` file, you've got to change some stuff
in a header file (possibly newly created) as well.

I'll admit: you have a valid point.

Yes, this happens. I do it pretty frequently. It's a chore,
though I don't think it's quite as bad as you are making it out
to be; annoying, certainly, but probably not in my list of top
10, 15, or 20 annoyances about C.

So you admit you have a list too! Mine had 100 items.

Of course. I never said that I did not.

Indeed, no one I've seen engage with you seriously recently has
suggested that they think C is perfect; most have said there are
things they wish were different about C.

in fast this "only see up" is on top or near top on that list..what you find worse?

i never make a list but this "see only up" is definitelly near top

other very annoing is that long x = 'dhbsf00d' is not standarized afaik
(such 8-char tags would be extremely handy sometimes)

also annoying is thet if {} has its own scope

also annoying if you cant foo( float x,y,z) {} (this ia somewhat
disputable if its allowed but x, y are ints but im not sure if it work
in today c

also annoying is that foo() {} has return type int instead of void
(though this could be eventually disputable)



annoying are also things that are not in c like "int x, y = foo(2,3);"
but those dont belong to that list
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

Dan Cross pisze:

In article <10uepa5$2dpee$1@dont-email.me>, Bart-a <bc@freeuk.com> wrote: >>> On 18/05/2026 02:22, Dan Cross wrote:

In article <10uc81u$1kd2r$1@dont-email.me>, Bart-a <bc@freeuk.com>
wrote:

On 17/05/2026 02:21, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

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.

And you offered no evidence for your claim, not even telling us
that you had tried it and found it difficult.

Everyone here will know what is involved. But nobody wants to admit >>>>> that
it can be onerous.

Here is a very simple example of one 'module', which involves two
source
files, 'a.h' and 'a.c':

[snip]

So, yes, I believe a decent module scheme means stuff like this is
less
work than in C.

The example is you have two files, a.h and a.c; a.c has (say) a
bunch of `static`-qualified functions; obviously these are
file-scope, but have internal linkage.-a They can call each
other.

Now you split the file into two, and these functions need
external linkage-a and prototypes in a header file.-a Instead of
just creating a new `.c` file, you've got to change some stuff
in a header file (possibly newly created) as well.

I'll admit: you have a valid point.

Yes, this happens.-a I do it pretty frequently.-a It's a chore,
though I don't think it's quite as bad as you are making it out
to be; annoying, certainly, but probably not in my list of top
10, 15, or 20 annoyances about C.

So you admit you have a list too! Mine had 100 items.

Of course.-a I never said that I did not.

Indeed, no one I've seen engage with you seriously recently has
suggested that they think C is perfect; most have said there are
things they wish were different about C.

in fast this "only see up" is on top or near top on that list..what you
find
worse?

i never make a list but this "see only up" is definitelly near top

other very annoing is that long x = 'dhbsf00d' is not standarized afaik (such 8-char tags would be extremely handy sometimes)

also annoying is thet if {} has its own scope

also annoying if you cant foo( float x,y,z) {}-a (this ia somewhat disputable if its allowed but x, y are ints but im not sure if it work
in today c

also annoying is that foo() {} has return type int instead of void
(though this could be eventually disputable)

annoying is alos that "'" dont work more like

if(a) a=3,c=3,print(2), x=10;

AND ye i forgot

b instead of *a.b THAT is annoying (esp im not sure does not a.*b is notjust avaliable?)

annoying are also things that are not in c like "int x, y = foo(2,3);"
but those dont belong to that list

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/05/2026 12:57, David Brown wrote:

On 18/05/2026 12:57, Bart wrote:

In my C compiler project, there are nearly 3000 top-level functions,
variables, types, enumerations, named constants and macros. That is,
declared at module scope, and including local and exported names.

(My non-C compiler generates that list which is picked up by my IDE.)

I really don't want the extra hassle of managing a dependency order.
In any case, there are also mutual out of order references.

So it is a necessity. Once you use such a language yourself, C will
seem archaic.

You are simply incorrect.

You have a personal style that is somewhat anarchic and you prefer to be able to jumble your declarations around.-a Okay, I accept that's what you like.

-a But you are wrong to think it is somehow an objectively better
way to organise code or an objectively good language feature.-a You are wrong to guess what I or anyone else might think or prefer.

You really need to stop assuming that you have found some kind of
nirvana of programming.-a All you have found is what you happen to like - nothing more than that.

This is more fundamental. You seem think all top-level entities, even
within one source file, need to be some sort of ordered set, which
depends on which interactions there may or may not be between then.

Interactions which can change as code is developed, which may require a
change in the order.

Nobody should really need to care about such things; they are plenty of
other matters to deal with.

You only thing it is a 'good' thing because C requires it.

If you were using a language where order didn't matter, would you go to
the same trouble?

Maybe some people prefer their functions in alphabetical order!

So it's not question of liking or not liking, but doing anyway with an irrelevant distraction.

In any case, when I look at open source C code, I do see loads of
forward function declarations, even for non-exported functions.

I guess not everyone is as meticuluous as you. So for those people,
needing those declarations is a nuisance.

It is for simplicity. I don't want an extra pass generating internal
data structures when I can just generate source text as I go. But then
some details are not known until later.

I don't care.-a This is a limitation of your own making, and there is no good technical reason for that limitation.-a So your "solution" to your
own invented problem does not provide any evidence or justification for
why declaring after usage is a useful feature in a language.-a Of course
you can make your own language the way you prefer, and use it the way
you want - but don't imagine that it is "better" in any sense, or that others would also like it.-a Similarly, I don't claim to know that others would /not/ like it - I can only answer for myself.-a And I can only
point to the strong bias of real-world imperative languages where
"declare before use" is the norm as an indication that people see that
as a better way for a language to work.

Same reasons as for the above for functions. I make much use of
enumerations for example, especially in table form where there are
parallel sets of data defined at the same time. Example:

enumdata []int promotions =
(ti8, ti64),
(ti16, ti64),
(ti32, ti64),
(ti64, ti64),
(tu8, tu64), ....
end

This defines enums ti8-ti64... which I want to be ordered that way,
while the parallel array gives the type it will be promoted to. But
'ti64' in those first three entries isn't defined until the fourth entry.

But a more typical example is simply where one table may refers to enums defined earlier, later, or in some other module.

Here again I simply do not want to worry about the order of the tables.
Maybe tables A, B, C all have references to each order, so it is
impossible to order them anyway.

Sure, there will be /some/ way to get around it in C, maybe involving
those lovely X-macros, but the point is /not needing to care or bother/.

People here always say, just write code clearly and in the most obvious
way, and the compiler will take care of making it efficient.

But when I try and do similar things, then Oh, it doesn't really matter!
It's not needed. I've never needed to do that. It's a minor annoyance.
You just do X, Y and Z, no problem. You're doing it wrong! You must be mentally ill to think that! (JP actually said this.)

You know, all it takes is to admit that out-of-order definitions can be
a desirable and convenient language feature. It's one that other
languages have, it's not something that only exists in my language
(though I take it a bit further).



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/05/2026 14:01, fir wrote:

fir pisze:

Dan Cross pisze:

i never make a list but this "see only up" is definitelly near top

other very annoing is that long x = 'dhbsf00d' is not standarized
afaik (such 8-char tags would be extremely handy sometimes)

I think you would have liked my language! That does have char constants
up to 'ABCDEFGH' (When I supported 128-bit types, up to 'ABCDEFGHIJKLMNOP'.)

C will support them up to 'int' width, which means 'ABCD' for 32-bit
int. In theory a C with a 64-bit int would allow longer constants, but
that's not going to happen on any common platforms.

As it is, even anything above 'A' is implementation-defined, unless C23
has changed that.

also annoying is thet if {} has its own scope

(My language only has a single function-wide scope.)

also annoying if you cant foo( float x,y,z) {}-a (this ia somewhat
disputable if its allowed but x, y are ints but im not sure if it work
in today c>> also annoying is that foo() {} has return type int instead of void
(though this could be eventually disputable)

Not sure what either of these mean.

annoying is alos that "'" dont work more like

if(a) a=3,c=3,print(2), x=10;

AND ye i forgot

b instead of *a.b THAT is annoying (esp im not sure does not a.*b is notjust avaliable?)

m is equivalent to (*P).m. However, (**Q).m cannot be reduced to

(*Q)->m; -> only fixes one level!

A post-fix '*' operator would mean being able to type P*.m and Q**.m.
You wouldn't really need -> here.

(My language uses post-fix '^' for derefs. However, the language allows
you to drop the explicit '^'; it will add in the derefs as needed.

That means those examples can be written as P.m and Q.m. This is very nice.

I was against allowing P->m in C to be written as P.m in C at one time,
but I've changed my mind; the cleaner code is too big an advantage.)

annoying are also things that are not in c like "int x, y = foo(2,3);"
but those dont belong to that list

Huh? This is legal C.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/05/2026 15:18, Bart wrote:

On 18/05/2026 12:57, David Brown wrote:

On 18/05/2026 12:57, Bart wrote:

In my C compiler project, there are nearly 3000 top-level functions,
variables, types, enumerations, named constants and macros. That is,
declared at module scope, and including local and exported names.

(My non-C compiler generates that list which is picked up by my IDE.)

I really don't want the extra hassle of managing a dependency order.
In any case, there are also mutual out of order references.

So it is a necessity. Once you use such a language yourself, C will
seem archaic.

You are simply incorrect.

You have a personal style that is somewhat anarchic and you prefer to
be able to jumble your declarations around.-a Okay, I accept that's
what you like.

-a But you are wrong to think it is somehow an objectively better way
to organise code or an objectively good language feature.-a You are
wrong to guess what I or anyone else might think or prefer.

You really need to stop assuming that you have found some kind of
nirvana of programming.-a All you have found is what you happen to like
- nothing more than that.

This is more fundamental. You seem think all top-level entities, even
within one source file, need to be some sort of ordered set, which
depends on which interactions there may or may not be between then.

I am telling you that the order within a source file comes from personal preference. Some people like a specific order - it makes the code
easier to navigate, and easier to understand. Some people prefer the
freedom to order any way they fancy as they go along.

There are occasions - a very small minority of cases - where you can't
have a fixed order because you have mutual references between functions
or data structures. That means you need some sort of forward
declaration mechanism. Such situations are rare in most code.

Interactions which can change as code is developed, which may require a change in the order.

Nobody should really need to care about such things; they are plenty of other matters to deal with.

You only thing it is a 'good' thing because C requires it.

Please stop doing that. As has been pointed out to you, your ability to understand other people or guess their reasoning is almost completely non-existent. Stopped clocks are better at guessing than you are.

And please stop insinuating that people in this group are lying to you
or inventing things just to disagree with you.

I have already said that when programming in a language where functions
can usually be ordered willy-nilly, I prefer to use a bottom-up
ordering. I've explained why I prefer that.

If you were using a language where order didn't matter, would you go to
the same trouble?

It is not "trouble" - I /choose/ bottom-up ordering, because I prefer
it. I think it makes code clearer and easier to navigate, both for
myself and for others.

Maybe some people prefer their functions in alphabetical order!

So it's not question of liking or not liking, but doing anyway with an irrelevant distraction.

The "trouble" or "distraction" is purely in your own mind.

That does not mean it is not real, for you. If you find it bothers you
to be unable to re-order functions (and other top-level entities)
freely, then the hassle is real - for you. And you are not alone in
your preferences. But that does not mean it is real for everyone else,
or that everyone else has the same preferences you do.

In any case, when I look at open source C code, I do see loads of
forward function declarations, even for non-exported functions.

Some people do write forward function declarations for static functions.
I don't - I find tracking and updating them to be an inconvenience and
a not insignificant source of inconsistency. But I can pretty much
guarantee that you do not understand /why/ some people choose to write
such declarations, because you appear to assume it is so that they can re-order their function definitions. That is no doubt the case for some people, but I think most people write such declarations because they
think it is helpful (to themselves, or to others reading the code) to
see a summary of the file's functions in one place.

I guess not everyone is as meticuluous as you. So for those people,
needing those declarations is a nuisance.

It is for simplicity. I don't want an extra pass generating internal
data structures when I can just generate source text as I go. But
then some details are not known until later.

I don't care.-a This is a limitation of your own making, and there is
no good technical reason for that limitation.-a So your "solution" to
your own invented problem does not provide any evidence or
justification for why declaring after usage is a useful feature in a
language.-a Of course you can make your own language the way you
prefer, and use it the way you want - but don't imagine that it is
"better" in any sense, or that others would also like it.-a Similarly,
I don't claim to know that others would /not/ like it - I can only
answer for myself.-a And I can only point to the strong bias of real-
world imperative languages where "declare before use" is the norm as
an indication that people see that as a better way for a language to
work.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart pisze:

also annoying if you cant foo( float x,y,z) {}-a (this ia somewhat
disputable if its allowed but x, y are ints but im not sure if it
work in today c>> also annoying is that foo() {} has return type int
instead of void
(though this could be eventually disputable)

Not sure what either of these mean.

i simply mean that repeating that float is annoying


Something(float x1, float y1, float x2, float y2 ) {}

should be

Something(float x1,y1,x2,y2 ) {}

esp if those last 3 are not ints by default in present c - it was in
old, but in present i dont remember

checked they are not

_WAVE_SAMPLES.C:62:18: error: unknown type name 'y'
void foo(float x,y,z) {}

in old c it would be disputable if foo(a,b,c) {} having a b c ints it is
not good but if it not work then thise repeating floats are annoying

one of two should work

void foo(float x,y,z) {}

either x y z are all floats or x float y z ints..

present compile error is bad

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart pisze:

AND ye i forgot

b instead of *a.b THAT is annoying (esp im not sure does not a.*b

is notjust avaliable?)

m is equivalent to (*P).m. However, (**Q).m cannot be reduced to

(*Q)->m; -> only fixes one level!

A post-fix '*' operator would mean being able to type P*.m and Q**.m.
You wouldn't really need -> here.

(My language uses post-fix '^' for derefs. However, the language allows
you to drop the explicit '^'; it will add in the derefs as needed.

That means those examples can be written as P.m and Q.m. This is very nice.

I was against allowing P->m in C to be written as P.m in C at one time,
but I've changed my mind; the cleaner code is too big an advantage.)

from sorta cpmpatibility only to repair flaws imo *a.b should work as
(*a).b and a.*b should work as *(a.b) i guess

if to skip pointers at all

void foo(int*a)
{
a=2; print(a); //woring as *a=2; print(*a);
}

im maybe not 100% sure but it seem im like 75% convinced that those
pointers in fact should be dropped

(i was writing back then on this but i dont remember fully my conclusions)

probbaly you should use labels a, and p instead of present *a, *p
and only at lace of definition it should be noted as pointer

float x = 3.4;
float* xf = &x;
xf+=0.1;


the usage of *xf has probably not much sense becouse you much more
operate on values even if you use pointers than on pointers itself

i know people often use

char *P = "akjsnjksnk";

while(*p++!=0) something;

but still imo use by value is more common

so it would be more

while(p!=0) { &p++; something; }

assuming you still use int*p; as a definition of pointer
and &p as deference to its addres value (which is not obvious becouse eventually one could use *p as a deference to pointer value - just
oposite it is now

int *P; - definition
p - pointer value,
*p - value

where it could be

int *P; - definition
p - value
*p - pointer value


this "swap" is probably quite sane

annoying are also things that are not in c like "int x, y =
foo(2,3);" but those dont belong to that list

Huh? This is legal C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart pisze:

annoying are also things that are not in c like "int x, y =
foo(2,3);" but those dont belong to that list

Huh? This is legal C.

ye i know , but it is probably not work like i would have

you can deturn structure like int2{int x, y;}

but as thsi structure is not builtin it makes a SIN/FLAW
of making unnecesary dependency (on structure definition)
alos makes unnecesary names and so on

you know that ** unnecesary dependencies are bad **, and
** unnesesary things (objects ) are bad **


(of i would like to return two values and assign it to two separate
variables)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/05/2026 15:39, fir wrote:

Bart pisze:

also annoying if you cant foo( float x,y,z) {}-a (this ia somewhat
disputable if its allowed but x, y are ints but im not sure if it
work in today c>> also annoying is that foo() {} has return type int
instead of void
(though this could be eventually disputable)

Not sure what either of these mean.

i simply mean that repeating that float is annoying

Something(float x1, float y1, float x2, float y2 ) {}

should be

Something(float x1,y1,x2,y2 ) {}

esp if those last 3 are not ints by default in present c - it was in
old, but in present i dont remember

checked they are not

_WAVE_SAMPLES.C:62:18: error: unknown type name 'y'
-avoid foo(float x,y,z) {}

in old c it would be disputable if foo(a,b,c) {} having a b c ints it is
not good but if it not work then thise repeating floats are annoying

one of two should work

-avoid foo(float x,y,z) {}

either x y z are all floats or x float y z ints..

present compile error is bad

OK, this actually what I posted about nearly 2 weeks ago:


BC:

Huh. This is C:

uint64_t F(uint64_t s, uint64_t t, uint64_t u, uint64_t v) ...

This is my language:

func F(u64 s, t, u, v)u64 ...

This is what Dan Cross said about that last line:

That's awful.

This is the typical attitude here to any such ideas.


As for the return type, I think that needs to be specified. As you
showed, it wasn't clear what it is, which is bad.

C is not high enough level to do type inference, but even if it was,
users would need to apply the same algorithms, and do the same analysis,
to figure out what some return type actually was. It's better to just
state it.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/05/2026 15:59, fir wrote:

Bart pisze:

AND ye i forgot

b instead of *a.b THAT is annoying (esp im not sure does not a.*b

is notjust avaliable?)

m is equivalent to (*P).m. However, (**Q).m cannot be reduced to

(*Q)->m; -> only fixes one level!

A post-fix '*' operator would mean being able to type P*.m and Q**.m.
You wouldn't really need -> here.

(My language uses post-fix '^' for derefs. However, the language
allows you to drop the explicit '^'; it will add in the derefs as needed.

That means those examples can be written as P.m and Q.m. This is very
nice.

I was against allowing P->m in C to be written as P.m in C at one
time, but I've changed my mind; the cleaner code is too big an
advantage.)

from sorta cpmpatibility only to repair flaws imo *a.b should work as
(*a).b and a.*b should work as *(a.b) i guess

That would need to apply also to *a[i]. It means completely changing the relative precedences of deref '*' and of "." and of "[]" (I don't know
about "()").

It would also means half of all type declarations needing to be updated,
if there was to be the same relation between declarations and expressions.

Unless the context here is a new, incompatible version of C? Then you
can do what you like.

if to skip pointers at all

void foo(int*a)
{
-a a=2; print(a); //woring as *a=2; print(*a);
}

The 'a=2' might be OK. Since the LHS has type 'pointer to int', and RHS
has 'int', it can make it apply the right number of derefs.

(This is how Algol68 works, the language I based by own syntax on. But I
only copied syntax, not semantics since that had a lot of complex
behaviour.)

The 'print(a)' is harder, as you can't tell if you want to print the
value of the pointer, or what is points to.

The places I drop it in my language are these:

P^[i] -> P[i]
Q^.m -> Q.m
R^(x) -> R()

since there is no ambiguity. P by itself is the pointer, and P^ is what
it points to.

im maybe not 100% sure but it seem im like 75% convinced that those
pointers in fact should be dropped

(i was writing back then on this but i dont remember fully my conclusions)

probbaly you should use labels a, and p instead of present *a, *p
and only at lace of definition it should be noted as pointer

float x = 3.4;
float* xf = &x;
-a-a xf+=0.1;

Tricky one. Of that was 1 on the RHS, then 'xf += 1' might increment the pointer, or it might increment the float it points to. So ambiguous.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

Bart pisze:

AND ye i forgot

b instead of *a.b THAT is annoying (esp im not sure does not a.*b

is notjust avaliable?)

m is equivalent to (*P).m. However, (**Q).m cannot be reduced to

(*Q)->m; -> only fixes one level!

A post-fix '*' operator would mean being able to type P*.m and Q**.m.
You wouldn't really need -> here.

(My language uses post-fix '^' for derefs. However, the language
allows you to drop the explicit '^'; it will add in the derefs as needed.

That means those examples can be written as P.m and Q.m. This is very
nice.

I was against allowing P->m in C to be written as P.m in C at one
time, but I've changed my mind; the cleaner code is too big an
advantage.)

from sorta cpmpatibility only to repair flaws imo *a.b should work as
(*a).b and a.*b should work as *(a.b) i guess

if to skip pointers at all

void foo(int*a)
{
-a a=2; print(a); //woring as *a=2; print(*a);
}

im maybe not 100% sure but it seem im like 75% convinced that those
pointers in fact should be dropped

(i was writing back then on this but i dont remember fully my conclusions)

probbaly you should use labels a, and p instead of present *a, *p
and only at lace of definition it should be noted as pointer

float x = 3.4;
float* xf = &x;
-a-a xf+=0.1;

the usage of *xf has probably not much sense becouse you much more
operate on values-a even if you use pointers than on pointers itself

i know people often use

char *P = "akjsnjksnk";

while(*p++!=0) something;

but still imo use by value is more common

so it would be more

while(p!=0) { &p++; something; }

assuming you still use int*p; as a definition of pointer
and &p as deference to its addres value (which is not obvious becouse eventually one could use *p as a deference to pointer value - just
oposite it is now

int *P; - definition
p - pointer value,
-a*p - value

where it could be

int *P; - definition
p - value
-a*p - pointer value

this "swap" is probably quite sane

this would hovewer reduce arrays arithmetic becouse
it tab is an array then tab would mean value of an array
(block of many bytes)

then tab+2 has no sense (unles treating it as tab block plus one byte or
int more, which is no nonsense imo .. like tab + "something", tab +1.0+'a'+0xff; )

*tab+2 then has sense as pointer to tab increased by 2 but then there is
no imediate way to drop the pointer to get value, unles introducing
special syntax or assigning it to value

char * p = *tab+2; p is a third byte of tab


as for now this swapped pointer seem more logical to me that this from
old c probbaly - that would get rid of many pointer seen in c code i guess

wonder if then if i got this eswpapped pointers

int* p ;

then p could/should be name as reference (is such swpapped pointer a reference?)

btw

int* p = 2; would mean p value is 2

so question does it much differ form

int p =2; ??

int *p = a; would mean p value is a

but when a changes also value of p changes

if some has normal

int a = 3;

then it eventually could be adding those pointer
operators *a++ //a points to ram after normal a

- but this probably shouldnt be legal as most of
a usage is fixed..so maybe changing a 'pointer value' should compile fail

annoying are also things that are not in c like "int x, y =
foo(2,3);" but those dont belong to that list

Huh? This is legal C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/05/2026 16:04, fir wrote:

Bart pisze:

annoying are also things that are not in c like "int x, y =
foo(2,3);" but those dont belong to that list

Huh? This is legal C.

ye i know , but it is probably not work like i would have

you can deturn structure like int2{int x, y;}

but as thsi structure is not builtin it makes a SIN/FLAW
of making unnecesary dependency (on structure definition)
alos makes unnecesary names and so on

you know that ** unnecesary dependencies are bad **, and
** unnesesary things (objects ) are bad **

(of i would like to return two values and assign it to two separate variables)

OK, I used to have such a feature, but dropped it because it wasn't used enough; it wasn't worth the extra complication. But it worked like this:

func foo:int, int =
return (10, 20)
end

It was used like this:

int x, y
(x, y) := foo()

(You can't combine with the declaration.) It also worked like this:

x := foo() # discard 2nd value
foo() # discard both

The implementation didn't use a struct, more of a tuple, but it simply returned N values (limited to 3/4) in the first N registers.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart pisze:

As for the return type, I think that needs to be specified. As you
showed, it wasn't clear what it is, which is bad.

C is not high enough level to do type inference, but even if it was,
users would need to apply the same algorithms, and do the same analysis,
to figure out what some return type actually was. It's better to just
state it.

not sure what you talkin about but sole identifier , like say f tells
you what it is, you need to look up

it will tel you it is double, or it is struct of int and char or this is function which returns 2 foats and tahe 3 ints as an input - pure
identifier encodes it and i dont thionk you should specify it more than that

repeating thsi info in ann call-places if you mean that would be bad
becouse there oftrn may and you need more unnecesary work
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart pisze:

float x = 3.4;
float* xf = &x;
-a-a-a xf+=0.1;

Tricky one. Of that was 1 on the RHS, then 'xf += 1' might increment the pointer, or it might increment the float it points to. So ambiguous.

this aboe may be flawed as it probably should be

float x = 3.4;
float* xf = x;
xf+=0.1;

here float* xf = x; copies the adress but it also look like it copies a
value

this swapped * arithmetic is not ambigious imo - its just swapped

a meand value of pointer a and *a means adress/pointer value as adress


this is probably better for all people who do not like to se such many *
in codes as they would be very reduced

and when you would see it you would see it in two cases

1) in definitions
2) in places where realadres arithmetic is done


now you see it in places where values are used and sometimes you dont
see it when dres arithmetic is done - which is sorta swapped to reality
it seems (becous when you see * you should hae places when pointer
arithemetic is really done imo)

in fact you culd ewen get rid it in definitions using this reference
like in c++

int& c = a;

c is value
*c would mean pointer

i dont like c++ but it is the option

option is also drop * and use & in both cases

int& c = a;

c is value
&c would mean pointer

this is maybe enough to say that

I. reference (if it behaves how i assumed here above) is a swapped pointer
II. swapped probably has more sense then normal

(so eventually they really coud add references to c)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart pisze:

On 18/05/2026 16:04, fir wrote:

Bart pisze:

annoying are also things that are not in c like "int x, y =
foo(2,3);" but those dont belong to that list

Huh? This is legal C.

ye i know , but it is probably not work like i would have

you can deturn structure like int2{int x, y;}

but as thsi structure is not builtin it makes a SIN/FLAW
of making unnecesary dependency (on structure definition)
alos makes unnecesary names and so on

you know that ** unnecesary dependencies are bad **, and
** unnesesary things (objects ) are bad **


(of i would like to return two values and assign it to two separate
variables)

OK, I used to have such a feature, but dropped it because it wasn't used enough; it wasn't worth the extra complication. But it worked like this:

-a func foo:int, int =
-a-a-a-a-a return (10, 20)
-a end

It was used like this:

-a int x, y
-a (x, y) := foo()

(You can't combine with the declaration.) It also worked like this:

-a x := foo()-a-a-a # discard 2nd value
-a foo()-a-a-a-a-a-a-a-a # discard both

The implementation didn't use a struct, more of a tuple, but it simply returned N values (limited to 3/4) in the first N registers.

returning many vaules is logical so it shouldnt be dropped

you may use my conclusions resulted form deducing what should be
improved in c to be better - for ma its more valuable to makin such conclusions than writing a compiler

for example you could take such clear piece of syntax

->z ->b foo _x _y { z-> x+y, b-> x-y }

_x mean delare int x
x_ means assign int x

upper _ means that this variable is output one

this is good for ints (very clean and dynamic syntax imo) hovever i have trouble how to add other types)


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

Bart pisze:

float x = 3.4;
float* xf = &x;
-a-a-a xf+=0.1;

Tricky one. Of that was 1 on the RHS, then 'xf += 1' might increment
the pointer, or it might increment the float it points to. So ambiguous.

this aboe may be flawed as it probably should be

-afloat x = 3.4;
-afloat* xf = x;
-a-a-a-a xf+=0.1;

here-a float* xf = x; copies the adress but it also look like it copies a value

this swapped * arithmetic is not ambigious imo - its just swapped

a meand value of pointer a and *a means adress/pointer value as adress

this is probably better for all people who do not like to se such many *
in codes as they would be very reduced

and when you would see it you would see it in two cases

1) in definitions
2) in places where realadres arithmetic is done

now you see it in places where values are used and sometimes you dont
see it when dres arithmetic is done - which is sorta swapped to reality
it seems (becous when you see * you should hae places when pointer arithemetic is really done imo)

in fact you culd ewen get rid it in definitions using this reference
like in c++

int& c = a;

-a-a c is value
-a-a *c would mean pointer

i dont like c++ but it is the option

option is also drop * and use & in both cases

int& c = a;

-a-a c is value
-a-a &c would mean pointer

this is maybe enough to say that

I.-a reference (if it behaves how i assumed here above) is a swapped pointer II. swapped probably has more sense then normal

(so eventually they really coud add references to c)

weird thing is those normal pointers and swapped ones (references) can
be in language parrallel

i love c bot im not much big fan of pointers so maybe i should try to
use c++ and write "only references" c (?)

im not using them so i dont quite aware if they work fully as i would
see them in above thoughts
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart pisze:

On 18/05/2026 16:04, fir wrote:

Bart pisze:

annoying are also things that are not in c like "int x, y =
foo(2,3);" but those dont belong to that list

Huh? This is legal C.

ye i know , but it is probably not work like i would have

you can deturn structure like int2{int x, y;}

but as thsi structure is not builtin it makes a SIN/FLAW
of making unnecesary dependency (on structure definition)
alos makes unnecesary names and so on

you know that ** unnecesary dependencies are bad **, and
** unnesesary things (objects ) are bad **


(of i would like to return two values and assign it to two separate
variables)

OK, I used to have such a feature, but dropped it because it wasn't used enough; it wasn't worth the extra complication. But it worked like this:

-a func foo:int, int =
-a-a-a-a-a return (10, 20)
-a end

It was used like this:

-a int x, y
-a (x, y) := foo()

(You can't combine with the declaration.) It also worked like this:

-a x := foo()-a-a-a # discard 2nd value
-a foo()-a-a-a-a-a-a-a-a # discard both

The implementation didn't use a struct, more of a tuple, but it simply returned N values (limited to 3/4) in the first N registers.

reeturning many values is definitelly logical so you should not drop it (question is how it would be implemented in s i think starting
convention would be to pass to pointers to in and out structures

struct in (int,int,int)
struct out {int , int }

foo(&out, &in)

so the function should use pointers to acces it and physically this ram
should belong to caller


you could use any of conclusions i for example personally em talking about becuse i prefer deducing what should be done in languages which is more
fun to me than write compiler (i wrote a half but stopped)

you could mayge take this syntax

->z ->b foo _x _y { z-> x+y, b-> x-y }

its unusually clean _x mean "input int x "

z means" output int z"

z-> x+y, means assign output z by a+b

got a problem how to put floats hovever

(sorry its redundant - but it not sent properly i thought it vanished so
i wrote another one than found it in editor, so i post it again)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

David Brown <david.brown@hesbynett.no> wrote:

Sure. But in the C world, pre-C99 code is often written in a style with local variables all declared at the top of the function - after C99, it
is common to declare them when you need them. So as a C programmer, I
see declaring local variables in one clump together as archaic.

I agree about style. But AFAICS even in very early C there is block
structure and one can put variable declarations in the middle of
sequence, just at the cost of introducing extra blocks. So C99
looks nicer as there is no need for extra blocks, but pre C99
already one could keep scopes tight and initialize variables in
declarations.
--
Waldek Hebisch
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/05/2026 18:47, Waldek Hebisch wrote:

David Brown <david.brown@hesbynett.no> wrote:

Sure. But in the C world, pre-C99 code is often written in a style with
local variables all declared at the top of the function - after C99, it
is common to declare them when you need them. So as a C programmer, I
see declaring local variables in one clump together as archaic.

I agree about style. But AFAICS even in very early C there is block structure and one can put variable declarations in the middle of
sequence, just at the cost of introducing extra blocks. So C99
looks nicer as there is no need for extra blocks, but pre C99
already one could keep scopes tight and initialize variables in
declarations.

Certainly you can do that. But it quickly gets ugly and inconvenient if
you have a lot of extra blocks. It's fair enough if you have a block
already, from a loop or conditional.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/05/2026 09:35, David Brown wrote:

On 18/05/2026 09:22, Janis Papanagnou wrote:

On 2026-05-18 08:56, David Brown wrote:

[...]

Much better, IMHO, is to use a language that lets you mix
declarations and statements as needed.

Indeed. But not "mixing" as a value per se, but to keep declarations
locally is a good thing, IMO.

Yes - it is not the mixing itself that is good, it is what it allows.
You get to keep your scopes small, you don't need to declare variables
until you have an initial value for them (who cares if reading an uninitialised variable is UB if you never have them!), and you can often declare your variables as const.-a That means it's easy to know what the variable holds because it is only set once, and never changed.

I see declaring your local variables in a list at the top of a
function - or, far worse, at the bottom - as archaic style.

Well, "archaic" expresses a time-related qualification. But even in
earlier times we saw, depending on the actual programming language,
both styles existing.

Sure.-a But in the C world, pre-C99 code is often written in a style with local variables all declared at the top of the function - after C99, it
is common to declare them when you need them.-a So as a C programmer, I
see declaring local variables in one clump together as archaic.

I hate dealing with code that just declares variables higgledy-piggledy
all over the place; it is so lazy. I'm not into block scopes either.

I /like/ to have them all in one place for easy reference. Then the code itself will have less clutter.

There are several places in C where it is common to declare stuff in one place:

* In parameter lists (at least we always have that, except when
parameter 'x' is used, and you see 'x' in the body, your practice means
I have to scan backwards from that point to see if it is parameter 'x',
or some other 'x' in a nested scope that shadows it).

* #includes
* Imported variables
* Imported functions
* Forward function declarations

Imagine how annoying it would be if any of those last were used inside a
block within a function. Well, that's how annoying local declarations
mixed with code are.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <10uffq4$m4se$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

David Brown <david.brown@hesbynett.no> wrote:

Sure. But in the C world, pre-C99 code is often written in a style with
local variables all declared at the top of the function - after C99, it
is common to declare them when you need them. So as a C programmer, I
see declaring local variables in one clump together as archaic.

I agree about style. But AFAICS even in very early C there is block >structure and one can put variable declarations in the middle of
sequence, just at the cost of introducing extra blocks. [snip]

Maybe. But on projects based on older variants of C, it was
common as a matter of local policy to mandate that locals were
declared at the top of a function; this enabled readers to get
a sense of how much stack space was required at a glance.

Fortunately, those bad days old are _mostly_ gone.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <10uffq4$m4se$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

David Brown <david.brown@hesbynett.no> wrote:

Sure. But in the C world, pre-C99 code is often written in a style with >>> local variables all declared at the top of the function - after C99, it >>> is common to declare them when you need them. So as a C programmer, I
see declaring local variables in one clump together as archaic.

I agree about style. But AFAICS even in very early C there is block >>structure and one can put variable declarations in the middle of
sequence, just at the cost of introducing extra blocks. [snip]

Maybe. But on projects based on older variants of C, it was
common as a matter of local policy to mandate that locals were
declared at the top of a function; this enabled readers to get
a sense of how much stack space was required at a glance.

That mandate also facilitated the use of the vi '[['
sequence to easily move to the local declarations,
and '``' would return to the previous location.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/05/2026 19:35, Bart wrote:

On 18/05/2026 09:35, David Brown wrote:

On 18/05/2026 09:22, Janis Papanagnou wrote:

On 2026-05-18 08:56, David Brown wrote:

[...]

Much better, IMHO, is to use a language that lets you mix
declarations and statements as needed.

Indeed. But not "mixing" as a value per se, but to keep declarations
locally is a good thing, IMO.

Yes - it is not the mixing itself that is good, it is what it allows.
You get to keep your scopes small, you don't need to declare variables
until you have an initial value for them (who cares if reading an
uninitialised variable is UB if you never have them!), and you can
often declare your variables as const.-a That means it's easy to know
what the variable holds because it is only set once, and never changed.

I see declaring your local variables in a list at the top of a
function - or, far worse, at the bottom - as archaic style.

Well, "archaic" expresses a time-related qualification. But even in
earlier times we saw, depending on the actual programming language,
both styles existing.

Sure.-a But in the C world, pre-C99 code is often written in a style
with local variables all declared at the top of the function - after
C99, it is common to declare them when you need them.-a So as a C
programmer, I see declaring local variables in one clump together as
archaic.

I hate dealing with code that just declares variables higgledy-piggledy
all over the place; it is so lazy. I'm not into block scopes either.

Um, okay. You seem to define a lot of your programming life around
hating things a large proportion of programmers consider good practice.
But you are free to have your preferences.

I /like/ to have them all in one place for easy reference. Then the code itself will have less clutter.

There are several places in C where it is common to declare stuff in one place:

* In parameter lists (at least we always have that, except when
parameter 'x' is used, and you see 'x' in the body, your practice means
I have to scan backwards from that point to see if it is parameter 'x',
or some other 'x' in a nested scope that shadows it).

That's a typical (for you) strawman argument. I don't know of anyone
who considers it good practice to shadow function parameters with local variables.

* #includes

It is common in most languages to use includes, imports, uses, or
whatever "module import" mechanism the language supports, near the top
of source files.

* Imported variables
* Imported functions

I'm not sure what you are trying to say here. People tend to group
things that logically hang together - though there is often more than
one way to do so.

* Forward function declarations

Imagine how annoying it would be if any of those last were used inside a block within a function. Well, that's how annoying local declarations
mixed with code are.

Some people do like to declare imported (i.e., "extern") functions or
data within the functions that use them. I don't, but different people
have different preferences.

I appreciate that /you/ find declarations after statements to be
annoying - yet you sing the praises of your own language because it
allows declarations to occur anywhere mixed with statements, including
after their usage. I suppose it is annoying when someone else does it,
yet innovative and god's gift to the programming world when /you/ do it.

People who mix declarations and statements in their C programming do so knowing full well that they could put their local variable declarations
all at the top of the function - but they feel that mixing them gives
the best quality code, with the least risk of mistakes and the clearest,
most understandable and most maintainable results.

Or perhaps they only do so specifically to annoy you.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/05/2026 20:24, David Brown wrote:

On 18/05/2026 19:35, Bart wrote:

I hate dealing with code that just declares variables higgledy-
piggledy all over the place; it is so lazy. I'm not into block scopes
either.

Um, okay.-a You seem to define a lot of your programming life around
hating things a large proportion of programmers consider good practice.
But you are free to have your preferences.

I have to deal with C quite a lot.

People who mix declarations and statements in their C programming do so knowing full well that they could put their local variable declarations
all at the top of the function - but they feel that mixing them gives
the best quality code, with the least risk of mistakes and the clearest, most understandable and most maintainable results.

Or perhaps they only do so specifically to annoy you.

Every time I do a survey of C codebases, I tend to get about the same
set of results:

* On average functions have only around three local variables

* 80% of all functions have 4 locals or fewer

I don't find such stats a compelling reason for block scopes, or why
people want to hide a function's handful of locals within the executable
code.

(Stats vary but for STB_IMAGE.H, a library I use, and tested after I
wrote the above, they are:

Number of Functions: 207
Average Locals: 3.4
Funcs with <= 4 Locals: 170 (82%)
Most common # of locals: 1 (57/207; next most common is 0: 56/207)
)

I appreciate that /you/ find declarations after statements to be
annoying - yet you sing the praises of your own language because it
allows declarations to occur anywhere mixed with statements, including
after their usage. I suppose it is annoying when someone else does it,
yet innovative and god's gift to the programming world when /you/ do it.

Yes I allow them anywhere, but 99% of the time in a finished program
they are at the top of a function. Mostly they are used for temporary code.

(If other people were to use my language, they may do things
differently. I would still find that annoying if I had to deal with it.

Remember that I don't have block scopes, so if I see a declaration in
the middle, I know that applies function-wide.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart <bc@freeuk.com> writes:
[...]

You know, all it takes is to admit that out-of-order definitions can
be a desirable and convenient language feature. It's one that other
languages have, it's not something that only exists in my language
(though I take it a bit further).

I acknowledge that out-of-order definitions *can* be a a desirable
and convenient language feature. (I used the word "acknowledge"
because it's not an admission. It doesn't contradict anything I've
said before, or as far as I can tell anything anyone else here has
said before.)

You said that's all it takes. What do we win?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart <bc@freeuk.com> writes:
[...]

I hate dealing with code that just declares variables
higgledy-piggledy all over the place; it is so lazy. I'm not into
block scopes either.

I would probably hate such code myself. Nobody advocates just
declarating variables "higgledy-piggledy all over the place".

Something that is widely considered good programming style is
to define variables close to where they're used. In a medium to
large sized function, that can result in something that you might
perceive as "higgledy-piggled", but it's not. I'd explain further
if I thought you'd be interested.

Yes, it's less of an issue if functions are short.

I /like/ to have them all in one place for easy reference. Then the
code itself will have less clutter.

I acknowledge your preference. Others do not share it.

[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart <bc@freeuk.com> writes:
[...]

I think you would have liked my language! That does have char
constants up to 'ABCDEFGH' (When I supported 128-bit types, up to 'ABCDEFGHIJKLMNOP'.)

C will support them up to 'int' width, which means 'ABCD' for 32-bit
int. In theory a C with a 64-bit int would allow longer constants, but
that's not going to happen on any common platforms.

C does not specify the maximum width of a multi-character constant.

As it is, even anything above 'A' is implementation-defined, unless
C23 has changed that.

It hasn't. For that matter, the value of 'A' is
implementation-defined. (It's 65 on most implementations these days,
but EBCDIC isn't completely dead.)

Multi-character constants are largely a legacy feature, though the
standard doesn't say so. I've seen code that uses them and depends
on the values specified by a particular implementation, but they're
of little use in portable code. It's not even guaranteed that
'aa' and 'ab' have distinct values (Pelles C ignores all but the
first character).

also annoying is thet if {} has its own scope

[...]

annoying are also things that are not in c like "int x, y =
foo(2,3);" but those dont belong to that list

Huh? This is legal C.

It is, but perhaps fir wanted both x and y to be initialized.
Of course you could write
int x = foo(2, 3);
int y = x;
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2