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

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

about NULL as a parameter to a libc function

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

Contents

  about NULL as a parameter to a libc function gaoqiang <gaoqiangscut@gmail.com> - 2011-10-28 01:49 -0700
    Re: about NULL as a parameter to a libc function Mark Bluemel <mark_bluemel@pobox.com> - 2011-10-28 10:14 +0100
      Re: about NULL as a parameter to a libc function gaoqiang <gaoqiangscut@gmail.com> - 2011-10-28 03:22 -0700
        Re: about NULL as a parameter to a libc function Mark Bluemel <mark_bluemel@pobox.com> - 2011-10-28 11:29 +0100
          Re: about NULL as a parameter to a libc function Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-10-29 07:08 +0000
        Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-10-28 07:05 -0400
        Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-28 14:15 -0700
        Re: about NULL as a parameter to a libc function gordonb.4o15x@burditt.org (Gordon Burditt) - 2011-10-28 16:36 -0500
          Re: about NULL as a parameter to a libc function Robert Wessel <robertwessel2@yahoo.com> - 2011-10-28 17:30 -0500
            Re: about NULL as a parameter to a libc function jgharston <jgh@arcade.demon.co.uk> - 2011-10-31 10:40 -0700
        Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-10-28 22:32 +0000
        Re: about NULL as a parameter to a libc function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-29 06:20 -0700
          Re: about NULL as a parameter to a libc function "BartC" <bc@freeuk.com> - 2011-10-29 15:40 +0100
            Re: about NULL as a parameter to a libc function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-30 08:05 -0700
      Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-28 14:13 -0700
        Re: about NULL as a parameter to a libc function Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-29 15:11 +0300
          Re: about NULL as a parameter to a libc function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-29 06:41 -0700
          Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-29 11:29 -0700
    Re: about NULL as a parameter to a libc function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-28 02:36 -0700
      Re: about NULL as a parameter to a libc function Mike Manilone <mike@laptop.mike> - 2011-10-28 12:58 +0000
        Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-10-28 11:00 -0400
          Re: about NULL as a parameter to a libc function Kenneth Brody <kenbrody@spamcop.net> - 2011-11-03 11:13 -0400
        Re: about NULL as a parameter to a libc function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-29 06:37 -0700
        Re: about NULL as a parameter to a libc function Kenneth Brody <kenbrody@spamcop.net> - 2011-11-03 11:00 -0400
          Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-11-03 12:54 -0400
            Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-11-03 17:08 +0000
              Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-11-03 13:18 -0400
                Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-11-03 17:28 +0000
                  Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-11-03 13:48 -0400
                    Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-11-03 17:55 +0000
                      Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-11-03 14:12 -0400
                        Re: about NULL as a parameter to a libc function blp@cs.stanford.edu (Ben Pfaff) - 2011-11-03 11:22 -0700
                          Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-11-03 14:28 -0400
                        Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-11-03 19:47 +0000
                          Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-11-03 16:19 -0400
                        Re: about NULL as a parameter to a libc function Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 22:13 -0800
                      Re: about NULL as a parameter to a libc function Ike Naar <ike@sverige.freeshell.org> - 2011-11-03 18:20 +0000
                        Re: about NULL as a parameter to a libc function Ike Naar <ike@sverige.freeshell.org> - 2011-11-03 18:34 +0000
                          Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-11-03 19:49 +0000
                            Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-11-03 16:21 -0400
                            Re: about NULL as a parameter to a libc function Ike Naar <ike@iceland.freeshell.org> - 2011-11-03 22:19 +0000
                          Re: about NULL as a parameter to a libc function Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 22:17 -0800
            Re: about NULL as a parameter to a libc function Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 21:19 -0800
      Re: about NULL as a parameter to a libc function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-28 14:26 +0100
        Re: about NULL as a parameter to a libc function Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-10-28 12:46 -0600
        Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-28 14:19 -0700
          Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-28 16:37 -0700
    Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-10-28 07:22 -0400
      Re: about NULL as a parameter to a libc function Kenneth Brody <kenbrody@spamcop.net> - 2011-11-03 10:40 -0400
        Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-11-03 15:10 +0000
        Re: about NULL as a parameter to a libc function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-04 03:03 +0000
    Re: about NULL as a parameter to a libc function Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-28 08:42 -0400
    Re: about NULL as a parameter to a libc function "io_x" <a@b.c.invalid> - 2011-10-28 16:31 +0200
    Re: about NULL as a parameter to a libc function "BartC" <bc@freeuk.com> - 2011-10-28 20:29 +0100
      Re: about NULL as a parameter to a libc function Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-29 14:49 +0300
        Re: about NULL as a parameter to a libc function Ike Naar <ike@sverige.freeshell.org> - 2011-10-29 13:41 +0000
    Re: about NULL as a parameter to a libc function John Gordon <gordon@panix.com> - 2011-10-28 19:53 +0000
      Re: about NULL as a parameter to a libc function "BartC" <bc@freeuk.com> - 2011-10-28 21:13 +0100
        Re: about NULL as a parameter to a libc function John Gordon <gordon@panix.com> - 2011-10-28 20:33 +0000
          Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-10-28 16:56 -0400
            Re: about NULL as a parameter to a libc function blp@cs.stanford.edu (Ben Pfaff) - 2011-10-28 14:30 -0700
        Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-10-28 16:45 -0400
        Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-28 15:35 -0700
          Re: about NULL as a parameter to a libc function "BartC" <bc@freeuk.com> - 2011-10-29 13:00 +0100
            Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-29 11:26 -0700
              Re: about NULL as a parameter to a libc function "BartC" <bc@freeuk.com> - 2011-10-29 20:24 +0100
                Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-29 14:03 -0700
        Re: about NULL as a parameter to a libc function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-29 07:30 -0700
        Re: about NULL as a parameter to a libc function Kenneth Brody <kenbrody@spamcop.net> - 2011-11-03 11:26 -0400
          Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-11-03 12:59 -0400
          Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-11-03 13:42 -0700
    Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-10-28 20:17 +0000
      Re: about NULL as a parameter to a libc function Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-28 18:51 -0400
    Re: about NULL as a parameter to a libc function Nobody <nobody@nowhere.com> - 2011-10-28 21:40 +0100
      Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-10-28 17:09 -0400
        Re: about NULL as a parameter to a libc function Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-29 15:03 +0300
          Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-10-29 09:42 -0400
      Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-10-28 21:18 +0000
        Re: about NULL as a parameter to a libc function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-28 23:30 +0100
        Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-28 15:37 -0700
          Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-10-28 23:47 +0000
            Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-28 17:13 -0700
              Re: about NULL as a parameter to a libc function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-29 04:31 +0100
                Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-10-29 05:42 +0000
                  Re: about NULL as a parameter to a libc function Seebs <usenet-nospam@seebs.net> - 2011-10-30 17:22 +0000
                    Re: about NULL as a parameter to a libc function Patrick Scheible <kkt@zipcon.net> - 2011-10-30 23:43 -0700
                      Re: about NULL as a parameter to a libc function Robert Wessel <robertwessel2@yahoo.com> - 2011-10-31 05:31 -0500
                        Re: about NULL as a parameter to a libc function Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-31 12:42 +0200
                          Re: about NULL as a parameter to a libc function Robert Wessel <robertwessel2@yahoo.com> - 2011-10-31 13:11 -0500
                      Re: about NULL as a parameter to a libc function Seebs <usenet-nospam@seebs.net> - 2011-10-31 17:18 +0000
        Re: about NULL as a parameter to a libc function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-29 07:32 -0700
      Re: about NULL as a parameter to a libc function jacob navia <jacob@spamsink.net> - 2011-10-28 23:41 +0200
        Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-10-28 22:42 +0000
          Re: about NULL as a parameter to a libc function jacob navia <jacob@spamsink.net> - 2011-10-29 10:09 +0200
            Re: about NULL as a parameter to a libc function Nobody <nobody@nowhere.com> - 2011-10-29 10:11 +0100
              Re: about NULL as a parameter to a libc function Angel <angel+news@spamcop.net> - 2011-10-29 09:42 +0000
              Re: about NULL as a parameter to a libc function jacob navia <jacob@spamsink.net> - 2011-10-29 16:17 +0200
            Re: about NULL as a parameter to a libc function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-29 07:39 -0700
              Re: about NULL as a parameter to a libc function jacob navia <jacob@spamsink.net> - 2011-10-29 19:29 +0200
                Re: about NULL as a parameter to a libc function "io_x" <a@b.c.invalid> - 2011-10-29 20:25 +0200
                Re: about NULL as a parameter to a libc function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-30 08:14 -0700
      Re: about NULL as a parameter to a libc function ImpalerCore <jadill33@gmail.com> - 2011-10-31 18:30 -0700
        Re: about NULL as a parameter to a libc function Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 18:21 -0800
      Re: about NULL as a parameter to a libc function Kenneth Brody <kenbrody@spamcop.net> - 2011-11-03 11:31 -0400
        Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-11-03 13:45 -0700
    Re: about NULL as a parameter to a libc function Jonathan Leffler <jleffler@earthlink.net> - 2011-10-29 23:41 -0700
      Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-10-30 07:13 -0400

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#12215

