Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #392892 > unrolled thread

integer divided by zero

Back to article view | Back to comp.lang.c

Contents

  integer divided by zero Thiago Adams <thiago.adams@gmail.com> - 2025-04-25 14:38 -0300
    Re: integer divided by zero David Brown <david.brown@hesbynett.no> - 2025-04-25 19:50 +0200
      Re: integer divided by zero Thiago Adams <thiago.adams@gmail.com> - 2025-04-25 16:37 -0300
        Re: integer divided by zero Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-25 13:32 -0700
          Re: integer divided by zero Thiago Adams <thiago.adams@gmail.com> - 2025-04-26 12:30 -0300
            Re: integer divided by zero gazelle@shell.xmission.com (Kenny McCormack) - 2025-04-26 16:27 +0000
              Re: integer divided by zero Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-26 17:01 +0000
    Re: integer divided by zero Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-25 12:05 -0700
      Re: integer divided by zero Thiago Adams <thiago.adams@gmail.com> - 2025-04-25 16:32 -0300
        Re: integer divided by zero Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-25 13:31 -0700
          Re: integer divided by zero Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-25 21:36 +0000
            Re: integer divided by zero Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-25 16:09 -0700
              Re: integer divided by zero Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-14 01:09 -0700
          Re: integer divided by zero Thiago Adams <thiago.adams@gmail.com> - 2025-04-28 11:05 -0300
      Re: integer divided by zero Rosario19 <Ros@invalid.invalid> - 2025-04-30 12:41 +0200
        Re: integer divided by zero David Brown <david.brown@hesbynett.no> - 2025-04-30 13:35 +0200
    Re: integer divided by zero John McCue <jmccue@magnetar.jmcunx.com> - 2025-04-25 19:41 +0000
    Re: integer divided by zero antispam@fricas.org (Waldek Hebisch) - 2025-04-26 09:57 +0000
    Re: integer divided by zero Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-27 15:33 +0200
      Re: integer divided by zero Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-27 15:46 +0200
        Did you get confused again?  You seem eaily bewildered. (Was: integer divided by zero) gazelle@shell.xmission.com (Kenny McCormack) - 2025-04-27 14:43 +0000
          Re: Did you get confused again? You seem eaily bewildered. (Was: integer divided by zero) Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-27 16:54 +0200
            Re: Did you get confused again? You seem eaily bewildered. (Was: integer divided by zero) scott@slp53.sl.home (Scott Lurndal) - 2025-04-27 16:16 +0000
              Re: Did you get confused again? You seem eaily bewildered. (Was: integer divided by zero) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-27 16:23 +0000
                Re: Did you get confused again? You seem eaily bewildered. (Was: integer divided by zero) Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-27 20:28 +0200
                Re: Did you get confused again? You seem eaily bewildered. (Was: integer divided by zero) scott@slp53.sl.home (Scott Lurndal) - 2025-04-27 22:52 +0000
                  Re: Did you get confused again? You seem eaily bewildered. antispam@fricas.org (Waldek Hebisch) - 2025-04-28 10:41 +0000
              Re: Did you get confused again? You seem eaily bewildered. antispam@fricas.org (Waldek Hebisch) - 2025-04-28 10:12 +0000
                Re: Did you get confused again? You seem eaily bewildered. Rosario19 <Ros@invalid.invalid> - 2025-04-30 09:16 +0200
                Re: Did you get confused again? You seem eaily bewildered. Richard Heathfield <rjh@cpax.org.uk> - 2025-04-30 08:36 +0100
            Re: Did you get confused again? You seem eaily bewildered. antispam@fricas.org (Waldek Hebisch) - 2025-04-28 10:39 +0000
              Re: Did you get confused again? You seem eaily bewildered. Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 12:50 +0200
      Re: integer divided by zero Richard Heathfield <rjh@cpax.org.uk> - 2025-04-28 08:54 +0100
        Re: integer divided by zero Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 12:49 +0200
          Re: integer divided by zero Richard Heathfield <rjh@cpax.org.uk> - 2025-04-28 12:01 +0100
            Re: integer divided by zero Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 13:27 +0200
      Re: integer divided by zero Richard Damon <richard@damon-family.org> - 2025-04-28 07:15 -0400
        Re: integer divided by zero Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 13:28 +0200
          Re: integer divided by zero scott@slp53.sl.home (Scott Lurndal) - 2025-04-28 14:28 +0000
            Re: integer divided by zero Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 16:51 +0200
            Re: integer divided by zero Michael S <already5chosen@yahoo.com> - 2025-04-28 18:03 +0300
              Re: integer divided by zero scott@slp53.sl.home (Scott Lurndal) - 2025-04-28 16:35 +0000
                Re: integer divided by zero Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 18:38 +0200
              Re: integer divided by zero Muttley@DastardlyHQ.org - 2025-04-28 17:02 +0000
        Re: integer divided by zero antispam@fricas.org (Waldek Hebisch) - 2025-04-28 14:44 +0000
          Re: integer divided by zero Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 16:52 +0200
    Re: integer divided by zero Richard Heathfield <rjh@cpax.org.uk> - 2025-04-28 14:52 +0100
      Re: integer divided by zero Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-28 13:44 -0700
    Re: integer divided by zero Vir Campestris <vir.campestris@invalid.invalid> - 2025-05-03 21:47 +0100
      Re: integer divided by zero Michael S <already5chosen@yahoo.com> - 2025-05-03 23:58 +0300
    Re: integer divided by zero goldside000@outlook.com - 2025-05-31 18:56 +0000
      Re: integer divided by zero Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-31 14:07 -0700
        Re: integer divided by zero scott@slp53.sl.home (Scott Lurndal) - 2025-05-31 21:53 +0000

Page 1 of 3  [1] 2 3  Next page →

#392892 — integer divided by zero

Does anyone know of any platform where integer division by zero returns 
a number, or in other words, where it's not treated as an error? I'm 
asking because division by zero is undefined behaviour, but I think 
division by a constant zero should be a constraint instead.

[toc] | [next] | [standalone]

#392893

On 25/04/2025 19:38, Thiago Adams wrote:
> Does anyone know of any platform where integer division by zero returns 
> a number, or in other words, where it's not treated as an error? I'm 
> asking because division by zero is undefined behaviour, but I think 
> division by a constant zero should be a constraint instead.
> 

Some processors might give a specific value for their integer division 
instructions for divide by 0 - or they might support masking of relevant 
traps, exceptions or other fault mechanisms.  Software should probably 
not rely on division by 0 behaviour, even if it is in non-portable code.

But most processors that are too small to have a fault, trap or 
exception system are also too small to have division instructions. 
There are exceptions, of course.

Division by a constant 0 is not a constraint in C because that would 
require compilers to detect division by zero.  But conforming compilers 
are free to detect it anyway, and issue a warning.  Note that compilers 
should probably not consider it a fatal error in the code (i.e., one 
that stops the compilation) unless the compiler can be sure that the 
code in question is not executed.  There is no problem having undefined 
behaviour in the code until you try to execute that code path.

[toc] | [prev] | [next] | [standalone]

#392896

Em 4/25/2025 2:50 PM, David Brown escreveu:
> On 25/04/2025 19:38, Thiago Adams wrote:
>> Does anyone know of any platform where integer division by zero 
>> returns a number, or in other words, where it's not treated as an 
>> error? I'm asking because division by zero is undefined behaviour, but 
>> I think division by a constant zero should be a constraint instead.
>>
> 
> Some processors might give a specific value for their integer division 
> instructions for divide by 0 - or they might support masking of relevant 
> traps, exceptions or other fault mechanisms.  Software should probably 
> not rely on division by 0 behaviour, even if it is in non-portable code.
> 
> But most processors that are too small to have a fault, trap or 
> exception system are also too small to have division instructions. There 
> are exceptions, of course.
> 
> Division by a constant 0 is not a constraint in C because that would 
> require compilers to detect division by zero.  

