Your understanding is incomplete.

  $ gcc -c test.c
  test.c: In function ‘foo’:
  test.c:3:12: warning: return makes pointer from integer without a cast [-Wint-conversion]
     return x;
            ^

The translation unit has a constraint violation, for which ISO C requires a diagnostic. The compiler supplied one.

ISO C doesn't say that translation must be terminated.

ISO C doesn't define different classes of diagnostic like "error" or "warning".

I didn't tell GCC to be an ISO C compiler. The above diagnostic tells us that while conversions from integers to pointers happen implicitly, the GNU C dialect, like ISO C, wants that diagnosed. You have to go out of your way to modify the dialect not to have that diagnosed, like:

  $ gcc -Wno-int-conversion -c test.c
  $

That's not GNU C any more, but a tweaked sub-dialect of GNU C with a diagnostic requirement removed.

Yes, I agree especially for code intended to teach something else it's not a good idea to include GCCisms.

I didn't find any section about compilation set-up (compiler, warning levels, flags etc) at all in the OP, but didn't spend a lot of time looking. Perhaps it would be a good addition too to specify which dialect of C is used.

What's the GNUism here? Silently casting ints to pointers is a time-honored C tradition.

Well, that's just ill formed in ISO C.

edit: hmm, maybe not:

https://cigix.me/c17#6.3.2.3.p5

Looks like gcc rejects the implicit conversion with -std=c17 -pedantic-errors as it's such a bad idea to allow this, but ISO C actually allows this.

That's about explicit conversion right?

    void * ptr;
    uintptr_t x = (uintptr_t)ptr;

But allowing this would be just insane:

    uintptr_t x = ptr;

I haven't programmed in plain C (as opposed to C++) in decades, but I can't believe it is allowed... ... but gcc on godblot only raises a warning but still happily compiles it. o_O

Yeah, you are right that 6.3 lists all conversions, implicit and explicit.

https://cigix.me/c17#6.3.p1

> Several operators convert operand values from one type to another automatically. This subclause specifies the result required from such an implicit conversion, as well as those that result from a cast operation (an explicit conversion). The list in 6.3.1.8 summarizes the conversions performed by most ordinary operators; it is supplemented as required by the discussion of each operator in 6.5.

Weather a conversion is allowed in a certain context should be specified for wording for that given context.

For example assignment:

https://cigix.me/c17#6.5.16.1.p1

Return statements are similarly restricted:

https://cigix.me/c17#6.8.6.4.p3

> If the expression has a type different from the return type of the function in which it appears, the value is converted as if by assignment to an object having the return type of the function.

(emphasis mine)

However I can't make sense of the footnote:

> The return statement is not an assignment. The overlap restriction of subclause 6.5.16.1 does not apply to the case of function return. The representation of floating-point values may have wider range or precision than implied by the type; a cast may be used to remove this extra range and precision.

Why doesn't the overlap restriction apply, if return is "as if by assignment"? Makes no sense to me.

In general, the C standard only requires a diagnostic for constraint violations.

> ISO C

Not being in ISO C(99, I'm less sure about 89) doesn't make it a GNUism. At best you're disagreeing with GCC over its default standards version.

Clang only changed the default in 2022, for example. https://reviews.llvm.org/D129881