On 2011-10-28, Keith Thompson <kst-u@mib.org> wrote:
> One could make a case that a null pointer is Not A String, in a similar
> sense to the way NaN is Not A Number.  NaN compares unequal to itself.

In ISO 9899:1999 there is an absence of a requirement that a NaN compares equal
to itself, which isn't the same thing at all.

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

#12216

Kaz Kylheku <kaz@kylheku.com> writes:
> On 2011-10-28, Keith Thompson <kst-u@mib.org> wrote:
>> One could make a case that a null pointer is Not A String, in a similar
>> sense to the way NaN is Not A Number.  NaN compares unequal to itself.
>
> In ISO 9899:1999 there is an absence of a requirement that a NaN
> compares equal to itself, which isn't the same thing at all.

6.5.9 just says that the == operator "yields 1 if the specified relation
is true and 0 if it is false"; it doesn't say just what that means.
It's not entirely clear from that that 1.0 == 1.0 must yield 1.

Annex F (which is optional) says that "The relational and equality
operators provide IEC 60559 comparisons."  I'm not entirely sure what
that means, but I guess it requires a NaN to compare unequal to itself.

In any case, my point was that a NaN *conventionally* compares unequal
to itself, and this *could* be used as a precedent to argue that
strcmp(NULL, NULL) might reasonably return a result denoting inequality.

