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. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
