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

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

Would someone tell me if I'm on the wrong track?

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

Contents

  Would someone tell me if I'm on the wrong track? luser- -droog <mijoryx@yahoo.com> - 2011-05-09 23:47 -0700
    Re: Would someone tell me if I'm on the wrong track? luser- -droog <mijoryx@yahoo.com> - 2011-05-10 00:05 -0700
    Re: Would someone tell me if I'm on the wrong track? "io_x" <a@b.c.invalid> - 2011-05-11 08:31 +0200
      Re: Would someone tell me if I'm on the wrong track? luser- -droog <mijoryx@yahoo.com> - 2011-05-10 23:46 -0700
      Re: Would someone tell me if I'm on the wrong track? luser- -droog <mijoryx@yahoo.com> - 2011-05-11 23:05 -0700
        Re: Would someone tell me if I'm on the wrong track? Seebs <usenet-nospam@seebs.net> - 2011-05-12 07:36 +0000
          Re: Would someone tell me if I'm on the wrong track? pete <pfiland@mindspring.com> - 2011-05-12 07:51 -0400
          Re: Would someone tell me if I'm on the wrong track? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-14 03:34 +0100
            Re: Would someone tell me if I'm on the wrong track? pete <pfiland@mindspring.com> - 2011-05-13 23:19 -0400
              Re: Would someone tell me if I'm on the wrong track? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-14 12:02 +0100
        Re: Would someone tell me if I'm on the wrong track? pete <pfiland@mindspring.com> - 2011-05-12 08:01 -0400
          Re: Would someone tell me if I'm on the wrong track? Seebs <usenet-nospam@seebs.net> - 2011-05-12 15:57 +0000
            Re: Would someone tell me if I'm on the wrong track? pete <pfiland@mindspring.com> - 2011-05-12 18:04 -0400
              Re: Would someone tell me if I'm on the wrong track? Seebs <usenet-nospam@seebs.net> - 2011-05-12 22:18 +0000
              Re: Would someone tell me if I'm on the wrong track? luser- -droog <mijoryx@yahoo.com> - 2011-05-12 23:05 -0700
                Re: Would someone tell me if I'm on the wrong track? "io_x" <a@b.c.invalid> - 2011-05-13 10:21 +0200
          Re: Would someone tell me if I'm on the wrong track? luser- -droog <mijoryx@yahoo.com> - 2011-05-12 09:33 -0700
        Re: Would someone tell me if I'm on the wrong track? Peter Nilsson <airia@acay.com.au> - 2011-05-12 22:47 -0700
          Re: Would someone tell me if I'm on the wrong track? "io_x" <a@b.c.invalid> - 2011-05-13 10:21 +0200
          Re: Would someone tell me if I'm on the wrong track? Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-18 22:21 -0700
            Re: Would someone tell me if I'm on the wrong track? Peter Nilsson <airia@acay.com.au> - 2011-05-18 23:47 -0700
              Re: Would someone tell me if I'm on the wrong track? Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-19 11:00 -0700

Page 2 of 2 — ← Prev page 1 [2]

#4296

Tim Rentsch <t...@alumni.caltech.edu> wrote:
> Peter Nilsson <ai...@acay.com.au> writes:
> > Conversion of an unsigned int value not in the range of int to
> > an int is unspecified in C90 and (to all intents and purposes)
> > undefined behaviour in C99.
>
> Correction:  in both cases the behavior is implementation defined.

So, unspecified but requiring the implementation to document its
choice.

> In C90 that is limited to producing an implementation-defined
> value.  C99 expands that just slightly to allow raising an
> implementation-defined signal.  This is different from UB both
> in principle

Perhaps.

> and in practice:

Well, I suppose it's possible to do...

  void bye(int sig) { _Exit(0); }

  int main(void)
  {
    for (int sig = 0; sig < INT_MAX; sig++)
      signal(sig, bye);
    signal(INT_MAX, bye);
    ...safe and sound...
  }

But that's not exactly practical on a 64-bit int machine.

--
Peter

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

#4341

Peter Nilsson <airia@acay.com.au> writes:

> Tim Rentsch <t...@alumni.caltech.edu> wrote:
>> Peter Nilsson <ai...@acay.com.au> writes:
>> > Conversion of an unsigned int value not in the range of int to
>> > an int is unspecified in C90 and (to all intents and purposes)
>> > undefined behaviour in C99.
>>
>> Correction:  in both cases the behavior is implementation defined.
>
> So, unspecified but requiring the implementation to document its
> choice.

Yes, that follows from the definition of implementation-defined
behavior.  It's still important to make the distinction.

>> In C90 that is limited to producing an implementation-defined
>> value.  C99 expands that just slightly to allow raising an
>> implementation-defined signal.  This is different from UB both
>> in principle
>
> Perhaps.
>
>> and in practice:
>
> Well, I suppose it's possible to do...
>
>   void bye(int sig) { _Exit(0); }
>
>   int main(void)
>   {
>     for (int sig = 0; sig < INT_MAX; sig++)
>       signal(sig, bye);
>     signal(INT_MAX, bye);
>     ...safe and sound...
>   }
>
> But that's not exactly practical on a 64-bit int machine.

Oh come on, I know you're smarter than that.  Because
the signal in question is implementation-defined, it
must be documented, and an appropriate signal call
can be written.  More to the point, such calls are
necessary only if the program is going to run on
implementations that do in fact raise a signal in
these cases, and almost none do;  simply checking
the documentation for the implementations that are
to be supported will reveal which ones need to set
a signal handler, and the most likely case is that
none will.

You seem to be assuming that it only makes sense to write
code that is guaranteed to be 100% portable for any
imaginable conforming implementation.  Obviously that isn't
realistically practical for a program of any significant
size -- there are bound to be some rough edges here and
there.  As non-portable transgressions go, converting an
out-of-range value to a signed type is among the least
likely to be problematic.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web