> nothing but an academic quibble
Oh man, you had to give away the secret! Now everyone knows that this is just about how some choice of words in a title doesn't correctly relate to the content.
It's always nice and very motivating when you spend your free time on a project for the benefit of the public and are then publicly defamed by some busybodies with some irrelevant side issues. Thank you all very much for that.
Concerning your attitude please consult the guidelines of this forum which state "Plese respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith. Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead." Maybe next time.
A common reason for coding in C89 is avoiding mixed declarations and statements. That's one of the most prominent differences between C89 and C99. The GNU compiler won't catch that unless you use -pedantic or else the more specific diagnostic flag -Wdeclaration-after-statement.
This one actually bit me, since in some projects where I was actually trying to avoid declarations after statements, some uses accidentally snuck into the code due to being undiagnosed! I thought that may be the case here: the author wants to work in C89, but is blind to accidental deviations from the dialect.
So that is to say, I didn't think that the title of the submission needed fixing so much as rather the code: make the code be C89, if you believe you are working in C89 and want to be doing that for some real reason. (Turns out, to my surprise, you don't know what C89 means and don't care, so, okay, never mind.)
I also pointed out that <memory.h> is a nonstandard header. <memory.h> is where AT&T Unix systems in the 1980's put memcpy and friends. ANSI C89 standardized those and put them in <string.h>. Glibc happens to have a <memory.h> header which includes <string.h> for you.
Code which has to work on such old systems that it is necessary to use <memory.h> should probably also be written in classic K&R C without prototypes. (Or with function definitions written without prototypes, with the headers optionally turning on prototypes using a macro, like int func PROTO((char *)); where PROTO(X) just expands to () for a non-ANSI compiler.)
Words mean whatever the people using them use them to mean; they can evolve as their usage changes, etc.
Jargon terms are defined, once, in some journal paper or textbook or standards document; and then anyone who uses the jargon term thinking it means anything other than that original definition, is wrong. Jargon terms are prescriptivist by definition — that's the point of them, the thing that make them useful, the reason people invent them.
C89 is a jargon term. It it is an abbreviation of "ANSI X3.159-1989", the name of an immutable, public-accessible document written back in 1989.
---
That being said: although "C89" itself has an exact jargon meaning, these aren't well-defined jargon terms:
1. what it means for something to be a "C89-supporting compiler"
2. what it means when a piece of code says that it requires only a "C89-supporting compiler"
However, given a common-sense understanding of these concepts as they would be defined to be useful to a working programmer or OS distro library packager, I would expect the following interpretations of these concepts:
1. a "C89-supporting compiler" is a compiler that supports a superset of the C89 standard, such that it can at least compile code that conforms to the C89 standard, to object code that has semantics that conform to the C89 standard. Such a compiler MAY (in the RFC sense of "MAY") be able to compile other code as well — perhaps with effect defined in some other standard; or perhaps with effect defined by no standard at all.) This is an "at least" guarantee — a "C89-supporting compiler" supports at least C89.
2. code that states that it requires a "C89-supporting compiler" (with no other specified requirements), should be able to be compiled by a hypothetical compiler that supports exactly and only the features and translational semantics defined by C89 standard. You should be able to implement a new compiler from scratch, to the C89 spec, and then compile this code using it. The code should be portable to any arbitrary compiler that claims to implement C89. This is an "at most" guarantee — such code will invoke features such that it requires the compiler to at most have 100% adherence to the C89 standard.