On 15 November 2017 at 17:09, Jakub Jermář <ja...@jermar.eu> wrote:
> On 11/15/2017 04:43 PM, Jiří Zárevúcky wrote:
>> On 15 November 2017 at 16:36, Jakub Jermář <ja...@jermar.eu> wrote:
>>> On 11/15/2017 04:21 PM, Jiří Zárevúcky wrote:
>>>>> Out of curiosity, which C89-only code is being compiled against libposix?
>>>>>
>>>>
>>>> libuv compiles as C89. It would probably work just fine as C99, but as 
>>>> restrict
>>>> shows, compatibility between different C revisions is not a 100% thing, so
>>>> I'd rather fix the headers once, than review and patch each legacy codebase
>>>> individually. We don't have many ports right now, but as our libraries 
>>>> improve,
>>>> that should change. ;)
>>>
>>> I don't like that a third-party C89 lib is forcing compromises onto
>>> HelenOS. I think the effort should go in the opposite direction: make
>>> things compatible with HelenOS (and the standards it uses) rather than
>>> making HelenOS compatible with whatever limitations third-party code can
>>> impose.
>>>
>>
>> 1. How is this a compromise?
>
> It is a compromise / concession by virtue of forcing HelenOS to stop
> using a standard language construct in favor of a non-standard one even
> though there is no other reason to do that.
>

That's argument from arbitrary vocabulary definitions. Being "non-standard" in
this case doesn't have any effect on outcomes of any circumstances.
There is no situation where "__restrict__" instead of "restrict" would
inconvenience
anyone, whether the opposite is very obviously true.

>> 2. By that logic, we should delete libposix and never even consider
>> the possibility of building existing POSIX code.
>
> If that stopped at the line drawn by libposix, I would not object. But
> here it is creeping into our libc.
>

libposix and libc are not completely separate. If they could be treated as
independent, then there would be no "creeping". They are not. It does
not make sense for them to be. Again, extra work for no benefit at all.

>> I mean, you are proposing that a lifetime of patching old codebases is
>> preferable
>> to a single one-minute change with literally no downsides. That outright
>> contradicts the principle of least insanity.
>
> No. I would suggest compiling libuv with a more modern standard (there
> are GitHub issues and tickets suggesting c99 should be possible). If it
> is possible, problem solved. Otherwise I would prefer to move libuv
> forwards rather than moving HelenOS backwards or sideways.
>

I'm trying to do the most work done with the limited time and resources I
have available. Reviewing any prospective ports for language revision
change is not a productive use of time.

_______________________________________________
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Reply via email to