unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Arthur Miller <arthur.miller@live.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: bruno@clisp.org,  emacs-devel@gnu.org
Subject: Re: Compiling in mingw-ucrt runtime
Date: Wed, 03 Apr 2024 15:09:48 +0200	[thread overview]
Message-ID: <DU2PR02MB101094F4AC202103BA4122ABB963D2@DU2PR02MB10109.eurprd02.prod.outlook.com> (raw)
In-Reply-To: <86a5mbafvj.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Apr 2024 12:28:55 -0400")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: Bruno Haible <bruno@clisp.org>,  emacs-devel@gnu.org
>> Date: Tue, 02 Apr 2024 17:30:25 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Bruno Haible <bruno@clisp.org>
>> >> Cc: arthur.miller@live.com, emacs-devel@gnu.org
>> >> Date: Sun, 25 Feb 2024 16:32:59 +0100
>> >> 
>> >> On Sonntag, 25. Februar 2024 16:14:51 CET Eli Zaretskii wrote:
>> >> > > From: Bruno Haible <bruno@clisp.org>
>> >> > > Cc: arthur.miller@live.com, emacs-devel@gnu.org
>> >> > > Date: Sun, 25 Feb 2024 16:05:54 +0100
>> >> > > 
>> >> > > > Strange that they claim that, because their sources tell a different
>> >> > > > story, both for MSVCRT and for UCRT.  Or maybe your interpretation of
>> >> > > > what they say there is inaccurate?
>> >> > > 
>> >> > > Re MSVCRT: My reading of Vc7/crt/src/fclose.c is that it never sets errno.
>> >> > 
>> >> > fclose.c doesn't, indeed, but it calls _close (in close.c), which
>> >> > does.
>> >> 
>> >> OK, so when it calls _close() and that fails, errno gets set. Good.
>> >> Still, fclose() can also fail due to !inuse(stream), in which case errno does
>> >> not get set.
>> >> 
>> >> > > Re UCRT: My reading of ucrt-10.0.10240.0/stdio/fclose.cpp
>> >> > > and 10.0.14393.0/ucrt/stdio/fclose.cpp
>> >> > > is that errno gets set to EINVAL if the stream argument is invalid,
>> >> > > and remains unchanged otherwise.
>> >> > 
>> >> > I do see errno being set in close.cpp, which fclose.cpp calls to do
>> >> > the actual job.
>> >> 
>> >> Likewise here: Still, fclose() can also fail due to !stream.is_in_use(), in
>> >> which case errno does not get set.
>> >
>> > Yes, I agree that it doesn't set errno in all the cases where it
>> > fails.  But that's a far cry from saying that errno is always
>> > undefined after it fails.
>> >
>> > And the question still stands why does it fail in Emacs in such a way.
>> 
>> Just a short question: did you got anywhere further with this?
>
> You are asking me or Bruno?
>
> I've been waiting for Bruno to come back and tell more about what
> happens with UCRT in this case.

Anyone and no one in particular, just curious if you or someone else have found
what could be the problem.

>> Where did you look at the source? Are they installed with their (MS) command
>> line tools or do I have to install the entire VS/Windows devkti for the sources?
>
> If you are asking about UCRT sources, they are freely available on the

Yes. I got an impression you were looking at some Windows sources,
because of the path in this sentence of yours:

> My reading of Vc7/crt/src/fclose.c is that it never sets errno.


> Internet, just search for them and you will find them promptly.
> (AFAIU, you also get them if you install some version of Studio or
> other, but I didn't install it.)

I took a look now. The only one I found freely on GH is someone's private
repository, "huangqinjin", with some commits, by them, so I don't want
to download that one.

I don't see any official ucrt repository amongst the 6.2k on MS Github. Perhaps
it is there, but tucked under some other project.

On SX they say, ucrt sources are distributed with SDKs, so I guess I'll download
Windows SDK anyway. I wanted to spare myself of VS and their SDKs, it is
gigabytes of downloads I don't need otherwise.



  reply	other threads:[~2024-04-03 13:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-22  0:01 Compiling in mingw-ucrt runtime Arthur Miller
2024-02-22  6:24 ` Po Lu via Emacs development discussions.
2024-02-22  7:14 ` Eli Zaretskii
2024-02-23  7:58   ` Arthur Miller
2024-02-23  8:24     ` Eli Zaretskii
2024-02-23 11:32       ` Arthur Miller
2024-02-23 12:02         ` Eli Zaretskii
2024-02-24  9:13           ` Arthur Miller
2024-02-24 10:24             ` Eli Zaretskii
2024-02-24 23:11               ` Arthur Miller
2024-02-25  5:56                 ` Po Lu
2024-02-25  6:33                 ` Eli Zaretskii
2024-02-25 10:19                   ` Arthur Miller
2024-02-25 10:48                     ` Eli Zaretskii
2024-02-25 11:40                       ` Arthur Miller
2024-02-25 12:15                         ` Eli Zaretskii
2024-02-25 14:11                           ` Bruno Haible
2024-02-25 14:29                             ` Eli Zaretskii
2024-02-25 15:05                               ` Bruno Haible
2024-02-25 15:14                                 ` Eli Zaretskii
2024-02-25 15:32                                   ` Bruno Haible
2024-02-25 16:02                                     ` Eli Zaretskii
2024-04-02 15:30                                       ` Arthur Miller
2024-04-02 16:28                                         ` Eli Zaretskii
2024-04-03 13:09                                           ` Arthur Miller [this message]
2024-02-23 14:47 ` Benjamin Riefenstahl
2024-02-23 15:03   ` Benjamin Riefenstahl

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/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DU2PR02MB101094F4AC202103BA4122ABB963D2@DU2PR02MB10109.eurprd02.prod.outlook.com \
    --to=arthur.miller@live.com \
    --cc=bruno@clisp.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).