Taking this out of the bug, since it's no longer really relevant... On Fri, Dec 02, 2016 at 01:00:08AM -0000, Mutt wrote: > Replying to [comment:18 derekmartin]: > > The macro version has the opposite problem: You can make the array too > small and it will "work" but it will be incomplete. > > I don't see any problem.
The problem here is exactly the same problem as with the version I presented... In both cases you can under-specify the data. In both cases it will still "work" -- you just won't get what you expect. The cases are different, but there's no *practical* difference. > > Ultimately, a bug is a bug, and you just have to write the code > correctly. > > This is more complex than that. I don't agree, because: > Code evolves and can become incorrect. This statement is true; however it's the responsibility of whoever modified it to understand the code and make correct modifications. If they failed, they created a bug. A bug is a bug is a bug. If someone modifies code without understanding it, all sorts of chaos might ensue. Also, this is an argument AGAINST using macros. They are less well-specified than functions, and especially where odd structures and casts are used to make them generic, are more prone to being used incorrectly, because the compiler has a lessened ability to ensure code correctness. As a result, the macro places a higher burden of understanding on the maintainer than a properly specified function. > The advantage of the macro is that the size of the array is given > only at one place: via the initializer list. Which makes zero difference to program correctness if the array was not specified properly. The advantage to the fixed length array is the programmer can see exactly how many elements are SUPPOSED to be in the array, and simply count them. But in this case, just as in the macro case, it still makes no difference to program correctness if the fixed-length array did not have enough elements assigned (was not specified properly). In the first case, menu doesn't have enough rows printed (some correct data is missing). In the second case, it has the right number of rows, but row 0 is incorrectly repeated 2 additional times at the end (some correct data is missing, though replaced with wrong data). It's exactly the same class of problem, just slightly different details. The helper function approach eliminates both of those problems, while using less code to do it. It is exactly precise and cannot fail so long as the SSL library provided valid and correct data to the caller (which was already required for both of the other two solutions anyway). The lesson is: Prefer functions to macros. In general, while they may have their uses, macros suck. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgp36ZROixPdv.pgp
Description: PGP signature
