Notes for Problem Setters (Updated 2026/05/10)

This is the specification for how verification code for special judge and reactive problems is executed.

    実行コマンド (問題の入力ファイルパス) (問題の出力ファイルパス) (提出されたソースコードのパス) (スコアファイルのパス)

    (標準入力に提出コードでの標準出力が渡される)

Here is an example of the execution command.

    ./a.out test_in/1.txt ans/1.txt main.ws score/1.txt < out/1.txt

Examples of verification code implementations

One thing to watch out for in verification code is that, depending on the language, the standard output of the submitted code may contain CR (newline code: carriage return), so please handle it as far as possible.
In particular, C++'s std::getline does not interpret CR in the judge environment.
Reference: Notes on std::getline
If there is anything else that similarly does not take CR into account, please let us know.

The code is executed in the format above. That is, there are at least 4 arguments (this number may increase in the future).
If the verification code ends with a runtime error (an Exit Code other than 0, for example termination by assert), the result is WA.
If the verification code exceeds the time limit, the result is J_TLE, but please avoid this as far as possible.
For reactive judges, if the verification code has a runtime error and the user code has TLE, the result is WA.
If the program terminates with Exit Code 100, the result is QLE. (Added 2019/11/14, tentative)

Other verdicts such as RE and TLE are determined by the usual checker.

For both special judge and reactive problems, please provide test output files. An empty file (a 0-byte file) is sufficient, but it may be a good idea to provide one example of a solution.
For reactive problems, place the input (for the verification code) in the problem's "test input file".
You may freely write to standard error in the verification code.

About Reactive Problems

In reactive problems, the judge code and the solution process communicate bidirectionally and live through standard input and output. The meanings of FD0/FD1 are the same as for the special judge (the solution's stdout goes to FD0, and FD1 goes to the solution's stdin), but the difference is that they are connected by real-time pipes rather than through batch processing via files.

• FD0 (stdin): connected to the stdout of the solution process (the judge reads what the solution outputs)
• FD1 (stdout): connected to the stdin of the solution process (the judge sends input to the solution process)
• FD2 (stderr): free to use (for logging, etc.)

The contents of the test input file are not sent to standard input (the same applies to the special judge; FD0 is occupied by the output of the solution process). If needed, open and read the input file path passed as a command line argument (argv[1]).
Never forget to call flush() after writing (buffering can cause deadlocks).

Pure code judging is not performed for reactive problems.

About Communication Problems

Communication problems are a type of reactive format in which the same program runs as 2 processes.
The judge code (verification code) mediates the input and output of each process through pipes and controls the communication between the processes.

Pipe Configuration

The standard input and output (FD0 to FD2) of the judge process are handled differently in the 3 formats, as follows.

FD	Special judge (file)	Reactive (real-time)	Communication
FD0 (stdin)	Output file of the solution process	stdout of the solution process	stdout of process 1
FD1 (stdout)	Judge output (free)	stdin of the solution process	stdin of process 1
FD2 (stderr)	Free	Free	Free
FD3	―	―	stdout of process 2 (read by the judge)
FD4	―	―	stdin of process 2 (written by the judge)

The special judge is a file-based execution in which, after the solution process has finished, its output file is passed to FD0. Reactive is a real-time interactive format in which the judge and the solution process run simultaneously, with FD0/FD1 directly connected by pipes. Communication is an extension of reactive, in which the judge communicates with process 1 via FD0/FD1 (the same as reactive) and with process 2 via FD3/FD4. In all formats, the test input is read from argv[1].

In communication problems, the following file descriptors (FDs) are assigned to the judge process.

    プロセス1 FD1 (stdout) ──→ FD0 (ジャッジが読み取る)
    プロセス1 FD0 (stdin)  ←── FD1 (ジャッジが書き込む)
    プロセス2 FD1 (stdout) ──→ FD3 (ジャッジが読み取る)
    プロセス2 FD0 (stdin)  ←── FD4 (ジャッジが書き込む)

From the user process's point of view, these are the usual FD0/FD1 (stdin/stdout). The judge communicates with process 1 via standard input and output (FD0/FD1) and with process 2 via FD3/FD4.

