From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 3B5D422B74 for ; Thu, 20 Jun 2024 07:30:03 +0200 (CEST) Received: from pb-smtp21.pobox.com ([173.228.157.53]) by 9front; Thu Jun 20 01:27:45 -0400 2024 Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id C54E234F9C for <9front@9front.org>; Thu, 20 Jun 2024 01:27:42 -0400 (EDT) (envelope-from me+unobe@fallglow.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=message-id :date:from:to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding; s=sasl; bh=hOLk4omTKU/eYGrgNCBkbcCoi BrQmXWbcCvV38hm/Bk=; b=JVsumtGy2jsOcL/zCclj/xnOIHol9N3BA5JyafH4X yeG8U82ZwfiAujwupVSmnowvLwUlTfvFq6N5tJUYv8ptLxv9UPDCAz1qCFn8SYaQ Ex33SjYRxjcM00v9sdhplfxEMiUpJw8zCi+vZrXc16Ix1BhpsCj0oe3RpsFywCXT 1U= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id B25B534F9B for <9front@9front.org>; Thu, 20 Jun 2024 01:27:42 -0400 (EDT) (envelope-from me+unobe@fallglow.com) Received: from strider.localdomain (unknown [97.131.41.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id 1344334F9A for <9front@9front.org>; Thu, 20 Jun 2024 01:27:39 -0400 (EDT) (envelope-from me+unobe@fallglow.com) Message-ID: Date: Wed, 19 Jun 2024 22:27:36 -0700 From: Romano To: 9front@9front.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: CF3389CA-2EC5-11EF-A2C9-DFF1FEA446E2-09620299!pb-smtp21.pobox.com List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: STM-based map/reduce session-aware storage Subject: Re: [9front] [PATCH] upas: allow send to parse e-mail descriptions like marshal Reply-To: 9front@9front.org Precedence: bulk On Wed Jun 19 15:55:59 -0700 2024, moody@posixcafe.org wrote: > On 6/18/24 13:05, Romano wrote: > > Ping. Here's a cleaned up patch: > > http://okturing.com/src/20104/body > > > > Similarly with the ramfs patch, any comments/concerns? > > The general idea seems fine I think. > I don't use upas, but I did find some > issues with the implementation purposed: > > +char * > Typical style is to make the return type 'char*' here Got it. So parameters and declarations look to have 'char *', but return types remove the space. > +userfrom(char *cp) > +{ > + char *s; > + int n; > + > + if((n = strlen(cp)) > 4 && cp[n-1] == '>'){ > + if((s = strrchr(cp, '<')) != nil && s != cp && isspace(s[-1])) { > + s++; > + cp[n-1] = '\0'; > + strcpy(cp, s); > > I don't love this loop, we're essentially walking the string three times here. > Once for the first strlen, again for strrchr, and a third time with the strcpy. > Because we return a pointer here we could get rid of this strcpy entirely and just > make this inner block two lines like so: > + cp[n-1] = '\0'; > + return s + 1; > > However at this point we'd still be walking the string twice. I wanted to see if > we could just walk the string once without having the code suck and this is what > I came up with: > > char* > userfrom(char *cp) > { > char *p, *e; > > if((p = strchr(cp, '<')) == nil) > return cp; > if(p == cp || !isspace(p[-1])) > return cp; > p++; > if((e = strchr(p, '>')) == nil) > return cp; > *e = '\0'; > return p; > } > > Not that the length is going to be super long here, but being a bit more efficient doesn't > make the code any more complicated (imo). I like it--easier to follow. Admittedly, I had cargo-culted from the marshal code (you link to below). I did that poorly. > Also I believe the commit message is incorrect given it's understanding of what > printform is doing. I pulled the code out to play with it, and from what I see > when it is given a "A name " it will print out the full thing, > not just the email. The point of this code seems to ensure that the "name" portion > of this description is passed through the rfc2047fmt function (installed as %U). > > /sys/src/cmd/upas/marshal/marshal.c:820 > Specifically prints both portions there, with the only difference from the default > case being that it passes the name through %U. > > So I think the description of what is going on in the commit message is not quite > correct either. Yeah, my description is flat out wrong. Is this better? /sys/src/cmd/upas/marshal/marshal.c:/^printfrom parses $upasname (or the login name) as an e-mail with description (e.g., "A Name ") to set the From: line. This does similarly for upas/send, but only parses the e-mail portion so that upasname='A name ' can be used to both set the From: in marshal with a description and to match the correct from in upas/send for sending via smtp. > Thanks, > moody Thank you for taking the time to give a better implementation (imo).