Every C and C++ project I wrote at 1337 was built on a Mac, with clang, under -Wall -Wextra -Werror. All of them compiled clean since the grading script will not bother running a binary that produced a warning.

So when I rebuilt my repos on Linux under GCC, I expected all green builds. Boy I was wrong.

The three failures ware not caused by a bug. The programs were correct. They did what they were supposed to do, and they still do. What broke was that I had been writing against one compiler's opinion and calling it the language.

Here are the three lines, the exact diagnostics from both toolchains, and what each one actually taught me. Everything below was reproduced on Ubuntu 24.04 with GCC 13.3.0 and clang 18.1.3.

1. Subscripting a void *

This is ft_memchr from my libft — the first project, the one where you reimplement the C standard library.

void	*ft_memchr(const void *str, int c, size_t size)
{
	unsigned char	occ;
	unsigned char	*s;
	size_t			i;

	occ = (unsigned char)c;
	s = (unsigned char *)str;
	i = 0;
	while (i < size)
	{
		if (occ == s[i])
			return ((void *)&str[i]);
		i++;
	}
	return (NULL);
}

Look at the return. I compare using s[i] — the unsigned char * I cast at the top of the function, exactly as intended — and then return the address of str[i], where str is still a const void *.

str[i] means *(str + i). You cannot do arithmetic on a void *, because void has no size, so the compiler has nothing to multiply i by.

GCC says so :

ft_memchr.c:27:45: error: dereferencing 'void *' pointer [-Werror]
   27 |                         return ((void *)&str[i]);
      |                                             ^
cc1: all warnings being treated as errors

clang, same file, same -Wall -Wextra -Werror, says nothing at all. Exit code zero.

Both compilers implement the same GNU extension: treat sizeof(void) as 1 and let the arithmetic through. The difference is entirely in how loudly each one admits to it. clang only mentions it if you ask for strict standard conformance :

$ clang -Wall -Wextra -Werror -pedantic -c ft_memchr.c
ft_memchr.c:27:24: error: subscript of a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]

That is the whole story of case one: clang has a named warning for this and keeps it off by default; GCC has an unnamed warning for this and keeps it on.

The "unnamed" part surprised me. GCC's message ends in [-Werror], not [-Werror=something], and that is not a formatting quirk. The warning has no flag name, so there is no -Wno- that turns it off. I tried -Wno-pointer-arith and got the warning anyway; that flag controls the -pedantic phrasing, not this one. GCC has decided this is not a matter of taste.

The fix is a single character, and the right variable was already sitting two lines up :

return ((void *)&s[i]);

Which, if I am honest, is what I meant the first time.

2. std::strtod without <cstdlib>

From mode.cpp in my IRC server — the +l handler, parsing a channel user limit :

double limit = std::strtod(partsCmd[pos].c_str(), NULL);

The file includes exactly one header of its own :

#include "../inc/parse.hpp"

which reaches <string>, <vector>, <iostream>, <sstream>, and my own classes. Nothing in that tree includes <cstdlib> — I grepped the whole inc/ directory to be sure — and <cstdlib> is where std::strtod is declared.

GCC :

src/mode.cpp:208:61: error: 'strtod' is not a member of 'std'; did you mean 'strtok'?
  208 |    double limit = std::strtod(partsCmd[pos].c_str(), NULL);

(No, GCC, I did not mean strtok.)

I filed this one under "GCC is stricter" and moved on. Then I ran it through clang on Linux to confirm, and clang failed too :

src/mode.cpp:208:26: error: no member named 'strtod' in namespace 'std'

Which means my theory was wrong. This was never about the compiler.

std::strtod is not part of <string> or <iostream> on any implementation. It is only ever visible because some other header quietly included <cstdlib> on the way past — and whether that happens is decided by the standard library, not the compiler. macOS clang defaults to libc++. Linux defaults to libstdc++.

Same clang, same file, same flags, only the standard library swapped :

$ clang++ -std=c++98 -fsyntax-only src/mode.cpp
src/mode.cpp:208:26: error: no member named 'strtod' in namespace 'std'

$ clang++ -std=c++98 -fsyntax-only -nostdinc++ -isystem …/c++/v1 src/mode.cpp
$ echo $?
0

And libc++ is not being sloppy by accident. It is right there in the source of <string>:

#if !defined(_LIBCPP_REMOVE_TRANSITIVE_INCLUDES) && _LIBCPP_STD_VER <= 20
#  include <algorithm>
#  include <concepts>
#  include <cstdlib>
…
#endif

A deliberate compatibility block, with a macro to switch it off, and an upper bound on the language version. Which one of my headers leaks the symbol depends on both :

The <string> route has already been withdrawn above C++20. The others still work, for now, on one implementation, as an explicitly transitional favor.

This happens because I was relying on a header I never named. The fix is the line I should have written in 2024 :

#include <cstdlib>

Include what you use.

3. A clamp written as &&

From cub3D the raycaster, a two-person project; this particular file is my teammate's. It broke my build all the same, and it is the most interesting of the three.

(mlx->wall_start < 0.0) && (mlx->wall_start = 0.0);
(mlx->wall_end > mlx->height) && (mlx->wall_end = mlx->height);

That is a clamp. && short-circuits, so the assignment on the right only runs when the test on the left is true. It is legal C, it is correct, and it does exactly what an if would do.

GCC :

ray_casting.c:68:41: error: value computed is not used [-Werror=unused-value]
   68 |   (mlx->wall_start < 0.0) && (mlx->wall_start = 0.0);
      |                           ^~
ray_casting.c:69:47: error: value computed is not used [-Werror=unused-value]

The expression produces a bool. Nobody reads it. -Wunused-value lives inside -Wall, so -Wall -Werror makes it fatal.

clang is silent. Not just at -Wall -Wextra -Werror — at -Weverything, which turns on literally every warning clang ships. I ran it on the file and counted what came back :

1 × [-Wcomma]
5 × [-Wfloat-conversion]
1 × [-Wpadded]
0 × [-Wunused-value]

Zero. clang does not consider this an unused value at any setting. It does have an opinion about those two lines, but a completely different one :

ray_casting.c:68:47: warning: implicit conversion turns floating-point number into integer: 'double' to '_Bool' [-Wfloat-conversion]
   68 |   (mlx->wall_start < 0.0) && (mlx->wall_start = 0.0);
      |                           ~~  ~~~~~~~~~~~~~~~~^~~~~

That is not "you threw away a value." That is "your double became a bool" , not in -Wall by the way.

And the one -Wcomma is on a line I have not shown you yet, three lines down in the same function:

1 && (a += step, screen_x++);

A constant 1, a && that can never short-circuit, and a comma operator doing two updates in one statement. GCC which just failed the build twice over the lines above has nothing to say about this one. clang, which said nothing about those, calls it out:

ray_casting.c:71:18: warning: possible misuse of comma operator here [-Wcomma]

Two mature compilers. Neither found what the other found.

So why write any of this?

cub3D is graded against the Norm, 1337's style checker, and the Norm caps a function body at 25 lines. ray_casting() is 23. Hard line budget. It was written in that exact way to buy three lines back. Which happens to be what GCC rejects.

The fix, once the function is split so there is room for it :

if (mlx->wall_start < 0.0)
	mlx->wall_start = 0.0;
if (mlx->wall_end > mlx->height)
	mlx->wall_end = mlx->height;

What I actually took from this

All three fixes are trivial. One character, one #include, one if. All three now compile clean under GCC and clang at -Wall -Wextra -Werror -pedantic, which is a stronger claim than either of them made alone.

I used to read -Wall -Wextra -Werror as the code is fine. It is not. It is one implementation had no objection, and implementations object to different things :

• GCC failed the build on cases 1 and 3. clang passed both without a word, and kept passing at -Weverything — the most aggressive setting it has still misses what plain -Wall catches on GCC.

• It runs the other way too. clang flagged the comma operator on line 71 that GCC ignored completely. Neither compiler is the strict one; they are strict about different things.

Three things I do now :

1. -pedantic, always. It is what turned case 1 from an invisible extension into a named diagnostic, -Wgnu-pointer-arith, on the compiler that was otherwise happy.

2. Build on both, in CI. Two jobs, gcc and clang, same flags. It is a few lines of YAML and it would have caught every one of these.

3. Name the standard library, not just the compiler. "It builds with clang" is half a sentence. On macOS it means libc++. On Linux it usually does not.

None of this is advanced. It is the sort of thing you learn the first time someone else tries to build your code which, for most of us, is the first time it matters.

The repos are on GitHub if you want to see the before and after.