lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87y2h6urwe.fsf@nvidia.com>
Date:   Wed, 6 Jan 2021 14:16:49 +0100
From:   Petr Machata <petrm@...dia.com>
To:     Roi Dayan <roid@...dia.com>
CC:     <netdev@...r.kernel.org>, David Ahern <dsahern@...il.com>,
        Petr Machata <me@...chata.org>
Subject: Re: [PATCH iproute2] build: Fix link errors on some systems


Roi Dayan <roid@...dia.com> writes:

> On 2021-01-06 10:42 AM, Roi Dayan wrote:
>> 
>> On 2021-01-04 6:07 PM, Petr Machata wrote:
>>>
>>> I think that just adding an unnecessary -lm is more of a tidiness issue
>>> than anything else. One way to avoid it is to split the -lm deps out
>>> from util.c / json_print.c to like util_math.c / json_print_math.c. That
>>> way they will be in an .o of their own, and won't be linked in unless
>>> the binary in question needs the code. Then the binaries that do call it
>>> can keep on linking in -lm like they did so far.
>>>
>>> Thoughts?
>>>
>> ok fine by me.
>
> I looked at this and for get_size()/rate/.. it went smooth.
> but for print_color_size() there is an issue that it uses
> _IS_JSON_CONTEXT and statuic *_jw which are defined in json_print.c
> Is it ok to expose those in json_print.h now so json_print_math.c
> could use?

You don't need json_print_math.h IMHO, it can all be backed by the same
header, just different implementation modules. From the API point of
view, I don't think the user should really care which of the symbols use
math (though of course they will have to know whether to link in -lm).

Regarding the publishing, the _jw reference can be changed to a call to
is_json_context(), which does the same thing. Then _jw can stay private
in json_print.c.

Exposing an _IS_JSON_CONTEXT / _IS_FP_CONTEXT might be odd on account of
the initial underscore, but since it's only used in implementations,
maybe it's OK?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