On: Some Obscure C Features

[EGreg]

Here is an obscure c feature:

  int main()
  {
     int a = 8;
     {
       int a = 4;
       /* a is only scoped to this block */
     }
     printf("%d", a); /* prints 8 */
  }

It is also why C++ is not a strict superset of C

[eMSF → EGreg]

That's hardly obscure: it's Javascript that's the odd one out of the languages with C-like syntax, with its wacky function-level scoping instead of variable shadowing when using 'var', and falling back to global scope when not declaring a variable properly. Also, C and C++ behave identically with your given example.

A perhaps obscure feature is that you can "unshadow" a global variable like this:

  #include <stdio.h>
  int global = 0;
  int main()
  {
    int global = 1;
    {
      extern int global;
      printf("%d\n", global); // prints 0
    }
  }

[dkersten → EGreg]

> It is also why C++ is not a strict superset of C

Can you explain? That code in C++ also scopes ‘a’ to the block.

EDIT: I see you’ve edited the code, but I think it’s still true in C++. I’ve often done that for RAII and unless I’m mistaken it works just as well when shadowing variables like you’re doing as when not.

[scott_s → dkersten]

Agreed. And I have also used it in C++ for RAII purposes. In C++, braces introduce a scope, and objects local to that scope will be destructed upon exit.

[codesushi42 → EGreg]

... is this a joke? It's called lexical scoping, and it's supported by more languages than not.

[scott_s → EGreg]

That's true in C++ as well: https://en.cppreference.com/w/cpp/language/scope

[wahern → EGreg]

Off the top of my head, I can't think of any language that doesn't permit this. See https://en.wikipedia.org/wiki/Variable_shadowing

[saagarjha → wahern]

Your link mentions CoffeeScript as not allowing shadowing.

[jcranmer → EGreg]

If you want to tell if your compiler is C or C++, run this program:

   #include <stdio.h>
   int main() {
     printf("%d\n", sizeof('a'));
   }

It's the second thing C++ mentions in its list of incompatibility with C (the first is "new keywords").

A more obscure difference is this program:

   int i;
   int i;
   int main() {
     return i;
   }

It's legal C but not legal C++.

[_kst_ → jcranmer]

sizeof ('a') doesn't reliably tell you whether you're compiling C or C++. It yields the same result in an implementation where sizeof (int) == 1 (which requires CHAR_BIT >= 16). (The difference is that character constants are of type int in C, and of type char in C++.)

So if sizeof ('a') == 1, then either you're compiling as C++ or you're compiling as C under a rather odd implementation.

Both POSIX and Windows require CHAR_BIT==8. The only systems I know of with CHAR_BIT>8 are for digital signal processors (DSPs).

If you want to tell whether you're compiling C or C++:

    #ifdef __cplusplus
    ...
    #else
    ...
    #fi

[ksherlock → jcranmer]

    int main() {
      return 4//**/2
      ;
    }

[eMSF → ksherlock]

Line comments have been part of the C language for a long, long time (added in C99); so much so that, especially when discussing the subject on the internet, more and more often they predate some of the younger participants.

[saagarjha → eMSF]

Personally, I didn't know that C lacked line comments until I ran into a project that compiled with -std=c89 -pedantic.

[_kst_ → saagarjha]

C doesn't lack line comments. The obsolete 1989/1990/1995 version(s) of C did lack line comments.

[unwind → jcranmer]

You need to use %zu to print values of type size_t, otherwise you get undefined behavior. So in C, don't run that program. :)

[truncate → EGreg]

I don't think that's obscure at all. That's standard lexical scoping. Do it all the time in functional languages.

[IanS5 → EGreg]

Blocks are a common feature