To facilitate porting over to glib, this rewrites the auto cleanup
macros to use glib's equivalent.
As a result it is now possible to use g_autoptr/VIR_AUTOPTR, and
g_auto/VIR_AUTOCLEAN, g_autofree/VIR_AUTOFREE interchangably, regardless
of which macros were used to declare the cleanup types.
Within the scope of any single method, code must remain consistent
using either GLib or Libvirt macros, never mixing both. New code
must preferentially use the GLib macros, and old code will be
converted incrementally.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Convert the string duplication APIs to use the g_strdup family of APIs.
We previously used the 'strdup-posix' gnulib module because mingw does
not set errno to ENOMEM on failure
We previously used the 'strndup' gnulib module because this function
does not exist on mingw.
We previously used the 'vasprintf' gnulib module because of many GNU
supported format specifiers not working on non-Linux platforms. glib's
own equivalent standardizes on GNU format specifiers too.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Convert the VIR_ALLOC family of APIs with use of the g_malloc family of
APIs. Use of VIR_ALLOC related functions should be incrementally phased
out over time, allowing return value checks to be dropped. Use of
VIR_FREE should be replaced with auto-cleanup whenever possible.
We previously used the 'calloc-posix' gnulib module because mingw does
not set errno to ENOMEM on failure.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Add the main glib.h to internal.h so that all common code can use it.
Historically glib allowed applications to register an alternative
memory allocator, so mixing g_malloc/g_free with malloc/free was not
safe.
This was feature was dropped in 2.46.0 with:
commit 3be6ed60aa58095691bd697344765e715a327fc1
Author: Alexander Larsson <alexl@redhat.com>
Date: Sat Jun 27 18:38:42 2015 +0200
Deprecate and drop support for memory vtables
Applications are still encourged to match g_malloc/g_free, but it is no
longer a mandatory requirement for correctness, just stylistic. This is
explicitly clarified in
commit 1f24b36607bf708f037396014b2cdbc08d67b275
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Thu Sep 5 14:37:54 2019 +0100
gmem: clarify that g_malloc always uses the system allocator
Applications can still use custom allocators in general, but they must
do this by linking to a library that replaces the core malloc/free
implemenentation entirely, instead of via a glib specific call.
This means that libvirt does not need to be concerned about use of
g_malloc/g_free causing an ABI change in the public libary, and can
avoid memory copying when talking to external libraries.
This patch probes for glib, which provides the foundation layer with
a collection of data structures, helper APIs, and platform portability
logic.
Later patches will introduce linkage to gobject which provides the
object type system, built on glib, and gio which providing objects
for various interesting tasks, most notably including DBus client
and server support and portable sockets APIs, but much more too.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Blacklist Perl and Shell code in favour of Python for
sake of readability and portability.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This reverts commit 47cbc92987.
The section is no longer correct when the patch switching to gnulib's
make coverage was reverted.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Acked-By: Eric Blake <eblake@redhat.com>
Forbid breaking lines inside the two branches of the ternary operator
and nesting them. Using it in these instances does not help readability.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
ACKed-by: Eric Blake <eblake@redhat.com>
Document that checking if a integer is (non-)zero should (not must)
avoid the shortened form that C allows as it may confuse readers into
overlooking the other possible values which might be interresting to
handle.
While pointers have distinct values from the point of view of the code
we only care whether it's non-NULL and thus it's documented it's okay
to shorten those.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
ACKed-by: Eric Blake <eblake@redhat.com>
State that error messages should not be broken into multiple lines for
programmer friendliness and should not be concatenated on the fly for
translator friendliness and few other details.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
ACKed-by: Eric Blake <eblake@redhat.com>
We finally get rid of the strncpy()-like semantics
and implement our own, more sensible ones instead.
As a bonus, this also fixes compilation on MinGW.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Currently, the functions return a pointer to the
destination buffer on success or NULL on failure.
Not only does this kind of error handling look quite
alien in the context of libvirt, where most functions
return zero on success and a negative int on failure,
but it's also somewhat pointless because unless there's
been a failure the returned pointer will be the same
one passed in by the user, thus offering no additional
value.
Change the functions so that they return an int
instead.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The https:// protocol is much more reliably usable than git:// when
faced with unreasonably strict firewalls. The libvirt.org web server is
now setup to support the smart https:// protocol, which is just as fast
as git://, so change all the docs to use https://
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Document that contributors are required to assert compliance with the
Developers Certification of Origin 1.1, by providing Signed-off-by tags
for all commit messages. The DCO is formally stating what we have long
implicitly expected of contributors in terms of their legal rights to
make the contribution. This puts the project in a stronger position
should any questions around contributions be raised going forward in the
future.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The HTML5 doctype is simply
<!DOCTYPE html>
no DTD is present because HTML5 is no longer defined as an
extension of SGML.
XSL has no way to natively output a doctype without a public
or system identifier, so we have to use an <xsl:text> hack
instead.
See also
https://dev.w3.org/html5/html-author/#doctype-declaration
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The 'name' attribute on <a...> elements is deprecated in favour
of the 'id' attribute which is allowed on any element. HTML5
drops 'name' support entirely.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
For the benefit of first time contributors, we point out that 'git
send-email' might have to be installed separately; however, we omit
the fact that some configuration will likely be needed before it
can successfully deliver patches to the mailing list.
Some minor tweaks to the existing contents are included as well.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This documents the preferred conventions for naming files,
structs, enums, typedefs and functions.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Updating docs/news.xml in the same commit that performs the
documented change makes backports needlessly complicated,
both for mainteinance branches and downstream distributions,
because it introduces additional potential for merge
conflicts.
Document in the contributor guidelines that the release notes
should be updated in a separate commit instead, so that it's
easy to backport just the code change.
Now that we have built a fairly solid process for dealing with
release notes, we should start pushing for contributors to
provide the relevant information along with their code:
documenting the process is clearly a requirement for this to
happen.
When updating the source file in commit bd4f4d1686, I forgot
that we also store the generated plain text version in git and
didn't regenerate it.
I also missed one spot that required an additional <p> tag, so
fix both mistakes in one go.
Some of the <li> elements in the "General tips for contributing
patches" section were missing the corresponding inner <p> element,
so they ended up all lumped together.
I can't think of any good reason to do either of those, and having the
examples there will just lead to unusable patch emails from people who
can't be bothered to read the entire page.
All the accesses to files outside our build or source directories
are now identified and appended into a file for later processing.
The location of the file that contains all the records can be
controlled via VIR_TEST_FILE_ACCESS env variable and defaults to
abs_builddir "/test_file_access.txt".
The script that will process the access file is to be added in
next commit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
If this enviroment variable is set, the virTestCompareToFile helper
will overwrite the file content we are comparing against, if the
file doesn't exist or it doesn't match the expected input.
This is useful when adding new test cases, or making changes that
generate a lot of output churn.
After recent discussion it looks like curly brackets around one-line
bodies are preferred if the preceding condition is, itself, multiline.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Now that hanging brace offenders have been fixed, we can automate
the check, and document our style. Done as a separate commit from
code changes, to make it easier to just backport code changes, if
that is ever needed.
* cfg.mk (sc_curly_braces_style): Catch hanging braces.
* docs/hacking.html.in: Document it.
* HACKING: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
On some places in the libvirt code we have:
f(a,z)
instead of
f(a, z)
This trivial patch fixes couple of such occurrences.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The link to the page "how to get your code into an open source
project" has been fixed.
Signed-off-by: Michele Paolino <m.paolino@virtualopensystems.com>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Check if the buffer is in error state and report an error if it is.
This replaces the pattern:
if (virBufferError(buf)) {
virReportOOMError();
goto cleanup;
}
with:
if (virBufferCheckError(buf) < 0)
goto cleanup;
Document typical buffer usage to favor this.
Also remove the redundant FreeAndReset - if an error has
been set via virBufferSetError, the content is already freed.
Enforce and document the style set up by the previous patches.
* build-aux/bracket-spacing.pl: Add comma checks.
* docs/hacking.html.in: Document the rules.
* HACKING: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
Commit ab92ae333 added a cool feature, but didn't document it.
* docs/hacking.html.in: Document debugging a subset of tests.
* HACKING: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
The gnulib testsuite is relatively stable - the only times it is
likely to have a test change from pass to fail is on a gnulib
submodule update or a major system change (such as moving from
Fedora 18 to 19, or other large change to libc). While it is an
important test for end users on arbitrary machines (to make sure
that the portability glue works for their machine), it mostly
wastes time for development testing (as most developers aren't
making any of the major changes that would cause gnulib tests
to alter behavior). Thus, it pays to make the tests optional
at configure time, defaulting to off for development, on for
tarballs, with autobuilders requesting it to be on. It also
helps to allow a make-time override, via VIR_TEST_EXPENSIVE=[01]
(much the way automake sets up V=[01] for overriding the configure
time default of how verbose to be).
Automake has some pretty hard-coded magic with regards to the
TESTS variable; I had quite a job figuring out how to keep
'make distcheck' passing regardless of the configure option
setting in use, while still disabling the tests at runtime
when I did not configure them on and did not use the override
variable. Thankfully, we require GNU make, which lets me
hide some information from Automake's magic handling of TESTS.
* bootstrap.conf (bootstrap_epilogue): Munge gnulib test variable.
* configure.ac (--enable-expensive-tests): Add new enable switch.
(VIR_TEST_EXPENSIVE_DEFAULT, WITH_EXPENSIVE_TESTS): Set new
witnesses.
* gnulib/tests/Makefile.am (TESTS): Make tests conditional on
configure settings and the VIR_TEST_EXPENSIVE variable.
* tests/Makefile.am (TESTS_ENVIRONMENT): Expose VIR_TEST_EXPENSIVE
to all tests.
* autobuild.sh: Enable all tests during autobuilds.
* libvirt.spec.in (%configure): Likewise.
* mingw-libvirt.spec.in (%mingw_configure): Likewise.
* docs/hacking.html.in: Document the option.
* HACKING: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
Based on a report by Chandrashekar Shastri, at
https://bugzilla.redhat.com/show_bug.cgi?id=979360
On systems where git cannot access the outside world, a developer
can instead arrange to get a copy of gnulib at the right commit
via side channels (such as NFS share drives), set GNULIB_SRCDIR,
then use ./autogen.sh --no-git. In this setup, we will now
avoid direct use of git. Of course, this means no automatic
gnulib updates when libvirt.git updates its submodule, but it
is expected that any developer in such a situation is already
prepared to deal with the fallout.
* .gnulib: Update to latest, for bootstrap.
* bootstrap: Synchronize from gnulib.
* autogen.sh (no_git): Avoid git when requested.
* cfg.mk (_update_required): Skip automatic rerun of bootstrap if
we can't use git.
* docs/compiling.html.in: Document this setup.
* docs/hacking.html.in: Mention this.
* HACKING: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
The previous handling of <a> tags led to some less-than-ideal
layout in HACKING (most noticeable on a mid-sentence reference
to the valgrind home page).
* docs/hacking.html.in: Slight tweaks to <a> tags.
* docs/hacking1.xsl: Move <a> handling...
* docs/hacking2.xsl: ...here.
* HACKING: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
While reviewing proposed VIR_STRDUP conversions, I've already noticed
several places that do:
if (str && VIR_STRDUP(dest, str) < 0)
which can be simplified by allowing str to be NULL (something that
strdup() doesn't allow). Meanwhile, code that wants to ensure a
non-NULL dest regardless of the source can check for <= 0.
Also, make it part of the VIR_STRDUP contract that macro arguments
are evaluated exactly once.
* src/util/virstring.h (VIR_STRDUP, VIR_STRDUP_QUIET, VIR_STRNDUP)
(VIR_STRNDUP_QUIET): Improve contract.
* src/util/virstring.c (virStrdup, virStrndup): Change return
conventions.
* docs/hacking.html.in: Document this.
* HACKING: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
VIR_APPEND_ELEMENT(array, size, elem) was not safe if the expression
for 'size' had side effects. While no one in the current code base
was trying to pass side effects, we might as well be robust and
explicitly document our intentions.
* src/util/viralloc.c (virInsertElementsN): Add special case.
* src/util/viralloc.h (VIR_APPEND_ELEMENT): Use it.
(VIR_ALLOC, VIR_ALLOC_N, VIR_REALLOC_N, VIR_EXPAND_N)
(VIR_RESIZE_N, VIR_SHRINK_N, VIR_INSERT_ELEMENT)
(VIR_DELETE_ELEMENT, VIR_ALLOC_VAR, VIR_FREE): Document
which macros are safe in the presence of side effects.
* docs/hacking.html.in: Document this.
* HACKING: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
