This is the mail archive of the
mailing list for the elfutils project.
Re: [PATCH] Check for existence of mempcpy
- From: Ulf Hermann <ulf dot hermann at qt dot io>
- To: Mark Wielaard <mjw at redhat dot com>
- Cc: elfutils-devel at sourceware dot org
- Date: Fri, 17 Feb 2017 13:16:11 +0100
- Subject: Re: [PATCH] Check for existence of mempcpy
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=ulf dot hermann at qt dot io;
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qtcompany.onmicrosoft.com; s=selector1-qt-io; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YBaGDJCJiHg/4yYetd/2ozmiSp70DaaU2XqEJCn8iS0=; b=GUVihgjX1qnGi8ipAc/b+cyHArrF49y04lbGB77cer9YUX5uvERGPNog5sHgKaH3G9SzHFWYR1M566aM+wwBk/oeGs9yo4o8du+QiWKZ4hK8IIl5shMM+sUVOj4H9CiXmvOMfhQrQrzaigcCoxY9d5ez59IasDl7FY76rLXV2xg=
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
> If at all possible I would like elfutils to not turn into some
> abstraction layer for broken non-GNU/Linux systems. I don't mind small
> (mostly) obvious correct defines/checks or tweaks to help out people
> using such broken systems. But if we need a lot more of these things I
> think we should look if we can just import the necessary gnulib modules
> to get portability functions.
I've actually done that, but the amount of stuff that would need to be imported is staggering (see for example https://codereview.qt-project.org/#/c/182654/13) and comes with a serious mess of different licenses.
I've since switched to a different strategy where I rather disable features than import large gnulib modules. Disabling maintainer mode (for obstack) and any code that uses argp certainly helps. The remaining pain point is tsearch/tfind/tdelete/tdestroy for which we probably need third party code. Another problem is that we need fts for dwfl_linux_kernel_*. I'm on the edge on whether to include the gnulib implementation or disable it.
The retrying I/O functions can be implemented on top of either Linux/GNU or windows API and I would just move them to a separate file which I can replace based on availability of one or the other (I don't need to upstream the windows implementation). This technique will require universally using the retrying variants rather than the plain ones, which is a good thing anyway.
Replacements for mmap() and dlopen() on windows are a somewhat more involved matter but I don't really need to upstream them either, if you don't want them.
All other missing functions are just a few lines of C code each, which can either be pulled from gnulib or reimplemented. As I didn't want to taint myself with license problems I chose to reimplement them for now. But that can be decided on a case by case basis. Those are the patches I'm going to focus on next.
And then there are nonstandard C constructs, especially void* arithmetics and statement expressions, which I would like to replace with standards compliant C. That is a somewhat larger and not yet finished project, and I'm hoping you're generally open to it.