Sync with gnulib 64ddc975e72cb55d2b2d755c25603bd70312aa5e:
This patch alters xstrtoumax behavior slightly, in areas are not
likely to affect any real callers, by making xstrtoumax behave more
like the system strtol. In particular, it lets xstrtoumax support
bases other than those required by POSIX, if the underlying
implementation does; this removes the need for an g_assert().
* lib/strutil/strtol.c: Do not include stdio.h.
(xstrtoumax): Use same parameter names as POSIX, to make it
easier for outsiders to follow. Do not require the base to be 0-36,
as the underlying implementation is allowed to support other bases.
Sync with gnulib 16b33e6649425fcdce095f262da98b539d2f7448.
* (xstrtoumax): Don't update *endptr if strtol doesn't.
Also, if the underlying strtol gives an unusual error number and
sets *endpnr = nptr, assume that's an error not a missing number.
Sync with gnulib bd1e981434c98751b1106a1744e77a27317b52b3
* (xstrtoumax): Stop worrying about hypothetical implementations that
are causing more confusion than the code is worth. Instead, go back
more to old way of doing things. None of this matters for practical
applications.
Add commemt.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
../../../src/filemanager/file.c:2402:61: warning: variable 'attrs' may be uninitialized when used here [-Wconditional-uninitialized]
while (attrs_ok && mc_fsetflags (dst_vpath, attrs) != 0 && !ctx->skip_all)
^~~~~
../../../src/filemanager/file.c:2266:24: note: initialize the variable 'attrs' to silence this warning
unsigned long attrs;
^
= 0
../../../src/filemanager/file.c:3227:38: warning: variable 'attrs' may be uninitialized when used here [-Wconditional-uninitialized]
mc_fsetflags (dst_vpath, attrs);
^~~~~
../../../src/filemanager/file.c:2942:24: note: initialize the variable 'attrs' to silence this warning
unsigned long attrs;
^
= 0
../../../lib/strutil/tokenize.c:163:44: warning: variable 'delimopen' may be uninitialized when used here [-Wconditional-uninitialized]
if (nestdelim != 0 && string[i] == delimopen)
^~~~~~~~~
../../../lib/strutil/tokenize.c:72:19: note: initialize the variable 'delimopen' to silence this warning
char delimopen;
^
= '\0'
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
When using an external editor (i.e. "Use internal edit" in the Configure
Options is unchecked) the environment variable EDITOR is used. However,
if $EDITOR contains a command line argument after the executable name,
these arguments are not processed properly, and the editor might not be
started at all.
How to reproduce: (Precondition: vi is available on the system)
1) On the command line, execute: export EDITOR="vi +" && mc
(the + argument should let vi start at the document's end instead of the
beginning).
2) Go to the Options menu -> Configuration -> uncheck "Use internal
edit".
3) Move the cursor to a file that is larger than a single screen (e.g.
ABOUT-NLS in mc's source directory).
4) Press F4 to start the external editor.
Result: Nothing visible happens
Expected result: vi is opened showing the end of the file ABOUT-NLS
The bug: my_system_make_arg_array() doesn't perform full-feature
parsing of the comman line.
* (str_tokenize): mew function based on history_tokenize_internal()
from GNU readline-8.2.
* (str_tokenize_word): mew function based on history_tokenize_word()
from GNU readline-8.2.
* (my_system_make_arg_array): reimplement using str_tokenize().
* (my_systemv_flags): use modified my_system_make_arg_array().
* (fork_child_tokens): new test for string tokenization.
* (fork_child_tokens2): likewise.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
Get rig of intermediate storage of string patrs. Create result string directly.
Update comments. Update test.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
Found via `codespell -S
po,doc,./misc/syntax,./src/vfs/extfs/helpers/README.it -L
parm,rouge,sav,ect,vie,te,dum,clen,wee,dynamc,childs,ths,fo,nin,unx,nd,iif,iterm,ser,makrs,wil`
Co-authored-by: Yury V. Zaytsev <yury@shurup.com>
Signed-off-by: Kian-Meng Ang <kianmeng@cpan.org>
Signed-off-by: Yury V. Zaytsev <yury@shurup.com>
As voted for in Nov 2022 by the BIPM:
https://www.bipm.org/en/cgpm-2022/resolution-3
Sync with gnulib 0ad3ea4951f77835d02180021589f3a849d885f2.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
filevercmp: don't treat entire filename as suffix.
Sync with gnulib 1ba2b66ea45f9bc43cdc0f6f93efa59157d2b2ba.
(file_prefixlen): When stripping (\.[A-Za-z~][A-Za-z0-9~]*)*$ suffixes,
do not strip the entire file name.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
Sync with gnulib 9f48fb992a3d7e96610c4ce8be969cff2d61a01b.
Problems reported by Michael Debertol in <https://bugs.gnu.org/49239>.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
When content of a large directory is being sorted by file names, a
significant amount of CPU time is spent in str_utf8_normalize() that is
called from str_utf8_create_key_gen().
For example, /usr/bin/ contains 5437 files on my Archlinux box. Running
mc /usr/bin/ /usr/bin/ takes approx. 75 000 000 CPU instructions to sort
file names, or 25% of total program run time. From these 75 000 000
instructions, 42 500 000 instruction are spent in str_utf8_normalize().
str_utf8_normalize() uses g_utf8_normalize() to do the work.
g_utf8_normalize() is a heavyweight function, that converts UTF-8 into
UCS-4, does the normalization and then converts UCS-4 back into UTF-8.
Since file names are composed of ASCII characters in most cases, we can
speed up str_utf8_normalize() by checking if the heavyweight Unicode
normalization is actually needed. Normalization of ASCII string is
no-op, so it is effectively "normalized" by just strdup().
With this patch, running mc /usr/bin/ /usr/bin/ requires just 37 000 000
instructions to sort the file names (down from 75 000 000) and 4 500 000
instuctions to do str_utf8_normalize() (down from 42 500 000).
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
