Kaz Kylheku <
643-408-1753@kylheku.com> writes:
On 2025-04-27, Scott Lurndal <scott@slp53.sl.home> wrote:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 27.04.2025 um 16:43 schrieb Kenny McCormack:
In article <vulcf3$tsqb$1@raubtier-asyl.eternal-september.org>,
Bonita Montero <Bonita.Montero@gmail.com> wrote:
Am 27.04.2025 um 15:33 schrieb Bonita Montero:
The platform with the most comfortable handling of division by zeroes >>>>>> is Windows. Win32 allows to catch that errors easily, whereas with >>>>>> Posix it's hard to continue the code in the same function or with
a calling function.
#include <Windows.h>
Burp!
#include <stdio.h>
using namespace std;
Burp again! Are you confused about which newsgroup this is?
Ignore it it you target a different platform. But it would be nice
if such problems were handleable that convenient in any lanugage.
Why? I've -never- needed to handle a divide by zero; a good programmer
won't let it happen.
What does a good programmer do if they are asked to write
a division routine for a run-time library called by other people's
code?
Or a programming language in which someone else can express a division
whose denominator could be zero?
Put a constraint in the documentation for the API specifying that
division by zero is undefined[*] and take the processor fault,
produce the core file and send it to the application developer with
a big sign marked RTFM.
You don't check virtual addresses being provided to a library
function, it is incumbent upon the user of the function to ensure
that any address passed is legal and valid for the purpose
(i.e. not read-only if the data is updated by the library).
While a library provider could certainly check for arithmetic arguments
that aren't in the domain of the function but it is not
required to and doesn't mean the programmer isn't at fault when
passing invalid arguments to a library API.
[*] Or define the range of legal arguments in the documentation.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)