> On 17 Dec 2021, at 15:33, Rasmus Villemoes <rasmus.villem...@prevas.dk> wrote:
> 
> On 17/12/2021 15.12, Olivier Hainque wrote:
>> Hi Rasmus
>> 
>>> On 17 Dec 2021, at 13:49, Rasmus Villemoes <rasmus.villem...@prevas.dk> 
>>> 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.

Ah, I see. Sorry, I misunderstood the point you were making.

Let me check and think about it some more.

Cheers,

Olivier

Reply via email to