And again, I'm not advocating any such thing.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#12220

Keith Thompson <kst-u@mib.org> writes:

> Kaz Kylheku <kaz@kylheku.com> writes:
>> On 2011-10-28, Keith Thompson <kst-u@mib.org> wrote:
>>> One could make a case that a null pointer is Not A String, in a similar
>>> sense to the way NaN is Not A Number.  NaN compares unequal to itself.
>>
>> In ISO 9899:1999 there is an absence of a requirement that a NaN
>> compares equal to itself, which isn't the same thing at all.
>
> 6.5.9 just says that the == operator "yields 1 if the specified relation
> is true and 0 if it is false"; it doesn't say just what that means.
> It's not entirely clear from that that 1.0 == 1.0 must yield 1.
>
> Annex F (which is optional) says that "The relational and equality
> operators provide IEC 60559 comparisons."  I'm not entirely sure what
> that means, but I guess it requires a NaN to compare unequal to
> itself.

Also, 6.2.6.1 p4 says (in part):

  "Two values (other than NaNs) with the same object representation
  compare equal..."

I think that's what Kaz is referring to by the "absence of a
requirement that a NaN compares equal to itself".

-- 
Ben.

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

#12221

On 2011-10-29, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Keith Thompson <kst-u@mib.org> writes:
>
>> Kaz Kylheku <kaz@kylheku.com> writes:
>>> On 2011-10-28, Keith Thompson <kst-u@mib.org> wrote:
>>>> One could make a case that a null pointer is Not A String, in a similar
>>>> sense to the way NaN is Not A Number.  NaN compares unequal to itself.
>>>
>>> In ISO 9899:1999 there is an absence of a requirement that a NaN
>>> compares equal to itself, which isn't the same thing at all.
>>
>> 6.5.9 just says that the == operator "yields 1 if the specified relation
>> is true and 0 if it is false"; it doesn't say just what that means.
>> It's not entirely clear from that that 1.0 == 1.0 must yield 1.
>>
>> Annex F (which is optional) says that "The relational and equality
>> operators provide IEC 60559 comparisons."  I'm not entirely sure what
>> that means, but I guess it requires a NaN to compare unequal to
>> itself.
>
> Also, 6.2.6.1 p4 says (in part):
>
>   "Two values (other than NaNs) with the same object representation
>   compare equal..."
>
> I think that's what Kaz is referring to by the "absence of a
> requirement that a NaN compares equal to itself".

