"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
>> 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
>> 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
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