LF is automatically converted to CRLF

[ekfacile]

Describe the bug

When LF (\n) is output to standard output, it is somehow converted to CRLF (\r\n) and output.

The print command outputs exactly what is written, so the command and the actual behavior are inconsistent.

If you specify LF in the print command, it must output LF as is.

Reproduction Steps

Save the below code as main.v.

print('\n')

Run it from the command prompt.

v run main.v > test.txt

If you open test.txt in a binary editor, you will see the following data:

0D 0A

As you can see from the table below, LF is always converted to CRLF.

Original code	Ourput code
\r	\r
\n	\r\n
\r\n	\r\r\n

Expected Behavior

It is desirable that LF is output as is.

0A

Current Behavior

LF is automatic converted to CRLF.

0D 0A

Possible Solution

LF is output as LF.

You don't need to consider platform differences.

Additional Information/Context

I am using v.exe built with GCC on MSYS2 + MinGW (UCRT64) on the Windows command prompt.

V version

0.4.12 92eb6cf

Environment details (OS name and version, etc.)

V full version	V 0.4.12 b0198f2.92eb6cf
OS	windows, Microsoft Windows 11 Pro 26200 64 ビット
Processor	12 cpus, 64bit, little endian, AMD Ryzen 5 3600 6-Core Processor
Memory	11.71GB/15.92GB
V executable	W:\Datas\Projects\msys2\v\v.exe
V last modified time	2025-10-31 23:59:51
V home dir	OK, value: W:\Datas\Projects\msys2\v
VMODULES	OK, value: C:\Users\UserName.vmodules
VTMP	OK, value: Y:\msys64\tmp\v_0
Current working dir	OK, value: Y:\msys64\home\UserName
env CFLAGS	"-O3 -march=znver2 -pipe"
Git version	git version 2.51.2
V git status	92eb6cf-dirty
.git/config present	true
cc version	cc (Rev8, Built by MSYS2 project) 15.2.0
gcc version	gcc (Rev8, Built by MSYS2 project) 15.2.0
clang version	N/A
msvc version	N/A
tcc version	tcc version 0.9.27 (x86_64 Windows)
tcc git status	thirdparty-windows-amd64 b425ac82
emcc version	N/A
glibc version	ldd (cygwin) 3.6.5

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[JalonSolov]

This is not a bug. V, as most other computer languages, declares \n as end of line for the current OS. Same as C, C++, Go, Python, or any other language.

From https://en.wikipedia.org/wiki/Newline :

When writing to a file, device node, or socket/fifo in text mode, \n is transparently
translated to the native newline sequence used by the system, which may be longer than
one character. When reading in text mode, the native newline sequence is translated
back to \n. In binary mode, no translation is performed, and the internal representation
produced by \n is output directly.

[ekfacile]

No.

Below is a C# example.

Create a new C# project.

md test
cd test
dotnet new console

Rewrite Program.cs as follows:

Console.Write("dog\ncat")

Run the program source and redirect it to a text file.

dotnet run > test.txt

C# is output without conversion as it is with LF.

However, if you redirect to a text file using print('dog\ncat') in V, it will be automatically converted to CRLF.

Needless to say, C# is a multi‐platform programming language.

[JalonSolov]

V is also multi-platform. V's default backend is C, not C#, so you get the C behavior with V.

[ekfacile]

The fact that V's backend is C is unrelated to whether V follows the conventions of C.

Why did V change the switch statement to a match statement? Wasn't it to make it more convenient and safer to use, right? If changing the switch statement to a match statement is good, what's wrong with standardizing newline character handling across all platforms?

In modern programming languages, bridging the gaps between different platforms is extremely important.

Writing complicated code like the following has only disadvantages and absolutely no advantages.

#include <stdio.h>
#include <io.h>
#include <fcntl.h>

int main(void)
{
	_setmode(_fileno(stdout), _O_BINARY);

	printf("dog\ncat");
	return 0;
}

[JalonSolov]

I agree with the sentiment, but it would be a "breaking change" to modify this in V now, as everything written in V so far expects \n to "do the right thing" regardless of which platform you compile the code on or for.

Every message would have to change to be a conditional based on the OS as to whether it added \n or \r\n just so things would print properly to the console.

[medvednikov]

if you are porting code from V and want Go to mimic the V behavior, you would need to manually write \r\n in Go. Go will not do that conversion for you.

We have to do it like Go. It's a valid bug report.