> MS Windows CE doesn't provide strdup(), so where should I put it? I guess I > should just compile in Python/strdup.c, right? Right. > However, where should I declare it? I recommend pyport.h. > Also, there is HAVE_STRDUP. I would actually expect that #undef HAVE_STRDUP > would do the trick to at least declare this, but it doesn't. I guess that > most modern OS have this so this will probably just be bitrot ... right? Wrong, I think. The macro is a side effect of AC_REPLACE_FUNCS, which will a) add strdup.c to the list of files to compile, or b) define HAVE_STRDUP. > BTW: there is another implementation (called my_strdup) in > Modules/_ctypes/_ctypes_test.c, why not use the one in Python/strdup.c there? I guess that's historical, from the times when ctypes was still a separate package. > First difference is that I wouldn't accept NULL as valid input, e.g. the glibc > implementation doesn't either and GCC even warns you if you call > strdup(NULL). Secondly, I would have used memcpy(), since the length is > already known and then potentially quicker. Should I write a patch? Is that really worth it? It works as-is, doesn't it? Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4