On 11 October 2017 at 17:51, Jakub Jermář <[email protected]> wrote: > On 10/11/2017 05:28 PM, Jiří Zárevúcky wrote: >> 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. > > Either that or or a non-legacy name, but no sys/*, please. >
Ok, I'll change it to <helenos/types.h> for now. I suggest we make it a point to discuss future naming directions on the next HelenOS meeting. :) -- jzr _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
