@socjuswiz@spinster.xyz @georgia@netzsphaere.xyz @meowski@fluf.club @pasture@pl.gamers.exposed @pernia@freespeechextremist.com @user@freespeechextremist.com > The produced executable does not behave differently when run. I gave two examples of it behaving differently, I can give more. > looks into implementation details. Have you never used a different libc? > A process in a UNIX environment should be seen as a blackbox with the following inputs and outputs: This is not a rule for a Unix environment. This is also a pants-on-head stupid non sequitur. A C compiler is not a Unix environment. C runs in several places that are not Unix environments. gcc is used in many of those places. "Unix" is not an acronym. (According to BWK, the small-caps style was due to excitement over adding small-caps to the typesetter.) If including an example of something as wild as "using the debugger and expecting that the program will do what you wrote" makes the example "wonky", I don't know how to help you. (Apparently v7's adb had breakpoints. But nobody was around to standardize the OS back then so I suppose Unix didn't exist until some time in the late 80s. One wonders how they got anything done!) gcc is a program inside this environment, I have executed it, and when I did, gcc has read some files and has written some files and I did not like its output. The output is not special simply because it's not text and the compiler is not special simply because it's a compiler: it's reading and writing and it has performed a bad transformation at one point. > The functions in the C and POSIX standards aid in ultimately producing this blackbox. This is the absolute worst way of viewing a standard. You have joined some sort of cargo cult: "Don't rely on implementation details remaining constant" is a very different thing from "Your environment is a black box." What you have described is not what a standard is for, it is not what this standard is for, and it is Even with your idiosyncratic rules, this is not the goal of a standard, and the standard is a guideline for implementors, and I am using a C compiler, not writing a POSIX-compliant system. POSIX is not the only OS standard, it is not the only Unix standard, it is not the C standard—of which there are also many–a standard is not the word of God, and POSIX is garbage anyway. *Should* the C compiler do this? I don't know, apparently unless I join a standards body, I'm not allowed to ask that question! "Not all that is lawful is honest" is a better way to approach this. "Is it the right thing to do?" is a very different question from "Is it legal?" If it's stupid behavior and the standard allows it, then the standard is not relevant for discussion of the behavior. If it's stupid behavior and the standard *requires* it, then the standard is stupid. In either case, "It's allowed to do this" is not a relevant point. Try, even once, writing a performant compiler or bytecode interpreter, or writing embedded software. Which functions the thing calls matters. It matters whether or not it translates to the same number of syscalls. Even if you're in a completely normal-looking Unix system, syscall overhead matters in any case where performance matters. If you are making anything, anything at all, that thing's dependencies are going to matter if you want it to actually work. If you write C, you will, sooner or later, have to stop pretending that you don't know how the stack works, or how paging works, or how syscalls work, or how your system lays out its memory, or how it works on other systems on which you expect your code to run, or endianness, or any of that. Go do whatever you people do: write another clone of grep in Rust, write an impassioned blog post defending Haskell's excessive memory usage, opine on Hacker News about how nobody but you really *gets* Dijkstra, or something. Adults are talking in this thread.