On Tuesday, 12 February 2019 at 20:03:09 UTC, Jonathan M Davis
wrote:
So, I'd say that it's safe to say that dmd
The whole thing just seems like a weird requirement that really
shouldn't be there,
Like I said in the first reply, FWIW, it's a POSIX requirement.
Turns out most tools don't care (and dmd is apparently one of
them). If you want an easy counterexample, try the wc command
(it miscounts lines for non-compliant files). I've never seen
that break an actual build system, which is why I said you could
mostly get away with it. On the other hand, being
POSIX-compliant always works.
it matters even less if text editors are automatically
appending newlines to files if they aren't there whether they
show them or not, since if that's the case, you'd have to
really work at it to have files not ending with newlines anyway.
There are definitely broken text editors out there that won't add
the newline (can't think of names). Like Jacob Carlborg said,
Github flags the files they generate.
hexdump shows a newline followed by a null character followed
by a newline after the carriage return.
hexdump is printing little-endian 16b by default, so I think
that's just two newlines followed by a padding byte from hexdump.
Try using the -c or -b flag and you probably won't see any null
byte.
Curiously, if I create a .cpp or .c file with vim and have it
end with a curly brace, vim _does_ append a newline followed by
a null character followed by a newline at the end of the file.
So, I guess that vim looks at the extension and realizes that
C/C++ has such a requirement and takes care of it for you, but
it does not think that .d files need them and adds nothing
extra for them. It doesn't add anything for a .txt file when I
tried it either.
Are you sure? vim is supposed to add the newline for all text
files because that's POSIX. It does on my (GNU/Linux) machine.
