From: Eli Zaretskii <eliz@gnu.org>
To: ludo@gnu.org (Ludovic Courtès)
Cc: wingo@pobox.com, mhw@netris.org, guile-devel@gnu.org
Subject: Re: Support open-process and friends on MS-Windows
Date: Mon, 11 Jul 2016 17:49:15 +0300 [thread overview]
Message-ID: <83r3b0cjro.fsf@gnu.org> (raw)
In-Reply-To: <87wpksoat0.fsf@gnu.org> (ludo@gnu.org)
> From: ludo@gnu.org (Ludovic Courtès)
> Cc: mhw@netris.org, wingo@pobox.com, guile-devel@gnu.org
> Date: Mon, 11 Jul 2016 10:09:47 +0200
>
> >> >>> Eli Zaretskii <eliz@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
next prev parent reply other threads:[~2016-07-11 14:49 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-24 9:51 Support open-process and friends on MS-Windows Eli Zaretskii
2016-06-24 10:45 ` Andy Wingo
2016-06-24 13:20 ` Eli Zaretskii
2016-06-24 11:49 ` Ludovic Courtès
2016-06-24 13:25 ` Eli Zaretskii
2016-06-25 9:11 ` Eli Zaretskii
2016-06-25 9:51 ` Andy Wingo
2016-06-25 10:22 ` Eli Zaretskii
2016-06-25 13:02 ` Ludovic Courtès
2016-06-25 13:20 ` Eli Zaretskii
2016-06-25 13:31 ` Eli Zaretskii
2016-06-25 14:43 ` Andy Wingo
2016-06-25 15:01 ` Eli Zaretskii
2016-07-02 23:02 ` Mark H Weaver
2016-07-03 3:47 ` Eli Zaretskii
2016-07-03 17:36 ` Eli Zaretskii
2016-07-05 7:44 ` Mark H Weaver
2016-07-05 8:04 ` Ludovic Courtès
2016-07-05 15:56 ` Eli Zaretskii
2016-07-11 8:09 ` Ludovic Courtès
2016-07-11 14:49 ` Eli Zaretskii [this message]
2016-07-05 15:51 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83r3b0cjro.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=mhw@netris.org \
--cc=wingo@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).