On Fri, May 01, 2020 at 10:37:48PM +0200, Martin Jambor wrote:
> On Fri, May 01 2020, Jeff Law wrote:
> >> I also find writing them useful as it forces me to go through every
> >> patch one last time before submitting it :-) If you spend some time
> >> configuring your text editor and git, the boil
On Fri, May 01, 2020 at 09:51:53AM -0600, Jeff Law wrote:
> On Thu, 2020-04-23 at 15:14 -0600, Tom Tromey wrote:
> > > > > > > "Segher" == Segher Boessenkool
> > > > > > > writes:
> >
> > Segher> My point was that this should *never* be part of patches, already.
> >
> > FWIW, I use a few script
Hi,
On Fri, May 01 2020, Jeff Law wrote:
> On Fri, 2020-04-24 at 22:01 +0200, Martin Jambor wrote:
>> Hi,
>>
>> On Fri, Apr 24 2020, Segher Boessenkool wrote:
>> > Hi!
>> >
>> > On Fri, Apr 24, 2020 at 05:48:38PM +0200, Thomas Koenig wrote:
>> > > > Of course, better would be to remove ChangeLog
On Fri, 2020-04-24 at 22:01 +0200, Martin Jambor wrote:
> Hi,
>
> On Fri, Apr 24 2020, Segher Boessenkool wrote:
> > Hi!
> >
> > On Fri, Apr 24, 2020 at 05:48:38PM +0200, Thomas Koenig wrote:
> > > > Of course, better would be to remove ChangeLogs entirely (including not
> > > > putting anything
On Thu, 2020-04-23 at 15:14 -0600, Tom Tromey wrote:
> > > > > > "Segher" == Segher Boessenkool writes:
>
> Segher> My point was that this should *never* be part of patches, already.
>
> FWIW, I use a few scripts so that I can keep ChangeLogs as files.
> That's what I do when working on gdb.
>
Hi!
On Fri, Apr 24, 2020 at 10:01:20PM +0200, Martin Jambor wrote:
> On Fri, Apr 24 2020, Segher Boessenkool wrote:
> > On Fri, Apr 24, 2020 at 05:48:38PM +0200, Thomas Koenig wrote:
> >> >Of course, better would be to remove ChangeLogs entirely (including not
> >> >putting anything like them into
Hi,
On Fri, Apr 24 2020, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Apr 24, 2020 at 05:48:38PM +0200, Thomas Koenig wrote:
>> >Of course, better would be to remove ChangeLogs entirely (including not
>> >putting anything like them into a commit message), because they are
>> >largely not useful and
Hi!
On Fri, Apr 24, 2020 at 05:48:38PM +0200, Thomas Koenig wrote:
> >Of course, better would be to remove ChangeLogs entirely (including not
> >putting anything like them into a commit message), because they are
> >largely not useful and are just make-work.
>
> I disagree. I find them quite usef
Of course, better would be to remove ChangeLogs entirely (including not
putting anything like them into a commit message), because they are
largely not useful and are just make-work.
I disagree. I find them quite useful.
> "Segher" == Segher Boessenkool writes:
Segher> My point was that this should *never* be part of patches, already.
FWIW, I use a few scripts so that I can keep ChangeLogs as files.
That's what I do when working on gdb.
https://github.com/tromey/git-gnu-changelog
This is easier on the whol
Hi!
On Thu, Apr 23, 2020 at 12:57:43PM -0400, Frank Ch. Eigler wrote:
> > *Nothing* should touch changelog files :-) They should be generated from
> > the
> > VCS. IMHO of course.
>
> IMHO: the VCS should be the changelog.
The VCS shows what changed. The changelog shows what was meant to be
On Thu, Apr 23, 2020 at 09:33:47AM -0600, Jeff Law wrote:
> On Thu, 2020-04-23 at 06:46 -0500, Segher Boessenkool wrote:
> > Hi!
> >
> > On Thu, Apr 23, 2020 at 12:54:04AM +, Tamar Christina wrote:
> > > but trains for GCC Will likely be very short because of Changelog
> > > conflicts.
> >
>
Hi -
> *Nothing* should touch changelog files :-) They should be generated from the
> VCS. IMHO of course.
IMHO: the VCS should be the changelog.
- FChE
It seems like this discussion doesn't have to be cc'ed to overseers. At
the very least it doesn't need to be cc'ed *twice* as someone who
apparently doesn't understand that gcc.gnu.org == sourceware.org has
cc'ed overseers in both domains.
So, I'd appreciate it if you all would please drop overse
On Thu, 2020-04-23 at 06:46 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Apr 23, 2020 at 12:54:04AM +, Tamar Christina wrote:
> > but trains for GCC Will likely be very short because of Changelog conflicts.
>
> Why that? Your patches should *not* touch changelog files, ever.
>
> For C
On Thu, 2020-04-23 at 09:34 +0100, Jonathan Wakely via Gcc wrote:
> On Thu, 23 Apr 2020 at 06:49, Florian Weimer wrote:
> > * Tamar Christina:
> >
> > > A bit late to the party, but this really doesn't work that well
> > > because until recent version of gitlab there was no fairness
> > > guarante
On Thu, Apr 23, 2020 at 12:56:20PM +0100, Jonathan Wakely wrote:
> On Thu, 23 Apr 2020 at 12:47, Segher Boessenkool
> wrote:
> > On Thu, Apr 23, 2020 at 12:54:04AM +, Tamar Christina wrote:
> > > but trains for GCC Will likely be very short because of Changelog
> > > conflicts.
> >
> > Why th
On Thu, 23 Apr 2020 at 12:47, Segher Boessenkool
wrote:
>
> Hi!
>
> On Thu, Apr 23, 2020 at 12:54:04AM +, Tamar Christina wrote:
> > but trains for GCC Will likely be very short because of Changelog conflicts.
>
> Why that? Your patches should *not* touch changelog files, ever.
>
> For CI it
Hi!
On Thu, Apr 23, 2020 at 12:54:04AM +, Tamar Christina wrote:
> but trains for GCC Will likely be very short because of Changelog conflicts.
Why that? Your patches should *not* touch changelog files, ever.
For CI it is probably easiest if the CI never gets to see the changelog
at all, an
> -Original Message-
> From: Florian Weimer
>
> * Tamar Christina:
>
> > A bit late to the party, but this really doesn't work that well
> > because until recent version of gitlab there was no fairness
> > guarantee. another patch could be approved after mine (with hours in
> > between
On Thu, Apr 23, 2020 at 09:34:20AM +0100, Jonathan Wakely via Gcc wrote:
> I've been having problems with it recently, e.g.
> https://gcc.gnu.org/g:e76100ced607218a3bf had to fix a changelog,
> because https://gcc.gnu.org/g:d76925e46fad09fc9be67 put my changelog
> entry in the wrong place in gcc/te
On Thu, 23 Apr 2020 at 06:49, Florian Weimer wrote:
>
> * Tamar Christina:
>
> > A bit late to the party, but this really doesn't work that well
> > because until recent version of gitlab there was no fairness
> > guarantee. another patch could be approved after mine (with hours
> > in between bec
On Thu, Apr 23, 2020 at 7:47 AM Florian Weimer wrote:
>
> * Tamar Christina:
>
> > A bit late to the party, but this really doesn't work that well
> > because until recent version of gitlab there was no fairness
> > guarantee. another patch could be approved after mine (with hours
> > in between
* Tamar Christina:
> A bit late to the party, but this really doesn't work that well
> because until recent version of gitlab there was no fairness
> guarantee. another patch could be approved after mine (with hours
> in between because of CI) and yet still get merged first causing my
> own patch
igler ; Frank Ch. Eigler ;
> Tom Tromey
> Subject: Re: Not usable email content encoding
>
> * Richard Biener:
>
> > On Thu, Mar 19, 2020 at 2:28 PM Florian Weimer
> wrote:
> >>
> >> * Tom Tromey:
> >>
> >> > Also, gerrit was pretty b
On Tue, Apr 14, 2020 at 10:38:12PM +0100, Maciej W. Rozycki wrote:
>Therefore I'd be happy to participate in testing a solution for
>disabling `From' munging for `p=none' domains.
I can't speak for fche but I have a limited amount of time for any
computer activity right now. A pinched nerve in my
On Tue, 14 Apr 2020, Christopher Faylor wrote:
> >I think that means that dmarc_moderation_action: "Munge From" can
> >simply be switched off then (at least I don't see which other headers
> >e.g. gcc@ is rewriting that would cause DMARC to scream; and if there
> >are any, then it would be better
On Mon, Apr 13, 2020 at 10:53:06PM +, Michael Matz wrote:
>On Mon, 13 Apr 2020, Christopher Faylor wrote:
>>On Wed, Apr 08, 2020 at 04:15:27PM -0500, Segher Boessenkool wrote:
>>>On Wed, Apr 08, 2020 at 01:50:51PM +, Michael Matz wrote:
On Wed, 8 Apr 2020, Mark Wielaard wrote:
>Earl
Hello,
On Mon, 13 Apr 2020, Christopher Faylor wrote:
> On Wed, Apr 08, 2020 at 04:15:27PM -0500, Segher Boessenkool wrote:
> >On Wed, Apr 08, 2020 at 01:50:51PM +, Michael Matz wrote:
> >>On Wed, 8 Apr 2020, Mark Wielaard wrote:
> >>>Earlier versions of Mainman2 had some issues which might a
On Wed, Apr 08, 2020 at 04:15:27PM -0500, Segher Boessenkool wrote:
>On Wed, Apr 08, 2020 at 01:50:51PM +, Michael Matz wrote:
>>On Wed, 8 Apr 2020, Mark Wielaard wrote:
>>>Earlier versions of Mainman2 had some issues which might accidentally
>>>change some headers. But the latest fixes make t
* Maciej W. Rozycki:
> On Tue, 7 Apr 2020, Christopher Faylor wrote:
>
>> >In a way that's amusing and just reinforces my p.o.v. that DMARC is
>> >bollocks.
>>
>> Not that it means anything but I agree 100%.
>>
>> It's like whoever made the "standard" just said "to hell with mailing
>> lists".
Hi!
On Wed, Apr 08, 2020 at 01:50:51PM +, Michael Matz wrote:
> On Wed, 8 Apr 2020, Mark Wielaard wrote:
> > Earlier versions of Mainman2 had some issues which might accidentally
> > change some headers. But the latest fixes make this possible. It is how
> > the FSF handles DMARC for various
Hello,
On Wed, 8 Apr 2020, Mark Wielaard wrote:
> On Tue, 2020-04-07 at 11:53 +0200, Florian Weimer via Overseers wrote:
> > Gmail can drop mail for any reason. It's totally opaque, so it's a
> > poor benchmark for any mailing list configuration changes because it's
> > very hard to tell if a pa
Hi,
On Tue, 2020-04-07 at 11:53 +0200, Florian Weimer via Overseers wrote:
> Gmail can drop mail for any reason. It's totally opaque, so it's a
> poor benchmark for any mailing list configuration changes because it's
> very hard to tell if a particular change is effective or not.
>
> Many mailin
On Tue, 7 Apr 2020, Christopher Faylor wrote:
> >In a way that's amusing and just reinforces my p.o.v. that DMARC is
> >bollocks.
>
> Not that it means anything but I agree 100%.
>
> It's like whoever made the "standard" just said "to hell with mailing
> lists".
Maybe they just didn't know of
On Tue, 7 Apr 2020, Christopher Faylor wrote:
> >Can we please switch it off? It's not like we really had a problem before
> >the switch to mailman.
>
> You can't really make statements like this which imply that you are
> aware of "problems" on sourceware when you're not a sourceware
> adminis
On Tue, Apr 07, 2020 at 03:56:09PM +, Michael Matz wrote:
>In a way that's amusing and just reinforces my p.o.v. that DMARC is
>bollocks.
Not that it means anything but I agree 100%.
It's like whoever made the "standard" just said "to hell with mailing
lists".
On Tue, Apr 07, 2020 at 03:13:53PM +, Michael Matz wrote:
>Can we please switch it off? It's not like we really had a problem before
>the switch to mailman.
You can't really make statements like this which imply that you are
aware of "problems" on sourceware when you're not a sourceware
admi
Hello,
On Tue, 7 Apr 2020, Frank Ch. Eigler wrote:
> > I find that unconvincing, because even googlegroup email lists don't
> > mangle From: from sender domains that are now mangled by sourceware.org
> > :-/
>
> It turns out receiving mail FROM google-groups mail is itself
> sometimes at risk
Hi -
> > A number of lists I'm on switched to our current style of minging a
> > year or two ago, because gmail users were not receiving mail, because
> > gmail was rejecting the mail.
>
> I find that unconvincing, because even googlegroup email lists don't
> mangle From: from sender domains tha
Hello,
On Tue, 7 Apr 2020, Jonathan Wakely via Gcc wrote:
> On Mon, 6 Apr 2020 at 23:00, Maciej W. Rozycki via Gcc
> wrote:
> > And can certainly score a positive though not a definite rating in spam
> > qualification. I don't think we ought to encourage bad IT management
> > practices by try
* Jonathan Wakely:
> On Mon, 6 Apr 2020 at 23:00, Maciej W. Rozycki via Gcc
> wrote:
>> And can certainly score a positive though not a definite rating in spam
>> qualification. I don't think we ought to encourage bad IT management
>> practices by trying to adapt to them too hard and hurting o
On Mon, 6 Apr 2020 at 23:00, Maciej W. Rozycki via Gcc wrote:
> And can certainly score a positive though not a definite rating in spam
> qualification. I don't think we ought to encourage bad IT management
> practices by trying to adapt to them too hard and hurting ourselves (our
> workflow) in
Hi!
On Mon, Apr 06, 2020 at 09:58:27PM +0100, Maciej W. Rozycki wrote:
> On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote:
> > > Out of curiousity, is this rewriting you are talking about the cause for a
> > > lot of mails showing up as "From: GCC List" rather than their real
> > > senders?
>
Hi Frank,
> > I am fairly sure it breaks `git am' too, requiring a `From' override in
> > the change description for author attribution in patch application to work
> > reliably (I tend to work on my outbox when applying my own patches, so I
> > avoid this issue, but I am sure the issue will h
Hi -
> [...]
> I am fairly sure it breaks `git am' too, requiring a `From' override in
> the change description for author attribution in patch application to work
> reliably (I tend to work on my outbox when applying my own patches, so I
> avoid this issue, but I am sure the issue will hit s
On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote:
> > Out of curiousity, is this rewriting you are talking about the cause for a
> > lot of mails showing up as "From: GCC List" rather than their real senders?
> > This has become very annoying recently.
>
> Yes, for emails from domains with dec
On Tue, 17 Mar 2020, Segher Boessenkool wrote:
> > I'm surprised it's an issue for you: normally your email client
> > would transform quoted-printable and copying would do the right thing
> > (i.e. select actual patch contents, without whitespace munging).
> >
> > Are you trying to copy from the
On Thu, Mar 19, 2020 at 02:58:55PM +0100, Florian Weimer wrote:
> * Richard Biener:
> > I guess if anything we'd want something git-centric now like github
> > or gitlab pull requests & reviews. The only complication is approval
> > then which would still mean manual steps.
>
> Gitlab has a “merg
On Thu, Mar 19, 2020 at 02:41:05PM +0100, Richard Biener wrote:
> I guess if anything we'd want something git-centric now like github
> or gitlab pull requests & reviews. The only complication is approval
> then which would still mean manual steps. Patch review would also not
> be publicly visibl
* Richard Biener:
> On Thu, Mar 19, 2020 at 2:28 PM Florian Weimer wrote:
>>
>> * Tom Tromey:
>>
>> > Also, gerrit was pretty bad about threading messages, so it became quite
>> > hard to follow progress in email (but following all patches in the web
>> > interface is very difficult, a problem sh
On Thu, Mar 19, 2020 at 2:28 PM Florian Weimer wrote:
>
> * Tom Tromey:
>
> > Also, gerrit was pretty bad about threading messages, so it became quite
> > hard to follow progress in email (but following all patches in the web
> > interface is very difficult, a problem shared by all these web UIs).
* Tom Tromey:
> Also, gerrit was pretty bad about threading messages, so it became quite
> hard to follow progress in email (but following all patches in the web
> interface is very difficult, a problem shared by all these web UIs).
What I found most disappointing was that the web interface doesn
> "Jonathan" == Jonathan Wakely via Gcc writes:
[gerrit]
Jonathan> I think it also only very recently gained the ability to group a
Jonathan> series of patches together, as it wants a single commit per review.
We tried gerrit for gdb for a while, and in the end decided to drop it.
The main
On Wed, Mar 18, 2020 at 11:30:22PM -0400, Christopher Faylor wrote:
>On Wed, Mar 18, 2020 at 06:44:15PM -0400, Frank Ch. Eigler wrote:
>>> N.B. the CC list has got too big and is causing posts to this thread
>>> to be held for moderator approval.
>>
>>Ah, can cycle through the lists and raise that
On Wed, Mar 18, 2020 at 06:44:15PM -0400, Frank Ch. Eigler wrote:
>> N.B. the CC list has got too big and is causing posts to this thread
>> to be held for moderator approval.
>
>Ah, can cycle through the lists and raise that limit.
>The default 10 is too low.
Didn't you have to lower that limit f
Hi!
On Wed, Mar 18, 2020 at 02:52:14PM -0700, Jim Wilson wrote:
> I'm one of the old timers that likes our current work flow, but even I
> think that we are risking our future by staying with antiquated tools.
It's not ancient tools, it is low-requirement generic tools, and
everyone can use that
Hi!
On Wed, Mar 18, 2020 at 06:33:08PM -0400, Frank Ch. Eigler wrote:
> > [...] We need to think about setting up easier ways for people to
> > submit patches, rather than trying to fix all of the MUAs and MTAs
> > in the world.
>
> Another related point. We are comingling email as a communicat
On Wed, 18 Mar 2020 at 22:45, Joseph Myers wrote:
>
> On Wed, 18 Mar 2020, Jonathan Wakely via Gcc wrote:
>
> > > Some git based projects are using gerrit.
> >
> > Which I looked into previously and decided I didn't like it. If I
> > recall correctly, gerrit has to "own" the repo, and so it's only
On Wed, 18 Mar 2020, Jonathan Wakely via Gcc wrote:
> > Some git based projects are using gerrit.
>
> Which I looked into previously and decided I didn't like it. If I
> recall correctly, gerrit has to "own" the repo, and so it's only
The glibc experiment with gerrit worked without it owning the
Hi -
> N.B. the CC list has got too big and is causing posts to this thread
> to be held for moderator approval.
Ah, can cycle through the lists and raise that limit.
The default 10 is too low.
- FChE
N.B. the CC list has got too big and is causing posts to this thread
to be held for moderator approval.
On Wed, 18 Mar 2020 at 21:54, Jim Wilson wrote:
>
> I'm one of the old timers that likes our current work flow, but even I
> think that we are risking our future by staying with antiquated tools.
> One of the first things I need to teach new people is now to use email
> "properly". It is a barrier
Hi, Jim -
> [gerrit etc.]
Good points.
> [...] We need to think about setting up easier ways for people to
> submit patches, rather than trying to fix all of the MUAs and MTAs
> in the world.
Another related point. We are comingling email as a communication
medium AND a commit transport mediu
I'm one of the old timers that likes our current work flow, but even I
think that we are risking our future by staying with antiquated tools.
One of the first things I need to teach new people is now to use email
"properly". It is a barrier to entry for new contributors, since our
requirements are
Hello,
On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote:
> > > The From: header rewriting for DMARC participants is something sourceware
> > > is doing now.
> >
> > Out of curiousity, is this rewriting you are talking about the cause for a
> > lot of mails showing up as "From: GCC List" rathe
Hi -
> > The From: header rewriting for DMARC participants is something sourceware
> > is doing now.
>
> Out of curiousity, is this rewriting you are talking about the cause for a
> lot of mails showing up as "From: GCC List" rather than their real senders?
> This has become very annoying recentl
On 3/18/20 3:22 PM, Frank Ch. Eigler via Gcc wrote:
The From: header rewriting for DMARC participants is something sourceware
is doing now.
Out of curiousity, is this rewriting you are talking about the cause for
a lot of mails showing up as "From: GCC List" rather than their real
senders? Th
Hi -
> [...] You're talking about rewriting or adding headers (where the
> former is Real Bad, no matter what DMARC wants to impose), but the
> suggestion is based on not rewriting the body. If the body
> (including attachtments) is rewritten any way then that simply is a
> bug. [...]
We're mix
Hi,
On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote:
> > > The key here is to realize that the raw message is not what you get
> > > back from the mailing list reflector, and also not the raw message
> > > that was sent by the sender. In this day of mta intermediaries,
> > > proxies, reflect
* Frank Ch. Eigler:
> Hi -
>
>> > The key here is to realize that the raw message is not what you get
>> > back from the mailing list reflector, and also not the raw message
>> > that was sent by the sender. In this day of mta intermediaries,
>> > proxies, reflectors, it may be time to revisit th
Hi -
> > The key here is to realize that the raw message is not what you get
> > back from the mailing list reflector, and also not the raw message
> > that was sent by the sender. In this day of mta intermediaries,
> > proxies, reflectors, it may be time to revisit that suggestion.
>
> But thes
* Frank Ch. Eigler via Gcc:
>> > Are you trying to copy from the raw message representation?
>>
>> Everyone trying to work with a patch (instead of just the email) always
>> is working with the raw message. Just patch < mbox or git-am mbox
>> for example.
>>
>> https://gcc.gnu.org/contribute
Hi!
On Tue, Mar 17, 2020 at 03:51:58PM -0400, Frank Ch. Eigler via Gcc wrote:
> > > Are you trying to copy from the raw message representation?
> >
> > Everyone trying to work with a patch (instead of just the email) always
> > is working with the raw message. Just patch < mbox or git-am mbox
Hi -
> > Are you trying to copy from the raw message representation?
>
> Everyone trying to work with a patch (instead of just the email) always
> is working with the raw message. Just patch < mbox or git-am mbox
> for example.
>
> https://gcc.gnu.org/contribute.html says
> It is strongly
On Mon, Mar 16, 2020 at 04:54:51PM +0300, Alexander Monakov via Gcc wrote:
> On Mon, 16 Mar 2020, Martin Liška wrote:
>
> > It's probably related to the following email tag:
> > Content-Transfer-Encoding: quoted-printable
> >
> > The format is problematic when copying a patch.
> > Email example:
On Mon, 16 Mar 2020 at 14:13, Martin Liška wrote:
>
> On 3/16/20 2:54 PM, Alexander Monakov wrote:
> > Are you trying to copy from the raw message representation?
>
> Exactly.
That's never been reliable.
On 3/16/20 2:54 PM, Alexander Monakov wrote:
Are you trying to copy from the raw message representation?
Exactly.
Martin
On Mon, 16 Mar 2020, Martin Liška wrote:
> It's probably related to the following email tag:
> Content-Transfer-Encoding: quoted-printable
>
> The format is problematic when copying a patch.
> Email example:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542053.html
I'm surprised it's an
* Martin Liška:
> It's probably related to the following email tag:
> Content-Transfer-Encoding: quoted-printable
>
> The format is problematic when copying a patch.
> Email example:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542053.html
This is a known issue in the redhat.com email i
Hi -
> I noticed some emails reaching gcc-patc...@gcc.gnu.org use the following
> quoting:
> It's probably related to the following email tag:
> Content-Transfer-Encoding: quoted-printable
This is not something that the mailing list system does. This
content-transfer-encoding comes from the ori
On 3/16/20 2:47 PM, Richard Earnshaw wrote:
This isn't new. It's usually the sender that controls that, though it's often
automatic in their email client.
Jakub told me that he sees:
Ten mail byl:
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
while the email reachin
On 16/03/2020 13:45, Martin Liška wrote:
Hello.
I noticed some emails reaching gcc-patc...@gcc.gnu.org use the following
quoting:
```
case UNGT_EXPR:
case UNGE_EXPR:
case UNEQ_EXPR:
+ case MEM_REF:
/* Binary operations evaluating both arguments (increment and
=0
Hello.
I noticed some emails reaching gcc-patc...@gcc.gnu.org use the following
quoting:
```
case UNGT_EXPR:
case UNGE_EXPR:
case UNEQ_EXPR:
+case MEM_REF:
/* Binary operations evaluating both arguments (increment and
=09 decrement are binary internally in GCC). */
84 matches
Mail list logo
