On Sat, Feb 13, 2016 at 1:56 PM, Thomas Koenig <tkoe...@netcologne.de> wrote: > Am 12.02.2016 um 11:42 schrieb Janne Blomqvist: >> >> On Fri, Feb 12, 2016 at 12:16 PM, Andre Vehreschild <ve...@gmx.de> wrote: > > >>> The proposed alloca() call >>> has according to the documentation of libc some availability issues on >>> certain platforms, too. > > > These availablity issues cannot be too serious, or we would be having > trouble already: > > ig25@linux-fd1f:~/Gcc/trunk/gcc/fortran> fgrep -H -n 'alloca (' *.c > cpp.c:839: to_file_quoted = (unsigned char *) alloca (to_file_len * 4 + > 1); > cpp.c:1079: (unsigned char *) alloca (to_file_len * 4 + 1); > error.c:898: buffer = (char *) alloca (strlen (msg) + strlen (msg2) + 2); > module.c:6042: filename = (char *) alloca (n); > module.c:6048: filename = (char *) alloca (n); > module.c:6058: filename_tmp = (char *) alloca (n + 1); > options.c:267: source_path = (char *) alloca (i + 1); > primary.c:214: buffer = (char *) alloca (length + 1); > primary.c:438: buffer = (char *) alloca (length + 1); > primary.c:600: buffer = (char *) alloca (count + 1); > scanner.c:321: q = (char *) alloca (len + 1); > simplify.c:6381: buffer = (unsigned char*)alloca (buffer_size); > target-memory.c:674: buffer = (unsigned char*)alloca (len); > target-memory.c:781: buffer = (unsigned char*)alloca (buffer_size); > >>> Therefore why not going with the fixed size >>> stack array and adding a check for possible overflow to it and be done? >> >> >> Yes, I agree. That sounds like the best approach in this case. > > > OK, here is the final version of the patch. I'd like to get this > committed so I can turn to PR 69742.
Ok, thanks for the patch. -- Janne Blomqvist