Oh, I see I made a mistake.  Your address confused me I thought I was
answering to Omar Polo.

On Mon, Aug 05, 2024 at 09:20:42AM +0200, Walter Alejandro Iglesias wrote:
> On Sun, Aug 04, 2024 at 05:40:37PM -0400, ori@eigenstate.org wrote:
> > Quoth Walter Alejandro Iglesias <wai@roquesor.com>:
> > > Now at last appears one and takes
> > > the simplest of my diffs and completely rewrite it.  What can I expect
> > > will happen to the rest of what I did? :-)
> > 
> > That's the point of review: for someone more exprienced with the
> > system to reshape the code into something they're happy to maintain.
> > 
> 
> Are you the one maintaining mail(1)?  If so, and if you are interested
> in these improvements, you could have done it yourself.  ;-)
> 
> 
> > Are you interested in the featurs, or are you more attached to the
> > code being untouched, the way you initially wrote it?
> > 
> > 
> 
> Features?  Attachment?  I'd cut my own arm if it bothers me!  My main
> concern about people is honesty, about software what gets the job done.
> 
> I *test everything*, what the professional and the amateur, the
> intelligent and the foolish tell me, the argument that seems solid and
> the one that sounds crazy.  And above all, what my intelligence,
> experience and creativity suggest to me.  My conclusions and my methods
> are the result of this learning process.  In this case, taking into
> account that this is not my home, and I am not an expert on the subject,
> trying to adapt, I listened to many pieces of advice and ideas only
> trying to make the developers of this project "happy".
> 
> Even if I were the worst C noob and half-brained considering that I have
> been trying this and that for almost a year, what I've done deserves
> more that *zero* credit.  Last year, I contacted you privately because
> you had been the only one who had expressed interest in my proposal, but
> when I had already moved on and discarded features of my original
> idea, for example the use of the (-m) option, you posted a patch that
> ignored my subsequent changes.  What we now see would have been a
> mistake.
> 
> Regarding the date() function I found out that NetBSD doesn't have a
> strftime_l() so if, as you said, portability is important, there's
> little difference between Sven's solution and mine.  What I assume
> should be portable is to simply do this:
> 
> size_t
> date(char *str)
> {
> 	struct tm newtime;
> 	time_t ltime;
> 	static char buf[32];
> 	size_t n;
> 
> 	setlocale(LC_ALL, "C");
> 
> 	ltime = time(&ltime);
> 	localtime_r(&ltime, &newtime);
> 	n = strftime(buf, sizeof(buf), "%a, %d %b %Y %T %z", &newtime);
> 	snprintf(str, sizeof(buf), "%s", buf);
> 
> 	return (n);
> }
> 
> At least under Linux, whatever they may use setlocale() in any other
> place in the code it won't affect this function.  However, this is not
> the first time I heard from a OpenBSD developer that it's better to
> avoid depending on locales (I'd appreciate some explanation about it.)
> If this and portability could be issues then your proposal is the option
> to follow.  But, given the complexity that comes with copyright, I don't
> know how far the balance tips one way or the other.  Which brings me to
> the following: as I've mentioned in other threads I've changed the
> function I originally wrote to generate the Message-ID to the one
> OpenSMTP uses (also trying to make OpenBSD developers "happy".)  If
> we're willing to keep this function, should we include it with date() in
> a same file, under the same copyright?  See?  This, and what I explained
> earlier about the '-m' option, suggests that doing things in chunks
> directly is error-prone and a waste of time, you need to look at and
> plan the whole idea first.
> 
> 
> -- 
> Walter