GitLab

Korean Update

Korean Update

Korean Update

* fix bug stopping iteration when --no-floppy is used

* fix gfxmenu theme config handling bug

@ventoy 
I translated new adding lines(528,529) on Turkish Language

* Add slovak translations

* Add missing czech translations

* Fix two typos

* Fix previous typo fix (im dumb, ok?)
Co-authored-by: longpanda <59477474+ventoy@users.noreply.github.com>

Updated and fixed typos in the Macedonian language

1. When click install button, if the USB stick already installed with Ventoy, then popup a dialog to require a YES text input to confirm.
2. Prevent DLL search order hijacking

* fix gcc11 warnings

* add mouse support for uefi

* add GitHub actions state to README

* Update README.md

* remove link in README
Co-authored-by: Dylan M. Taylor <dylan@dylanmtaylor.com>

Dear Ventoy community –
 
Our team is working with your code and we noticed this if logical expression:
 
                if (len - 1 - (int)(long)(pos - pwdstr) != 32)
 
We studied the surrounding code. We believe we understand the intention of the type casts in the above if statement. It seems they were meant to ensure an underflow doesn’t occur by the subtraction between to char pointers, which is a great catch (!). However, we believe the way the type casts are structured, the code is not actually protecting against such underflow because pwdstr isn’t cast into a signed long until after the subtraction occurs. To properly protect this code against underflow, we believe it should be changed to something like the following:

if (len - 1 - ((long)pos – (long)pwdstr) != 32)

Or, to enhance readability for junior engineers who may not know that the “long” type cast is implicitly of a signed integer type, we could include the `signed` keyword for added verbosity:
 
if (len - 1 - ((signed long)pos – (signed long)pwdstr) != 32)
 
Thank you!

Co-authored-by: longpanda <59477474+ventoy@users.noreply.github.com>

Changes detail to details and replug to reinsert. Which makes words flow with the sentance better.

I think this might be a minor typo-- since the conditional checks for `priority` to be in the signed int16 range, the error message should line up with that expected range.