> The program could read this -1 to (for example) uint16_t and interpret as 65535 and fail to notice the parent is not giving any fd.
File descriptors have been of int type since Unix was designed (at least) and -1 is documented as the invalid descriptor. E.g. the open() system call and every other system call returning an fd returns -1 on error and always has. The idea that any program would read something explicitly documented as a file descriptor into an unsigned type seems effectively inconceivable. David On Tue, Feb 9, 2021 at 7:36 AM Dmitry Goncharov via Bug reports and discussion for GNU make <bug-make@gnu.org> wrote: > On Tue, Feb 9, 2021 at 5:31 AM Edward Welbourne <edward.welbou...@qt.io> > wrote: > > > Rather than removing the jobserver-auth data, you could amend the > > MAKEFLAGS to includ jobserver-auth data with plainly invalid fds, > > i like jobserver-auth data with plainly invalid fds, because it lets > older binaries fail on parsing jobserver-auth > and print some (hopefully useful) error message. > E.g. make itself would print > "internal error: invalid --jobserver-auth string" > > > > e.g. -1, as the two fds > > The program could read this -1 to (for example) uint16_t and interpret > as 65535 and fail to notice the parent is not giving any fd. > i'd rather provide no fd at all. E.g. > --jobserver-auth= > > regards, Dmitry > > > > > > Eddy. > > > >
