The annual Underhanded C Contest announced their winners today.

As always, the results are very entertaining, and also an excellent advertisement for languages-that-are-not-C.

The first place entry is particularly ridiculous; is there any modern language that would make it so easy to commit such an awful "mistake"?

http://www.underhanded-c.org/#winner

Actually, I'm surprised that this works even in C - I would have expected at least a compiler (or linker?) warning; this seems like it should be easy to detect automatically.

On Thu, Feb 04, 2016 at 10:57:00PM +0000, tsbockman via Digitalmars-d wrote:
> The annual Underhanded C Contest announced their winners today.
> 
> As always, the results are very entertaining, and also an excellent advertisement for languages-that-are-not-C.
> 
> The first place entry is particularly ridiculous; is there any modern language that would make it so easy to commit such an awful "mistake"?
> 
> http://www.underhanded-c.org/#winner
> 
> Actually, I'm surprised that this works even in C - I would have expected at least a compiler (or linker?) warning; this seems like it should be easy to detect automatically.

The C preprocessor accepts all sorts of nasty, nonsensical things. For example, the following code compiles and runs (without any warning(!) on my Linux box's standard gcc installation), and prints "No":

	#include <stdio.h>
	#define if(a) if(!(a))
	int main() {
		int i = 1;
		if (i == 1)
			printf("Yes\n");
		else
			printf("No\n");
	}

Imagine if this nasty #define is buried somewhere under several layers of #include's.

I'm pretty sure somebody can also concoct some nasty #define that will break the standard #include headers in horrible ways by changing the semantics of certain supposedly-built-in constructs.


T

-- 
Mediocrity has been pushed to extremes.

On Thursday, 4 February 2016 at 22:57:00 UTC, tsbockman wrote:
> Actually, I'm surprised that this works even in C - I would have expected at least a compiler (or linker?) warning; this seems like it should be easy to detect automatically.

AFAICT C would have complained if he had included <math.h>. This is a rather unlikely mistake...

Anyway, in C being able to work around restrictions is sometimes desired, so... if you don't want the ability to do it, don't use C.

On Thursday, 4 February 2016 at 23:10:23 UTC, H. S. Teoh wrote:
> On Thu, Feb 04, 2016 at 10:57:00PM +0000, tsbockman via Digitalmars-d wrote:
>> The annual Underhanded C Contest announced their winners today.
>> 
>> As always, the results are very entertaining, and also an excellent advertisement for languages-that-are-not-C.
>> 
>> The first place entry is particularly ridiculous; is there any modern language that would make it so easy to commit such an awful "mistake"?
>> 
>> http://www.underhanded-c.org/#winner
>> 
>> Actually, I'm surprised that this works even in C - I would have expected at least a compiler (or linker?) warning; this seems like it should be easy to detect automatically.
>
> The C preprocessor accepts all sorts of nasty, nonsensical things.

Definitely. What puzzles me about the winning entry, though, is that the compiler and/or linker should be able to trivially detect the type mismatch *after* the preprocessor pass(es) are already done.

It should just see that the post-preprocessor signatures of `spectral_contrast()` in match.c and spectral_contrast.c are in conflict, and either issue a warning, or refuse to link them at all.

On Thu, 04 Feb 2016 22:57:00 +0000, tsbockman wrote:

> The annual Underhanded C Contest announced their winners today.
> 
> As always, the results are very entertaining, and also an excellent advertisement for languages-that-are-not-C.
> 
> The first place entry is particularly ridiculous; is there any modern language that would make it so easy to commit such an awful "mistake"?
> 
> http://www.underhanded-c.org/#winner
> 
> Actually, I'm surprised that this works even in C - I would have expected at least a compiler (or linker?) warning; this seems like it should be easy to detect automatically.

C linkage does zero name mangling, which is the problem. C++ introduced name mangling, so compiling with g++ would show the error rather quickly. C99 is pretty close to C++98, but there are enough differences that that isn't a reliable diagnostic. (Though if you're familiar with the differences, you could use it as a quick way to show potential problem areas.)

I suppose a compiler could produce two symbol tables, one featuring mangled names and one with unmangled names. The linker would prefer matching mangled names and issue a warning if it only had an unmangled match with a mangled false match.

On Thursday, 4 February 2016 at 23:19:20 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 4 February 2016 at 22:57:00 UTC, tsbockman wrote:
>> Actually, I'm surprised that this works even in C - I would have expected at least a compiler (or linker?) warning; this seems like it should be easy to detect automatically.
>
> AFAICT C would have complained if he had included <math.h>. This is a rather unlikely mistake...
>
> Anyway, in C being able to work around restrictions is sometimes desired, so... if you don't want the ability to do it, don't use C.

What restriction does not checking, by default, that the parameter types match allow one to work around, though?

C already has `void*` and explicit casts, either of which would allow one to explicitly indicate that type checking is not desired.

On Thursday, 4 February 2016 at 23:21:54 UTC, tsbockman wrote:
> Definitely. What puzzles me about the winning entry, though, is that the compiler and/or linker should be able to trivially detect the type mismatch *after* the preprocessor pass(es) are already done.

Linkers don't know anything about types. A type is a language feature.

> It should just see that the post-preprocessor signatures of `spectral_contrast()` in match.c and spectral_contrast.c are in conflict, and either issue a warning, or refuse to link them at all.

Has nothing to do with the preprocessor.

He defined float_t to be an alias for double in one compilation unit, and float_t to be an alias for float in another compilation unit.

In C, compilation units are completely independent, and can in fact come from different compilers and different languages. C is very much a system level programming language.

On Thursday, 4 February 2016 at 23:24:21 UTC, Chris Wright wrote:
> C linkage does zero name mangling, which is the problem. C++ introduced name mangling, so compiling with g++ would show the error rather quickly. C99 is pretty close to C++98, but there are enough differences that that isn't a reliable diagnostic. (Though if you're familiar with the differences, you could use it as a quick way to show potential problem areas.)
>
> I suppose a compiler could produce two symbol tables, one featuring mangled names and one with unmangled names. The linker would prefer matching mangled names and issue a warning if it only had an unmangled match with a mangled false match.

That explains why the linker doesn't catch it. I still don't see much excuse for the compiler allowing it though, beyond a desire to allow each module to be compiled independently.

On Thursday, 4 February 2016 at 23:25:58 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 4 February 2016 at 23:21:54 UTC, tsbockman wrote:
>> It should just see that the post-preprocessor signatures of `spectral_contrast()` in match.c and spectral_contrast.c are in conflict, and either issue a warning, or refuse to link them at all.
>
> Has nothing to do with the preprocessor.

Yes, that was my point...

> He defined float_t to be an alias for double in one compilation unit, and float_t to be an alias for float in another compilation unit.
>
> In C, compilation units are completely independent, and can in fact come from different compilers and different languages. C is very much a system level programming language.

Just because *sometimes* the source code of the other module must be compiled independently, is a poor excuse to skip obvious, useful safety checks *all* the time.

On Thursday, 4 February 2016 at 23:29:10 UTC, tsbockman wrote:
> That explains why the linker doesn't catch it. I still don't see much excuse for the compiler allowing it though, beyond a desire to allow each module to be compiled independently.

The excuse is that C use the same mechanism for creating bindings to C and non-C code. It is actually very handy. IF you want a system level language and full separation of compilation units (which allows for very fast compilation).