Documentation says the limit is 5, but it was really 10 (at least
since 2004). But since MPD wants to promote using many small clients
idling around, and these clients consume only very few resources, it
seems reasonable to raise this limit's default value.
exp10 is a GNU function, is not part of C++, and is not available
everywhere.
pow(10,x) is an alternative that works just as well. It is used in musl as
the implementation of exp10.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
The former is deprecated by C++14. The standard says they are the same:
The header defines all types and macros the same as the C standard library
header<stdint.h>.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
The former is deprecated with C++14. The standard says both are the same:
The contents and meaning of the header<cstddef>are the same as the C
standard library header<stddef.h>,except that it does not declare the type
wchar_t, that it also declares the type byte and its associated
operations (21.2.5), and as noted in 21.2.3 and 21.2.4.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
The former was deprecated in C++14. The Standard says they are the same:
The contents of the header<cstdarg>are the same as the C standard library
header<stdarg.h>, with the following changes: The restrictions that ISO C
places on the second parameter to the va_start macro in header<stdarg.h>
are different in this International Standard. The parameter parmN is the
rightmost parameter in the variable parameter list of the function
definition (the one just before the...).219If the parameter parmN is a
pack expansion (17.5.3) or an entity resulting from a lambda capture
(8.1.5), the program is ill-formed, no diagnostic required. If the
parameter parmN is of a reference type, or of a type that is not
compatible with the type that results when passing an argument for which
there is no parameter, the behavior is undefined.
Also changed va_list to the std:: namespace version, which is the same.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
The former was deprecated with C++14. The standard says they are the same:
The contents of the header<csignal>are the same as the C standard library
header<signal.h>.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
The former was deprecated with C++14. The standard says they are the same
with one exception:
The header<climits>defines all macros the same as the C standard library
header<limits.h>.
[Note:The types of the constants defined by macros in<climits>are not
required to match the types to which themacros refer.— end note]
Signed-off-by: Rosen Penev <rosenp@gmail.com>
The former has been deprecated by C++14. They are also the same.
From the standard:
The contents and meaning of the header<cinttypes>are the same as the C
standard library header<inttypes.h>, with the following changes:
-The header<cinttypes>includes the header<cstdint>instead of<stdint.h>,and
—if and only if the typeintmax_tdesignates an extended integer type
(6.7.1), the following functionsignatures are added:intmax_t
abs(intmax_t);imaxdiv_t div(intmax_t, intmax_t);which shall have the same
semantics as the function signaturesintmax_t imaxabs(intmax_t)andimaxdiv_t
imaxdiv(intmax_t, intmax_t), respectively.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
The former is deprecated by C++14. It's also functionally the same.
From the standard:
19.4
The header<cerrno>is described in Table 43. Its contents are the same as
the POSIX header<errno.h>,except that errno shall be defined as a macro.
[Note: The intent is to remain in close alignment with the POSIX
standard.] A separate errno value shall be provided for each thread.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
None of the functions in these files come from ctype.h
Also changed one instance of isdigit to the C++ variant.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
The former was deprecated with C++14.
According to the C++11 and C++17 standards, both files are identical.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Aparently, libcdio sometimes returns empty filenames, causing MPD
crashes. This shouldn't really happen, and I consider this a libcdio
bug - but if it happens, people blame MPD, so let's add a check.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/776
Fixes
../src/time/ISO8601.cxx:67:24: error: use of undeclared identifier 'strtoul'
unsigned long value = strtoul(s, &endptr, 10);
^
../src/time/ISO8601.cxx:77:14: error: use of undeclared identifier 'strtoul'
minutes = strtoul(s, &endptr, 10);
^
on NetBSD with clang 9.0.0.
Using libgme 0.6.2 on macOS, it appears that gme_info_t strings can be
empty, which creates weird track titles: (001/050)
This adds an additional check for an empty string.
"The issue is that ParseCommandArgSignedSongTime parses with
SongTime::FromS, not SignedSongTime::FromS, before casting back to a
SignedSongTime for the return. With x86 overflow rules this doesn't
matter, but on ARM the first cast turns negative values to zero."
Closes https://github.com/MusicPlayerDaemon/MPD/issues/757
