On Wed, 18 Dec 2024, James K. Lowden wrote: > * Please make sure to do all regeneration with *unmodified* versions > [Joseph] > - I don't understand.
You appeared to have regenerated a configure script built with a version of autoconf from a GNU/Linux distribution that patched autoconf to add a variable runstatedir that's not in the relevant upstream version of autoconf (2.69). Don't do that. Everyone needs to use the same version of autoconf to regenerate checked-in configure scripts, which means unmodified 2.69 built directly from upstream sources, not a distribution-patched version of 2.69. > * does not build on Darwin/macOS [Iain] > - We have built only on Linux, on aarch64 x86_64 (per arch(1)). > - We rely on support for 128-bit integer and floating point to meet > ISO COBOL requirements. > - We want to build on any 64-bit Posix OS, BE and LE. > - 32-bit architectures are not a consideration. It's still not clear here what is about the host and what is about the target. * It would be odd to care whether the host is 32-bit or 64-bit. * If you care about whether the target is 32-bit or 64-bit, that might affect which multilibs you build the runtime library for - but the choice between 32-bit and 64-bit is a multilib choice on several common platforms, so you can't say "disable building the compiler for 32-bit targets", since x86_64-linux-gnu and i686-linux-gnu can be targets that are both 32-bit and 64-bit depending on whether -m32 / -m64 / -mx32 are passed to the compiler. * A key overall principle here is: don't break default builds using --enable-languages=all. If the compiler won't build for a particular host or target, arranging for the build of COBOL to be disabled there is much better than breaking the build. Likewise for the runtime library. Of course broad portability is nice, but if you're known not to be portable to some configuration, at least keep --enable-languages=all builds working there. > * check asprintf [Joseph] > - The only examples I find where the returned value of asprintf is not > checked is in symbols_dump(), which is used only to debug the front > end. I'd still encourage moving to xasprintf everywhere to avoid needing to check it locally in each place; using such libiberty interfaces when available is less error-prone. > * Static buffers with a PATH_MAX size will probably break the build on > Hurd host. [Joseph] > - Hurd probably not relevant to COBOL > - PATH_MAX is Posix. There is no perfect solution. As per POSIX, "A definition of one of the symbolic constants in the following list shall be omitted from the <limits.h> header on specific implementations where the corresponding value is equal to or greater than the stated minimum, but where the value can vary depending on the file to which it is applied. The actual value supported for a specific pathname shall be provided by the pathconf() function.". You can't rely on there being any given maximum. > - If any provided filename is too long, the front end should report it > as an error. That's what tar(1) does. The thing to do is just to pass the filename through the compiler (without a size limit, use dynamic memory allocation not fixed-size buffers) and give errors if opening it fails, at the point where it needs to be opened. It's a principle of the GNU Coding Standards not to have arbitrary fixed limits. > - Regarding translation support, we would prefer to add that soon > after the front end is accepted. If you use the GCC diagnostic machinery (calling existing functions such as error_at and warning_at with gmsgid parameters), translations should mostly work automatically. > * please make sure that every function has such a comment [Josef] > - There are 2074 functions, 1295 of which are static. I estimate the > effort would require 86 man-days. > - IMO this is not the best way to write documentation, nor a measure > of its quality. How do you intend to ensure that people other than those who originally wrote the code (which practically also includes those who wrote it, ten years later when they've forgotten the details) can read and maintain it, and in particular can figure out what the intended interface between different functions is? The comments are meant to be a guide to intent, both so someone reading a call to a function can figure out what it's meant to do without needing to read all the content of the function being called (only the comment), and so that if there seems to be a mismatch between expectations in the caller and in the callee, there is some indication of what was originally intended. -- Joseph S. Myers josmy...@redhat.com
