2

What is the reason to use a const char* for selecting the open mode instead of an enum like this:

enum open_mode {
        READ,
        READ_BINARY,
        WRITE,
        ...
};

It wouldn't be more simply to use an enum?

  • 3
    That might have been a design decision. You could may try to ask this in Programmer network also; you might have more luck there. – Ely Jul 15 '15 at 15:03
  • Holdover from early C which I think lacked enums. – Isaiah Jul 15 '15 at 15:04
  • 1
    A very similar question: https://stackoverflow.com/questions/18999459/c-fopen-mode-parameter – cremno Jul 15 '15 at 16:01
  • Another one (answers are mainly speculations): https://stackoverflow.com/questions/2519263/why-does-cs-fopen-take-a-const-char-as-its-second-argument – cremno Jul 15 '15 at 17:40
  • Does this answer your question? [Why does C's "fopen" take a "const char \*" as its second argument?](https://stackoverflow.com/questions/2519263/why-does-cs-fopen-take-a-const-char-as-its-second-argument) – kevinarpe Mar 08 '22 at 15:22

2 Answers2

4

This is to provide freedom for implementations. For instance the implementation in VC++ has the possibility to select encoding and such: fopen("test.xml", "wt+,ccs=UNICODE")

dalle
  • 18,057
  • 5
  • 57
  • 81
  • I think that this is the correct answer. Because before there were `enum`s, people usually used `int`s and `#define`d macro constants for the same purpose rather than using character strings. – 5gon12eder Jul 15 '15 at 15:07
  • 1
    Sure, but an implementation could add more elements to an `enum` type. – Keith Thompson Jul 15 '15 at 15:34
  • @KeithThompson: That wouldn't work (without introducing weird varargs) for variable stream attributes: `"wb,reclen=80"` (an example from the C rationale). – cremno Jul 15 '15 at 15:57
  • 1
    @cremno: True, but the original author(s) of `fopen` might not have been concerned with that. In any case, [dasblinkenlight's answer](http://stackoverflow.com/a/31434115/827263) is correct; `fopen` predates `enum`. – Keith Thompson Jul 15 '15 at 17:27
  • @KeithThompson: I agree that it answers _this_ question. However I've found [yet another question](https://stackoverflow.com/questions/2519263/why-does-cs-fopen-take-a-const-char-as-its-second-argument). It's more broad. A definitive answer is missing though. – cremno Jul 15 '15 at 17:54
4

The reason is most likely historical: function fopen has been around in the early K&R version of the language, while enum has been added to the language only for the ANSI standard.

By the time enums were added the language has been in such widespread use that changing the signature of such important function was impractical.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • Hmm, I thought K&R1 had enums. (My copy is at the office, and I'll check it later today; I'm adding this comment mostly as a reminder to myself.) – Keith Thompson Jul 15 '15 at 15:07
  • @KeithThompson Are you one of the lucky owners of the first edition of K&R? I've got only the second edition (I learned the language from a home-made Russian translation of the first edition, though). Wikipedia says that "In the years following the publication of K&R C, several features were added to the language, supported by compilers from AT&T (in particular PCC[19]) and some other vendors. These included: ... enumerated types" ([link](https://en.wikipedia.org/wiki/C_(programming_language)#K.26R_C)). – Sergey Kalinichenko Jul 15 '15 at 15:11
  • Yes, I first learned C from K&R1. I'll also check whether it mentions `fopen` (I know it has ``). If it has `fopen` and not `enum`, you'll be able to remove the "most likely" from your answer. – Keith Thompson Jul 15 '15 at 15:33
  • 3
    K&R1 does *not* have `enum`. It does mention `fopen()`, and shows a sample implementation. (The implementation only checks the value of `*mode`, and permits `'r'`, `'w'`, or `'a'`, so there's no allowance for binary mode or for more than one character.) – Keith Thompson Jul 15 '15 at 17:26