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