3 ms·

Is this a serious proposal for a new C language feature? Or is this just an experiment from someone's masters thesis or something? The paper is titled "Proposal

Is this a serious proposal for a new C language feature? Or is this just an experiment from someone's masters thesis or something? The paper is titled "Proposal for C2x", but this can't possibly be seriously considered. I have so many questions. In section 1.1, the linearization it gives with goto statements is barely longer than the defer example. They claim defer is better just because of the proximity of the cleanup code? Why not just move the "resources acquired" code to a separate function? You wouldn't even need goto in that case, you could just nest if statements to do the cleanup. The spec claims defer allocates memory. Why? As far as I know __attribute__((cleanup(fn))) doesn't allocate memory. This defer may exhaust memory, and if so, it will immediately terminate execution of the enclosing guard block with a panic() and DEFER_ENOMEM. So like an exception? This says exit() or panic() will clean up all guarded blocks across all function calls of the same thread. So basically stack unwinding? Apparently you can recover somewhere with a call to recover()? This is just exceptions by another name. This stack unwinding can't possibly interoperate with existing code that expects error return values. This claims it's robust because any deferred statement is guaranteed to be executed eventually, and it describes in great detail how it runs defer statements on signals. What if I write an infinite loop, or get a SIGKILL, or yank the power cord? Obviously deferred statements won't be executed. This says defer is implemented with longjmp. Isn't setjmp/longjmp way too slow for exception handling? C++ compilers haven't done exceptions that way for decades. What happens if I longjmp or goto past a defer statement? This says it just doesn't invoke the defer mechanism and may result in memory leaks or other damage. Does that mean it's undefined behaviour? C++ won't compile a goto past constructors for good reason. All POSIX error and signal codes have an equivalent prefixed with DEFER_, e.g. DEFER_ENOMEM, DEFER_HUP. This is just in case the system doesn't already have ENOMEM? Doesn't the standard already require that ENOMEM exist? If not, why not just make this feature require that ENOMEM exist? Why depend so much on errno for new core language features when it's basically an ugly artifact of ancient C library functions? > If C will be extended with lamdas (hopefully in a nearer future) I wouldn't hold my breath.

tom_mellior 6y ago
You're arguing in bad faith, which the HN rules explicitly ask you not to do. > Or is this just an experiment from someone's masters thesis or something? The proposal has seven authors, three of which list industry affiliations and three various academic institutions. You're not required to know that some (all?) of the authors are on the C standard committee to tell that this is very probably a more serious proposal than someone's masters thesis. > Why not just move the "resources acquired" code to a separate function? You wouldn't even need goto in that case, you could just nest if statements to do the cleanup. That wouldn't work nicely with jumps out of the separate function. Not just with goto, but imagine the guarded block being a loop body and doing break/continue. The function would have to return some special value to indicate "I would like to break/continue here, please". Possible, but why would that be an improvement over goto for something that is clearly a goto use case that the compiler should handle? > So basically stack unwinding? You're saying this as if you had puzzled out the "real meaning" hidden inside this proposal. But the proposal doesn't hide that this is, yes, basically stack unwinding. > This says defer is implemented with longjmp. This says that this reference implementation, the goal of which is to allow people to test the ergonomics of the feature, is implemented with longjmp. The proposal itself is written to allow such an implementation, but it doesn't require it.
- ludocode 6y ago
  I don't believe I'm arguing in bad faith. Of course I think this would be wildly inappropriate for C2x, but I am still genuinely curious about this which is why I spent so much time reading it and writing that post. I do actually want to know the answers to my questions. Stack unwinding is one of the largest, most complicated to implement, and most controversial features of C++. Google, a company with billions of lines of C++, famously disables exception handling in most or all of their code [1]. Not only do many popular C++ projects disable exceptions, but even C++ compilers themselves disable exceptions in their own implementation [2]! C became popular in large part because of its simplicity of implementation. Some of these projects historically disabled C++ exceptions because they were slow and bloated, a result of the difficulty of implementing them efficiently. Now that they're fast and less bloated, these projects still can't turn them on because code that relies on stack unwinding is incompatible with code that does not. This proposal just repeats all of the same problems as C++. It is extremely surprising that such a large group of people would propose such a radical feature addition to C, especially one that is so complicated to implement and that effectively makes code that uses it totally incompatible with old code that doesn't. This is interesting when viewed as a feature of a new language based on C, but the idea of adding this to C is frankly absurd. [1]: https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions [2]: https://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions https://llvm.org/docs/CodingStandards.html#do-not-use-rtti-o...
  - tom_mellior 6y ago
    I think these questions about stack unwinding are valuable. If you really do actually want answers, you should probably, in this order, (a) study the actual proposal in detail and not confuse it with an imperfect reference implementation, (b) check comp.std.c for previous discussions on the topic and maybe ask there, (c) see if there are other previous discussions involving the members who proposed this (maybe the standard committee has some semi-public mailing list or something?) and maybe ask there, (d) contact the email address given in the proposal. In all cases, it's probably a very good idea to stay as civil as you were in this post, not as confrontational as you were above. I'm stressing that you should study the proposal because some of the things you got hung up before were not properties of the proposal but only of the reference implementation. Besides the longjmp issue, the dynamic allocation issue might be in this category as well. The proposal doesn't mention DEFER_ENOMEM, I think a compiler would have enough information in any case to allocate the needed space on the stack.