Well, that would be one place where the requirement isn't made.
The other places would be ... all other sentences of the document. :)

It does appear that IEEE 754 specifies this lunacy of a NaN comparing
not equal with itself, however.

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

#12295

On 2011-10-29, Kaz Kylheku <kaz@kylheku.com> wrote:
> It does appear that IEEE 754 specifies this lunacy of a NaN comparing
> not equal with itself, however.

It's not lunacy.  These people... they do a lot of things that look
really weird, but it turns out that there are sound technical reasons for
it.

It's like the goat you sacrifice to make a SCSI chain work.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#12319

Seebs <usenet-nospam@seebs.net> writes:

> On 2011-10-29, Kaz Kylheku <kaz@kylheku.com> wrote:
>> It does appear that IEEE 754 specifies this lunacy of a NaN comparing
>> not equal with itself, however.
>
> It's not lunacy.  These people... they do a lot of things that look
> really weird, but it turns out that there are sound technical reasons for
> it.
>
> It's like the goat you sacrifice to make a SCSI chain work.

Somehow SCSI got a worse reputation than it deserves.  I used NeXTs with
several SCSI devices hanging off of them and never had any trouble with
them.  Contemporary IDE drives were a PITA by comparison.

-- Patrick

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

#12331

On Sun, 30 Oct 2011 23:43:33 -0700, Patrick Scheible <kkt@zipcon.net>
wrote:

>Seebs <usenet-nospam@seebs.net> writes:
>
>> On 2011-10-29, Kaz Kylheku <kaz@kylheku.com> wrote:
>>> It does appear that IEEE 754 specifies this lunacy of a NaN comparing
>>> not equal with itself, however.
>>
>> It's not lunacy.  These people... they do a lot of things that look
>> really weird, but it turns out that there are sound technical reasons for
>> it.
>>
>> It's like the goat you sacrifice to make a SCSI chain work.
>
>Somehow SCSI got a worse reputation than it deserves.  I used NeXTs with
>several SCSI devices hanging off of them and never had any trouble with
>them.  Contemporary IDE drives were a PITA by comparison.


It was the combination of multitudes of connectors and different
busses that had partial interoperability.  For example, you could put
wide and narrow SCSI devices on the same bus, but you had to terminate
half the bus at the point where the bus transitioned between wide and
narrow.

And if you unexpectedly got a mix of differential and single ended
devices, you'd be scrambling to put another SCSI channel on your
machine.