FD	Direction	Connected to	Purpose
FD0 (stdin)	Read	stdout of process 1	The judge reads data output by process 1
FD1 (stdout)	Write	stdin of process 1	The judge sends data to process 1
FD3	Read	stdout of process 2	The judge reads data output by process 2
FD4	Write	stdin of process 2	The judge sends data to process 2

The judge code communicates with the 2 user processes via FD0/FD1 (process 1) and FD3/FD4 (process 2).
The argument format is the same as for reactive problems. If you need the test input file, open and read argv[1].

User processes read from standard input (stdin) and write to standard output (stdout) as usual.
Only the judge code needs to be aware of the FD numbers.

Example Implementation of Judge Code (Python)

Process 1 uses standard input and output (FD0/FD1), and process 2 uses FD3/FD4. Process 1 can be written either with sys.stdin/sys.stdout or with os.fdopen(), which specifies the FD number explicitly.

Style 1: Using sys.stdin / sys.stdout (the same style as reactive)

import os, sys

# プロセス1: 標準入出力で通信
user1_read  = sys.stdin              # プロセス1の出力を読む
user1_write = sys.stdout             # プロセス1に入力を送る

# プロセス2: FD3/FD4で通信
user2_read  = os.fdopen(3, 'r')      # プロセス2の出力を読む
user2_write = os.fdopen(4, 'w')      # プロセス2に入力を送る

# テスト入力は argv[1] から
with open(sys.argv[1]) as f:
    test_input = f.read()

user1_write.write("1 ...\n")
user1_write.flush()
user2_write.write("2 ...\n")
user2_write.flush()

Style 2: Using os.fdopen() for everything (the same style as process 2)

import os, sys

# プロセス1・プロセス2 を同じスタイルで開く
user1_read  = os.fdopen(0, 'r')      # FD0: プロセス1の出力
user1_write = os.fdopen(1, 'w')      # FD1: プロセス1への入力
user2_read  = os.fdopen(3, 'r')      # FD3: プロセス2の出力
user2_write = os.fdopen(4, 'w')      # FD4: プロセス2への入力

with open(sys.argv[1]) as f:
    test_input = f.read()

user1_write.write("1 ...\n")
user1_write.flush()
user2_write.write("2 ...\n")
user2_write.flush()

Both behave the same. sys.stdin internally refers to FD0, so Style 1 and Style 2 are equivalent. Choose Style 2 if you want to emphasize the symmetry between process 1 and process 2, or Style 1 if you value consistency with reactive problems.

When implementing judge code for communication problems, please note the following points.

• Communicate with process 1 via standard input and output (FD0/FD1) and with process 2 via FD3/FD4
• Read the test input from argv[1] (stdin is used for process 1)
• Always call flush() after writing
• If one process produces invalid output, take care that the other process does not deadlock
• Memory usage is judged by the maximum of the 2 user processes
• If either user process terminates abnormally, its exit code is used

Pure code judging is not performed for communication problems.

About Scores (Beta)

If you select "Score Problem" as the problem type on the problem edit page, a "By Score" tab appears at the top of the problem page.
The "By Score" tab shows, among submissions that are AC, each user's highest-scoring submission (with the smaller submission ID).
For score problems, a submission restriction is provisionally in place: you cannot submit within 5 minutes of your last submission (other than CE) to the same problem.

In this case, the value output to the score file is taken as the score, and the scores are totaled over all test cases.
Please output a signed 64-bit integer value to the score file. (A trailing newline is also allowed.)
(Take care that the total does not overflow either.)

64-bit integer values can be used, but many digits are hard to read, so around 9 digits at most is preferable.
If you want scores to be ranked in ascending order, it is a good idea to state so explicitly in the problem statement and multiply the score by minus one.
In most cases you can simply open the file and write to it without thinking about anything in particular, but take care not to give write permission to "other users".

Note that choosing "Score Problem" automatically turns off "Publish on AC".
The difficulty of a score problem may be set to 0.
Pure code judging is not performed for score problems.