On 17/12/2021 15.12, Olivier Hainque wrote:
> Hi Rasmus
>
>> On 17 Dec 2021, at 13:49, Rasmus Villemoes <[email protected]>
>> wrote:
>
>> I'm not sure what to do. But this patch will definitely break our build
>> - primarily because we've done a private workaround.
>
> I don't think we can reasonably cope with private changes
> to system headers.
Of course not. And I'm more than willing to undo that private change if
a suitable fix can be worked out.
> Can't you just undo your workaround and use this (very simple)
> "fix" instead?
No, because as I explained, the open() implementation on vxworks 5.5
must not be called as a two-arg function with garbage in r5. Do you have
access to any of the kernel source code for the other vxworks versions
with a three-arg-only open() in fcntl.h? If not, how can you know that
those kernels do not make use of the mode argument even if O_CREAT is
not in flags? (For example, I could actually imagine an implementation
where non-zero mode would imply O_CREAT. Then 'open("foo", O_RDWR)'
could result in foo being created with a more-or-less random mode, where
it should have resulted in ENOENT.)
I'm sure libstdc++ builds with this change, as I said I had the same
thing initially, but after looking at the open() implementation we were
worried about the implications.
> Otherwise, add a local patch to your tree to remove this fix?
Always an option, of course.
Rasmus
