[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFR] man://manpages-l10n/sscanf.3.po (4/4)



Hallo Christoph,
Am Sat, May 04, 2024 at 12:04:04PM +0200 schrieb Christoph Brinkhaus:
> > # FIXME Why is "Undefined Behaviour" capitalized?
> > #. type: Plain text
> > #: archlinux fedora-40 fedora-rawhide mageia-cauldron opensuse-tumbleweed
> > msgid ""
> > "Use of the numeric conversion specifiers produces Undefined Behavior for "
> > "invalid input.  See E<.UR https://port70.net/\\:%7Ensz/\\:c/\\:c11/\\:n1570.";
> > "html\\:#7.21.6.2p10> C11 7.21.6.2/10 E<.UE .> This is a bug in the ISO C "
> > "standard, and not an inherent design issue with the API.  However, current "
> > "implementations are not safe from that bug, so it is not recommended to use "
> > "them.  Instead, programs should use functions such as B<strtol>(3)  to parse "
> > "numeric input.  Alternatively, mitigate it by specifying a maximum field "
> > "width."
> > msgstr ""
> > "Die Verwendung von numerischen Umwandlungskennzeichnern erzeugt nicht "
> > "definiertes Verhalten für ungültige Eingabe. Siehe E<.UR https://port70.net/";
> > "\\:%7Ensz/\\:c/\\:c11/\\:n1570.html\\:#7.21.6.2p10>C11 7.21.6.2/10 E<.UE .> "
> > "Dies ist ein Fehler im ISO-C-Standard und keine immanennte Eigenschaft mit "
> > "dem API. Allerdings sind aktuelle Implementierungen nicht vor dem Fehler "
> > "gefeiht, daher wird deren Verwendung nicht empfohlen. Stattdessen sollten "
> > "Programme Funktionen wie B<strtol>(3) verwenden, um numerische Eingabe "
> > "auszuwerten. Alternativ entschärfen Sie dies durch Angabe einer maximalen "
> > "Feldbreite."
> s/nicht definiertes Verhalten/undefiniertes Verhalten/

Wo ist da der Unterschied? Nicht definiert ist doch das gleiche wie
undefiniert, oder?

> Hier und in anderen Zeichenketten zwei Tippfehler:
> s/immannente/immanente/
> s/gefeiht/gefeit/

Korrigiert.

> > msgid ""
> > "As shown in the above example, it is necessary to call B<free>(3)  only if "
> > "the B<sscanf>()  call successfully read a string."
> > msgstr ""
> > "Wie im obigen Beispiel gezeigt, ist der Aufruf von B<free>(3) nur notwendig, "
> > "falls der Aufruf B<sscanf>() erfolgreich eine Zeichenkette gelesen hat."
> Wenn der Normalfall der ist, dass B<sscanf> erfolgreich ist, dann würde
> ich "falls" durch "wenn" ersetzen. Meiner Meinung nach ist das Auftreten
> vom "falls"-Fall eine Ausnahme und das Auftreten vom "wenn"-Fall
> normaler.

Ich bin ja (siehe Listenarchiv) schon mit falls/wenn hier angeeckt,
daher übernehme ich das ohne Diskussion.

> > msgid ""
> > "The value B<EOF> is returned if the end of input is reached before either "
> > "the first successful conversion or a matching failure occurs.  B<EOF> is "
> > "also returned if a read error occurs, in which case the error indicator for "
> > "the stream (see B<ferror>(3))  is set, and I<errno> is set to indicate the "
> > "error."
> > msgstr ""
> > "Der Wert B<EOF> wird zurückgegeben, wenn das Ende der Eingabe erreicht wird, "
> > "bevor entweder die erste erfolgreiche Umwandlung oder ein »matching failure« "
> > "auftrat. B<EOF> wird auch zurückgegeben, wenn ein Lesefehler auftritt. In "
> > "diesem Fall wird die Fehleranzeige für den Datenstrom gesetzt (siehe "
> > "B<ferror>(3)) und I<errno> so gesetzt, dass es den Fehler angibt."
> s/auftrat/auftritt/

Warum? Wenn ich am Zeilenende bin, ist das bereits Vergangenheit. (Und
Deine Fassung liest sich für mich auch falsch.)

Viele Grüße

            Helge
-- 
      Dr. Helge Kreutzmann                     debian@helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

Attachment: signature.asc
Description: PGP signature


Reply to: