"Joachim Schmitz" <j...@schmitz-digital.de> writes: > I haven't found any other to be needed. Well, poll, maybe, but with only > minor tweaks for the win32 one works for me (and those tweaks are compatible > with win32 > >> A separate file, compat/tandem/mkdir.c, is fine, though.
If you wouldn't have dozens of them, so compat/tandem/mkdir.c is not suitable; compat/tandem.c would be good, then. >> > I'll go for git_mkdir(), similar to other git wrappers, (like for >> > mmap, pread, fopen, snprintf, vsnprintf, qsort). >> >> Again, no. Your breakage is that having underlying system mkdir that does > not >> understand trailing slash, which may not be specific to __TANDEM, but > still is >> _not_ the only possible mode of breakage. > > Well, it is the only one GNUlib's mkdir caters for and I'd regard that an > authoritative source... I suspect that you may be misunderstanding what compat/ is about, so let's try again. Platform difference in mkdir may not be limited to "on this platform, the underlying one supplied by the system does not like path ending with a slash". What I am saying is that it is unacceptable to call something that caters to that specific kind of difference from what the codebase expects with a generic name such as "git_mkdir()". Look at mingw's replacement. The platform difference over there is that the one from the system does not take mode parameter. Imagine that one was already called "git_mkdir()". Now we have two different kind of differences, and one has more officially-looking "git_mkdir()" name; yours cannot take it---what would you do in that case? Neither kind of difference is more officially sanctioned difference; don't call yours any more official/generic than necessary. Your wrapper is not limited to tandem, but is applicable to ancient BSDs, so it is fine to call it as compat_mkdir_wo_trailing_slash(), so that it can be shared among platforms whose mkdir do not want to see trailing slashes. If you are going that route, the function should live in its own file (without any other wrapper), and not be named after specific platform (should be named after the specific difference from what we expect, instead). I am perfectly fine with that approach as well. >> Squatting on a generic "git_mkdir()" name makes it harder for other people > to >> name their compat mkdir functions to tweak for the breakage on their >> platforms. The examples you listed are all "the platform does not offer > it, so >> we implement the whole thing" kind, so it is in a different genre. > > Nope, git_fopen() definitly is a wrapper for fopen(), as is git_vsnprintf() > for vsnprintf(). I was talking more about mmap() and pread(). For the two you mentioned, ideally they should have been named after the specific breakages they cover (fopen that does not error out on directories is primarily AIX thing IIRC, and snprintf returns bogus result are shared between HPUX and Windows), but over these years we haven't seen any other kind of differences from various platforms, so the need to rename them away is very low. On the other hand, we already know there are at least two kinds of platform mkdir() that need different compat/ layer support, so calling one "git_mkdir()" to cover one particular kind of difference does not make any sense. Besides, an earlier mistake is not a valid excuse to add new mistakes. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
