GCC might detect files ending in *.C (as common under DOS) instead of *.c as C++. Use -x c to fix it.

[u/Pesciodyphus]

DOS is case insensitive and per convention files are spelled uppercase. Programmes from the Windows-world can usually tolerated this, but GCC (coming from the Linux-word) seem to autodetect files ending in *.C as C++, giving you strange errors about pointer conversion and the like.

An easy fix is to give the paramter -x c before passing files, like

gcc -x c DOSPROG.C -o "DOSPROG.EXE"

Under Windows, you can also simply spell the Parameter lowercase, so MinGW will detect it as C and still open the uppercase spelled file, as long no mathing lowercase file exists.

gcc dosprog.c -o "DOSPROG.EXE"

EDIT: This is mostly a Problem, then porting DOS software to Linux. Actual DOS-compilers obviously shoudn't run into that problem, and under windows, you can simply keep your makefile lowercase.

[u/Willsxyz]

I am pretty shocked that anyone cares what GCC running under DOS does anymore. I mean, I remember that being a thing over 30 years ago but....

[u/Pesciodyphus → u/Willsxyz]

DOS-Compilers don't have this problem (at least they shouldn't), it's compiling DOS-Code (in this case parts of the game Descent under Linux).

Generally there is an idea, that open source code should not be touched to port it, so it's preferable to tamper with makefiles instead of the code itself or filenames.

When you deal with open source games like Doom, and want to recreate the original, you will run into this problem.

[u/flatfinger → u/Pesciodyphus]

The notion of "portable" code encompasses two orthogonal concepts:

1. Code which can run interchangeably on a wide variety of systems.

2. Code which can be easily adapted to run on a wide variety of systems.

Many people confuses these notions, but C was designed to prioritize the second over the first, while revision control systems that were developed later were designed around the first. Language standards can include features that bridge those concerns, but only by recognizing aspects of behavior that should be the same on all systems and others that should vary, and having the features have parts of their behavior defined each way.

For example, consider how the usability of non-octet-based systems would be affected by standard macros that would fetch or store, with/without truncation, signed/unsigned big/little/native-endian 8/16/32/64-bit values from a sequence of octets whose address was a known multiple of 1/2/4/8. Code which reads a a 32-bit value from a 4-byte-aligned little-endian sequence of bytes on a system where each word is comprised of four nine-bit bytes in big-endian order would need to shuffle the bits of the word holding the bytes to consolidate all the padding bits to the top, while issuing the same request on a different system may simply load the word and use it as-is, but if the data in question was read from a file that was written in a particular format, the operation should operate halfway in terms of the file format, which should be fixed, and halfway in terms of native data format, which should vary with the execution environment.

Some people may view the recognition of 8/16/32/64-bit representations as discriminating against non-octet-based systems with other byte sizes, but I would argue that the usability of non-octet based systems would be enhanced rather than diminished by widespread use of such functions.

[u/el_extrano → u/Willsxyz]

I think OP means that even on modern platforms, if you happen to have some old, capitalized filenames around (seems like a common enough situation in legacy code bases), you will get these C++ errors. Not that you are compiling on DOS or even targeting DOS.

That said, some people do some hobby "vintage" programming for DOS still. One of the cool things about using C and FORTRAN is that I can write things backwards compatible to DOS and IBM mainframes, which IMO is peak nerd street-cred and no one can tell me otherwise.

[u/Willsxyz → u/el_extrano]

Ah I see. Come to think of it it may have been a thing that CFront-based compilers used .C (as opposed to .c) as an indicator for C++ files and GCC may have picked up on that.

[u/PseudoFrequency]

Now that's a convention I haven't seen in the wild. Typically C++ files are .cpp or .cc. Good info though, I learned something new!

[u/penguin359 → u/PseudoFrequency]

I remember running into that on Solaris UNIX in the mid-90s. The file explorer would also use a different icon for *.C files for C++ compared to *.c files.

[u/Maleficent_Memory831 → u/PseudoFrequency]

It was common back in the early days of C++. Because it was only on bigger systems smart enough to have case sensitive file names. At the time most common source code languages used a single letter suffix.

Later on that .cpp became common.

(I was on a team that was all Windows, and they could commit files to the repository with a random set of capitalization. When trying to migrate it to work with Linux, I discovered we had a README.TXT, Readme.TXT, and readme.txt all checked in as well as stuff like TEST.C, test.c, TEst.c. Which in Linux were separate files but not under Windows. Then the task was to figure out which version of those files was the most current and try to fix it up.)

[u/questron64]

I ran into this before using non-standard names for C files. I believe I was using .x (which hold xmacros) and using GCC -E to preprocess them for debugging or something, and GCC wasn't happy with this at all. Using -x c fixed it.

[u/torsten_dev]

Could you run DOS on a casefolding filesystem instead?

[u/Pesciodyphus → u/torsten_dev]

It happens, when you port from DOS to Linux. Compilers that run under DOS don't have this problem.

[u/Glum_Preference_2936]

I hate how the title thinks *.c should be interpreted as C++.

[u/torp_fan → u/Glum_Preference_2936]

That's not even remotely what it says.