[PATCH] Refactor mktime and add the POSIX function timegm

[Brian Inglis]

On 2021-05-03 10:23, R. Diez wrote:
>> [...]
>> Don't see where *non-inline* static functions and trivial renames are 
>> improvements over macros.
>> [...]

> Like I said, I did not write the code, I only manually reconstructed the last 
> patch version from Andrew Russell.
> I was under the impression that the patch had already been reviewed, at least up 
> to a point. It was by no means the first patch version posted.
> But, if there is some sort of consensus here, I could rework the patch.

>> It may have been better to compare against the upstream BSD (or tzcode) sources
>> [...]

> That means extra work. Do you have any reason to suspect that the existing code 
> is wrong in some way? Or do you know whether the code in Newlib is actually 
> supposed to track some BSD or tzcode source? There is no source code comment to 
> that respect, and the code in other libraries will probably have diverged by now.
> 
> Unless you volunteer and/or specify concrete reasons, I would assume that the 
> existing implementation in Newlib is fine, so a small refactor in order to 
> provide timegm() is probably the best solution. Such a patch is also easier to 
> review than bringing in new or further modified code from an external source.

My comments are for your and the committers' consideration.

I previously commented on patches after comparing some source files against BSD 
(licence) and tzcode (public domain) upstreams and found them line-by-line 
similar mostly: it's been a while and details are now fuzzy.

Some amounts of newlib code are pulled or adapted from BSD sources, as the 
licences allow commercial use, and newlib is used in RTEMS and development 
products offered by hardware and RT OS vendors.
As you may have noticed, there are not always a lot of comments in sources.

Such a substantial patch will also require a BSD licence assignment, but given 
that it is an adaptation of another's work, I am unsure where that leaves it.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]