Re: Sourceware mitigating and preventing the next xz-backdoor
> > > > > I think the key difference here is that Autotools allows arbitrarily > generated code to be executed at any time. More modern build systems > require the use of specific commands/files to run arbitrary code, e.g. > CMake (IIRC [`execute_process()`][2] and [`ExternalProject`][3]), Meson > ([`run_command()`][1]), Cargo ([`build.rs`][4]).\ > > To me it seems that Cargo is the absolute worst case with respect to > supply chain attacks. > > It pulls in dependencies recursively from a relatively uncurated > list of projects, puts the source of all those dependencies into a > hidden directory in home, and runs Build.rs automatically with > user permissions. > 100% this. Wait until you learn how proc macros work.
Re: contracts library support (was Re: [PATCH] PING implement pre-c++20 contracts)
> Is just using std::terminate as the handler viable? Or if we're sure > contracts in some form will go into the IS eventually, and the > signature won't change, we could just add it in __cxxabiv1:: as you > suggested earlier. No, the handler needs to be configurable (at least quietly) in order to support experimentation by SG21. No idea if it will stay that way. Andrew
Re: [PATCH] PING implement pre-c++20 contracts
I think so, yes. On Fri, Jul 2, 2021 at 11:09 AM Jason Merrill wrote: > > On 7/1/21 12:27 PM, Andrew Sutton wrote: > >>> I think this version addresses most of your concerns. > >> > >> Thanks, looking good. I'll fuss with it a bit and commit it soon. > > Do you agree that this testcase should compile?
Re: [PATCH] PING implement pre-c++20 contracts
> > I think this version addresses most of your concerns. > > Thanks, looking good. I'll fuss with it a bit and commit it soon. Awesome! Andrew
Re: A suggestion for going forward from the RMS/FSF debate
> > > Of computer science graduates I have encountered over the last decade, I > > know few who started their journey with gcc and they were all in the > > initial part of the decade. In recent years I don't think I encountered > > any student who works on gcc; many even start with the assumption that > > gcc is in maintenance mode. > > For military focused PhDs, gcc is used. > Is this a real thing? I spent 15 year in academia (I left a few years ago), and I've never heard of a "military-focused PhD", especially in the context of computer science. I know of security-focused PhDs with intelligence applications, and I can imagine there are people out there working on AI/CV applications with military applications, but I think it's unlikely that those would require modifying a compiler. Applications in HPC might require deep compiler work and have potential military applications supporting AI/CV apps, but I wouldn't consider those "military-focused". I see things pretty much the same way as Siddhesh describes. > - Funding - llvm has a much stronger funding ecosystem than gcc. This > > includes direct funding from the foundation and development workforce > > from various organizations and universities. > > You will not get funding grants in the US if you mention free software, > because the US Department of Commerce does not allow it. > This is wildly inaccurate. Commerce has nothing to do with funding offered by other agencies. The NSF, which provides a significant portion of funding for CS research in the US, has embraced the release of research artifacts (read code) as open-source software. What's even better, the licensing on released work almost doesn't matter to the funding agency, unless they specifically enumerate limits and restrictions in their solicitations. For example, GCC's implementation of C++20 concepts was funded by NSF. I know because I was the postdoc funded to do that work. In fact, you can find NSF acknowledgments in the proposals I worked on. As a professor, I had NSF-funded work related to software-defined networking. All that code was also released open-source, albeit under an Apache or MIT license---I forget which. DoD and DoE almost certainly have restrictions. Corporate funding too, but I have less experience with those. Andrew
Re: Remove RMS from the GCC Steering Committee
Are you still responding to me? Your response reads like a thinly veiled threat. Angry friends on a jihad? Sounds serious. On Tue, Mar 30, 2021, 7:14 PM Christopher Dimech wrote: > > I have some friends in this movement who have been getting rather angry > recently. There is a lot of anger in the world, > in fact, in politics. Our political movement is not the only one > suffering from anger at the moment. But some of my angry > friends, have come to the conclusion that they’re on a jihad for free > software. > > That way won’t work. If a campaign of coercive compliance is carried just > a moment too far, willingness to use free > software among rational people will decline to a point which is dangerous > to freedom. > > - > Christopher Dimech > General Administrator - Naiad Informatics - GNU Project (Geocomputation) > - Geophysical Simulation > - Geological Subsurface Mapping > - Disaster Preparedness and Mitigation > - Natural Resource Exploration and Production > - Free Software Advocacy > > > *Sent:* Wednesday, March 31, 2021 at 9:55 AM > *From:* "Andrew Sutton" > *To:* "Christopher Dimech" > *Cc:* "Joseph Myers" , "GCC Development" < > gcc@gcc.gnu.org>, "Nathan Sidwell" > *Subject:* Re: Remove RMS from the GCC Steering Committee > Sorry for the confusion, but was this response directed to me? It seems > entirely unrelated to what I wrote. > > On Tue, Mar 30, 2021, 5:35 PM Christopher Dimech wrote: > >> >> Seriously. When you want something to happen within society, it is >> complex. Just >> because you want to push something - an ideology - you chant about it >> every day, >> does not mean things will go your way. >> >> Perhaps you can start donating money to Antifa! >> >> >> >> >> >> *Sent:* Wednesday, March 31, 2021 at 9:09 AM >> *From:* "Andrew Sutton" >> *To:* "Christopher Dimech" >> *Cc:* "Joseph Myers" , "GCC Development" < >> gcc@gcc.gnu.org>, "Nathan Sidwell" >> *Subject:* Re: Remove RMS from the GCC Steering Committee >> I guess I'll add my two cents. It seems everyone else is... >> >> I'm not a maintainer or frequent contributor, but I did implement >> concepts for C++, and I'd like to continue contributing, time permitting. >> My company (as in, I own it) also does some work on GCC, implementing new >> and experimental features like contracts, which we intend to upstream, >> pending review. Some modules-related stuff too (I hope). >> >> Maybe my response is a little different because I'm writing as a business >> owner and not a contributor. >> >> >> >> I understand that RMS is not actually on the steering committee and not >> an active contributor, and the SC web page should be updated to reflect >> that if it hasn't already. >> >> I agree with Nathan. >> >> The SC needs to be forward-looking --- you can't steer effectively if >> you're always looking in the rear-view mirror. My understanding is that GCC >> put RMS behind it a long time ago. And for the better. >> >> Part of the SC's job is (or should be) considering recruitment and >> retention for this community, including corporate participation. This idea >> that we have to somehow revere a person who has managed to make himself >> controversial for reasons entirely unrelated to his ideology on free >> software actively works against both of those goals. >> >> Undeniably so. If RMS were actually in the SC, I would have serious >> reservations about committing my employees time to this community. His >> documented behavior readily violates my company's code of conduct. At best, >> I'd risk burn out employees in a toxic environment. At worst, I could end >> up as a defendant in a sexual harassment case. And this 100% not hyperbole. >> >> (Thanks to everyone who makes GCC a good community to participate in.) >> >> I think it's perfectly reasonable for GCC to acknowledge RMS' past >> contributions, both ideological and code-wise, but it's time to move on. >> Nothing good comes from lionizing a man who purportedly asked teenage girls >> to eat candy out of his hand. >> >> >> >> On Tue, Mar 30, 2021, 2:14 PM Christopher Dimech via Gcc >> wrote: >> >>> >>> > Sent: Wednesday, March 31, 2021 at 5:45 AM >>> > From: "Joseph Myers" >>> > To: "JeanHeyd Meneide" >>> > Cc: "GCC Development" , "Nathan Sidwell" < >>> nat...@acm.org> >>> > Subject: Re: Remove RMS from the GCC Steering Committee >>> > >>> > On Tue, 30 Mar 2021, JeanHeyd Meneide via Gcc wrote: >>> > >>> > > So, it boils down to this for me: either GCC is a place where >>> all >>> > > contributions are welcome, or GCC is a place of hypocrisy, where >>> > > contributions are welcome except when Stallman (or someone else in a >>> > > position of power) lobbies a non-technical, non-factual argument >>> > > against you and jumps from their high tower to slam down on >>> > > rank-and-file contributors and participants. You cannot have it both >>> > > ways. >>> > >>> > All contributions are welcome. One of the key functions of the SC is >>> > actually
Re: [PATCH] implement pre-c++20 contracts
> > > > Attached is a new squashed revision of the patch sans ChangeLogs. The > > current work is now being done on github: > > https://github.com/lock3/gcc/tree/contracts-jac-alt > > I'm starting to review this now, sorry for the delay. Is this still the > branch you want me to consider for GCC 11? I notice that the -constexpr > and -mangled-config branches are newer. I think so. Jeff can answer more authoritatively. I know we had one set of changes to the design (how contracts) work aimed at improving the debugging experience for violated contracts. I'm not sure if that's in the jac-alt branch though. The -constexpr branch checks for trivially satisfied contracts (e.g., [[assert: true]]) and issues warnings. It also preemptively checks preconditions against constant function arguments. It's probably worth reviewing that separately. I'm not sure the -manged-config branch is worth considering for merging at this point. It's trying to solve a problem that might not be worth solving. Out of curiosity, are you concerned that future versions of contracts might have considerably different syntax or configurability? I'd hope it wouldn't, but who knows where SG21 is going :) Andrew
Re: [PATCH] implement pre-c++20 contracts
Hi Jason, Sorry I haven't been able to get back to this. I've been swamped with other work, and we haven't had the resources to properly address this. Jeff Chapman will be working on cleaning this up for when master/trunk re-opens. > I find the proposed always_continue semantics kind of nonsensical, as > somewhat evidenced by the contortions the implementation gets into with > marking the violation handler as pure. The trick of assigning the > result to a local variable won't work with optimization. We tend to agree and think it's practically non-implementable. IIRC, later contracts proposals steered away from adding this as a concrete semantic. I suspect killing this would be fine. > > +/* Definitions for C++ contract levels > > + Copyright (C) 1987-2018 Free Software Foundation, Inc. > > Should just be 2019 for a new file. Probably 2020 now :) > > + Contributed by Michael Tiemann (tiem...@cygnus.com) > > This seems inaccurate. :) Indeed :) > This change to member function redeclaration seems undesirable; your > rationale in P1680 is "for generality", but member functions are already > stricter about redeclaration than non-member functions; I don't see a > reason to relax this rule just for contracts. With member functions, > there *is* always a canonical first declaration, and people expect the > class definition to have its complete interface, of which contracts are > a part. There was a proposal that gave more motivation than just "for generality". Apparently, I was a co-author -- I think I just helped write the wording. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1320r2.html > For non-member functions, we still need to complain if contracts are > added after we've seen an ODR-use of the function, just like with > explicit specializations. We could do that, but it doesn't seem necessary with this model. Whether the contracts have been seen or not doesn't affect which function is called. > > + /* TODO is there any way to relax this requirement? */ > > + if (DECL_VIRTUAL_P (olddecl) && !TYPE_BEING_DEFINED (DECL_CONTEXT > > (olddecl))) > > Relatedly, I don't think we want to relax this requirement. Probably. Virtual functions and contracts have complex interactions. There are going to be more EWG papers about this, I'm sure. > > + /* FIXME Is this right for friends? Can a friend refer to a static > > member? > > + Can a friend's contracts refer to our privates? Turning them into > > + [[assert]]s inside the body of the friend itself certainly lets them > > do > > + so. */ > > P0542 says contracts are limited to the accessibility of the function > itself, so a friend cannot refer to private members. That will almost certainly be changed. This was the proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1289r0.pdf There was near-unanimous support for removing that (19 for, 1 against). Andrew
