e13c79ee..273a6df9 #ifdef's the VLA logic as discussed, but would be nice if someone with VS could confirm that the compiler is now happy, especially as my VLA_ARRAY_LEN_DIGEST macro generates stuff like
char array[((n<4)?1:abort()),4]; which I'm not 100% sure will be read as an obviously constant-size array by some compilers ;-). Also, I might have overlooked a VLA somewhere... On 12/10/18 7:14 PM, Jonathan McDougall wrote: > On 12/10/18, Tim Rühsen <tim.rueh...@gmx.de> wrote: >> On 12/10/18 2:27 PM, Christian Grothoff wrote: >>> On 12/10/18 9:53 AM, Tim Rühsen wrote: >>>> instead of keeping all projects at C89, you can also use Visual >>>> Studio with LLVM/Clang or GCC > > 0.9.62 does build with the clang toolset on Visual Studio after some > changes to the project file. It's not something most users will have > installed though. > > Note also that VLAs are an _optional_ feature of C11 (see 6.7.6.2/4 and > 6.10.8.3). > >>> Well, we do know the max for all of the VLAs, so it would be trivial >>> to change the code to use that value instead. However, for the sake >>> of keeping the stack shallow on embedded systems, I would prefer to >>> do this conditionally only if the C compiler doesn't support VLAs. > > Just how many bytes are we talking about? VLAs aren't free either, and > the code generated to create the array might just be bigger than the > number of bytes you save on allocation, as well as being generally less > efficient than a simple array of constant size. > >>> Does the W32-crowd know whether AC_C_VARARRAYS and the resulting >>> __STDC_NO_VLA__ works nicely with Visual Studio? > > __STDC_NO_VLA__ is undefined in Visual Studio, regardless of the toolset > selected. As for AC_C_VARARRAYS, the configure script isn't used on > Windows at all. I guess __STDC_NO_VLA__ could be conditionally defined > in w32/common/MHD_config.h. > >>> If so, we could >>> >>> #if __STDC_NO_VLA__ >>> #define VLA_LEN_DIGEST(n) (32*2+1) >>> #else >>> #define VLA_LEN_DIGEST(n) (n) >>> #endif > > Well, at this point I guess it becomes a matter of taste, but I'd be > really uncomfortable with having such a difference in code between two > platforms, especially since Windows is not exactly tested very often. If > you go that route, at least put a check for `n < 32*2+1` to avoid buffer > overflows. > >> You could also add a configure check for alloca and use that function >> in case __STDC_NO_VLA__ is defined. > > alloca() is not part of any standard, whether it's C, C++ or POSIX. > Visual Studio had an _alloca(), but it's deprecated. It has a weird > _malloca() that requires a weirder _freea(). > > alloca() also has a bunch of problems, like interfering with inlining > on gcc and undefined behaviour on failure. Basically every single > manpage I could find discourages its use. > > I would personally go for constant size arrays, or malloc() if you > can't. Keep it simple and portable. >
signature.asc
Description: OpenPGP digital signature
