Joe Hershberger <joe.hershber...@ni.com> schrieb am Di., 17. Sep. 2019, 23:22:
> Hi Simon, > > On Sat, Sep 14, 2019 at 1:55 PM Simon Goldschmidt > <simon.k.r.goldschm...@gmail.com> wrote: > > > > Joe Hershberger <joe.hershber...@ni.com> schrieb am Sa., 14. Sep. 2019, > > 20:46: > > > > > On Sat, Sep 14, 2019 at 1:32 PM Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > On Sat, Sep 14, 2019 at 04:05:44PM +0200, Ondřej Jirman wrote: > > > > > Hi, > > > > > > > > > > On Fri, Sep 13, 2019 at 07:40:22PM -0500, Joe Hershberger wrote: > > > > > > Part of the env cleanup moved this out of the environment code > and > > > into > > > > > > the net code. However, this helper is sometimes needed even when > the > > > net > > > > > > stack isn't included. > > > > > > > > > > > > Move the helper to lib/net_utils.c like it's similarly-purposed > > > > > > string_to_ip(). Also rename the moved function to similar naming. > > > > > > > > > > > > Signed-off-by: Joe Hershberger <joe.hershber...@ni.com> > > > > > > Reported-by: Ondrej Jirman <meg...@megous.com> > > > > > > > > > > I've tested the patch and it works, but I'be found other related > > > issue, where > > > > > u-boot thinks %pM will format a MAC address string, but it does > just > > > > > print out the pointer due to relevant functions being gated by > > > CONFIG_CMD_NET > > > > > guard in lib/vsprintf.c. > > > > > > > > > > The gating should probably be done so that it panics/halts the > u-boot > > > if gated > > > > > pointer flags are used by u-boot code, because that will clearly be > > > incorrect, > > > > > without calling code ever knowing. This way the user will know that > > > something > > > > > is wrong and will have to fix the code. > > > > > > > > I'm not in favor of panic because of calling an unimplemented print > > > > format character. I guess we'll need to see what the size increase > is > > > > on un-guarding these formats and go from there. > > > > > > I'll look into it. I'm also not in favor of a panic. > > > > > > > In lwIP, we're using macros for such format characters. Would it work to > do > > that here and make the compiler complain about an undefined symbol of the > > macro for this extended format character isn't defined? > > Maybe... Though, if we don't successfully police the usage of the > macro, it won't help. I'd like to evaluate the code-size impact and > maybe just always include it. > Well, if you ensure the macro is only defined when the corresponding printf code is enabled, I guess it does help. Such macros might also help in the numerous cases where tiny printf doesn't understand a formatter in spl, but that's a different issue, although related. OTOH, here, always including it (unless compiling for tiny printf) might be ok as well... Regards, Simon > -Joe > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
