desired behavior or missing warning?
I found myself with code similar to this:
struct base {
virtual void cb() = 0;
};
struct deriv final : public base {
void cb() final override { }
};
The question is about the second use of 'final'. Because the entire
class is declared final, should the individual function's annotation be
flagged with a warning? I personally think it should because it might
distract from the final of the class itself.
signature.asc
Description: OpenPGP digital signature
-Wformat and u8""
I have a C++20+ code base which forces the program to run using an UTF-8
locale and then uses u8"" strings internally. This causes warnings with
-Wformat.
#include
int main()
{
printf((const char*) u8"test %d\n", 1);
return 0;
}
Compile with
g++ -std=gnu++20 -c -O -Wall t.cc
and you'll see:
t.cc: In function ‘int main()’:
t.cc:5:24: warning: format string is not an array of type ‘char’ [-Wformat=]
5 | printf((const char*) u8"test %d\n", 1);
|^
I would say it is not gcc's business to question my use of u8"" given that
I use a cast and the u8"" string can be parsed by the -Wformat handling.
Before filing a report I'd like to take the temperature and see whether
people agree with this.
Thanks.
Re: -Wformat and u8""
On Mon, May 9, 2022 at 11:26 AM Florian Weimer wrote: > On the other hand, that cast is still quite ugly. Yes, there aren't yet any I/O functions defined for char8_t and therefore that's the best we can do right now. I have all kinds of ugly macros to high these casts. > All string-related > functions in the C library currently need it. Yes, but the cast isn't the issue. Or more correctly: gcc disregarding the cast for -Wformat is. Anyway, I'm not concerned about the non-I/O functions. This is all C++ code after all and there are functions for all the rest. > Isn't this a problem with char8_t? > Well, yes, the problem is that gcc seems to just see the u8"" type (char8_t) even though I tell it with the cast to regard it as a const char. Again, I ensure that the encoding matches and putting UTF-8 in char strings is actually incorrect (in theory).
[RFC] database with API information
I talked to Jonathan the other day about adding all the C++ library APIs to the name hint file now that the size of the table is not really a concern anymore. Jonathan mentioned that he has to create and maintain a similar file for the module support. It needs to list all the exported interfaces and this is mostly a superset of the entries in the hint table. Instead of duplicating the information it should be kept in one place. Neither file itself is a natural fit because the additional information needed (e.g., the standard version information for the name hint table) is not needed in the other location. Hence, let's use a simple database, a CSV file for simplicity, and generate both files from this. Easily done, I have an appropriate script and a CSV file with the information of both Jonathan's current export file and the current state of the name hint table. The only detail that keeps me from submitting this right now is the way the script is implemented. This is just a natural fit for a Python script. The default installation comes with a csv module and there are nice ways to adjust and output boilerplate headers like those needed in those files. It would be possible to create separate awk scripts (there is only one Python script) but it'll be rather ugly and harder to maintain than the Python version. Of course the problem is: I don't think that there is yet any maintainer tool written in Python (except some release engineering tools). The question is therefore: is it time to lift this restriction? I cannot today imagine any machine capable of serving a gcc developer which doesn't also have a Python implementation. As long as there is no dependency on exotic modules I doubt that anything will break. Opinions?
Re: [RFC] database with API information
On Fri, Sep 9, 2022 at 5:26 PM Iain Sandoe wrote: > One small request, I realise that Python 2 is dead, but I regularly > bootstrap GCC > on older machines that only have Python 2 installations. If possible (and > it sounds > plausible if the job is really quite simple) - it would be good to support > those older > machines without having to take a detour to find a way to build Python 3 > on them first. > Would this really be an issue? Just as is the case for the gperf-generated files, the repository would contain the generated files and gperf/python would only be needed if someone changes those files or explicitly removes them.
commit signing
For my own projects I started /automatically/ signing all the git commits. This is so far not that important for my private projects but it is actually important for projects like gcc. It adds another layer of security to the supply chain security. My shell prompt (as many other people's as well) shows the current git branch but in addition also shows the validity of the signature if it exists. For this a file with the authorized keys needs to be provided. I found it easiest to use SSH keys for signing. One can create a new key for each project. If the desktop environment uses GPG daemon or something like that one doesn't even realize the signing request, it's handled automatically. git allows to set up signature handling on a per-project basis. I.e., no decision made for one project will have any impact on other projects. For painless operation all that is needed is that the authorized keys are published but that's not a problem, they are public keys after all. They can be distributed in the source code repository itself. My question is: could/should this be done for gcc? It's really easy to set up: - create new key: $ ssh-keygen -f ~/.ssh/id_ed25519_gcc -t ed25519 (of course you can use other key types) - configure your git repository. This has to be done for each git tree, the information is stored in the respective tree's .git/config file $ git config gpg.format ssh $ git config user.signingKey ~/.ssh/id_ed25519_gcc.pub $ git config commit.gpgsign true $ git config tag.gpgsign true If ssh-agent is not used then the user.signingKey must point to the private key but this is hopefully not the case for anyone. It's also possible to add the entire key to the configuration, which doesn't compromise security. It is possible to define global git configurations (by adding --global to the command lines) but this means the settings are shared with all the projects you work on. This can work but doesn't have to. - collect all maintainer's keys in a public place. There could be in the gcc tree a file 'maintainer-keys'. The file contains one line per key, the public key preceded by the respective email address. If this is the case use $ git config gpg.ssh.allowedSignersFile maintainer-keys At least the original git seems to be happy with relative paths (i.e., if the file is not at the toplevel an appropriate path can be added) Every maintainer then just has to remember to submit any newly created key as a patch to the 'maintainer-keys' file. That's it. The key creation ideally is a one-time effort. The git configuration is for everyone using the gcc git tree a once-per-local-repository effort (and can be scripted, the gcc repo could even contain a script for that). After this setup everything should be automated. Someone not interested in the signature will see no change whatsoever. Those who care can check it. Note, that github also has support for this in their web UI. CLI users can use $ git config log.showSignature true to have git display the signature state in appropriate places by default. If and when signatures are universally used one could think about further steps like restricting merges based on trust levels, add revocation lists, Or even refusing pushes without a valid signature. This would indeed mean a higher level of security. Opinions?
Re: commit signing
On Wed, Sep 14, 2022 at 1:31 PM Richard Biener wrote: > How does this improve supply chain security if the signing happens > automagically rather than manually at points somebody actually > did extra verification? It works only automatically if you have ssh-agent (and/or gpg-agent) running. I assume that's what developers do anyway because that's how they like push changes to sourceware. If you don't have an agent you'll have to provide the signature of the signing key at the time of the commit. What's the extra space requirement if every commit is signed? I suspect > the signatures themselves do not compress well. > The signatures are probably implemented as signed hashes of some sort. So, perhaps an additional SHA256 block plus infrastructure to determine the key used etc. I doubt that this is really measurable with today's disks and servers and network connections.
Re: commit signing
On Wed, Sep 14, 2022 at 2:07 PM Ulrich Drepper wrote: > On Wed, Sep 14, 2022 at 1:31 PM Richard Biener > wrote: > >> How does this improve supply chain security if the signing happens >> automagically rather than manually at points somebody actually >> did extra verification? > > > It works only automatically if you have ssh-agent (and/or gpg-agent) > running. I assume that's what developers do anyway because that's how they > like push changes to sourceware. If you don't have an agent you'll have to > provide the signature of the signing key at the time of the commit. > This was the last message I sent and no further questions or comments arrived. Shall I prepare a small patch with an initial version of the key files (with my key), perhaps a patch to the setup script Jonathan mentioned, and a few words to be added to a README or similar file (which?)? Initially this could be optional and we could gather data on the pickup and only after an initial period switch to make the signing mandatory.
