remove use of printf format %z[d|u] from dmd source

[WalterBright]

@LightBender Adam Wilson writes on the n.g.:

I recently got hit by a rather esoteric bug that looked like a real bug, but was actually not a bug, but also kind of a bug. Specifically, on Windows the printf %zd format would fail with a Segfault. The simple fix was to delete %zd and use %d with a cast to a fixed size int type. But it was the wrong fix.

I fixed it anyway.

[Herringway]

printf sure seems to demand a lot of work from us.

[WalterBright]

I made a proposal to have chkformat() automatically replace %s in the format string with the correct format for the argument type, so it would behave much like writef().

Then you could do things like:

printf("I have %s %s\n", 6, "apples");

But nobody was in favor of it.

[Herringway]

I made a proposal to have chkformat() automatically replace %s in the format string with the correct format for the argument type, so it would behave much like writef().

Then you could do things like:

printf("I have %s %s\n", 6, "apples");

But nobody was in favor of it.

There is a much simpler solution to have printf behave like writef...

alias printf = writef;

[WalterBright]

Some reasons why I use printf:

1. printf is very lightweight. Do an obj2asm of a simple function with a writef in it, vs a printf.
2. betterC doesn't rely on Phobos
3. some tools, like the compiler, cannot rely on Phobos

[Herringway]

Some reasons why I use printf:

1. printf is very lightweight. Do an obj2asm of a simple function with a writef in it, vs a printf.

2. betterC doesn't rely on Phobos

3. some tools, like the compiler, cannot rely on Phobos

1. Why on earth would I use obj2asm? Every task I have encountered that involves me looking at assembly is better done with other tools, modern and otherwise, and they've proven more than capable of handling writef and the bare metal clones of it I've written in the past.
2. Put writef in druntime and you can continue pretending that not using phobos in the compiler is useful instead of arbitrary.
3. ditto.

Improve your tooling instead of imposing its limitations on everyone else.

[WalterBright]

1. to develop the compiler, I need to be able to see its output.
2. the less output, the easier it is to find the problem. Phobos with all its interdependencies (every module imports every other module) is very very difficult to track down code gen problems with it. Druntime is a lot easier to cope with. I don't need to debug printf implementations.
3. nobody is imposing printf or improvements to printf on anybody

[dkorpel]

Are these meant to be committed?

[WalterBright]

Yes. But I don't know why .gitignore is part of the repository. Is there another name for it so I can have a local .gitignore?

[Herringway]

1. to develop the compiler, I need to be able to see its output.

   2. the less output, the easier it is to find the problem. Phobos with all its interdependencies (every module imports every other module) is very very difficult to track down code gen problems with it. Druntime is a lot easier to cope with. I don't need to debug printf implementations.

   3. nobody is imposing printf or improvements to printf on anybody

You aren't the only one who needs to see compiler output. I often have to debug my drt0 functions and interrupt handlers. A simple invocation of objdump+awk is all I need to focus on that. With LDC's propensity for silently giving up instead of failing on assembly errors, I do this A LOT. Even when calls to my writef clone are involved, they don't get in my way at all, because all those symbols have been filtered out! objdump even supports that filtering natively, though it doesn't handle demangling, so awk is just used for convenience. You control the tools, not the other way around.

I can even combine that with diff --side-by-side to get a nice comparison between two different compilations of the same function, or to compare a new implementation of some low level nonsense I need to deal with within the same binary.

I've even written multiple disassemblers of my own to deal with the REALLY esoteric stuff. I even had a web-based disassembler long ago for a collaborative reverse-engineering effort. You never need to suffer with insufficient tooling.

I've had fewer problems with phobos's interdependencies on bare metal than I've had with druntime's. Until I decided to stop using druntime entirely, every time druntime got updated, some random part of it seemed to gain a new dependency on core.stdc.time that ended up breaking everything for me. At least the majority of phobos's dependencies exist! You get to avoid most of the effects of this because the majority of that work has already been done by GCC and LDC.

You might not have had to debug printf implementations, but it seems someone had to for this PR!

If you're not imposing the requirement to use printf on the compiler, then who is?

[WalterBright]

If printf doesn't fit your requirements, just don't use it! The choice is yours.

As for the 'z' problem with MSVC libraries, I actually knew about it, but I thought it was ancient history.

[WalterBright]

P.S. I dread having compiler bugs with Phobos. It's always a long slog trying to narrow it down because the absolutely massive object files it generates. This is why I put Phobos as the last step in developing the compiler.

[LightBender]

We fixed the problem by upgrading to UCRT, which we really needed to do anyways for a host of other reasons, but this does unblock older libc's like msvcr120, so that is useful.