Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C23 Implications for C Libraries

htmlpreview.github.io

Post reply on HN
Print view View original

11–20 of 135 posts

Re: C23 Implications for C Libraries

#11

Post by GrumpySloth »

turminal wrote: post #7
GrumpySloth wrote: post #5

> Trigraphs are removed from the language. Finally! My joy knows no bounds.

Why? They seem pretty harmless, are they difficult to implement?

They’re not difficult to implement. It’s a sed pass running before any preprocessor or even lexer, which is the horrifying thing. They replace characters in source code, they’re not normal tokens like digraphs. And so e.g. the following program won’t print what a mere mortal would expect:

  #include 

  int main() {
    puts(“What??(Really.)”);
  }
Try running that. Only change the quote marks to the ones on a normal keyboard (I’m on my phone.)

Edit: Oh, and remember to compile with -std=c11 e.g. gnu11 has trigraphs disabled by default.

Re: C23 Implications for C Libraries

#14

Post by avar »

Not new in C23, but I still think it's a glaring hole in the standard that there's still no standard way to ask the compiler which (if any) of "J.5 Common extensions" is supported.

For the C version you have __STDC_VERSION__, but there's no similar facility to check if e.g. J.5.7 is supported, which effectively makes the behavior that's explicitly omitted in 7.22.1.4 and 6.3.2.3 go from "undefined" to supported by C23 + the extension.

I understand why C can't have some generic "is this undefined?" test, but it seems weird not to be able to ask if extensions defined in the standard itself are in effect, as they define certain otherwise undefined behavior. The effect is that anyone using these extensions must be intimately familiar with all the compilers they're targeting.

Re: C23 Implications for C Libraries

#15

Post by tpush »

avar wrote: post #9

"Extended integer types may be wider than intmax_t". I'm sure there's a good reason for this, but it was introduced in C99, which says (in 7.8.1.5): "[intmax_t] designates a signed integer type capable of representing any value of any signed integer type". That was already portable between 16 bit, 32 bit, 64 bit etc. Why is it that just because the compiler supports 128 bit or 256 bit integers that compiling in such…

Presumably because the size of intmax_t was set to something specific on its introduction and changing it now would constitute an ABI break most everywhere.

Re: C23 Implications for C Libraries

#16

Post by avar »

GrumpySloth wrote: post #11
turminal wrote: post #7

Earlier quoted context omitted.

Why? They seem pretty harmless, are they difficult to implement?

They’re not difficult to implement. It’s a sed pass running before any preprocessor or even lexer, which is the horrifying thing. They replace characters in source code, they’re not normal tokens like digraphs. And so e.g. the following program won’t print what a mere mortal would expect: #include int main() { puts(“What??(Really.)”); } Try running that. Only change the quote marks to the ones on a normal keyboard (I…

The standard itself has a better example (well, older versions). In C99 it's:

    printf("Eh???/n");
Which is the same as:

    printf("Eh?\n");
I.e. the "??/" supplies the "\" to the "n", making it a "\n". I think it's good that they're gone (they were there to support some ancient non-ASCII systems). But it's worth mentioning that the "horrifying" semantics are there so that these trigraphs combine with digraphs (edit: "escape sequences", see downthread) in this way.

Otherwise you'd just get:

    printf("Eh?\\n");

Re: C23 Implications for C Libraries

#17

Post by smcameron »

GrumpySloth wrote: post #11
turminal wrote: post #7

Earlier quoted context omitted.

Why? They seem pretty harmless, are they difficult to implement?

They’re not difficult to implement. It’s a sed pass running before any preprocessor or even lexer, which is the horrifying thing. They replace characters in source code, they’re not normal tokens like digraphs. And so e.g. the following program won’t print what a mere mortal would expect: #include int main() { puts(“What??(Really.)”); } Try running that. Only change the quote marks to the ones on a normal keyboard (I…

Edit: Nevermind. I had an extra space so my experiment was flawed.

So, I tried it with gcc and clang, and neither did anything strange.

Also tried -std=c99 and -std=c89. All behaved the same.

I thought maybe my distro had some default option configured to turn of trigraphs/digraphs, but --verbose didn't seem to show anything suspicious.

    $ cat garbage.c
    # include
    
    int main()
    {
     puts("What?? (really)");
     return 0;
    }
    $ clang -std=c11 -o garbage garbage.c
    $ ./garbage
    What?? (really)
    $ clang -std=c99 -o garbage garbage.c
    $ ./garbage
    What?? (really)
    $ man gcc
    $ clang -std=c89 -o garbage garbage.c
    $ ./garbage
    What?? (really)
    $ gcc -std=c11 -o garbage garbage.c
    $ ./garbage
    What?? (really)
    $ gcc -std=c99 -o garbage garbage.c
    $ ./garbage
    What?? (really)
    $ gcc -std=c89 -o garbage garbage.c
    $ ./garbage
    What?? (really)
    $

Re: C23 Implications for C Libraries

#18

Post by GrumpySloth »

avar wrote: post #16
GrumpySloth wrote: post #11

Earlier quoted context omitted.

They’re not difficult to implement. It’s a sed pass running before any preprocessor or even lexer, which is the horrifying thing. They replace characters in source code, they’re not normal tokens like digraphs. And so e.g. the following program won’t print what a mere mortal would expect: #include int main() { puts(“What??(Really.)”); } Try running that. Only change the quote marks to the ones on a normal keyboard (I…

The standard itself has a better example (well, older versions). In C99 it's: printf("Eh???/n"); Which is the same as: printf("Eh?\n"); I.e. the "??/" supplies the "\" to the "n", making it a "\n". I think it's good that they're gone (they were there to support some ancient non-ASCII systems). But it's worth mentioning that the "horrifying" semantics are there so that these trigraphs combine with digraphs (edit: "esc…

This example doesn’t involve digraphs. Trigraphs also preceded digraphs, so their semantics couldn’t have been motivated by digraphs. In fact digraphs were added as a better-thought-out alternative to trigraphs. Digraphs were added in C99, whereas trigraphs were added in C89.

Re: C23 Implications for C Libraries

#19

Post by GrumpySloth »

smcameron wrote: post #17
GrumpySloth wrote: post #11

Earlier quoted context omitted.

They’re not difficult to implement. It’s a sed pass running before any preprocessor or even lexer, which is the horrifying thing. They replace characters in source code, they’re not normal tokens like digraphs. And so e.g. the following program won’t print what a mere mortal would expect: #include int main() { puts(“What??(Really.)”); } Try running that. Only change the quote marks to the ones on a normal keyboard (I…

Edit: Nevermind. I had an extra space so my experiment was flawed. So, I tried it with gcc and clang, and neither did anything strange. Also tried -std=c99 and -std=c89. All behaved the same. I thought maybe my distro had some default option configured to turn of trigraphs/digraphs, but --verbose didn't seem to show anything suspicious. $ cat garbage.c # include int main() { puts("What?? (really)"); return 0; } $ cla…

You need to get rid of the space between “??” and “(“.
Post reply on HN