C23 C language standard made a decision which breaks C functions with arbitrary number of arguments.
How does one define an *arbitrary* function pointer in C23? (not only variadic, which is a special case)
@dimpase C doesn’t have arbitrary number of arguments for functions… never really had. A compliant implementation can put a relatively small limit on how many arguments you can actually pass to a function.
@amszmidt
the problem is that
void foobar();
(or perhaps foobar(void)) used to match a function foobar() with any calling convention and any number of arguments. (and similar for function pointers). It could have been implementation-dependent, formally speaking, but given that the most compilers were able to deal with it, no problems arose.
So 20-30-40 years ago people wrote Lisp compilers (ECL), computer algebra systems, and with minimal changes the code worked from one standard to another. Not any more with c23 or gnu23.
@dimpase I know, has there been a upstream bug been reported? I'd consider this a serious regression ... GCC 15 is still frozen, so there is a very small sliver that things might get fixed.
@dimpase > (or perhaps foobar(void))
Would have never been valid, the foobar() syntax goes back to K&R C. Which predates `void' by quite a bunch. Back then, if you didn't specify things .. all goes. If I don't remember incorrectly,
foobar(a,b)
int a;
int b;
int c;
{ ... }
might have been valid (recall, K&R C did not have variadic ..)
@larsbrinkhoff @AmenZwa @amszmidt @dimpase @trofi
What sizes were the integer types?
@larsbrinkhoff @brouhaha @amszmidt @dimpase @trofi I admire ITS’s fastidious uniformity.
@vnikolov @larsbrinkhoff @brouhaha @amszmidt @dimpase @trofi
I was born on a PDP-11/70 running Version 7 and raised on a VAX-11/780 running 4BSD. And although there was a DECsystem-10 in the computer centre, it was run by a small cadre of powerful system administrators and professors, who jealously guarded the monster. We undergrads never got to play with it.
In fact, I never got to use a 36-biter, because the workstation revolution took hold while I was in college, and the rest, as they say, is RISCtory.
@AmenZwa @vnikolov @larsbrinkhoff @brouhaha @amszmidt @trofi my 1st student job was using a stolen (probably from Italy? the 1st line or two of the booting message on the console was in Italian) copy of MUMPS on a Soviet clone of PDP-11 called SM-4, at a computing centre of the USSR Ministry of Health.
I even got to write an assembly plug-in for MUMPS.
https://en.m.wikipedia.org/wiki/MUMPS
@dimpase @AmenZwa @larsbrinkhoff @brouhaha @amszmidt @trofi
Annoying footnote:
> a Soviet clone of PDP-11 called SM-4
The latter acronym comes from the Russian for "Computing Machine" (if I recall the full nomenclature correctly), and curiously, in Cyrillics it is "СМ" (Счетная Машина, Schetnaya Mashina, pronounced /schot-/); make of the glyph coincidence what you will.
@vnikolov @AmenZwa @larsbrinkhoff @amszmidt @dimpase @trofi
The PDP-10 most certainly DOES have addressable bytes. That's the subject of section 2.3 of the System Reference Manual.
In theory, that was an optional feature of the earliest PDP-10 processor, the KA10, but there is no evidence that DEC ever sold a KA10 without the option.
@vnikolov @brouhaha @AmenZwa @amszmidt @dimpase @trofi I can see someone might object to this definition because byte pointers are only useful with a handful of instructions, not across the full instruction set. Surely it would be possible to come up with a definition of "address" that excludes byte pointers.
@larsbrinkhoff @brouhaha @AmenZwa @amszmidt @dimpase @trofi
larsbrinkhoff@mastodon.sdf.org> I can see someone might object to this definition because byte pointers are only useful with a handful of instructions, not across the full instruction set. Surely it would be possible to come up with a definition of "address" that excludes byte pointers.
Right.
And those who are that way inclined may conversely widen the definition to consider each bit addressable (with a pinch of biwise operations).