Then there were the connectors.  There were literally dozens in use,
for the same bus.  Invariably if you had three devices, one would have
a Centronics connector, another a micro DB-68 connector, and the third
a DB-25.  If you had a fourth device, it invariably had a proprietary
connector.  And in some cases the same connectors for different
busses.  Try getting the right set of cables for all the different
combinations ahead of times.  And vendors loved to use different
genders of connectors.

Or the common (especially in later years) appearance of two devices
that had only a single connector, and you needed a tee for one of them
to get both on the same channel.

You could have a drawer full of adapters, tees and terminators, and a
closet full of cables, and you still never seemed to have the right
combination of ends.

Or the plethora of jumper settings on most devices.  It was hard
enough to keep all the IDs straight, with the wildly inconsistent
jump/switch usage (number right-to-left or left-to-right, on-is-one or
on-is-zero), which half the time didn't have a label on the device, so
setting them required finding the documentation.  And then there were
devices that supported both single-ended and differential connection,
or narrow or wide, or different speeds, on the same connector, based
on the jumper settings.

Nor did it help that much of the early hardware and software was crap
too.  Anyone remember the Novel DCBs ("smart" SCSI HBAs) that
supported only the 6-byte commands and silently truncated block
numbers bigger than 2**21?  Or the many early SCSI devices that
implemented slightly different versions of commands?  At one point,
OSs supporting SCSI HDs needed drivers for each model of disk drive
attached.  Or bizarre hardware like HBAs that *only* supported CD-ROM
drives?

And then a bunch of the HBA vendors got the ISA plug-n-play religion,
which meant that in addition to the connection issues, half the time
the cards wouldn't work in your PC until you figured out how to
disable PNP on the card.

It improved a lot over the years (although parallel SCSI never became
consistent enough to be considered "easy"), but early SCSI fell *far*
short of its promise to be a general purpose I/O channel.

I'll stop ranting now.

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

#12335

Robert Wessel <robertwessel2@yahoo.com> writes:
> On Sun, 30 Oct 2011 23:43:33 -0700, Patrick Scheible <kkt@zipcon.net>
> wrote:
> 
> >Seebs <usenet-nospam@seebs.net> writes:
> >
> >> On 2011-10-29, Kaz Kylheku <kaz@kylheku.com> wrote:
> >>> It does appear that IEEE 754 specifies this lunacy of a NaN comparing
> >>> not equal with itself, however.
> >>
> >> It's not lunacy.  These people... they do a lot of things that look
> >> really weird, but it turns out that there are sound technical reasons for
> >> it.
> >>
> >> It's like the goat you sacrifice to make a SCSI chain work.
> >
> >Somehow SCSI got a worse reputation than it deserves.  I used NeXTs with
> >several SCSI devices hanging off of them and never had any trouble with
> >them.  Contemporary IDE drives were a PITA by comparison.
> 
> 
> It was the combination of multitudes of connectors and different
> busses that had partial interoperability.[...]
> And [...]
> Then [...]
> Or [...]
> and [...]
> Or [...]
> Nor [...]
> And [...]
> 
> It improved a lot over the years (although parallel SCSI never became
> consistent enough to be considered "easy"), but early SCSI fell *far*
> short of its promise to be a general purpose I/O channel.
> 
> I'll stop ranting now.

What amuses me is that on the other side of the interface, the OS
talking SCSI commands to adapters, the interface was so generically
useful that it got used and abused by all kinds of non-SCSI devices.
(At least in Linux.) Wanna burn an IDE CDR? Use sg. Plug in a USB
stick? Find it under /dev/sd*. ...

Phil
-- 
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

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

#12387

