Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: