Comment by kazinator | Hacker News Reader

Comment by kazinator | Hacker News Reader

Parent Full thread

I was being helpful by pointing out that the code might not reflect the author's intent.

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.)

Man, you didn't do a s**t. Just spending five minutes with the code reveals that it is compiled with -std=c89 and strict adherence to a standard is neither a promise nor a goal of the author. "C89" is not a protected term and is not uniformly understood or used in any way. So don't be so picky.

There isn't a nanometer of wiggle room in what C89 refers to.

Ha ha, dream on, my friend ...

There is a difference between words and jargon terms.

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.

Reply on news.ycombinator.com