summitto / pgp-packet-library Goto Github PK

Prompted by Mátyás failing to compile the library with gcc 7 because of an internal compiler error (!).

Perhaps everyone could post the compiler versions that they successfully (or unsuccessfully!) compiled the code with in this thread?

As for me: I'm successfully compiling using gcc 8.3.0 and clang 8.0.0.

Currently, we unconditionally use mpark::variant as our variant implementation, but because certain platforms may have special implementations of std::variant, we decided to switch automatically between the two. This could be done using a shim header file that does a preprocessor switch on __hasinclude(<variant>), and then either puts std::variant or mpark::variant into some custom namespace, e.g. util.

Additional remark by @omartijn: we may do the same thing to <span>.
Also, if we switch to std::variant and/or std::span, we can conditionally remove certain dependencies.

@rockhouse already did preliminary work for this; I'm working on implementing this in the refactored design.

At the moment the compilation fails with g++ due to unsupported compiler flags:

g++: error: unrecognized command line option ‘-Wdocumentation’

How to reproduce:

• Execute cmake -DCMAKE_CXX_COMPILER=g++ .. && make from the build folder.

Thought I would give the code at https://github.com/summitto/pgp-packet-library#creating-a-pgp-key-from-raw-point-data a test drive. Copied the code into a file called gen_cert.cpp

Only moved line 1 from to line 6 and changed from

#include <pgp-packet/packet.h>

to:

#include "packet.h" // From pgp-packet library

% make
clang++ -arch x86_64 -mmacosx-version-min=10.11 -std=c++17 -g -O0 -Wall -Werror -Wextra -pedantic -fPIC -I../pgp-packet-library/include -I/usr/local/homebrew/Cellar/cryptopp/8.1.0/include/cryptopp -I/usr/local/homebrew/Cellar/libsodium/1.0.18_1/include -I/usr/local/homebrew/Cellar/boost/1.72.0_3/include -c gen_cert.cpp -o gen_cert.o
In file included from gen_cert.cpp:6:
In file included from ../pgp-packet-library/include/packet.h:10:
In file included from ../pgp-packet-library/include/variable_number.h:7:
In file included from ../pgp-packet-library/include/decoder_traits.h:3:
../pgp-packet-library/include/util/span.h:3:10: fatal error: 'gsl/span' file not found
#include <gsl/span>
         ^~~~~~~~~~
1 error generated.
make: *** [gen_cert.o] Error 1

% cat ../pgp-packet-library/include/util/span.h
#pragma once

#include <gsl/span>
#include <gsl/span_ext>


namespace pgp {
    using gsl::span;
}

ls ../pgp-packet-library/include/util
./		../		narrow_cast.h	span.h		transaction.h	tuple.h		variant.h	vector.h

Any suggestions?

I try to compile the 3rd example: Creating a PGP key from raw point data
I think there is one error:
std::vector<uint8_t> data; data.resize( ...
versus
std::vector<uint8_t> data data.resize( ...
And regarding the newest GSL version 3.x I receive the following error:
/usr/local/include/pgp-packet/decoder.h:164:117: Fehler: »index_type« in »class gsl::span<unsigned char>«
If I pull tag v2.1.0 it seems to be fine.

Furthermore I am not able to create the following instances:
signature_creation_time_subpacket
key_expiration_time_subpacket
key_flags_subpacket
Is it ok to write the following, e.g.:
pgp::signature_subpacket::issuer_fingerprint

After the merge of the ECDSA code, it became apparent that I forgot to add tests for it, since the branch wasn't rebased after the tests merge. I'm working on this on ecdsa_tests.

gcrypt is used for sha1 and sha256 in a few places; this dependency was introduced before we started to depend on Crypto++.

Libsodium provides sha256 and Crypto++ provides sha1, so we should be able to remove the dependency on gcrypt without a large amount of effort.

The CMake module CheckCXXCompilerFlag can be used to detect whether the compiler supports a particular flag. This can be used instead of the compiler switch we're currently using to determine what flags are supported.

Motivation

Avoid the year 2038 problem

Specification

Replace the types of all the variables used to represent UNIX timestamps with the 64 bit unsigned integer type from the standard library

Currently, the code uses boost::string_view. Is there a standard library implementation that we wish to remain compatible with that does not have std::string_view, or can we switch?