Re: [PATCH] version-etc.c: Do not include URLS in translatable strings.

Ben Pfaff wrote: > > -License GPLv3+: GNU GPL version 3 or later > > .\n\ > > +License GPLv3+: GNU GPL version 3 or later <%s>.\n\ > > Does anyone ever try to translate the "GPLv3+" part? If so, then it > could be taken out as well. The Serbian translators

Re: Why does close_stdout close stdout and stderr?

Florian Weimer wrote: > ... would be fsync. And I doubt you want to > call that, purely for performance reasons. The trade-off between data safety and speed of disk accesses is to be done by the system administrator, when they decide whether to use the mount option 'sync' or not. It would be

Re: Why does close_stdout close stdout and stderr?

* Bernhard Voelker: > On 5/6/19 5:47 PM, Florian Weimer wrote: >> * Bernhard Voelker: >>> What is the problem? I mean if it is use-after-free as mentioned in >>> the first mail, then write() after fflush() without error checking via >>> another fflush() is in the same category, isn't it? >> >>

Re: Why does close_stdout close stdout and stderr?

On 5/6/19 5:47 PM, Florian Weimer wrote: > * Bernhard Voelker: >> What is the problem? I mean if it is use-after-free as mentioned in >> the first mail, then write() after fflush() without error checking via >> another fflush() is in the same category, isn't it? > > No, there is no memory

Re: Why does close_stdout close stdout and stderr?

On Mon, 2019-05-06 at 11:53 -0700, Paul Eggert wrote: > On 5/6/19 5:05 AM, Florian Weimer wrote: > > > I've been told that on Linux, close does not report writeback errors. > > So the only way to get a reliable error indicator (beyond what you get > > from the write system call) would be fsync. >

Re: Why does close_stdout close stdout and stderr?

On 5/6/19 5:05 AM, Florian Weimer wrote: > I've been told that on Linux, close does not report writeback errors. > So the only way to get a reliable error indicator (beyond what you get > from the write system call) would be fsync. Are you sure you asked your expert the right question? I just

Re: [PATCH] version-etc.c: Do not include URLS in translatable strings.

On Mon, May 06, 2019 at 08:21:34PM +0200, John Darrington wrote: > This method is better for several reasons: 1. It avoids the danger of > cut and paste errors. 2. Naive translators can't translate the urls > (it's amazing how many do things like that!) 3. Should the urls ever > change, only

[PATCH] version-etc.c: Do not include URLS in translatable strings.

This method is better for several reasons: 1. It avoids the danger of cut and paste errors. 2. Naive translators can't translate the urls (it's amazing how many do things like that!) 3. Should the urls ever change, only this file has to be updated rather than every single translation. *

Re: Why does close_stdout close stdout and stderr?

* Bernhard Voelker: > On 5/6/19 2:05 PM, Florian Weimer wrote: On 4/29/19 2:45 PM, Florian Weimer wrote: > I get that error checking is important. But why not just use ferror and > fflush? Closing the streams is excessive and tends to introduce > use-after-free issues, as

Re: Why does close_stdout close stdout and stderr?

On 5/6/19 2:05 PM, Florian Weimer wrote: >>> On 4/29/19 2:45 PM, Florian Weimer wrote: I get that error checking is important. But why not just use ferror and fflush? Closing the streams is excessive and tends to introduce use-after-free issues, as evidenced by the sanitizer

Re: Why does close_stdout close stdout and stderr?

* Florian Weimer: > * Eric Blake: > >> On 4/29/19 2:45 PM, Florian Weimer wrote: >>> I get that error checking is important. But why not just use ferror and >>> fflush? Closing the streams is excessive and tends to introduce >>> use-after-free issues, as evidenced by the sanitizer workarounds.

Re: Can't compile on Windows

Redirecting to bug-gnulib. Michele Locati wrote in : > > > i686-w64-mingw32.shared-gcc -DHAVE_CONFIG_H -DEXEEXT=\".exe\" -I. > > > -I/home/m/build-gettext-windows/shared-32/source/gettext-0.20-rc1/gettext-tools/gnulib-tests >