when truncate(...) is NULL, truncate(...) is not NULL evaluates to 1 unexpectedly

[r33s3n6]

1. Minimal reproduce step (Required)

create table t1 (c1 int);
insert into t1 values (null);
select truncate(1,c1), truncate(1,c1) is not NULL from t1;

2. What did you expect to see? (Required)

The column (truncate(...) is not NULL) should be 0 when the expression in the column truncate(...) is NULL：

mysql> select NULL is not NULL;
+------------------+
| NULL is not NULL |
+------------------+
|                0 |
+------------------+
1 row in set (0.00 sec)

3. What did you see instead (Required)

But TiDB output 1.

mysql> select truncate(1,c1), truncate(1,c1) is not NULL from t1;
+----------------+----------------------------+
| truncate(1,c1) | truncate(1,c1) is not NULL |
+----------------+----------------------------+
|           NULL |                          1 |
+----------------+----------------------------+
1 row in set (0.00 sec)

4. What is your TiDB version? (Required)

Release Version: v8.2.0-alpha-126-g5d780eb
Edition: Community
Git Commit Hash: 5d780ebf8e9bec3f4f38a26e3f1ec26269dda555
Git Branch: HEAD
UTC Build Time: 2024-05-11 01:07:06
GoVersion: go1.21.4
Race Enabled: false
Check Table Before Drop: false
Store: tikv

topology:

distributed.yaml:

global:
  user: "tidb"
  ssh_port: 22
  deploy_dir: "/tidb-deploy"
  data_dir: "/tidb-data"

pd_servers:
  - host: 10.0.2.31

tidb_servers:
  - host: 10.0.2.21

tikv_servers:
  - host: 10.0.2.11
  - host: 10.0.2.12
  - host: 10.0.2.13

monitoring_servers:
  - host: 10.0.2.8

grafana_servers:
  - host: 10.0.2.8

alertmanager_servers:
  - host: 10.0.2.8

tiflash_servers:
  - host: 10.0.2.32

about us

We are the BASS team from the School of Cyber Science and Technology at Beihang University. Our main focus is on system software security, operating systems, and program analysis research, as well as the development of automated program testing frameworks for detecting software defects. Using our self-developed database vulnerability testing tool, we have identified the above-mentioned vulnerabilities in TiDB that may lead to database logic error.

[XuHuaiyu]

The root cause is that the flag for truncate(1, c1) includes the NOT_NULL flag, which is unexpected.

mysql> select truncate(1,c1), truncate(1,c1) is not NULL from t1;
Field   1:  `truncate(1,c1)`
Catalog:    `def`
Database:   ``
Table:      ``
Org_table:  ``
Type:       LONGLONG
Collation:  binary (63)
Length:     20
Max_length: 0
Decimals:   0
Flags:      NOT_NULL BINARY NUM 

Field   2:  `truncate(1,c1) is not NULL`
Catalog:    `def`
Database:   ``
Table:      ``
Org_table:  ``
Type:       LONGLONG
Collation:  binary (63)
Length:     1
Max_length: 1
Decimals:   0
Flags:      NOT_NULL BINARY NUM 


+----------------+----------------------------+
| truncate(1,c1) | truncate(1,c1) is not NULL |
+----------------+----------------------------+
|           NULL |                          1 |
+----------------+----------------------------+
1 row in set (0.01 sec)