For instance, NV is whatever represents a number value (which is a type of scalar). Look at that subroutine, which is fairly straightforward C, but ignore the various types, which are Perl macros that stand in for the real thing. So, when sv.c calls Atof, it’s really calling my_atof, which is really Perl_my_atof. Sv.c: sv_setnv(sv,Atof(SvPVX_const(sv)) + 1.0) Sv.c: slot set, public IOK, Atof() unneeded. Sv.c: SvNV_set(sv, Atof(SvPVX_const(sv))) That’s how you see it in the rest of the code, mostly in sv.c, which is the code that tells scalar values how to be scalars: Now you’ve teased out that perl.h has another level of indirection by calling it Atof. After that entry in perl.h, embed.h has another level of indirection by getting rid of the Perl_ prefix, so if you look for my_atof:Įmbed.fnc:Ap |NV |my_atof |NN const char *sĮmbed.fnc:Ap |char* |my_atof2 |NN const char *s|NN NV* value # define Perl_atof2(s, n) ((n) = atof(s))įorget about the libc version and look at Perl’s internal versions. Otherwise, the source relies on whatever your libc provides (and that can be part of the problem if you have a broken libc): If USE_PERL_ATOF is defined (and it should be unless the person who compiled your perl turned it off with -DUSE_PERL_ATOF=0), then the Perl_atof* subroutines point to the internal ones. Look in there to see that the source figures out who gets to implement atof. There’s nothing exciting there, really, but notice the lines from perl.h. Proto.h:PERL_CALLCONV char* Perl_my_atof2(pTHX_ const char *s, NV* value) Proto.h:PERL_CALLCONV NV Perl_my_atof(pTHX_ const char *s) Perl.h:# define Perl_atof(s) Perl_my_atof(s) Numeric.c:Perl_my_atof2(pTHX_ const char* orig, NV* value) Numeric.c:Perl_my_atof(pTHX_ const char* s) Who uses these and what do they pass as arguments? Grep the repository:Įmbed.h:#define my_atof(a) Perl_my_atof(aTHX_ a)Įmbed.h:#define my_atof2(a,b) Perl_my_atof2(aTHX_ a,b) Now you have your first hook into the source code. Those might click as “ASCII to *” sorts of routines, in this case, ASCII to float. Scanning through that file (well, actually just looking at the subroutine list), you see a lot of names with atof in them. That’s seems the likely candidate for things that deal with numbers. Once you unpack the source, you should see a numeric.c in the top-level directory. You can download it from CPAN or clone its git repository as shown in perlrepository. Just what is perl doing? You’ll go a little code walk to find out.įirst, get the Perl source. I hadn’t previously investigated this issue, so I started as fresh as anyone else. You might also want to read Extending and Embedding Perl. If you want a quick tutorial in perl innards, see Perlguts Illustrated, although you won’t need it much for this item. I can tell you all sorts of stuff in Learning Perl or in the documentation, but the real answers are in the code. You’ll see how to skip the whole mess at the end, but be patient.Īlthough the perl source may seem like a scary place to go, if you know just a little C (and why don’t you?) it’s not that bad, especially for simple things like number conversions. This is related to the perlfaq answer to Why am I getting long decimals (eg, 19.9499999999999) instead of the numbers I should be getting (eg, 19.95)?, but a bit more involved. Why does 0.76178 come out differently than 7.6178E-01 When Perl stores them, they can come out as slightly different numbers. A recent question on Stackoverlow asked about the difference between the same floating numbers being stored in scientific notation and written out.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |