Dear Chris, In message <cafoyhzdk+cos-1odjscbf7otertzmgbgbhrc+wsrg4c5ito...@mail.gmail.com> you wrote: > > > The old code was forgiving and would accept 192,168,1,2 as well. > > Technically you can't enter that. The env_flags.c code prevents that > from being added to environment variables that have been tagged as ip > addresses. These patches are pushing the logic down a bit further. The > code handling env_flags_vartype_ipaddr could be updated to use > string_to_ip instead.
I'm not 100% sure about that. U-Boot environment is a complex thing. For example, what happens if we use "env import" to import variable settings from text or binary formats? Are all these checks present then, too? [Sorry for asking, I really don't know.] > > Also, at least crtitical parts of the network code (NFS, TFTP) do not > > check the return value of string_to_ip() - so what is the benefit of > > this change? > > > > The reasoning behind this change is to prepare for parsing ipv6 > addresses, which can contain ipv4 format addresses provided they are > at the end. > > e.g. This is a valid ipv6 address "::ffff:192.168.1.1" and so is > "::ffff:0192:0168:0001:0001" but the former triggers the ipv4 mapping > logic. Ah, I see. Makes sense. Should we add error handling to TFTP and NFS, then? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The world is coming to an end -- save your buffers! _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