This is easy for constant.

But conforming compilers
> are free to detect it anyway, and issue a warning.  Note that compilers 
> should probably not consider it a fatal error in the code (i.e., one 
> that stops the compilation) unless the compiler can be sure that the 
> code in question is not executed.  There is no problem having undefined 
> behaviour in the code until you try to execute that code path.
> 

Since 1/0 is not a constant, then if 1/0 were a constrain, the 
programmer could use a variable instead.

static int zero = 0;
1/zero //ok

[toc] | [prev] | [next] | [standalone]

#392899

Thiago Adams <thiago.adams@gmail.com> writes:
[...]
> Since 1/0 is not a constant, then if 1/0 were a constrain, the
> programmer could use a variable instead.
>
> static int zero = 0;
> 1/zero //ok

They could, but why?  `1/zero` is not "ok"; it's undefined behavior.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#392907

Em 4/25/2025 5:32 PM, Keith Thompson escreveu:
> Thiago Adams <thiago.adams@gmail.com> writes:
> [...]
>> Since 1/0 is not a constant, then if 1/0 were a constrain, the
>> programmer could use a variable instead.
>>
>> static int zero = 0;
>> 1/zero //ok
> 
> They could, but why?  `1/zero` is not "ok"; it's undefined behavior.
> 

It could me used in the sample given by Waldek

int signal_error(void) {
     return 1/0;
}

int signal_error(void) {
     int zero = 0;
     return 1/zero;
}

[toc] | [prev] | [next] | [standalone]

#392908

In article <vuiu6e$2lqot$1@dont-email.me>,
Thiago Adams  <thiago.adams@gmail.com> wrote:
>Em 4/25/2025 5:32 PM, Keith Thompson escreveu:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>> [...]
>>> Since 1/0 is not a constant, then if 1/0 were a constrain, the
>>> programmer could use a variable instead.
>>>
>>> static int zero = 0;
>>> 1/zero //ok
>> 
>> They could, but why?  `1/zero` is not "ok"; it's undefined behavior.
>> 
>
>It could me used in the sample given by Waldek
>
>int signal_error(void) {
>     return 1/0;
>}
>
>int signal_error(void) {
>     int zero = 0;
>     return 1/zero;
>}

Wouldn't it be easier just to use raise(3)?

-- 
So to cure the problem of arrogant incompetent rich people we should turn
the government over to an arrogant incompetent trust fund billionaire
who knows nothing about government and who has never held a job in his
entire spoiled life?

[toc] | [prev] | [next] | [standalone]

#392909

On 2025-04-26, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>int signal_error(void) {
>>     int zero = 0;
>>     return 1/zero;
>>}
>
> Wouldn't it be easier just to use raise(3)?

This is being described elsethread as something portable
across languages, not all of which have access to signal-related
functions.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#392894

Thiago Adams <thiago.adams@gmail.com> writes:
> Does anyone know of any platform where integer division by zero
> returns a number, or in other words, where it's not treated as an
> error? I'm asking because division by zero is undefined behaviour, but
> I think division by a constant zero should be a constraint instead.

Division by a constant zero is a constraint violation in a context that
requires a constant expression.

I wrote this quick and dirty program:

#include <stdio.h>
#include <time.h>
int main(void) {
    int one = time(NULL) / 1000000000;
    int zero = one - 1;
    int ratio = one / zero;
    printf("%d\n", ratio);
}

It's not portable, but on the systems where I've tried it it sets
one to 1 and zero to 0 in a way that the compiler can't detect,
so the division won't be optimized away.  (At least, it does so if
you run it between 2001 and 2286.)

On x86_64, it dies with a floating point exception.

On aarch64, it prints 0.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#392895

Em 4/25/2025 4:05 PM, Keith Thompson escreveu:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> Does anyone know of any platform where integer division by zero
>> returns a number, or in other words, where it's not treated as an
>> error? I'm asking because division by zero is undefined behaviour, but
>> I think division by a constant zero should be a constraint instead.
> 
> Division by a constant zero is a constraint violation in a context that
> requires a constant expression.


Consider this sample

int main(){
     int a[1/0];
}

1/0 does not have a value in compile time,
So I believe compilers are making "a" a VLA because 1/0 is
not constant.

(But what old c89 compilers where doing in this case?)

This sample is a motivation to make integer divided by
zero a constrain.

[toc] | [prev] | [next] | [standalone]

#392898

Thiago Adams <thiago.adams@gmail.com> writes:
> Em 4/25/2025 4:05 PM, Keith Thompson escreveu:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>> Does anyone know of any platform where integer division by zero
>>> returns a number, or in other words, where it's not treated as an
>>> error? I'm asking because division by zero is undefined behaviour, but
>>> I think division by a constant zero should be a constraint instead.
>> Division by a constant zero is a constraint violation in a context
>> that requires a constant expression.
>
> Consider this sample
>
> int main(){
>     int a[1/0];
> }
>
> 1/0 does not have a value in compile time,
> So I believe compilers are making "a" a VLA because 1/0 is
> not constant.

1/0 is not a constant expression.

A conforming compiler that supports VLAs (C99, or optionally C11 or
later) would make `a` a VLA, with undefined behavior at runtime when
1/0 is evaluated.  For a conforming compiler that doesn't support
VLAs (C89/C90, or optionally C11 or later) the declaration is a
constraint violation.

> (But what old c89 compilers where doing in this case?)
>
> This sample is a motivation to make integer divided by
> zero a constrain.

I consider it motivation not to write code like that.

Sure, I wouldn't mind if using / or % with a right operand
that's a constant expression with value zero (either integer or
floating-point) were a constraint violation, but some compilers
are going to warn about it anyway, and I doubt that such a language
change would catch many errors.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#392900

On 2025-04-25, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> Em 4/25/2025 4:05 PM, Keith Thompson escreveu:
>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>> Does anyone know of any platform where integer division by zero
>>>> returns a number, or in other words, where it's not treated as an
>>>> error? I'm asking because division by zero is undefined behaviour, but
>>>> I think division by a constant zero should be a constraint instead.
>>> Division by a constant zero is a constraint violation in a context
>>> that requires a constant expression.
>>
>> Consider this sample
>>
>> int main(){
>>     int a[1/0];
>> }
>>
>> 1/0 does not have a value in compile time,
>> So I believe compilers are making "a" a VLA because 1/0 is
>> not constant.
>
> 1/0 is not a constant expression.
>
> A conforming compiler that supports VLAs (C99, or optionally C11 or
> later) would make `a` a VLA, with undefined behavior at runtime when
> 1/0 is evaluated.  For a conforming compiler that doesn't support
> VLAs (C89/C90, or optionally C11 or later) the declaration is a
> constraint violation.

My interpretation (looking at n3301) is that 1/0 is a constant
expression, which violates a constraint.

("Each constant expression shall evaluate to a constant that is in the
range of representable values for its type.")

The constraint makes it clear that there may be constant expressions
which evaluate out of range. (They are constant expressions in form:
constant operands, subject to the permitted operators.)

The constraint's purpose isn't to give a classifying requirement in the
sense that expressions not meeting the constraint are not taken to be
constant. It is for diagnostic use: constant expressions not meeting the
constraint are to be diagnosed.

According to this interpretation the declarator a[1/0] would be deemed
to be a regular array, not VLA, and so a constraint violation occurs
regardless of VLA support.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#392902

Kaz Kylheku <643-408-1753@kylheku.com> writes:
> On 2025-04-25, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>> Em 4/25/2025 4:05 PM, Keith Thompson escreveu:
>>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>>> Does anyone know of any platform where integer division by zero
>>>>> returns a number, or in other words, where it's not treated as an
>>>>> error? I'm asking because division by zero is undefined behaviour, but
>>>>> I think division by a constant zero should be a constraint instead.
>>>> Division by a constant zero is a constraint violation in a context
>>>> that requires a constant expression.
>>>
>>> Consider this sample
>>>
>>> int main(){
>>>     int a[1/0];
>>> }
>>>
>>> 1/0 does not have a value in compile time,
>>> So I believe compilers are making "a" a VLA because 1/0 is
>>> not constant.
>>
>> 1/0 is not a constant expression.
>>
>> A conforming compiler that supports VLAs (C99, or optionally C11 or
>> later) would make `a` a VLA, with undefined behavior at runtime when
>> 1/0 is evaluated.  For a conforming compiler that doesn't support
>> VLAs (C89/C90, or optionally C11 or later) the declaration is a
>> constraint violation.
>
> My interpretation (looking at n3301) is that 1/0 is a constant
> expression, which violates a constraint.
>
> ("Each constant expression shall evaluate to a constant that is in the
> range of representable values for its type.")
>
> The constraint makes it clear that there may be constant expressions
> which evaluate out of range. (They are constant expressions in form:
> constant operands, subject to the permitted operators.)
>
> The constraint's purpose isn't to give a classifying requirement in the
> sense that expressions not meeting the constraint are not taken to be
> constant. It is for diagnostic use: constant expressions not meeting the
> constraint are to be diagnosed.
>
> According to this interpretation the declarator a[1/0] would be deemed
> to be a regular array, not VLA, and so a constraint violation occurs
> regardless of VLA support.

Also looking at n3301, the syntax is:

    constant-expression:
        conditional-expression

That doesn't imply that all conditional-expressions are
constant-expressions.  If it did, then

    time_t t = time(NULL);

would be a constraint violation; `time(NULL)` is a
conditional-expression, but it violates the constraint on function
calls -- but a constant expression is not required in that context
(assuming it's at block scope).

A construct is a constant-expression only if it appears in a place where
the grammar requires a constant-expression.  An array-declarator is not
one of those contexts; the syntax requires an assignment-expression.

There's a constraint on array declarators: "If the expression is
a constant expression, it shall have a value greater than zero."
That wording is a little iffy, but the meaning is clear enough.
It might have been more pedantically correct to say "If the
expression would be a constant expression if it appeared in a
context that requires a constant expression, ...".

None of these:
    int foo[time() % 10 + 1];
    int bar[1 / 0];
    int baz[INT_MAX + 1];
violates any constraint, even though constant expressions may not
include function calls, division by zero, or signed overflow.

A vaguely analogous case:
    int n = 1 + 2 * 3;
`1 + 2` is not an additive expression.  It looks like one, but it
appears in a context that syntactically doesn't allow an additive
expression.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#393403

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>
>> On 2025-04-25, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>
>>>> Em 4/25/2025 4:05 PM, Keith Thompson escreveu:
>>>>
>>>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>>>
>>>>>> Does anyone know of any platform where integer division by zero
>>>>>> returns a number, or in other words, where it's not treated as an
>>>>>> error?  I'm asking because division by zero is undefined behaviour, but
>>>>>> I think division by a constant zero should be a constraint instead.
>>>>>
>>>>> Division by a constant zero is a constraint violation in a context
>>>>> that requires a constant expression.
>>>>
>>>> Consider this sample
>>>>
>>>> int main(){
>>>>     int a[1/0];
>>>> }
>>>>
>>>> 1/0 does not have a value in compile time,
>>>> So I believe compilers are making "a" a VLA because 1/0 is
>>>> not constant.
>>>
>>> 1/0 is not a constant expression.
>>>
>>> A conforming compiler that supports VLAs (C99, or optionally C11 or
>>> later) would make `a` a VLA, with undefined behavior at runtime when
>>> 1/0 is evaluated.  For a conforming compiler that doesn't support
>>> VLAs (C89/C90, or optionally C11 or later) the declaration is a
>>> constraint violation.
>>
>> My interpretation (looking at n3301) is that 1/0 is a constant
>> expression, which violates a constraint.
>>
>> ("Each constant expression shall evaluate to a constant that is in the
>> range of representable values for its type.")
>>
>> The constraint makes it clear that there may be constant expressions
>> which evaluate out of range.  (They are constant expressions in form:
>> constant operands, subject to the permitted operators.)
>>
>> The constraint's purpose isn't to give a classifying requirement in the
>> sense that expressions not meeting the constraint are not taken to be
>> constant.  It is for diagnostic use:  constant expressions not meeting the
>> constraint are to be diagnosed.
>>
>> According to this interpretation the declarator a[1/0] would be deemed
>> to be a regular array, not VLA, and so a constraint violation occurs
>> regardless of VLA support.
>
> Also looking at n3301, the syntax is:
>
>     constant-expression:
>         conditional-expression
>
> That doesn't imply that all conditional-expressions are
> constant-expressions. [...]

Based on a memory of reading an old Defect Report (sorry don't know
which one), I think there was an official statement to the effect
that any conditional-expression is also a constant-expression, but
the constraints aren't in force unless the surrounding context
requires a constant-expression.  In other words whether something is
a constant-expression is purely a local syntactic condition;  the
conditions stated for constant expressions matter only when being
a constant expression is necessary to satisfy some other rule in
the C standard.

[toc] | [prev] | [next] | [standalone]

#392972

On 25/04/2025 17:31, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> Em 4/25/2025 4:05 PM, Keith Thompson escreveu:
>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>> Does anyone know of any platform where integer division by zero
>>>> returns a number, or in other words, where it's not treated as an
>>>> error? I'm asking because division by zero is undefined behaviour, but
>>>> I think division by a constant zero should be a constraint instead.
>>> Division by a constant zero is a constraint violation in a context
>>> that requires a constant expression.
>>
>> Consider this sample
>>
>> int main(){
>>      int a[1/0];
>> }
>>
>> 1/0 does not have a value in compile time,
>> So I believe compilers are making "a" a VLA because 1/0 is
>> not constant.
> 
> 1/0 is not a constant expression.
> 
> A conforming compiler that supports VLAs (C99, or optionally C11 or
> later) would make `a` a VLA, with undefined behavior at runtime when
> 1/0 is evaluated.  For a conforming compiler that doesn't support
> VLAs (C89/C90, or optionally C11 or later) the declaration is a
> constraint violation.
> 
>> (But what old c89 compilers where doing in this case?)
>>
>> This sample is a motivation to make integer divided by
>> zero a constrain.
> 
> I consider it motivation not to write code like that.
> 
> Sure, I wouldn't mind if using / or % with a right operand
> that's a constant expression with value zero (either integer or
> floating-point) were a constraint violation, but some compilers
> are going to warn about it anyway, and I doubt that such a language
> change would catch many errors.
> 

Another interesting example

enum {A = ((-2147483647-1) / -1)};

In this case it is a constant expression.
The resulting value is -2147483648 of type int.

The mathematically correct value is 2147483648 that does not fit
in a integer.

[toc] | [prev] | [next] | [standalone]

#393074

On Fri, 25 Apr 2025 12:05:13 -0700, Keith Thompson wrote:

>Thiago Adams writes:
>> Does anyone know of any platform where integer division by zero
>> returns a number, or in other words, where it's not treated as an
>> error? I'm asking because division by zero is undefined behaviour, but
>> I think division by a constant zero should be a constraint instead.
>
>Division by a constant zero is a constraint violation in a context that
>requires a constant expression.
>
>I wrote this quick and dirty program:
>
>#include <stdio.h>
>#include <time.h>
>int main(void) {
>    int one = time(NULL) / 1000000000;
>    int zero = one - 1;
>    int ratio = one / zero;
>    printf("%d\n", ratio);

in math
1/0 has to be +infinite ( for approximation +INT_MAX for C?)
but should be one error if one want one infinite array long 
as in "int a[1/0]" or want to do infinite/0 infinite-inifinite
infinite/infinite ecc could be ok if one make infinite+infinite=
infinite, infinite * infinite = infinite ecc



>}
>
>It's not portable, but on the systems where I've tried it it sets
>one to 1 and zero to 0 in a way that the compiler can't detect,
>so the division won't be optimized away.  (At least, it does so if
>you run it between 2001 and 2286.)
>
>On x86_64, it dies with a floating point exception.
>
>On aarch64, it prints 0.

[toc] | [prev] | [next] | [standalone]

#393081

On 30/04/2025 12:41, Rosario19 wrote:
> On Fri, 25 Apr 2025 12:05:13 -0700, Keith Thompson wrote:
> 
>> Thiago Adams writes:
>>> Does anyone know of any platform where integer division by zero
>>> returns a number, or in other words, where it's not treated as an
>>> error? I'm asking because division by zero is undefined behaviour, but
>>> I think division by a constant zero should be a constraint instead.
>>
>> Division by a constant zero is a constraint violation in a context that
>> requires a constant expression.
>>
>> I wrote this quick and dirty program:
>>
>> #include <stdio.h>
>> #include <time.h>
>> int main(void) {
>>     int one = time(NULL) / 1000000000;
>>     int zero = one - 1;
>>     int ratio = one / zero;
>>     printf("%d\n", ratio);
> 
> in math
> 1/0 has to be +infinite ( for approximation +INT_MAX for C?)

In common mathematics, 1 / 0 is undefined - just like in C.  If you 
extend the set of real numbers to include some kind of infinity ∞ , you 
immediately lose many other useful properties of the set.  INT_MAX is 
not a good approximation - there is no int value that makes sense for 
the result of 1 / 0.

[toc] | [prev] | [next] | [standalone]

#392897

Thiago Adams <thiago.adams@gmail.com> wrote:
> Does anyone know of any platform where integer division by zero returns 
> a number, or in other words, where it's not treated as an error? I'm 
> asking because division by zero is undefined behaviour, but I think 
> division by a constant zero should be a constraint instead.

I know of none and I have programmed on a few platforms.

Some had the ability to trap these issues with a statement,
but usually it was easier to check for 0 first.

-- 
[t]csh(1) - "An elegant shell, for a more... civilized age."
                        - Paraphrasing Star Wars

[toc] | [prev] | [next] | [standalone]

#392904

Thiago Adams <thiago.adams@gmail.com> wrote:
> Does anyone know of any platform where integer division by zero returns 
> a number, or in other words, where it's not treated as an error? I'm 
> asking because division by zero is undefined behaviour, but I think 
> division by a constant zero should be a constraint instead.

That question/proposal keeps to reappearing in various languages.
One reason to _not_ make it a constraint is the following nonportable
code (which assumes that division by zero is trapped at runtime):

int
signal_error(void) {
    return 1/0;
}

This in not portable, but at least in the past it was most portable
method to signal errors.  Portable in the sense that the method worked
in several programming languages and on various operating systems.
C library has 'exit' which should be preferable in most cases but
sometimes division by zero gives most appropriate indication of
error.

There is also another (probably more important) issue: there may
be division by zero on code path that is never executed.  One can
argue that division by "absolute" zero should be eliminated and non
exectuted code path should be removed.  But having zero or not may
depend on configuration, on configurations where constant is nonzero
code path may be doing something useful.
 
I am affraid that there is enough uses of the both features to
consider your proposal as breaking change.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#392914

Am 25.04.2025 um 19:38 schrieb Thiago Adams:

> Does anyone know of any platform where integer division by zero returns 
> a number, or in other words, where it's not treated as an error? I'm 
> asking because division by zero is undefined behaviour, but I think 
> division by a constant zero should be a constraint instead.

I guess the trap is induced on all platforms since there's no binary
representation for +/-inf with integrals.
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.

[toc] | [prev] | [next] | [standalone]

#392915

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>
#include <stdio.h>

using namespace std;

int main()
{
	__try
	{
		int volatile a = 1, b = 0;
		a /= b;
	}
	__except( EXCEPTION_EXECUTE_HANDLER )
	{
		printf( "caught !" );
	}
}

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web