On 31 Oct 2011 12:42:21 +0200, Phil Carmody
<thefatphil_demunged@yahoo.co.uk> wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>> On Sun, 30 Oct 2011 23:43:33 -0700, Patrick Scheible <kkt@zipcon.net>
>> wrote:
>> 
>> >Seebs <usenet-nospam@seebs.net> writes:
>> >
>> >> On 2011-10-29, Kaz Kylheku <kaz@kylheku.com> wrote:
>> >>> It does appear that IEEE 754 specifies this lunacy of a NaN comparing
>> >>> not equal with itself, however.
>> >>
>> >> It's not lunacy.  These people... they do a lot of things that look
>> >> really weird, but it turns out that there are sound technical reasons for
>> >> it.
>> >>
>> >> It's like the goat you sacrifice to make a SCSI chain work.
>> >
>> >Somehow SCSI got a worse reputation than it deserves.  I used NeXTs with
>> >several SCSI devices hanging off of them and never had any trouble with
>> >them.  Contemporary IDE drives were a PITA by comparison.
>> 
>> 
>> It was the combination of multitudes of connectors and different
>> busses that had partial interoperability.[...]
>> And [...]
>> Then [...]
>> Or [...]
>> and [...]
>> Or [...]
>> Nor [...]
>> And [...]
>> 
>> It improved a lot over the years (although parallel SCSI never became
>> consistent enough to be considered "easy"), but early SCSI fell *far*
>> short of its promise to be a general purpose I/O channel.
>> 
>> I'll stop ranting now.
>
>What amuses me is that on the other side of the interface, the OS
>talking SCSI commands to adapters, the interface was so generically
>useful that it got used and abused by all kinds of non-SCSI devices.
>(At least in Linux.) Wanna burn an IDE CDR? Use sg. Plug in a USB
>stick? Find it under /dev/sd*. ...


Certainly true.  The SCSI command set has been used on everything from
"real" SCSI" to FC to ATAPI to USB to iSCSI, to SAS, to...

I think partially by accident, the Shugart guys managed to develop a
fairly clean separation of the transport and logical protocols (and
defined the latter at a reasonable level - not to high, not too low),
and made it reasonably open, in an era where those sorts of things
weren't that common.

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

#12379

On 2011-10-31, Patrick Scheible <kkt@zipcon.net> wrote:
> Somehow SCSI got a worse reputation than it deserves.  I used NeXTs with
> several SCSI devices hanging off of them and never had any trouble with
> them.  Contemporary IDE drives were a PITA by comparison.

It mostly, I think, had to do with the Mac "innovation" of a 25-pin port
using a common ground.  I had endless trouble with SCSI devices using that
connector.  Probably my only real complaint about the Amiga 3000.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#12240

On Oct 28, 10:18 pm, Kaz Kylheku <k...@kylheku.com> wrote:
> On 2011-10-28, Nobody <nob...@nowhere.com> wrote:
>
> > On Fri, 28 Oct 2011 01:49:45 -0700, gaoqiang wrote:
>
> >> why memcpy,strcmp .etc ,these libc functions, do not
> >> accept NULL pointer ? called with NULL, just get  segment
> >> fault.  for efficiency ?
>
> > What would you expect strcmp("", NULL) to return?
>
> If this combination of inputs were to be defined, I would expect the null
> pointer not to compare equal to any string, since it isn't one.
>
> The remaining question, then, is where the null pointer lands in a
> lexicographic comparison against strings. I would place it ahead of
> strings, so that if you a null mixed up among a set of strings, it
> makes itself obvious by taking the top position in a sorted list.
>
> Furthermore, strcmp(NULL, NULL) ought return zero, since it is astonishing
> if a thing is not deemed equal to itself (reflexive property of the equivalence
> relation).

NaNs are astonishing

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

#12203

Le 28/10/11 22:40, Nobody a écrit :
> On Fri, 28 Oct 2011 01:49:45 -0700, gaoqiang wrote:
>
>> why memcpy,strcmp .etc ,these libc functions, do not
>> accept NULL pointer ? called with NULL, just get  segment
>> fault.  for efficiency ?
>
> What would you expect strcmp("", NULL) to return?
>

I would return a previously defined error value
(implementation defined) like INT_MIN+20 for instance.

Furthermore errno should be set to EINVAL

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

#12211

