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 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#12634

On 2011-11-03, Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2011-11-03, Ike Naar <ike@sverige.freeshell.org> wrote:
>> On 2011-11-03, Ike Naar <ike@sverige.freeshell.org> wrote:
>>> On 2011-11-03, Kaz Kylheku <kaz@kylheku.com> wrote:
>>>> &__NULL__ can be a contant integral expression evaluating to zero, if the
>>>> implementors so want.
>>
>> Sorry for my previous post which did not contain any new text.
>> Something went wrong during posting.
>>
>> In the meantime, James has already submitted a response
>> similar to what I was trying to submit:
>> Kaz's quoted statement about "contant integral expression" contradicts
>> 6.6 p6 which states that an integer constant expression shall have
>> integer type, while &__NULL__ has type pointer-to-char.
>
> On a DeathStation 9000, &__NULL__ overwrites the partition table on your
> root disk. :)

Then probably NULL is not defined in terms of &__NULL__ on that platform.

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

#16176

Ike Naar <ike@sverige.freeshell.org> writes:

> On 2011-11-03, Ike Naar <ike@sverige.freeshell.org> wrote:
>> On 2011-11-03, Kaz Kylheku <kaz@kylheku.com> wrote:
>>> &__NULL__ can be a contant integral expression evaluating to zero, if the
>>> implementors so want.
>
> Sorry for my previous post which did not contain any new text.
> Something went wrong during posting.
>
> In the meantime, James has already submitted a response
> similar to what I was trying to submit:
> Kaz's quoted statement about "contant integral expression" contradicts
> 6.6 p6 which states that an integer constant expression shall have
> integer type, while &__NULL__ has type pointer-to-char.

The statements made in 6.6p6 need not apply to "other forms of
constant expressions" accepted under 6.6p10.  That's the point
of putting in 6.6p10, to allow things that wouldn't be accepted
otherwise.

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

#16174

James Kuyper <jameskuyper@verizon.net> writes:

> On 11/03/2011 11:00 AM, Kenneth Brody wrote:
> ...
>> Note, too, that it's perfectly acceptable (as far as the C language itself 
>> is concerned) to have NULL point to a "valid" address, as long as no valid 
>> object can be at that address. ...
>
> That is correct.
>
>> ...  For example, it would be legal (AFAIK) for 
>> an implementation to do something like this:
>> 
>>      extern char __NULL__;
>>      #define NULL ((void *)(&__NULL__))
>
> No, NULL is required to expand into a null pointer constant. A null
> pointer constant is either "An integer constant expression with the
> value 0, or such an expression cast to type void *," (6.3.2.3p3).
>
> ICEs must have integer type; &__NULL__ has a pointer type. The operands
> of an ICE "shall only have operands that are integer constants,
> enumeration constants, character constants, sizeof expressions whose
> results are integer constants, and floating constants that are the
> immediate operands of casts." (6.6p6). __NULL__ qualifies as none of
> those things. While "an implementation may accept other forms of
> constant expressions" (6.6p10), those other forms will, by definition of
> "other", not have the right form to qualify as any of the specific types
> of constants specified in 6.6p6.  [snip unrelated]

This conclusion is wrong.  The phrase "other forms of constant
expressions" extendes to the different categories of CE described in
section 6.6, including integer constant expressions, as evidenced by
statements in the Rationale document and also (I believe but have not
taken the time to look up) several DR's.  See for example the
discussion of 'offsetof()' in the Rationale document.

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

#12180

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Oct 28, 10:49 am, gaoqiang <gaoqiangs...@gmail.com> wrote:
>> a good function should deal with unwanted parameters.
>>
>> why memcpy,strcmp .etc ,these libc functions, do not
>>
>> accept NULL pointer ? called with NULL, just get  segment
>>
>> fault.  for efficiency ?
>>
>> any idea ?
>>
> In the first incarnation of C, location zero in memory was always set
> to all bits clear. So a null pointer and the empty string were the
> same thing. It was soon realised that this was a bad idea, a string of
> no sausages isn't the same thing as no string of sausages. So a null
> pointer means "there's nothing here".

That does not match my recollection.  What incarnation of C had this
property, and when was it changed?

<snip>
-- 
Ben.

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

#12187

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>> On Oct 28, 10:49 am, gaoqiang <gaoqiangs...@gmail.com> wrote:
>>> a good function should deal with unwanted parameters.
>>>
>>> why memcpy,strcmp .etc ,these libc functions, do not
>>>
>>> accept NULL pointer ? called with NULL, just get  segment
>>>
>>> fault.  for efficiency ?
>>>
>>> any idea ?
>>>
>> In the first incarnation of C, location zero in memory was always set
>> to all bits clear. So a null pointer and the empty string were the
>> same thing. It was soon realised that this was a bad idea, a string of
>> no sausages isn't the same thing as no string of sausages. So a null
>> pointer means "there's nothing here".
>
> That does not match my recollection.  What incarnation of C had this
> property, and when was it changed?

I don't think it was ever anything to do with C specifically, but it was
true of at least one early Unix:  BSD Unix on a VAX 11/780, and I wrote
a lot of code based on the misunderstanding that a null pointer was a
zero-length string. This was no longer the case when I was fixing my
code so it would run on Sun 680x0 machines.

It's actually my understanding that the fact it was ever true was just
an accident of the implementation.

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

#12200

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> On Oct 28, 10:49 am, gaoqiang <gaoqiangs...@gmail.com> wrote:
>>> a good function should deal with unwanted parameters.
>>>
>>> why memcpy,strcmp .etc ,these libc functions, do not
>>>
>>> accept NULL pointer ? called with NULL, just get  segment
>>>
>>> fault.  for efficiency ?
>>>
>>> any idea ?
>>>
>> In the first incarnation of C, location zero in memory was always set
>> to all bits clear. So a null pointer and the empty string were the
>> same thing. It was soon realised that this was a bad idea, a string of
>> no sausages isn't the same thing as no string of sausages. So a null
>> pointer means "there's nothing here".
>
> That does not match my recollection.  What incarnation of C had this
> property, and when was it changed?
>
> <snip>

I know that *some* C implementations had that property.  I've heard that
porting from VAX to SPARC exposed a lot of bugs in code that assumed it
could dereference a null pointer and get zero.  But I haven't heard that
the *first* C implementation did this.

Oh, and a null pointer and the empty string have never been the same
thing, because *strings are not pointers*.

-- 
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]

#12214

Keith Thompson <kst-u@mib.org> writes:
[...]
> I know that *some* C implementations had that property.  I've heard that
> porting from VAX to SPARC exposed a lot of bugs in code that assumed it
> could dereference a null pointer and get zero.  But I haven't heard that
> the *first* C implementation did this.
[...]

It was probably VAX to Motorola 68k, not SPARC.

-- 
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]

#12176

On 10/28/2011 04:49 AM, gaoqiang wrote:
> a good function should deal with unwanted parameters.
> 
> why memcpy,strcmp .etc ,these libc functions, do not
> 
> accept NULL pointer ? called with NULL, just get  segment
> 
> fault.  for efficiency ?

For some functions, a null pointer can be used to indicate that
corresponding optional behavior should not occur. For example,
setlocale(LC_ALL, NULL) is perfectly legal; it still returns a pointer
to the current locale, but passing a null pointer turns off the feature
of changing the current locale.

That doesn't apply to these functions. There's no reason to bother
calling these functions with null pointers; the only behavior that could
reasonably be turned off by passing a null pointer is the entire
behavior of the function.
They could have been defined as checking whether the argument is null,
but that would mean that every caller of the function would have to pay
the small cost of checking whether it's null. One of the design
principles for C has been that "you don't pay for what you don't use".
Most code that calls these functions does so only in contexts where it's
already guaranteed that the pointer is not null, so such a check would
be a waste of time. Of course, that's not always true. Sometimes either
the source or the destination of a copy might be a null pointer - but in
that case the the cost of checking for the null pointer should be paid
by calling code, rather than in the subroutine:

	if(destination)
	     memcpy(destination, source, length);
	else
	{
	     // special handling when destination is null.
	}

