Re: [HelenOS-devel] What is wrong with restrict parameters?

2017-11-15 Thread Jiří Zárevúcky
On 15 November 2017 at 17:09, Jakub Jermář  wrote:
> On 11/15/2017 04:43 PM, Jiří Zárevúcky wrote:
>> On 15 November 2017 at 16:36, Jakub Jermář  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


Re: [HelenOS-devel] What is wrong with restrict parameters?

2017-11-15 Thread Jakub Jermář
On 11/15/2017 04:43 PM, Jiří Zárevúcky wrote:
> On 15 November 2017 at 16:36, Jakub Jermář  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.

> 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.

Jakub

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


Re: [HelenOS-devel] What is wrong with restrict parameters?

2017-11-15 Thread Jiří Zárevúcky
On 15 November 2017 at 16:36, Jakub Jermář  wrote:
> Hi Jiri,
>
> 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.
>

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.

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


Re: [HelenOS-devel] What is wrong with restrict parameters?

2017-11-15 Thread Jakub Jermář
Hi Jiri,

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.

Jakub

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


Re: [HelenOS-devel] What is wrong with restrict parameters?

2017-11-15 Thread Jiří Zárevúcky
On 15 November 2017 at 15:59, Vojtech Horky  wrote:
> 2017-11-15 15:49 GMT+01:00 Jiří Zárevúcky :
>> On Nov 15, 2017 15:20, "Ondřej Hlavatý"  wrote:
>>> strictly speaking, couldn't you define "restrict" a macro in the same
>>> way then? ;)
>> You couldn't. "restrict" is a legal identifier in C89, and existing code can
>> use it e.g. as a regular variable/function name. Identifiers starting with
>> two underscores are reserved, so the same problem doesn't apply for
>> __restrict__.
> Makes sense, thanks! Should be probably stated in the commit message ;-)
>

Yes it should. :) It didn't occur to me at the moment.

> 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. ;)

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


Re: [HelenOS-devel] What is wrong with restrict parameters?

2017-11-15 Thread Jiří Zárevúcky
On Nov 15, 2017 15:20, "Ondřej Hlavatý"  wrote:

Hi,

strictly speaking, couldn't you define "restrict" a macro in the same
way then? ;)


You couldn't. "restrict" is a legal identifier in C89, and existing code
can use it e.g. as a regular variable/function name. Identifiers starting
with two underscores are reserved, so the same problem doesn't apply for
__restrict__.




On 15.11., Jiří Zárevúcky wrote:
> Hi,
>
> the reason is that "restrict" wasn't a keyword before C99, so those
headers
> couldn't be included in code written for C89. __restrict__ is
non-standard,
> but that doesn't limit its usability in any way -- if you want to use a
> compiler that doesn't support it, you can just define __restrict__ to be
an
> empty macro on the command line.
>
> On Nov 15, 2017 10:00 AM, "Vojtech Horky"  wrote:
>
> > Hello Jiri,
> >
> > I have noticed the following commit [1] where the restrict keyword was
> > replaced with __restrict__ in multiple headers. I was wondering what
> > is the reason for replacing C99 standard keyword with a proprietary
> > extension (though implemented both by GCC and clang)? I assume they
> > are equivalent, right?
> >
> > Thanks,
> > - Vojtech
> >
> >
> > [1] https://github.com/HelenOS/helenos/commit/
> > 0dd477996e38407057517d8fe2b97d416cd4e667
> >
> > ___
> > HelenOS-devel mailing list
> > HelenOS-devel@lists.modry.cz
> > http://lists.modry.cz/listinfo/helenos-devel
> >

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


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


Re: [HelenOS-devel] What is wrong with restrict parameters?

2017-11-15 Thread Ondřej Hlavatý
Hi,

strictly speaking, couldn't you define "restrict" a macro in the same
way then? ;)

OH

On 15.11., Jiří Zárevúcky wrote:
> Hi,
> 
> the reason is that "restrict" wasn't a keyword before C99, so those headers
> couldn't be included in code written for C89. __restrict__ is non-standard,
> but that doesn't limit its usability in any way -- if you want to use a
> compiler that doesn't support it, you can just define __restrict__ to be an
> empty macro on the command line.
> 
> On Nov 15, 2017 10:00 AM, "Vojtech Horky"  wrote:
> 
> > Hello Jiri,
> >
> > I have noticed the following commit [1] where the restrict keyword was
> > replaced with __restrict__ in multiple headers. I was wondering what
> > is the reason for replacing C99 standard keyword with a proprietary
> > extension (though implemented both by GCC and clang)? I assume they
> > are equivalent, right?
> >
> > Thanks,
> > - Vojtech
> >
> >
> > [1] https://github.com/HelenOS/helenos/commit/
> > 0dd477996e38407057517d8fe2b97d416cd4e667
> >
> > ___
> > HelenOS-devel mailing list
> > HelenOS-devel@lists.modry.cz
> > http://lists.modry.cz/listinfo/helenos-devel
> >

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


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


Re: [HelenOS-devel] What is wrong with restrict parameters?

2017-11-15 Thread Jiří Zárevúcky
Hi,

the reason is that "restrict" wasn't a keyword before C99, so those headers
couldn't be included in code written for C89. __restrict__ is non-standard,
but that doesn't limit its usability in any way -- if you want to use a
compiler that doesn't support it, you can just define __restrict__ to be an
empty macro on the command line.

On Nov 15, 2017 10:00 AM, "Vojtech Horky"  wrote:

> Hello Jiri,
>
> I have noticed the following commit [1] where the restrict keyword was
> replaced with __restrict__ in multiple headers. I was wondering what
> is the reason for replacing C99 standard keyword with a proprietary
> extension (though implemented both by GCC and clang)? I assume they
> are equivalent, right?
>
> Thanks,
> - Vojtech
>
>
> [1] https://github.com/HelenOS/helenos/commit/
> 0dd477996e38407057517d8fe2b97d416cd4e667
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel
>
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel