Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22])
	by mail.sr.ht (Postfix) with ESMTPS id D58F4400DF
	for <~emersion/mrsh-dev@lists.sr.ht>; Wed, 30 Jan 2019 08:16:55 +0000 (UTC)
Authentication-Results: mail.sr.ht;
	dkim=pass (1024-bit key) header.d=emersion.fr header.i=@emersion.fr header.b=cMtw2Ggk
Date: Wed, 30 Jan 2019 08:16:33 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emersion.fr;
	s=protonmail; t=1548836195;
	bh=DlS4nQGm1M/Z6JrKeQvPconaHnfgmnrvzyIT9m1ebbY=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	 Feedback-ID:From;
	b=cMtw2Ggkl9/FUemFfMnwfHfectXXATbgs5jAPIXxVLMrAJBmNNNaThBHhNHfdSeKC
	 wyyLzBJxeLu2sy/zx28u/94kGwno1nmGoIH7qvgjlxXHEAhvVQ4nmd92j6KACy4MbD
	 4nmTTDDGxOG9u90cV/PJNqZPIi7b8rbfyi6FpziQ=
To: Cristian Ontivero <cristianontivero@gmail.com>
From: Simon Ser <contact@emersion.fr>
Cc: "~emersion/mrsh-dev@lists.sr.ht" <~emersion/mrsh-dev@lists.sr.ht>
Reply-To: Simon Ser <contact@emersion.fr>
Subject: Re: [PATCH v2] Parse arithmetic expressions with shifts
Message-ID: <gFhFagtIrfSiLWCJK75hpXbfwoHTnGGXj_OKB7KaoehbSJa6mkUP32yLWP8t-TIlXUOURW1OM_SusCXClleyaoXAzDsSxe87s9OGMsSSQ-0=@emersion.fr>
In-Reply-To: <CALvFPysnBQn=1ADtJHnXgj-n-pWGBS631smtWH=_o_j7zeAprw@mail.gmail.com>
References: <20190125085755.5290-1-cristianontivero@gmail.com>
 <U7ts9Yh_Z3XOiaWl6AhxSN67-FxIMtbaYeTlvyyyw5DQAS4ikfnS4TYaWhLzU3L__Qchoi8zRWD-ikFm8bmHtmYtoDUqVmfVKpSKHCpQSn0=@emersion.fr>
 <CALvFPysnBQn=1ADtJHnXgj-n-pWGBS631smtWH=_o_j7zeAprw@mail.gmail.com>
Feedback-ID: FsVprHBOgyvh0T8bxcZ0CmvJCosWkwVUg658e_lOUQMnA9qynD8O1lGeniuBDfPSkDAUuhiKfOIXUZBfarMyvA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF autolearn=ham
	autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.protonmail.ch

On Monday, January 28, 2019 10:24 PM, Cristian Ontivero <cristianontivero@g=
mail.com> wrote:
> > Is there anything that prevents this from being merged?
>
> Not really, as far as I could test, it all works, but I wanted to get
> your opinion on it first.

Pushed, with a minor fix:

To git.sr.ht:~emersion/mrsh
   a0141f7..7b4f77f  master -> master

Thanks!

> > Nitpick: the convention I've used so far is to use the `_func` prefix
> > for function types.
>
> My bad, I realized after sending the patch. But now that you mention it, =
I had
> something I wanted to bring up for discussion: the suffix currently used =
is
> `func_t`, but POSIX reserves the `_t` suffix (for a discussion, see
> for instance:
> https://stackoverflow.com/a/231807/3599459 ). Ultimately, I'll follow wha=
tever
> naming convention you see fit, but I wanted to know if you had some parti=
cular
> reason for disregarding that.

Oh, I wasn't aware of this. Hmm, that's a little annoying. I like adding _t
suffixes to make the difference between a type name and a function name or =
a
variable name. I've been doing this because many, many other libraries do s=
o
too (wayland, pixman, etc). But I guess "everybody cheats" is not a good
enough excuse!

I'd be okay with merging a patch that s/_func_t/_func/ though. I don't type=
def
other types like structs, so these should be the only problematic cases.