Note that an implementation of the C standard library is permitted to
check for null pointer arguments for these functions, and to deal with
them as it wishes. However, it was not considered appropriate for the
standard to mandate such behavior.
-- 
James Kuyper

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

#12587

On 10/28/2011 7:22 AM, James Kuyper wrote:
> On 10/28/2011 04:49 AM, gaoqiang wrote:
>> a good function should deal with unwanted parameters.
>>
>> why memcpy,strcmp .etc ,these libc functions, do not
>>
>> accept NULL pointer ? called with NULL, just get  segment
>>
>> fault.  for efficiency ?
[...]
> They could have been defined as checking whether the argument is null,
> but that would mean that every caller of the function would have to pay
> the small cost of checking whether it's null. One of the design
> principles for C has been that "you don't pay for what you don't use".
> Most code that calls these functions does so only in contexts where it's
> already guaranteed that the pointer is not null, so such a check would
> be a waste of time. Of course, that's not always true. Sometimes either
> the source or the destination of a copy might be a null pointer - but in
> that case the the cost of checking for the null pointer should be paid
> by calling code, rather than in the subroutine:
[...]

Does anyone know what K&R1 said about free(NULL)?

Regardless, I do know that the first C compilers I used would fail with such 
a call, so we wrote a wrapper -- freenz(pt) -- that was basically:

     if ( pt != NULL ) free(pt);

Now, the Standard guarantees that free(NULL) is a valid no-op.

-- 
Kenneth Brody

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

#12589

On 2011-11-03, Kenneth Brody <kenbrody@spamcop.net> wrote:
> Now, the Standard guarantees that free(NULL) is a valid no-op.

Since 1989. Some kids which were born then got their university degrees now and
are working as software devs. Can we move on?

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

#12653

Kenneth Brody <kenbrody@spamcop.net> writes:

> Does anyone know what K&R1 said about free(NULL)?

Nothing.  The C library was not standardised then, and there were no
malloc and free function with any universal meaning.

free occurs in the index, but it refers to and example function used
to illustrate how allocation could be done (it's partner is alloc in the
examples).

<snip>
-- 
Ben.

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

#12178

On 10/28/2011 4:49 AM, gaoqiang wrote:
> a good function should deal with unwanted parameters.

     A good caller should not pass incorrect parameters.  So there!

> why memcpy,strcmp .etc ,these libc functions, do not
>
> accept NULL pointer ? called with NULL, just get  segment
>
> fault.  for efficiency ?
>
> any idea ?

     There's the problem of inventing some kind of "good behavior"
for functions with bogus arguments:

	strcpy(NULL, "What should happen here?");
	printf("How many %s can dance on a %s?\n");
	longjmp(NULL, 42);

It would be a whole lot of work to define suitable behaviors for
these clearly erroneous calls, and both the compiler and library
implementors might need to expend a good deal of effort to ensure
the defined behaviors did in fact occur.  (The second example might
require a very large overhaul of function linkage conventions.)
And the benefit from all this work would be ... what?  To hide a
programmer's mistakes a little longer, making them harder to find
and fix?  Is that a Good Thing?

     There are a few cases where "suitable behavior" might not be
too hard to define.  memcpy(NULL, NULL, 0) could be defined as a
no-op, for example, and that might be a "reasonable" outcome.  But
c'mon: It's quite reasonable that the count could be zero in a
limiting case, but is it reasonable for a program to supply either
of the pointer arguments as NULL?  Insisting on a well-defined
outcome for such an implausible scenario seems of little value,
especially if it threatens to penalize all the more sensible uses.

     Finally, there are a few cases where the library does in fact
