4 ms·

"Pure" doesn't apply to "language purity" (nobody besides a very few seem to really care about the latter, especially not in C, not even compiler authors), but

by Rochus 3y ago

"Pure" doesn't apply to "language purity" (nobody besides a very few seem to really care about the latter, especially not in C, not even compiler authors), but that nothing else is required than a C89 compatible toolchain to use the library (i.e. it doesn't need any assembler or third-party tools/libraries). See also https://www.merriam-webster.com/dictionary/pure?utm_campaign=sd&utm_medium=serp&utm_source=jsonld https://www.merriam-webster.com/dictionary/pure?utm_campaign.... And so far the library compiles with all of my C89 copilers, even the very old ones (and old Posix versions). For a few cases to check, there are notes in the source code.

deleted 3y ago
[deleted]
kazinator 3y ago
> nothing else is required than a C89 compatible toolchain Fair enough. A "pure C89" program should be expected to work in Turbo C on MS-DOS.
- Rochus 3y ago
  No C89 compatible toolchain does "pure C89" without extra options (if at all); people would run away. Even if you use GCC or CLANG with the -std=c89 option it doesn't. So the complaints that the presented library is not "pure C89" is nothing but an academic quibble. EDIT: I now have changed the repository description to "A pure C (-std=c89) implementation of Go channels, including blocking and non-blocking selects.", so hopefully this idiotic discussion will come to an end.
  - kazinator 3y ago
    There are C89 toolchains that will not translate and execute the code, no matter what options they are given to control the language dialect, or anything else. > 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.
    - Rochus 3y ago
      Again: I now have changed the repository description to "A pure C (-std=c89) implementation of Go channels, including blocking and non-blocking selects.", so hopefully this idiotic discussion will come to an end. 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.
      - kazinator 3y ago
        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.)

by Rochus 3y ago

deleted 3y ago

[deleted]

kazinator 3y ago

> nothing else is required than a C89 compatible toolchain Fair enough. A "pure C89" program should be expected to work in Turbo C on MS-DOS.

Rochus 3y ago
No C89 compatible toolchain does "pure C89" without extra options (if at all); people would run away. Even if you use GCC or CLANG with the -std=c89 option it doesn't. So the complaints that the presented library is not "pure C89" is nothing but an academic quibble. EDIT: I now have changed the repository description to "A pure C (-std=c89) implementation of Go channels, including blocking and non-blocking selects.", so hopefully this idiotic discussion will come to an end.
- kazinator 3y ago
  There are C89 toolchains that will not translate and execute the code, no matter what options they are given to control the language dialect, or anything else. > 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.
  - Rochus 3y ago
    Again: I now have changed the repository description to "A pure C (-std=c89) implementation of Go channels, including blocking and non-blocking selects.", so hopefully this idiotic discussion will come to an end. 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.
    - kazinator 3y ago
      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.)