Verify that stderr is not fully-buffered.
CRTs before the Unversal CRT can open stderr in full buffering
mode (depending on the output type). That's not desirable and
we have a workaround in app_profile_dep.
This is to avoid the Wflag-enum warning that Clang emits when you have a
flags enum where a multi-bit value encompasses a bit that doesn't have a
corresponding single-bit value.
(I'm not sure why G_REGEX_NEWLINE_ANYCRLF isn't just 1 << 22...)
This is to avoid the Wflag-enum warning that Clang emits when you have a
flags enum where a multi-bit value encompasses a bit that doesn't have a
corresponding single-bit value.
It can appear either after 'enum' or after the closing brace. Also handle
__attribute__((flag_enum)) and, for C++ code, [[gnu::flag_enum]] and
[[clang::flag_enum]] and various other spellings of those. If it is
present, mark the enum as a flags enum, the same as if we detected left
shifts in the values.
This expands to __attribute__((flag_enum)) if available. It is useful when
using clang-tidy to do static analysis, which will warn about code like
(GParamFlags)(G_PARAM_CONSTRUCT_ONLY | G_PARAM_READWRITE).
citing https://no-color.org/
> Command-line software which adds ANSI color to its output by default should check
> for a NO_COLOR environment variable that, when present and not an empty string
> (regardless of its value), prevents the addition of ANSI color.
This makes sure that extensions can generate code at the expected
places, and change the GDBusInterfaceSkeleton subtype that generated
skeletons derive from.
This allows us to create a copy of an argument without going through
GValue. The codegen here does not have any use for it, but we will add
an extension system in a later commit. The libdex codegen extension will
make use of it to define a boxed type for the method return values.
The out type can be different from the in types in their qualifiers and
thus are not always simply a reference to the in type. However, the out
types used to include the reference instead of the "base" type because
the code generator always used them in places where we actually needed a
reference to the out type (e.g. as out params).
For example, the codegen here generates:
gboolean dex_dbus_ping_pong_call_ping_sync (
DexDbusPingPong *proxy,
const gchar *arg_name,
gchar ** out_pong,
GCancellable *cancellable,
GError **error);
Where `gchar **` is the out type. If we want to codegen a function which
returns the out params in a struct, it would need to look like this:
typedef struct _DexDbusPingPongPingResult
{
gchar * pong;
} DexDbusPingPongPingResult;
Where neither the out type `gchar **` nor the in type `const gchar *` is
appropriate.
This changes the ctype_out to be the base type, and makes the codegen
add the reference explicitly.
Contrary to MSDN documentation, GetThreadPriority() may return
undocumented priority values that SetThreadPriority() cannot accept.
This can happen, for example, when a high-priority process uses
MMCSS to modify thread priority levels.
Since failure to update thread priority is not critical and users
can adjust it later, do not treat such failures as errors
A mount table is inherently trusted, so this isn't really a security
issue, but let's not write out of bounds. If anybody is still using GLib
on AIX, then you're welcome.
Discovery and patch credit: mhzcyber - Mohammad Hussam Alzeyyat
(I, Michael, only wrote this commit message and adjusted the
whitespace.)
This previous behavior violates RFC-1123 which updated the original
RFC-952.
Patch originally from Ulrich Drepper.
Fixes: #3523
Signed-off-by: Christian Hergert <chergert@redhat.com>
This adds the condition that a new unix address is tried only when there
is enough space to append random character(s) before the address reach
the length of UNIX_PATH_MAX.
Before this change, creating a GDBusServer with unix addresses longer
than UNIX_PATH_MAX that existed in the filesystem would never return. A
test that expects G_IO_ERROR_ADDRESS_IN_USE in such scenario was added.