accept NULL arguments and define their meaning.  free(NULL) is
well-defined, as is realloc(NULL, 42); NULL values arise "naturally"
in some limiting cases.  The library also uses NULL's as special
values in setbuf(), setvbuf(), and fflush(), and there may be a few
more NULLable parameters I've overlooked.  But by and large the
philosophy is "trust the programmer" (Rationale, section 0).  Part
of that "trust" is "trust the programmer not to do silly things;"
the question of whether a language *should* be so trusting is fodder
for an entirely different debate.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#12184

"gaoqiang" <gaoqiangscut@gmail.com> ha scritto nel messaggio
news:14abde31-4573-45e7-bdaf-eb70b22741d7@z28g2000pro.googlegroups.com...
>a good function should deal with unwanted parameters.
>
> why memcpy,strcmp .etc ,these libc functions, do not
>
> accept NULL pointer ? called with NULL, just get  segment
>
> fault.  for efficiency ?

no, if i rember well they not admit these functions to fail [not return
an error code] so if the parameter is wrong
[do you want copy or read something
in the NULL address? the address use for error code??
] it is right seg-fault

for to show there is one error
is better segfault than silet wrong running

> any idea ?

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

#12188

"gaoqiang" <gaoqiangscut@gmail.com> wrote in message 
news:14abde31-4573-45e7-bdaf-eb70b22741d7@z28g2000pro.googlegroups.com...
> a good function should deal with unwanted parameters.
>
> why memcpy,strcmp .etc ,these libc functions, do not
>
> accept NULL pointer ? called with NULL, just get  segment
>
> fault.  for efficiency ?
>
> any idea ?

I agree. It was sloppy programming, possibly done for performance at one 
time. But C programmers are so used to it, they seem to think it's a good 
idea, and any other way of doing it is inferior!

If it's that good an idea, perhaps we should all give up testing for null 
pointers!

-- 
Bartc  

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

#12229

"BartC" <bc@freeuk.com> writes:
> "gaoqiang" <gaoqiangscut@gmail.com> wrote in message
> news:14abde31-4573-45e7-bdaf-eb70b22741d7@z28g2000pro.googlegroups.com...
> > a good function should deal with unwanted parameters.
> >
> > why memcpy,strcmp .etc ,these libc functions, do not
> >
> > accept NULL pointer ? called with NULL, just get  segment
> >
> > fault.  for efficiency ?
> >
> > any idea ?
> 
> I agree. It was sloppy programming, possibly done for performance at
> one time. But C programmers are so used to it, they seem to think it's
> a good idea, and any other way of doing it is inferior!
> 
> If it's that good an idea, perhaps we should all give up testing for
> null pointers!

That's truly abyssmal logic. Just because one component can say "it's
not my responsibility, it's someone else's", doesn't mean that every,
or even any, component can say "it's not my responsibility".

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

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

#12235

On 2011-10-29, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
> That's truly abyssmal logic. Just because one component can say "it's
> not my responsibility, it's someone else's", doesn't mean that every,
> or even any, component can say "it's not my responsibility".

Just because you say so, doesn't mean anybody can say so ;-)

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

#12189

In <14abde31-4573-45e7-bdaf-eb70b22741d7@z28g2000pro.googlegroups.com> gaoqiang <gaoqiangscut@gmail.com> writes:

> a good function should deal with unwanted parameters.
> why memcpy,strcmp .etc ,these libc functions, do not
> accept NULL pointer ? called with NULL, just get  segment
> fault.  for efficiency ?

Let's take your example of memcpy.

The purpose of memcpy is to copy bytes from one memory location to
another.

If one of those locations is NULL, memcpy can't do anything useful.
You can't copy bytes to or from a NULL location.

If memcpy just returned without raising an exception, you wouldn't have
any way of knowing that the bytes didn't get copied.

