On Mon, 2019-09-02 at 15:35 -0700, Paul Eggert wrote: > We need to be portable to C99 and later. C89 and later if the > programmer wants to and if it's not too much work. K&R C is almost > surely not worth the effort.
I generally attempt to keep GNU make more portable than most GNU projects as I consider it a bootstrap tool. However I gave up K&R portability in GNU make 3.82 if not in practice earlier than that. > OpenSSL is a different project from OpenSSL and uses different coding > standards. The GNU coding standards say that GNU code should be > portable. Although K&R C and C89 are no longer relevant on practical > hosts, C99 and later are, so they are core target platforms for GNU > Make and for other GNU projects that have code written in C. Correct. I should say, I expect GNU make to build properly with a C compiler that supports ANSI C89/ISO C 1990 _or later_. If people want to attempt to build GNU make with older C89 compilers, or newer compilers with settings forcing them to behave as older compilers, then that's fine and if they run across issues I'm interested in hearing about them, for code cleanliness purposes. But there's no _requirement_ to force older compiler behavior if your goal is simply to build GNU make and ensure it runs properly on a given platform. It should work with whatever standard behavior your compiler defaults to. I guess also as I start to use more gnulib library code, I can't say for sure if this C89 requirement is realistic because I don't know what gnulib coding standards require. I will point out, however, that it was only very, very recently that Visual Studio supported C99 more-or-less fully. Prior to Visual Studio 2017, I believe, only C89 was supported (many C99'isms were supported but not, for example, the full C runtime library). _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
