![](https://secure.gravatar.com/avatar/6d83e3f814bb74934be46eabe1b60d70.jpg?s=120&d=mm&r=g)
Hi all, Anyone knows why pypy.module._file.readinto uses a locally defined ‘os_read’ rather than rpython.rlib.rposix.c_read? It seems that the functions are defined almost the same way, except one uses rffi.CCHARP the other uses rffi.VOIDP, and the rposix.c_read has a more complete ExternalCompilationInfo. Whilst this doesn’t pose any problem to C backend, it does cause a small trouble in my Mu VM backend, as the two external functions have deemed different even though they are the same, thus causing a name conflict. The fix is simple in either case: use c_read in _file.readinto, or I just add a small hack in my backend. But I’d like to know why this is the case in the first place, is there a special reason for it? Regards, John Zhang ------------------------------------------------------ John Zhang Research Assistant Programming Languages, Design & Implementation Division Computer Systems Group ANU College of Engineering & Computer Science 108 North Rd The Australian National University Acton ACT 2601 john.zhang@anu.edu.au<mailto:john.zhang@anu.edu.au>
![](https://secure.gravatar.com/avatar/779e1633fecdd62c4c386fc953c5d3ec.jpg?s=120&d=mm&r=g)
Hi John, On 18 January 2017 at 01:20, John Zhang <John.Zhang@anu.edu.au> wrote:
Anyone knows why pypy.module._file.readinto uses a locally defined ‘os_read’ rather than rpython.rlib.rposix.c_read?
I think it's only because rposix.c_read is supposed to be private. But yes, if it makes your life easier we can as well call it anyway from pypy.module._file.readinto. Maybe you should open a pull request. A bientôt, Armin.
participants (2)
-
Armin Rigo
-
John Zhang