memcpy is doing you a favor by alerting you to a problem: the data did
not get copied.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

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

#12190

"John Gordon" <gordon@panix.com> wrote in message 
news:j8f16r$pgt$1@reader1.panix.com...
> In <14abde31-4573-45e7-bdaf-eb70b22741d7@z28g2000pro.googlegroups.com> 
> gaoqiang <gaoqiangscut@gmail.com> writes:
>
>> a good function should deal with unwanted parameters.
>> why memcpy,strcmp .etc ,these libc functions, do not
>> accept NULL pointer ? called with NULL, just get  segment
>> fault.  for efficiency ?
>
> Let's take your example of memcpy.
>
> The purpose of memcpy is to copy bytes from one memory location to
> another.
>
> If one of those locations is NULL, memcpy can't do anything useful.
> You can't copy bytes to or from a NULL location.

> memcpy is doing you a favor by alerting you to a problem: the data did
> not get copied.

When you use a function such as memcpy, you often have to check that each 
operand is in fact not null:

if (A && B && N) memcpy(A, B, N);

when A, B, N are themselves arguments to your code, for example. Wouldn't it 
be a lot easier to just write:

memcpy(A, B, N);

and know that no copying is done when any argument is null or zero? Having a 
null source or destination is not necessarily an error (and if it is, you 
check it conventionally).

> If memcpy just returned without raising an exception, you wouldn't have
> any way of knowing that the bytes didn't get copied.

What value does memcpy() return? Couldn't it have returned the number of 
bytes actually copied?

Anyway there's a million ways a program can silently go wrong; A, B and N 
might not be zero, but how do we know they are correct?

Having a program deliberately crash is a crude way of detecting some classes 
of error.

-- 
Bartc 

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

#12192

In <j8f2fn$vhu$1@dont-email.me> "BartC" <bc@freeuk.com> writes:

> and know that no copying is done when any argument is null or zero? Having a 
> null source or destination is not necessarily an error (and if it is, you 
> check it conventionally).

If your code makes it as far as actually calling memcpy, a null argument
absolutely is an error.  Copying bytes to or from a null location is a
nonsense operation.  If a program is misbehaving so badly as to try to do
this, I WANT it to crash rather than proceed and potentially damage things
even further.

In the larger context of your code which calls memcpy, null arguments may
or may not be an error.  Your code can handle those arguments any way it
wants to -- as long as it doesn't pass them to memcpy.

> > If memcpy just returned without raising an exception, you wouldn't have
> > any way of knowing that the bytes didn't get copied.

> What value does memcpy() return?

memcpy returns the original value of the destination pointer.

> Couldn't it have returned the number of bytes actually copied?

I assume there is a good reason why it returns what it does.  I'm not
familiar enough with such things to guess at the reason.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

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

#12195

On 10/28/2011 04:33 PM, John Gordon wrote:
> In <j8f2fn$vhu$1@dont-email.me> "BartC" <bc@freeuk.com> writes:
...
>> What value does memcpy() return?
...
>> Couldn't it have returned the number of bytes actually copied?
> 
> I assume there is a good reason why it returns what it does.  I'm not
> familiar enough with such things to guess at the reason.

Unlike some of the string functions, memcpy() has no permission to copy
anything less than the exact count of bytes that it was given (except
when the behavior is undefined). It could have been defined to return 0
if either pointer argument were null, but there seems little point in that.

A more useful return value for memcpy(dest, src, count) would be
(void*)((char*)dest + count). A naive C-based implementation of memcpy()
calculates that value automaticly as a side effect of doing it's job; a
clever compiler might arrange, at no extra cost, for it to already be
residing in the same register used for returning small scalar values
from a function. The same might also be true even of more efficient
implementations using assembly language.
That value could be useful when doing a long series of memcpy() calls
into consecutive memory locations. A similar argument applies to several
of the str*() functions. However, it's too late now for changes like
that to the C standard library.

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

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

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

csiph-web