IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
the only difference between
g_hash_table_insert and g_hash_table_replace is which key gets
freed/used
insert reuses the old key while replace used the new key
both insert the value or replace the value if it already exists
since the key is in the structure we allocate, we always
want to use the new key, and the old structure to be freed
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
when generating a bitmap for a character whose codepoint was above 255,
we used a cache_id of 0, malloc'd a CachedImage and inserted it into a
g_hashtable, without freeing the one which was before inserted with cache_id 0
this is circumvented by only generating a CachedImage when having
a cache_id != 0
the second leak was also with inserting into a hashtable, but there we
give the hashtable the g_free method as a value_destroy_func
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
changing most of the vt struct fields to unsigned, to avoid undefined
behaviour and use gotoxy for moving the cursor to correctly bound check
the cursor position
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
since we load the font from psf1 files, the highest utf8 codepoint we
have a fontmap for is 0xFFFF, so we use an unsigned short for the
character
but since we parse utf8 for up to 6 bytes we have to check the range, or
else we can get garbled output
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