On 2011-10-28, jacob navia <jacob@spamsink.net> wrote:
> Le 28/10/11 22:40, Nobody a écrit :
>> On Fri, 28 Oct 2011 01:49:45 -0700, gaoqiang wrote:
>>
>>> why memcpy,strcmp .etc ,these libc functions, do not
>>> accept NULL pointer ? called with NULL, just get  segment
>>> fault.  for efficiency ?
>>
>> What would you expect strcmp("", NULL) to return?
>>
>
> I would return a previously defined error value
> (implementation defined) like INT_MIN+20 for instance.

This is neither a good debugging aid for those who regard the above to be a
bug, nor a very meaningful extension of behavior for those who don't.

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

#12225

Le 29/10/11 00:42, Kaz Kylheku a écrit :
> On 2011-10-28, jacob navia<jacob@spamsink.net>  wrote:
>> Le 28/10/11 22:40, Nobody a écrit :
>>> On Fri, 28 Oct 2011 01:49:45 -0700, gaoqiang wrote:
>>>
>>>> why memcpy,strcmp .etc ,these libc functions, do not
>>>> accept NULL pointer ? called with NULL, just get  segment
>>>> fault.  for efficiency ?
>>>
>>> What would you expect strcmp("", NULL) to return?
>>>
>>
>> I would return a previously defined error value
>> (implementation defined) like INT_MIN+20 for instance.
>
> This is neither a good debugging aid for those who regard the above to be a
> bug, nor a very meaningful extension of behavior for those who don't.

yeah sure, just crash. That's the best solution for any error.

Forgot something? Did a small mistake somewhere?

Crash everything, that's THE BEST SOLUTION FOR ALL ERRORS.

That way there isn't any way of writing something solid in C,
ànd you have to hear again...

"Go to C++, C is just fucked up"

Mr Kylheju asserts (without any arguments since his word suffices)
"This is not a good debugging aid", returning an error code. Crashing
is better.

And why? Couldn't those "who regard the above to be a bug" TEST for
an error code?

No, that would be too easy. Just crash. That's a good solution.

And why setting errno and returning an error code is "not very
meaningful extension"?

Because he says so.

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

#12227

On Sat, 29 Oct 2011 10:09:31 +0200, jacob navia wrote:

>>> I would return a previously defined error value
>>> (implementation defined) like INT_MIN+20 for instance.
>>
>> This is neither a good debugging aid for those who regard the above to be a
>> bug, nor a very meaningful extension of behavior for those who don't.

Agreed. If the programmer isn't paying attention to whether they're
passing null pointers to strcmp() etc, they aren't going to be paying
attention to whether it flagged an error.

> yeah sure, just crash. That's the best solution for any error.

If you want Java, you know where to find it.

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

#12228

On 2011-10-29, Nobody <nobody@nowhere.com> wrote:
> On Sat, 29 Oct 2011 10:09:31 +0200, jacob navia wrote:
>
>>>> I would return a previously defined error value
>>>> (implementation defined) like INT_MIN+20 for instance.
>>>
>>> This is neither a good debugging aid for those who regard the above to be a
>>> bug, nor a very meaningful extension of behavior for those who don't.
>
> Agreed. If the programmer isn't paying attention to whether they're
> passing null pointers to strcmp() etc, they aren't going to be paying
> attention to whether it flagged an error.
>
Seconded. I prefer a program crashing during the test phase, telling the
programmer that he is an idiot, over the program being used as a point
of entry by some malicious hacker in the future.

>> yeah sure, just crash. That's the best solution for any error.
>
> If you want Java, you know where to find it.

Sweeping generalization from mr Navia. Nobody claimed crashing is the sane
thing to do in all situations, but he apparently has trouble accepting
it's the sane thing to do in some situations.

C assumes the programmer knows what he is doing and punishes the
programmer who does not. Java does neither, and thus managers tend to
assume every blind idiot can program in Java. In my daily work as an
admin, I'm regularly confronted with the results of the latter, and let
me tell you that they are not pretty.


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

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

