221–230 of 257 posts
Earlier quoted context omitted.
> Doesn't a similar DoS risk (from allowing users to allocate arbitrarily large amounts of memory) also apply to the heap? DoS Risk? No one cares too much about that - the problem with VLAs is stack smashing, which then allows aribtrary user-supplied code to be executed. You cannot do that with malloc() and friends.
VLAs don’t smash the stack.
Earlier quoted context omitted.
That seems to be what -fstack-check for gcc is doing: "If neither of the above are true, GCC will generate code to periodically “probe” the stack pointer using the values of the macros defined below."[1] I guess I'm wondering why this isn't always on if it solves the problem with negligible cost? Genuine question, not trying to make a point. [1] https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html
Because it's on by default in MSVC [0], and we all know that whatever technical decisions MS makes, they're superior to whatever technical decision the GNU people make. /s Speaking seriously, I too would like an answer. [0] https://docs.microsoft.com/en-us/windows/win32/devnotes/-win...
Earlier quoted context omitted.
That is like saying if sushi knifes are already sharp enough, there is no issue cutting fish with a samurai sword instead, except at least with the knife maybe the damage isn't as bad.
> That is like saying if sushi knifes are already sharp enough (...) No, it's like saying that professional people understand the need to learn what their tools of the trade do beyond random stackoverflow search on how to print text to stdout. It seems you have an irrational dislike of C. That's perfectly ok. No need to come up with excuses though.
Ever since I got my hands on Turbo C++ 1.0, back in 1993, I see no reason why one should downgrade ourselves to C.
At least C++ give us the tools to be a bit more secure, even if tainted with C's copy-paste compatibility.
You will find posts from me on Usenet, stading on C++ frontline of C vs C++ flamewars.
No one is making excuses, it should be nuked, unfortunely it will outlive all of us.
Earlier quoted context omitted.
Useless semantic pedantry at best, but arguable wrong as there isn't some sort of ISO standard on dumb hacking terms.
Overflowing the stack gives you a segfault. Smashing the stack lets hackers pop a shell on your computer. They are incredibly different. VLAs can crash your program, but they do not give attackers the ability to scribble all over the stack.
Earlier quoted context omitted.
If you want to talk about this kind of technicality, here are three other avenues through which I believe Turing completeness of C can be achieved: 1. As https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm helpfully points out, "If two objects have identical bit-pattern representations and their types are the same they may still compare as unequal", and "[implementations] may also treat pointers based on diff…
Let me address 2. and 3. first, because 1. is probably correct. 2. The problem with that is that you may have infinite recursion, but you can only pass finite amounts of memory between recursion steps. This has also been addressed by https://cs.stackexchange.com/a/60978 . 3. I don't follow, how could you create a growing `va_list`? Edit: Actually, I think I do now, so you essentially create a sort of linked list of `…
If I have two stacks (by spawning another thread), don't I have two PDAs ? That's what that stackoverflow post indicates, and IIRC two PDAs are equivalent to a Turing machine.
Earlier quoted context omitted.
> But something definite will happen, given the current state of the system. This is only true in the very loose and more or less useless sense that the compiler is definitely going to emit some machine code. What does that machine code do in the UB case? It might be absolutely anything . One direction you could go here is you insist that surely the machine code has a defined meaning for all possible machine states,…
You are confusing the C standard and actual platforms/C implementations. A lot of things are UB in the standard but perfectly well defined on your platform. Standards don’t compile code, real compilers do. The standard doesn’t provide standard library implementations, the actual platform does. Targeting the standard is nice, but if all of your target platforms guarantee certain behaviors, you might consider using tho…
Do you have examples of this "a lot of UB in the C standard" which is in fact guaranteed to be "perfectly defined and consistent" across all the platforms you listed ? You may need to link the guarantees you're relying on.
The line:
typedef int T[n];
It can be stack
T a;
T *a = malloc(sizeof *a);
T *a = alloca(sizeof *a);
VLA were added to language to handle multidimensional arrays.
And the really shine at this task. Even C++ has not good alternative for it. Vector of vectors is a really crappy data structure.
A few examples when working with square matrices:
- allocation on stack
float A[n][n];
float (*A)[n] = malloc(sizeof(int[n][n]));
...
free(A);
A[i][j]
void add(int n, float A[static n][n], float B[static n][n], float RES[restrict static n][n]);
...
Earlier quoted context omitted.
What's wrong with VLAs is their syntax. It really shouldn't use the same syntax as regular C arrays, otherwise they would be fine, maybe with a scary enough keyword. They are more generic than alloca too, alloca being scoped to the function, while VLAs being scoped to the innermost block scope that contains them.
Syntax, no protection against stack corruption,...
int A[100000000];
> Side note: even though we can't return, main is the exception to the rule that reaching the closing } of a function returning non-void is verboten, Isn't it legal to fall of the end of the end of a non-void function, only just defined as UB to use the return value?
Correct. > If the } that terminates a function is reached, and the value of the function call is used by the caller, the behavior is undefined.
> Otherwise, flowing off the end of a function other than main or a coroutine ([dcl.fct.def.coroutine]) results in undefined behavior.
https://timsong-cpp.github.io/cppwp/n4868/stmt.return#2.sent...
edit:
This also manifests in compiler optimizations, at least in gcc