On 11 October 2017 at 17:16, Jakub Jermář <[email protected]> wrote: > On 10/11/2017 04:51 PM, Jiří Zárevúcky wrote: >> On 11 October 2017 at 08:17, Jakub Jermář <[email protected]> wrote: >>> Hi Jiri, >>> >>> On 10/11/2017 04:04 AM, Jiří Zárevúcky wrote: >>>> On Oct 11, 2017 12:09 AM, "Jakub Jermář" <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi jzr, >>>> >>>> > [...] >>>> > Added: >>>> > uspace/lib/c/include/sys/types.h >>>> >>>> This commit reintroduces a POSIX header file (at least by name) which I >>>> removed a couple of months back. Any evil intentions? >>>> >>>> >>>> Yes, yes, much evil. I plan to move some of the awful copypasta from >>>> libarch into generic headers, and this is the first part of that. I'll >>>> write more about further evildoing in another mail, since I can't fall >>>> asleep. >>> >>> I am obviously not against reorganization, but against using names of >>> POSIX headers. Note that sys/types.h is pure POSIX, not even C11, and >>> there is no (well, shouldn't be) place for POSIX in the mainline. >> >> I don't understand this sentiment. Rejecting anything that's in POSIX >> just because it's in POSIX and "we aren't POSIX" sounds like a highly >> counterproductive way of thinking. >> >> Also, it begs the question: where do we put ssize_t? ssize_t is pure >> POSIX, and it's defined in <sys/types.h> and <unistd.h> headers, both >> of which are pure POSIX. Should we remove it entirely? >> >>> Can you, please, rework this and rename the current sys/types.h into >>> something else? How about C11 inttypes.h or even something completely >>> HelenOS specific, if inttypes.h is not suitable? >>> >> >> So, you reject the idea of using a header name that's the same as one >> in POSIX, and propose that instead we deliberately pollute standard C >> headers with definitions that aren't supposed to be in them? I fail to >> see the logic. >> >> Regardless, I'm open to suggestions. As far as I know, >> <libarch/types.h> defined a bunch of standard types along with a bunch >> of nonstandard types like sysarg_t etc. The standard types are >> obvious, but where do we put the nonstandard ones? I won't even >> entertain the idea of putting them in stdc headers just for the sake >> of not using a "POSIX header". That's just ridiculous. > > The problem with sys/ is that it creates false expectations of POSIX > compatibility. And people have tendency to add more. We've already had > sys/mman.h, sys/types.h, sys/stat.h and maybe more. My objection against > it is that it makes it harder, not easier, to arrive at a clean > separation between HelenOS-specific, C11-specific and POSIX code. As for > ssize_t, we can say that we reinvented it. It makes sense. But why does > types.h have to live in sys/? Because it lives there in POSIX systems? > > There is objectively no reason why introduce new POSIX names that do not > even carry POSIX-compliant content. As you may know, there is now a > doctrine in the HelenOS community against naming things in this way > (reusing standard names for non-standard purposes) and a general trend > to fix the existing instances. > > Just pick a different name outside of the sys/ directory that does not > allude to being compliant with anything, if a better name cannot be found. >
If you are concerned about giving an impression of supporting something we don't (and I don't think that even applies here), I'd suggest that the only way to achieve that is to put everything HelenOS specific into <helenos/...> subdirectory. -- jzr _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
