4 ms·
> C has no environment which smooths out platform or OS differences Not true - C has little environment, not no environment. For example, fopen("/path/file.txt
by nayuki 4y ago
> C has no environment which smooths out platform or OS differences
Not true - C has little environment, not no environment. For example, fopen("/path/file.txt", "r") is the same on Linux and Windows. For example, uint32_t is guaranteed to be 32 bits wide, unlike plain int.
> Each source file is compiled to a .o object file
Is this a convention that compilers follow, or are intermediate object files required by the C standard? Does the standard say much at all about intermediate and final binary code?
> static
This keyword is funny because in a global scope, it reduces the scope of the variable. But in a function scope, it increases the scope of the variable.
> Integers are very cursed in C. Writing correct code takes some care
Yes they very much are. https://www.nayuki.io/page/summary-of-c-cpp-integer-rules https://www.nayuki.io/page/summary-of-c-cpp-integer-rules
- LegionMammal978 4y ago> Is this a convention that compilers follow, or are intermediate object files required by the C standard? Does the standard say much at all about intermediate and final binary code? The standard only says that the implementation must preprocess, translate, and link the several "preprocessing translation units" to create the final program. It doesn't say anything about how the translation units are stored on the system. > This keyword is funny because in a global scope, it reduces the scope of the variable. But in a function scope, it increases the scope of the variable. Not quite: in a global scope, it gives the variable internal linkage, so that other translation units can use the same name to refer to their own variables. In a block scope, it gives the variable static storage duration, but it doesn't give it any linkage. In particular, it doesn't let the program refer to the variable outside its block.
- trap_goes_hot 4y agoOn Windows you can directly access UNC paths (without mounting) with fopen. You can't do this on POSIX platforms. Also, not all API boundaries are fixed width so you're going to be exposed to the ugliness of variable width types. I think the article is correct that one must be aware of the platform and the OS when writing C code.
- manv1 4y agofopen will/should fail on windows with the unix path syntax. The reason it's indeterminate is because some stdc lib vendors will do path translation on Windows, some won't. I believe cygwin does (because it's by definition a unix-on-windows), but I'm pretty sure the normal stdclib vendors on windows do not. I'm almost positive that MacOS (before MacOS X) will fail with unix path separators, since path separators are ':' not '/'.
- spc476 4y agoIt will work on Windows, since it inherits the behavior from MS-DOS. It's the shell on Windows (or MS-DOS) where it fails since the shell uses '/' to designate options, so when MS-DOS gained subdirectories (2.0) it used '\' as the file separator on the shell. The "kernel" will accept both. There even used to be an undefined (or underdefined) function in MS-DOS to switch the option character.
- manv1 4y agoApparently it's true. I wonder when this was implemented? Canonicalize separators "All forward slashes (/) are converted into the standard Windows separator, the back slash (\). If they are present, a series of slashes that follow the first two slashes are collapsed into a single slash." https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats https://learn.microsoft.com/en-us/dotnet/standard/io/file-pa...
- spc476 4y agoSince MS-DOS 2.0, released in October of 1983---39 years ago.