On 11 October 2017 at 17:16, Jakub Jermář <[email protected]> wrote: > > 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. >
Then we disagree what it actually means. By my interpretation, it means that if we have a function named "read", and POSIX has a function named "read", then they should have identical semantics, and be defined in the same place. When you already have a function named "read" that intrinsically has identical semantics to the "read" in POSIX, I don't see the value of inventing new headers and renaming the functions just for the sake of not using the same name. The problem with our headers is where they define the same name with the same intent purpose, but are not drop-in compatible. That's where problems happen. If we need a header for "system types", why would you prefer to create a completely different header that is intrinsically the same thing? <sys/types.h> is easily discoverable, easily understandable, and the contents is not incompatible with POSIX (types with same name have same semantics). I could understand if the motivation was to not polute namespace for actual posix users (e.g. via libposix), but since you proposed moving the types to <inttypes.h>, that's obviously not your concern. -- jzr _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