tom_mellior 6y ago

You're arguing in bad faith, which the HN rules explicitly ask you not to do. > Or is this just an experiment from someone's masters thesis or something? The proposal has seven authors, three of which list industry affiliations and three various academic institutions. You're not required to know that some (all?) of the authors are on the C standard committee to tell that this is very probably a more serious proposal than someone's masters thesis. > Why not just move the "resources acquired" code to a separate function? You wouldn't even need goto in that case, you could just nest if statements to do the cleanup. That wouldn't work nicely with jumps out of the separate function. Not just with goto, but imagine the guarded block being a loop body and doing break/continue. The function would have to return some special value to indicate "I would like to break/continue here, please". Possible, but why would that be an improvement over goto for something that is clearly a goto use case that the compiler should handle? > So basically stack unwinding? You're saying this as if you had puzzled out the "real meaning" hidden inside this proposal. But the proposal doesn't hide that this is, yes, basically stack unwinding. > This says defer is implemented with longjmp. This says that this reference implementation, the goal of which is to allow people to test the ergonomics of the feature, is implemented with longjmp. The proposal itself is written to allow such an implementation, but it doesn't require it.

ludocode 6y ago
I don't believe I'm arguing in bad faith. Of course I think this would be wildly inappropriate for C2x, but I am still genuinely curious about this which is why I spent so much time reading it and writing that post. I do actually want to know the answers to my questions. Stack unwinding is one of the largest, most complicated to implement, and most controversial features of C++. Google, a company with billions of lines of C++, famously disables exception handling in most or all of their code [1]. Not only do many popular C++ projects disable exceptions, but even C++ compilers themselves disable exceptions in their own implementation [2]! C became popular in large part because of its simplicity of implementation. Some of these projects historically disabled C++ exceptions because they were slow and bloated, a result of the difficulty of implementing them efficiently. Now that they're fast and less bloated, these projects still can't turn them on because code that relies on stack unwinding is incompatible with code that does not. This proposal just repeats all of the same problems as C++. It is extremely surprising that such a large group of people would propose such a radical feature addition to C, especially one that is so complicated to implement and that effectively makes code that uses it totally incompatible with old code that doesn't. This is interesting when viewed as a feature of a new language based on C, but the idea of adding this to C is frankly absurd. [1]: https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions [2]: https://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions https://llvm.org/docs/CodingStandards.html#do-not-use-rtti-o...
- tom_mellior 6y ago
  I think these questions about stack unwinding are valuable. If you really do actually want answers, you should probably, in this order, (a) study the actual proposal in detail and not confuse it with an imperfect reference implementation, (b) check comp.std.c for previous discussions on the topic and maybe ask there, (c) see if there are other previous discussions involving the members who proposed this (maybe the standard committee has some semi-public mailing list or something?) and maybe ask there, (d) contact the email address given in the proposal. In all cases, it's probably a very good idea to stay as civil as you were in this post, not as confrontational as you were above. I'm stressing that you should study the proposal because some of the things you got hung up before were not properties of the proposal but only of the reference implementation. Besides the longjmp issue, the dynamic allocation issue might be in this category as well. The proposal doesn't mention DEFER_ENOMEM, I think a compiler would have enough information in any case to allocate the needed space on the stack.