what? the question had nothing to do with varargs; the poster quite rightly noted that at some point in the implementation of printf, when you needed to send an actual character to an actual output device, you would need something conceptually lower-level than C. they were just confused about the specifics of interfacing between C and the machine; i think one of the comment-level answers put its finger on the nub:

> Visual Studio x64 doesn't support inline assembler. That doesn't mean you can't have assembler code. You can still have assembler, just not inline.

and in the answer section

> The system calls are (on platforms that I know of) internally implemented by a call to a function with inline asm that puts a system call number and parameters in CPU registers and triggers an interrupt that the kernel then processes.

I have a hard time seeing this as a magical part even in the eyes of a newbie. How common is it to hear about stdio but not also know about write()? I am pretty sure one man page refers to another. My point, just as it is with varargs, is you should be curious enough to find these answers yourself, run some experiments, make some good guesses.

Since Visual Studio is mentioned, I'll say that despite some extra layers (CRT, kernel32, ntdll) the concepts are identical and when I was a kid learning C I was able to dig through header files and documentation to conceptually figure it out.

it's not a question of anything being magical; the op just got confused by the difference between writing inline assembly in a c program and calling from c code into compiled and linked in assembly code.

I'll say, somebody is a little confused.

I still say, they don't understand varargs, don't understand the difference between stdio and write(), and most importantly, they are not curious enough to read documentation and make smart guesses. And I am saying, the bullshit obfuscation involved in this article, sharing so many meaningless implementation details about a very specific libc, will not help answer this question or gain insight more than RTFMing and being curious about the world would.

So... If you are even asking questions like... "Does printf use assembly?" I'd argue you are not thinking it through. You need to get yourself to a place where you can answer that yourself. It will be a very obvious answer when you do. Writing frivolous blog posts is not the way to get there.

Just noting that the article is not the source of the bullshit obfuscation, nor does it condone it. I'm part of the Red project.

http://www.red-lang.org/p/contributions.html

We're trying to undo this stuff. I was just answering a question.

The article struck me as such because the important point is not how glibc layers things, it's the conceptual detail that stdio buffers first and then flushes with write(). [You happened to pick a really bad libc to pick apart because a much simpler implementation is possible.] If someone saw your post having no idea they would have to parse it out of what you are saying, and probably get lost, because you did not say it plainly.

red looks awesome, and has come a lot further than I expected! (i peeked at it a few years ago and there didn't seem to be much). I love that small executable sizes are an explicit design goal.

The next release will be able to directly build and sign .APK files, with no JDK or JarSigner required to be installed. Still under 1MB for that same compiler executable on all platforms...that can also build PE (Windows), Mach-O (OS/X), and ELF (Linux etc.)

It's moving slower than we'd like, but definitely moving.