Fix build with gcc15

[wishstudio]

Compile error in gcc15:

fileops.c: In function 'ftemp':
fileops.c:71:15: error: conflicting types for 'fdopen'; have 'FILE *(void)'
   71 |         FILE* fdopen();                         /* in case -ansi is used */
      |               ^~~~~~
In file included from fileops.c:2:
/nix/store/fbbw928argckfii0j322346ihmllg7a7-glibc-2.42-61-dev/include/stdio.h:302:14: note: previous declaration of 'fdopen' with type 'FILE *(int,  const char *)'
  302 | extern FILE *fdopen (int __fd, const char *__modes) __THROW
      |              ^~~~~~
fileops.c:72:16: error: too many arguments to function 'fdopen'; expected 0, have 2
   72 |         if(f = fdopen(fd, mode)) return f;
      |                ^~~~~~ ~~
fileops.c:71:15: note: declared here
   71 |         FILE* fdopen();                         /* in case -ansi is used */
      |               ^~~~~~

The fdopen function should be in stdio.h header which is already included in the file. So I just removed the problematic definition.

[squell]

Thanks for opening a PR! These decls were, I recall distinctly, added to prevent a problem when (on some platforms) “-ansi” was used (or “-std=c90”) which would shut out these declarations (since they are in SUS/POSIX but not strictly in the C standard), and then the C compiler would use the implicit declaration int fdopen(). Which is a disaster if ints are 32bits and pointers 64bits.

I don’t think this happend on Linux, but it is something that worries me to this day (and which prompts me to tell people not to use “-std=cXX” but rather “-std=gnuXX”, but I digress)

In lieu of using a proper configure script, instead of removing, I’d propose changing the forward decls to match exactly what POSIX says they should be (the error probably occurs because more modern C standards don’t like these oldstyle decls), and perhaps wrapping them in an ifndef which detects whether POSIX “extensions” to C are enabled.

[wishstudio]

Thanks for opening a PR! These decls were, I recall distinctly, added to prevent a problem when (on some platforms) “-ansi” was used (or “-std=c90”) which would shut out these declarations (since they are in SUS/POSIX but not strictly in the C standard), and then the C compiler would use the implicit declaration int fdopen(). Which is a disaster if ints are 32bits and pointers 64bits.

I don’t think this happend on Linux, but it is something that worries me to this day (and which prompts me to tell people not to use “-std=cXX” but rather “-std=gnuXX”, but I digress)

In lieu of using a proper configure script, instead of removing, I’d propose changing the forward decls to match exactly what POSIX says they should be (the error probably occurs because more modern C standards don’t like these oldstyle decls), and perhaps wrapping them in an ifndef which detects whether POSIX “extensions” to C are enabled.

Makes sense! PR updated.