#12238

Le 29/10/11 11:11, Nobody a écrit :
> On Sat, 29 Oct 2011 10:09:31 +0200, jacob navia wrote:
>
>>>> I would return a previously defined error value
>>>> (implementation defined) like INT_MIN+20 for instance.
>>>
>>> This is neither a good debugging aid for those who regard the above to be a
>>> bug, nor a very meaningful extension of behavior for those who don't.
>
> Agreed. If the programmer isn't paying attention to whether they're
> passing null pointers to strcmp() etc, they aren't going to be paying
> attention to whether it flagged an error.
>

Error analysis and error reporting is then, completely unnecessary.

Just crash, so they will learn how to program.

>> yeah sure, just crash. That's the best solution for any error.
>
> If you want Java, you know where to find it.
>

Speak about error analysis and the answer is always the same:

error analysis is for bad programmers that make errors. Good programmers
that use C never make any error and error analysis is just not necessary
for those super-heroes.

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

#12245

On Oct 29, 9:09 am, jacob navia <ja...@spamsink.net> wrote:
> Le 29/10/11 00:42, Kaz Kylheku a écrit :
> > On 2011-10-28, jacob navia<ja...@spamsink.net>  wrote:
> >> Le 28/10/11 22:40, Nobody a écrit :

<snip>

> >>> What would you expect strcmp("", NULL) to return?
>
> >> I would return a previously defined error value
> >> (implementation defined) like INT_MIN+20 for instance.
>
> > This is neither a good debugging aid for those who regard the above to be a
> > bug, nor a very meaningful extension of behavior for those who don't.
>
> yeah sure, just crash. That's the best solution for any error.

you're putting words in his mouth. There are arguments for very low
level stuff not doing such checking, whilst higher level stuff checks.
If you're not sure about your arguments to memcpy() you could stick
some asserts in.


> Forgot something? Did a small mistake somewhere?
>
> Crash everything, that's THE BEST SOLUTION FOR ALL ERRORS.
>
> That way there isn't any way of writing something solid in C,
> ànd you have to hear again...
>
> "Go to C++, C is just fucked up"

which would be silly as C++ has a similar philosophy to C. For
instance memcpy() is also aC++ function. And much of the STLis
unchecked.

std::vector v [20];

v[-1]=0;
v[20]=0;

> Mr Kylheju asserts (without any arguments since his word suffices)
> "This is not a good debugging aid", returning an error code. Crashing
> is better.

crashing is better for those who don't check error codes.

<snip rant>

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

#12248

Le 29/10/11 16:39, Nick Keighley a écrit :
>> Mr Kylheju asserts (without any arguments since his word suffices)
>> "This is not a good debugging aid", returning an error code. Crashing
>> is better.
>
> crashing is better for those who don't check error codes.
>

What a moron!

How can you check an error code if the program crashes?

Go figure, maybe he runs his applications always inside a debugger.

There is no point in discussing with people like this any further.

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

#12251

"jacob navia" <jacob@spamsink.net> ha scritto nel messaggio 
news:j8hd6f$jpm$1@speranza.aioe.org...
> Le 29/10/11 16:39, Nick Keighley a écrit :
>>> Mr Kylheju asserts (without any arguments since his word suffices)
>>> "This is not a good debugging aid", returning an error code. Crashing
>>> is better.
>>
>> crashing is better for those who don't check error codes.
>>
>
> What a moron!
>
> How can you check an error code if the program crashes?

but we know it have one...
the real problem is when a program run, all know there are errors
and nobody see where is the origin of these

as someone has already say: if you *can not check* errors then crash
is good
in some assembly program in some path i pose too something as
mov eax, 0|mov  [eax], 0
for explicity seg fault

> Go figure, maybe he runs his applications always inside a debugger.
>
> There is no point in discussing with people like this any further.

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

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

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

csiph-web