> > Hm. > > > > If you're porting a whole standard C library to EDK2 then I suppose it > > makes sense to build up all this infrastructure for it. > > > > But in this case when it's only the single inet_pton() function that > > you need, perhaps it makes more sense to 'port' that one function to > > UEFI (or just reimplement it looking like EDK2 code), instead of > > bringing all this stuff along with it? > > I didn't want to take responsibility for touching any of that code -- I > wanted it to be a piece of the puzzle that we'd just drop in. Its coding > style is very foreign to edk2 norms, so once we started, we wouldn't > stop before rewriting it more or less completely. (For example it quite > frequently consumes the values that assignment expressions evaluate to, > which is a huge no-no in edk2, as far as I understand.) I have no > capacity for such a rework (or additional ownership / responsibility), > sorry. > > I worked from Friday evening to Saturday ~6-7AM as my "second sprint" on > this code and its testing, until I was satisfied with the test coverage. > I apologize but I simply cannot repeat that. This is all I can > contribute code-wise (and testing-wise) to fixing this issue.
Jian, do you think it makes sense to keep the exiting coding style of inet_pton() in edk2\CryptoPkg\Library\BaseCryptLib\SysCall? (Personally, I can accept that). > > Thanks > Laszlo > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49576): https://edk2.groups.io/g/devel/message/49576 Mute This Topic: https://groups.io/mt/37952588/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-