Rendered at 05:30:58 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
chasil 3 hours ago [-]
I just rebuilt a core program that talks to my UNIVAC OS2200 CITA and my VAX ACMS from Linux.
I built this first as a 32-bit binary, and there was noise that I had to cut with a substr function.
In the rebuilding with my MinGW 64-bit Windows cross compiler on Oracle Linux, I had to mine function prototypes out of all the code for exactly this reason.
'for those unaware: c89 has a cool "feature" where, if you try to call a function which doesn't exist, rather than erroring out, the function is implicitly declared as a function with unspecified parameters returning int.'
I'm not testing this, because that is agony.
I'm leaving them a working build, and retiring this month.
This code was written by the living and the dead, and my stewardship is finished. I do not envy the poor soul who must test this.
It was ashes when I excavated it myself. A hat tip to those who have gone before.
ronsor 56 minutes ago [-]
Implicit declarations are a classic!
Current GCC and clang error on them by default now, but that's a rather recent change.
malkia 5 minutes ago [-]
This... from the time when kids played with real toys :)
bellowsgulch 4 days ago [-]
All the weird stuff I have read about C or C++ doing over the years could be summed up with “Well… don’t do that.”
Like almost without fail. I can’t even think of how you’d end up in a scenario like this because a compiler would complain before letting you use an undefined implicit declaration.
mjevans 1 hours ago [-]
I sum it up with: give me an error message rather than undefined or unintuitive behavior.
bitbasher 4 days ago [-]
That doesn't make it any less interesting :)
Joel_Mckay 1 hours ago [-]
Most people build C in g++ before gcc, as it tends to have a better chance of catching most oddities. Then run it past valgrind to double check if something looks suspect or is slowly leaking. =3
guenthert 4 days ago [-]
"because the problematic behavior was removed from the standard over 27 years ago, we'll never have closure on what the intended interpretation is."
Obsolete standard turns out to be insufficiently strict, news at 11.
inigyou 4 hours ago [-]
newc at 11, too. it was called c11.
kevin_thibedeau 4 hours ago [-]
> f[...]
It is illegal to perform pointer arithmetic on function pointers. They are not necessarily interchangeable with data pointers. Clang is wrong.
phire 3 hours ago [-]
In c89, there doesn't seem to be any distinction between pointer to functions and pointer to data.
Do you know what c89 does explicitly say is undefined? Any pointer arithmetic at all (or array subscripting) for pointers are not pointing to a member of an array. It's already invalid to do pointer arithmetic a pointer to a struct.
Not that it matters for this. This isn't doing pointer arithmetic, f is simply the identifier for the array of "sizeof(f) ints" that make up the function argument. The identifier is optional for a function declaration.
kevin_thibedeau 3 hours ago [-]
There is a distinction. Lisp machines do not allow function pointers to become data pointers. The C standard accounts for that. Function pointers also have special decay behavior unlike data pointers. You can chain an unlimited number of '*'s and still get a valid function pointer.
int f(int x) { return x + 1; }
int main(int argc, char *argv[]) {
int (*fp)(int) = f;
printf("Answer: %d\n", fp(39) + (****fp)(1));
return 0;
}
phire 2 hours ago [-]
Not sure about later versions, but c89 doesn't seem to forbid casting a function pointer to a data pointer (it does say that casting pointers has implementation defined aspects, so lisp machines aren't out of spec if they fail).
The reason you can chain unlimited ''s is that f isn't actually a function pointer, it's a function designator. Function designators are automatically converted to function pointers in almost every case, but '' is special cased so that indirecting a raw function designator results in another function designator.
Edit: Actually on a closer reading, maybe it does. C89 doesn't explicitly point it out as forbidden or undefined, it simply defines two classes (objects and functions) and only defines a very limited set of valid operations on pointers to functions.
Though one operation that is implementation defined is converting a pointer to an int, and an int to a pointer. So with two steps through an implementation defined path, you have a data pointer to a function.
I built this first as a 32-bit binary, and there was noise that I had to cut with a substr function.
In the rebuilding with my MinGW 64-bit Windows cross compiler on Oracle Linux, I had to mine function prototypes out of all the code for exactly this reason.
'for those unaware: c89 has a cool "feature" where, if you try to call a function which doesn't exist, rather than erroring out, the function is implicitly declared as a function with unspecified parameters returning int.'
I'm not testing this, because that is agony.
I'm leaving them a working build, and retiring this month.
This code was written by the living and the dead, and my stewardship is finished. I do not envy the poor soul who must test this.
It was ashes when I excavated it myself. A hat tip to those who have gone before.
Current GCC and clang error on them by default now, but that's a rather recent change.
Like almost without fail. I can’t even think of how you’d end up in a scenario like this because a compiler would complain before letting you use an undefined implicit declaration.
Obsolete standard turns out to be insufficiently strict, news at 11.
It is illegal to perform pointer arithmetic on function pointers. They are not necessarily interchangeable with data pointers. Clang is wrong.
Do you know what c89 does explicitly say is undefined? Any pointer arithmetic at all (or array subscripting) for pointers are not pointing to a member of an array. It's already invalid to do pointer arithmetic a pointer to a struct.
Not that it matters for this. This isn't doing pointer arithmetic, f is simply the identifier for the array of "sizeof(f) ints" that make up the function argument. The identifier is optional for a function declaration.
The reason you can chain unlimited ''s is that f isn't actually a function pointer, it's a function designator. Function designators are automatically converted to function pointers in almost every case, but '' is special cased so that indirecting a raw function designator results in another function designator.
Edit: Actually on a closer reading, maybe it does. C89 doesn't explicitly point it out as forbidden or undefined, it simply defines two classes (objects and functions) and only defines a very limited set of valid operations on pointers to functions.
Though one operation that is implementation defined is converting a pointer to an int, and an int to a pointer. So with two steps through an implementation defined path, you have a data pointer to a function.
That's a nice bit of understated 90s design right there