alt.hn

3/18/2026 at 1:57:21 PM

Side-Effectful Expressions in C (2023)

https://blog.xoria.org/expr-stmt-c/

by surprisetalk

3/24/2026 at 6:51:02 AM

It might sound easy to fix just a little detail that disturbs you and keep the rest as it is, but it's rarely feasible.

If we ban side effects from expressions, we must change the "for" syntax too, because the third "argument" currently is an expression. It should be a statement instead. Let's see...

  for (int i=0; i<n; ++i) // old
  for (int i=0; i<n; i+=1;) // new
What about the typical 2-variable loop?

  for (int i=0,j=n; i<j; ++i,--j) // old
  for (int i=0,j=n; i<j; {i+=1;j-=1;}) // maybe?
Or we simply forbid all this and force the increment and decrement in the body:

  for (int i=0,j=n; i<j; ;) {
    ...
    i+=1;
    j-=1;
  }
This is throwing the baby out with the bathwater!

And finally, if the third argument is a statement, would a break or continue be accepted there as well? A nested for? Sure, these are examples of abusing the syntax, but so is using x and ++x in the same expression.

My conclusion is that some constructs are so powerful that they can both simplify our code and make it unreadable. The choice how to use them is ours.

by teo_zero

3/23/2026 at 7:44:55 PM

Maybe I'm just Stockholm syndrome-d into the C programming language, but none of the examples here are terribly compelling to me - I love articles about C's weirdness, but I don't really think his before and after comparisons make a case for a replacement for C.

by commandlinefan

3/23/2026 at 7:59:53 PM

Yeah, just because you can grab from your refrigerator a piece of raw meat and put it in a cup of milk in 10 secs and it tastes bad doesn’t mean the refrigerator should be blamed because of this.

by up2isomorphism

3/23/2026 at 9:50:13 PM

Yeah, but if the refrigerator is built in a way that makes it very easy to grab some refrigerant when you want to pour yourself a glass of milk (to the point that one has to be careful and skilled to safely drink milk), maybe we should get a new refrigerator.

by volemo

3/23/2026 at 9:48:14 PM

For fun, my attempt to rewrite the functions. Eliminate ++ and pointer arithmetic by introducing a counter. Obviously less terse.

  void *my_memcpy(void *dst, const void *src, size_t n)
  {
   const uint8_t *s = src;
   uint8_t *d = dst;
   for (size_t i = 0; i < n; i += 1) d[i] = s[i];
   return dst;
  }

  int powi(int x, int y)
  {
   int result = 1;
   for (int i = 0; i < y; i += 1) result *= x;
   return result;
  }
For itoa, I experiment with the comma operator to show the post-increment on the same line, but visibly after. I also move the negation sign block to the absolute value block.

  void itoa(int n, char s[])
  {
   int i = 0;
   if (n < 0){
    n = -n;
    s[0] = '-', s += 1; // exclude from reverse
   }
   do{
    s[i] = n % 10 + '0', i += 1;
    n /= 10;
   }while(n > 0);
   s[i] = '\0';
   // reverse
   for(int j = 0, hi = i / 2; j < hi; j += 1) {
    i -= 1;
    char swap = s[j];
    s[j] = s[i];
    s[i] = swap;
   }
  }
Test code:

  #include <stdio.h>
  #include <stdint.h>
  // insert functions
  int main(void){
   char src[] = "hello";
   char dst[10];
   my_memcpy(dst, src, sizeof(src));
   printf("%s == hello\n", dst);
   printf("%d == 27\n", powi(3,3));
   itoa(-12345, dst);
   printf("%s == -12345\n", dst);
   itoa(0, dst);
   printf("%s == 0\n", dst);
  }

by amavect

3/23/2026 at 5:49:55 PM

Really this is mainly about the ++ and -- operators. I think Go made the right call here and allows these only as statements, not as expressions. I will basically never use these in code I write and will remove it from code I maintain or review; the only value add is compactness which is very rarely a goal.

The other side effect expression here is the equals operator; once again, this should not be an expression but should just be a statement. Once again this is used (intentionally) mainly for compactness and unintentionally used to create messy bugs. I do find the "yoda" style checks to be aesthetically unpleasing so I'm party of the problem here.

Maybe it's time to add `-Wno-crement-expressions` and `-Wno-assignment-expressions`. `-Wparentheses` gets you part of the way to the second but even the legitimate uses are ugly to my eye.

by andrewla

3/23/2026 at 9:21:06 PM

> Maybe it's time to add `-Wno-crement-expressions` and `-Wno-assignment-expressions`. `-Wparentheses`

Aren't there static analyzers in widespread use that would catch these?

by HackerThemAll

3/23/2026 at 7:15:52 PM

[flagged]

by nadavdebi