Pull request #3630 started showing the countries where ranks are from,
but created a mismatch between the two queries, one selected
Time, Ago, Stamp
the other
Time, Ago, Stamp, Name, Server
but both tried accessing the server. Add Server to the former query and
swap Name and Server in the second query to fix the problem.
Fixes#3643.
3568: Get rid of the MySQL C++ connector as a dependency and disable C++ exceptions r=Learath2 a=heinrich5991
We now use the C API directly. This has the advantage of using one
obscure dependency less, as the C++ connector also used the C API.
Also remove exceptions from database code.
The equivalent code with return codes is a human-assisted mechanical
translation of the old code, no attempts to improve correctness were
made.
This allows us to enable the -fno-exceptions flag.
## Checklist
- [x] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [x] Tested in combination with possibly related configuration options
- [ ] Written a unit test if it works standalone, system.c especially
- [x] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: heinrich5991 <heinrich5991@gmail.com>
The equivalent code with return codes is a human-assisted mechanical
translation of the old code, no attempts to improve correctness were
made.
This allows us to enable the -fno-exceptions flag.
3630: /times: Show country rank is from r=heinrich5991 a=def-
<!-- What is the motivation for the changes of this pull request -->
## Checklist
- [ ] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test if it works standalone, system.c especially
- [ ] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: def <dennis@felsin9.de>
3581: Improve performance of /top5points query, remove negative /top5points since it makes no sense anyway r=heinrich5991 a=def-
<!-- What is the motivation for the changes of this pull request -->
## Checklist
- [x] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test if it works standalone, system.c especially
- [ ] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: def <dennis@felsin9.de>
3626: Rename save/load to conform to the code style r=def- a=Zwelf
Small cleanup
## Checklist
- [ ] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test if it works standalone, system.c especially
- [ ] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: Zwelf <zwelf@strct.cc>
3541: rank/teamrank: Display how much better you are r=def- a=def-
## Checklist
- [x] Tested the change ingame
- [x] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test if it works standalone, system.c especially
- [x] Considered possible null pointers and out of bounds array indexing
- [x] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: def <dennis@felsin9.de>
Co-authored-by: Zwelf <zwelf@strct.cc>
Previously, a save could possibly be loaded twice given enough latency
discrepancy between servers. The server only verified that it deleted
*some* save with the given password, not *the* save it is trying to
load. This is fixed by also checking the SaveID column that is random
and globally unique (except for the old NULLs). Since users can't create
new saves with NULL SaveID, these pose no problem.
Also change the default UUID for saves without save ID to something
nonzero, so we can't accidentally hit it due to a bug.
/media/ddnet/src/engine/server/sql_string_helpers.cpp:74:3: warning: Call to function 'strcpy' is insecure as it does not provide bounding of the memory buffer. Replace unbounded copy functions with analogous functions that support length arguments such as 'strlcpy'. CWE-119 [clang-analyzer-security.insecureAPI.strcpy]
Purely automatic change. In case of conflict with this change, apply the
other change and rerun the formatting to restore it:
$ python scripts/fix_style.py
The slow query logs are full of this:
# Time: 200906 21:03:43
# User@Host: teeworlds[teeworlds] @ ger6.ddnet.tw [89.163.212.120]
# Thread_id: 101540 Schema: teeworlds QC_hit: No
# Query_time: 11.012166 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0
# Rows_affected: 0 Bytes_sent: 67
SET timestamp=1599419023;
LOCK TABLES record_teamrace WRITE, record_teamrace AS r WRITE;
Do we really need these lock? See also
https://dev.mysql.com/doc/refman/5.7/en/table-locking.html
> InnoDB tables use row-level locking so that multiple sessions and
> applications can read from and write to the same table simultaneously,
> without making each other wait or producing inconsistent results. For
> this storage engine, avoid using the LOCK TABLES statement, because it
> does not offer any extra protection, but instead reduces concurrency.
