> From: l...@gnu.org (Ludovic Courtès) > Cc: m...@netris.org, wi...@pobox.com, guile-devel@gnu.org > Date: Mon, 11 Jul 2016 10:09:47 +0200 > > >> >>> Eli Zaretskii <e...@gnu.org> writes: > >> >>> > +# define getuid() (500) /* Local Administrator */ > >> >>> > +# define getgid() (513) /* None */ > >> >>> > +# define setuid(u) (0) > >> >>> > +# define setgid(g) (0) > >> > >> What about leaving ‘setuid’ and ‘setgid’ undefined, as was the case > >> until now? > > > > I fail to see how this would be better. It would mean any program > > that calls these will not work on MS-Windows. Why should we expect > > developers of those Guile programs to be aware of the issue and solve > > it on the Guile Scheme level? And what solution will they possibly be > > able to come up with, except not to call these APIs on Windows? > > Our strategy so far has been to (1) either solve the portability issue > via Gnulib, or (2) do not provide the feature that is unavailable (the > #ifdef HAVE_ in posix.c et al.) > > It means that application writers have to be aware of the portability > problems, even if it’s all Scheme. That sounds reasonable to me. > > WDYT?
I don't think it's wise, and I explained why. Gnulib in this case is unlikely to provide any implementation, except one that always fails, because these operations have no equivalent on MS-Windows. But if agreeing to remove these two lines will cause the rest of the patch to be finally admitted, I'm fine with that compromise. TIA