On Wednesday, 13 February 2019 at 05:13:12 UTC, sarn wrote:
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.
A lots of fgets() based tools on Unix systems fail to read the
last line if it doesn't contain a line feed character at the end.
Afaicr glibc implementation does not have that problem but a lot
of other standard C libs do.
When we were still on Solaris we had to be very careful with
that, as strange things could happen when using sed, awk, wc and
a lot of other standard Unix commands.
Now that we have switched to Linux we don't have the issue
anymore.
