[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH



On Sun, Aug 04, 2019 at 01:40:32PM +0200, Gero Treuner wrote:
> Hi
> 
> On Sun, Aug 04, 2019 at 01:18:12PM +0200, Hilmar Preuße wrote:
> > > Note: Patch was made against the Buster version
> > > (texlive-bin-2018.20181218.49446).
> > > 
> > That's fine. In Debian unstable we had just an offset of 30 lines.
> > I applied the patch, compiled the binary and can confirm that is solves
> > the problem.
> 
> Great.
> 
> > > I'm not a Debian developer/maintainer, so please check and adopt it 
> > > according all your procedures (including QA).
> > > 
> > Our coding styles are described here [1]. The only adaption I found was:
> > 
> > Variable declarations
> > .....................
> > The declaration of global variables follows analogous rules: they are
> > either declared 'static' if used in only one file or declared 'extern'
> > in exactly one header and instantiated in exactly one file.
> > 
> > --> As far as I can see your new variable is only one time used in the
> > mpost code, hence I declared it to be static. Do you agree here?
> 
> > [1] https://github.com/debian-tex/texlive-bin/blob/master/README.6coding
> 
> The variable is not global, but local to the function which means that
> memory is allocated on the stack and automatically freed by return from
> the function. Declaring it static would make the variable implicitely
> global (and non-reentrant by the way, but not relevant here because
> getenv() isn't reentrant anyway).

I verified my assumption that the whole program is not designed for
multi-threading: No signs of threading functions or threading library
(only in configure stuff, which would support it but unused here).
In code the word "thread" is used with other meanings.

Also getenv() is used in other places.

==> all fine

> 
> The variable should remain local, so left as-is without further
> declaration.
> 
> With coding style I slightly adjusted to what I found by inserting a
> space after the cast statement. It is best to match the style of the
> code surround for readabality.

Kind regards,
   Gero


Reply to: