After a recent Emacs update, the clang-format package started to misbehave under Windows. For instance, calling clang-format-buffer on a test.cpp file with the following content returns error:

"(clang-format failed with code 1: error: invalid length 34, offset + length (34) is outside the file.)"

  int a = 2;
  int b = 1;

It seems that the length passed to clang-format is right, because putting Point at the end of the buffer and calling (bufferpos-to-filepos (point)) returns 34. The file uses DOS-style file endings. But the error seems to be that call-process-region passes \n line endings to clang-format instead of \r\n.

The documentation of clang-process-region states:

The input sent to a subprocess by call-process-region is encoded using a coding system, much like text written into a file.

buffer-file-coding-system in the buffer is undecided-dos. Is it normal then that call-process-region passes \n instead or \r\n to clang-format?

The clang-format package I tried is installed from melpa.org, version 20161004.253.

1 Answer 1


The issue comes from the fact Emacs using undecided-unix by default for sending data to a subprocess. Calling describe-coding-system (Ctrl + h, C) shows all the different encodings used for a given buffer.

This issue is fixed by calling (setq default-process-coding-system '(undecided-dos . undecided-dos))

I've filed a bug report on llvm.org's bug tracker to see if this can be solved in clang-format.el directly. https://llvm.org/bugs/show_bug.cgi?id=31092

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.