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

#12167 — about NULL as a parameter to a libc function

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 ?

[toc] | [next] | [standalone]

#12169

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

That's one point of view. Another point of view is that code should 
abide by the contract of the api and pass the appropriate arguments to 
to functions.

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

For example, my man page for strcmp states "The strcmp() function 
compares the two strings s1 and s2" - a NULL pointer isn't a string, so 
why should the function deal with it?

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

#12173

On Oct 28, 5:14 pm, Mark Bluemel <mark_blue...@pobox.com> wrote:
> On 10/28/2011 09:49 AM, gaoqiang wrote:
>
> > a good function should deal with unwanted parameters.
>
> That's one point of view. Another point of view is that code should
> abide by the contract of the api and pass the appropriate arguments to
> to functions.
>
> > why memcpy,strcmp .etc ,these libc functions, do not
> > accept NULL pointer ? called with NULL, just get  segment
> > fault.  for efficiency ?
>
> For example, my man page for strcmp states "The strcmp() function
> compares the two strings s1 and s2" - a NULL pointer isn't a string, so
> why should the function deal with it?

I don't think it explains. NULL is not a string,then what about
memcmp ?
NULL is a pointer now ...

you remind me .

I just got an idea that NULL pointer is nothing different with other
invalid
pointer. If a function checks the NULL pointer ,then why not other
invalid
pointers? to say void*p=0x01 ?

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

#12174

On 10/28/2011 11:22 AM, gaoqiang wrote:
> On Oct 28, 5:14 pm, Mark Bluemel<mark_blue...@pobox.com>  wrote:
>> On 10/28/2011 09:49 AM, gaoqiang wrote:
>>
>>> a good function should deal with unwanted parameters.
>>
>> That's one point of view. Another point of view is that code should
>> abide by the contract of the api and pass the appropriate arguments to
>> to functions.
>>
>>> why memcpy,strcmp .etc ,these libc functions, do not
>>> accept NULL pointer ? called with NULL, just get  segment
>>> fault.  for efficiency ?
>>
>> For example, my man page for strcmp states "The strcmp() function
>> compares the two strings s1 and s2" - a NULL pointer isn't a string, so
>> why should the function deal with it?
>
> I don't think it explains. NULL is not a string,then what about
> memcmp ?
> NULL is a pointer now ...

It's not a pointer to anything useful. It's specifically not a pointer
to "n" bytes of data that can be compared to another "n" bytes of data.

>
> you remind me .
>
> I just got an idea that NULL pointer is nothing different with other
> invalid pointer. If a function checks the NULL pointer ,then why not other
> invalid
> pointers? to say void*p=0x01 ?

What makes you think that location 0x01 is universally invalid?

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

#12223

On Fri, 2011-10-28, Mark Bluemel wrote:
> On 10/28/2011 11:22 AM, gaoqiang wrote:
>> On Oct 28, 5:14 pm, Mark Bluemel<mark_blue...@pobox.com>  wrote:
>>> On 10/28/2011 09:49 AM, gaoqiang wrote:
>>>
>>>> a good function should deal with unwanted parameters.
>>>
>>> That's one point of view. Another point of view is that code should
>>> abide by the contract of the api and pass the appropriate arguments to
>>> to functions.
>>>
>>>> why memcpy,strcmp .etc ,these libc functions, do not
>>>> accept NULL pointer ? called with NULL, just get  segment
>>>> fault.  for efficiency ?
...

>> I just got an idea that NULL pointer is nothing different with other
>> invalid pointer.

It's really a bit different, because it's the only invalid pointer
which you typically *do* want in your program.

>> If a function checks the NULL pointer ,then why not other
>> invalid
>> pointers? to say void*p=0x01 ?
>
> What makes you think that location 0x01 is universally invalid?

It's not, but for practical reasons it's /almost/ universally invalid.
If you want to crash in order to detect bugs like

   p=NULL; *p = 42;

then you probably want the same protection against

   q=NULL; q->foo = 42;

I bet most systems try to avoid having data in the low address space
for this reason.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#12175

On 10/28/2011 06:22 AM, gaoqiang wrote:
> On Oct 28, 5:14�pm, Mark Bluemel <mark_blue...@pobox.com> wrote:
>> On 10/28/2011 09:49 AM, gaoqiang wrote:
>>
>>> a good function should deal with unwanted parameters.
>>
>> That's one point of view. Another point of view is that code should
>> abide by the contract of the api and pass the appropriate arguments to
>> to functions.
>>
>>> why memcpy,strcmp .etc ,these libc functions, do not
>>> accept NULL pointer ? called with NULL, just get �segment
>>> fault. �for efficiency ?
>>
>> For example, my man page for strcmp states "The strcmp() function
>> compares the two strings s1 and s2" - a NULL pointer isn't a string, so
>> why should the function deal with it?
> 
> I don't think it explains. NULL is not a string,then what about
> memcmp ?
> NULL is a pointer now ...
> 
> you remind me .
> 
> I just got an idea that NULL pointer is nothing different with other
> invalid
> pointer. If a function checks the NULL pointer ,then why not other
> invalid
> pointers? to say void*p=0x01 ?

First, some nit picking. "NULL" is a macro, which is required to expand
into an expression which is a null pointer constant. "null" is an
adjective which can be applied to, among other things, a C pointer
value. Please try to clearly distinguish between "NULL" and "null".

There are many operations that can be performed on pointer values; some
pointer values are valid for use with some operations, but not with
others. A null pointer is a valid pointer value, but it's the least
valid type of pointer value - there's only two things that can be done
with it: it can be assigned to a pointer variable, and it can be
compared for equality with other pointer values. What this means is that
in C, a null pointer value is used for the very special purpose of not
pointing at anything. It is in fact prohibited for a null pointer to
compare equal to any pointer value that actually points at any object or
function, while it is required that null pointers compare equal to each
other (6.5.9p6).

The definition

	void *p = 0x01;

is a constraint violation. Initialization of a scalar object like p is
handled according to the rules of simple assignment (6.7.8p11), and
initializing a pointer object with an integer doesn't fit any of the
allowed combinations of left and right operands for a simple assignment
given in 6.5.16.1p1. There would be special handling in this context if
the initializer were an integer constant expression with a value of
zero; such an expression would qualify as a null pointer constant, and
that is one of the cases that would be permitted by 6.5.16.1p1. It would
result in p being initialized with a null pointer value of type void*.
No such special handling applies to 0x01. What you meant is probably
better expressed by

	void *p = (void*)0x01;

However, there's still a problem - the expression (void*)0x01 is NOT
guaranteed to be a valid pointer value for ANY purpose: "the result is
implementation-defined, might not be correctly aligned, might not point
to an entity of the referenced type, and might be a trap
representation.56)" (6.3.2.3p5).
-- 
James Kuyper

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

#12198

gaoqiang <gaoqiangscut@gmail.com> writes:
> I just got an idea that NULL pointer is nothing different with other
> invalid pointer. If a function checks the NULL pointer ,then why not
> other invalid pointers? to say void*p=0x01 ?

Because it is in general not possible to determine whether a given
pointer is valid or not.

It's the caller's responsibility to pass a valid pointer.

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

#12202

>> > a good function should deal with unwanted parameters.

A segmentation fault is a rather nice way (compared with some of
the alternatives) of dealing with incorrect parameters.  It is much
better than, say, ignoring the problem and proceeding (which some
systems, especially those with no hardware memory protection, do).
It tells you there is a problem and the program abort usually occurs
fairly close to the point of error.

*Unwanted* parameters are extra parameters passed that the function
does not expect.  There is no portable way for a called function
to detect this.

Thought experiment:  if you have a machine where:
	strcpy(NULL, "h**l d**n s**t f**k");
does not cause an abort of the program, try putting it at the
beginning of main(), using the FCC Seven Deadly Words fully spelled
out.  Do not check to see whether that string comes out in unexpected
places until the output of the program has been passed on to a
customer or your boss's boss.  How soon will you be needing to
polish up your resume?

What might be the output of:
	char	buffer[1024];

	strcpy(buffer, NULL);
	printf("%s\n", buffer);
?

> you remind me .
> 
> I just got an idea that NULL pointer is nothing different with other
> invalid
> pointer. If a function checks the NULL pointer ,then why not other
> invalid
> pointers? to say void*p=0x01 ?

Who said (void *) 0x01 is an invalid pointer?  Except for testing
for null, there's no portable way to make such a test.  "Testing"
an invalid pointer will likely terminate the program, or worse, do
something to mess up the rest of its execution or mortally wound
the operating system.

It's much like testing a motorcycle to see if it can jump the Grand
Canyon with you riding it naked.  After you've started the test and
see it's going to fall short, you probably won't live to report the
results after landing.

A Standard C library function will accept NULL as a parameter if
it is documented to accept NULL.  That applies to each parameter
individually.  If it's not documented to accept NULL, don't pass
it NULL.  For example, strtol() and similar functions will accept
NULL as a second argument, but not the first.  *Most* of the functions
wanting a string will not accept NULL in its place (but strtok()
does, and that's not the only one.) *Most* of the functions wanting
a FILE * (from fopen()) will not accept NULL in its place (but
fflush() does, and with a rather odd meaning).

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

#12206

On Fri, 28 Oct 2011 16:36:28 -0500, gordonb.4o15x@burditt.org (Gordon
Burditt) wrote:

>>> > a good function should deal with unwanted parameters.
>
>A segmentation fault is a rather nice way (compared with some of
>the alternatives) of dealing with incorrect parameters.  It is much
>better than, say, ignoring the problem and proceeding (which some
>systems, especially those with no hardware memory protection, do).
>It tells you there is a problem and the program abort usually occurs
>fairly close to the point of error.
>
>*Unwanted* parameters are extra parameters passed that the function
>does not expect.  There is no portable way for a called function
>to detect this.
>
>Thought experiment:  if you have a machine where:
>	strcpy(NULL, "h**l d**n s**t f**k");
>does not cause an abort of the program, try putting it at the
>beginning of main(), using the FCC Seven Deadly Words fully spelled
>out.  Do not check to see whether that string comes out in unexpected
>places until the output of the program has been passed on to a
>customer or your boss's boss.  How soon will you be needing to
>polish up your resume?


Interestingly(?) many C compilers for Win16 allowed you to store into
location zero, at least in small or medium model where a 16 bit
pointer value of zero merely pointed to the first byte of the data
segment.  Many compilers checked the contents of the first word of the
data segment at exit, and if it was not the expected value, would
print a diagnostic message.

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

#12383

Robert Wessel wrote:
> Interestingly(?) many C compilers for Win16 allowed you to store into
> location zero, at least in small or medium model where a 16 bit

C doesn't allow or disallow storage to location zero, the environment
the program is executing on allows or disallows storage to location
zero, usually with the absence or presence of memory mapping/
protection
hardware.

JGH

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

#12208

On 2011-10-28, gaoqiang <gaoqiangscut@gmail.com> wrote:
> I just got an idea that NULL pointer is nothing different with other
> invalid
> pointer. 

That is false. A null pointer is a valid value. It is not valid for
the purposes of dereferencing.

A portable program can initialize a pointer to null: it is not a bad value.

Other kinds of invalid pointers ere not only invalid pointers, but invalid
values. Portable programs cannot use such pointers in any way; even just
creating one and assigning it to a variable is undefined behavior.

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

#12237

On Oct 28, 11:22 am, gaoqiang <gaoqiangs...@gmail.com> wrote:
> On Oct 28, 5:14 pm, Mark Bluemel <mark_blue...@pobox.com> wrote:
> > On 10/28/2011 09:49 AM, gaoqiang wrote:

> > > a good function should deal with unwanted [invalid?] parameters.

yes but if the caller *knows* the parameter is valid it can be
inefficient to check over and over again

/* how many times do we have to check s1 isn't NULL? */
strcpy (s1, s2);
strcpy (s1, s3);
...
strcpy (s1, sn);

/* public key generator. Both parameters must be prime */
/* this could be fantastically expensive to check */
BigNum keygen (BigNum p1, BigNum p2);

/* cmp() must terminate */
/* this could be impossible to verify */
void sort (T a[], size_t n, int (*cmp) (T, T));


> > That's one point of view. Another point of view is that code should
> > abide by the contract of the api and pass the appropriate arguments to
> > to functions.
>
> > > why memcpy,strcmp .etc ,these libc functions, do not
> > > accept NULL pointer ? called with NULL, just get  segment
> > > fault.  for efficiency ?
>
> > For example, my man page for strcmp states "The strcmp() function
> > compares the two strings s1 and s2" - a NULL pointer isn't a string, so
> > why should the function deal with it?
>
> I don't think it explains. NULL is not a string,then what about
> memcmp ? NULL is a pointer now ...

from (a draft copy of) the standard

****
4.11.1 String function conventions
[...]
but in all cases a char * or void * argument points to the initial
(lowest
addressed) character of the array.
****

NULL does not satisfy this criterion

> you remind me .
>
> I just got an idea that NULL pointer is nothing different with other
> invalid
> pointer.

oh but it is

> If a function checks the NULL pointer ,then why not other
> invalid pointers? to say void*p=0x01 ?

because it could be very expensive (if not impossible in some cases)
to check. NULL may not be zero and 0x1 may be a valid address.

void f (void)
{
    char somearray [50];
    free (somearray);
}

is somearray a valid address?

void f (char* dst)
{
     char somearray1 [10];
     char somearray2 [10];
     char somearray3 [10];

     memcpy (dst, &somearray2[-1], 3);
}

is &somearray2[-1] a valid address? The above program likely exhibits
Undefined Behaviour and yet that address is likely an accessible on
most implementations.

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

#12242

"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message 
news:110bf1f4-3285-4e02-b039-1359ced22f6d@f36g2000vbm.googlegroups.com...
> On Oct 28, 11:22 am, gaoqiang <gaoqiangs...@gmail.com> wrote:
>> On Oct 28, 5:14 pm, Mark Bluemel <mark_blue...@pobox.com> wrote:
>> > On 10/28/2011 09:49 AM, gaoqiang wrote:
>
>> > > a good function should deal with unwanted [invalid?] parameters.
>
> yes but if the caller *knows* the parameter is valid it can be
> inefficient to check over and over again
>
> /* how many times do we have to check s1 isn't NULL? */
> strcpy (s1, s2);
> strcpy (s1, s3);
> ...
> strcpy (s1, sn);
>

That's not really a likely piece of code. A better example is:

 strcpy(s2,s1);
 strcpy(s3,s1);
 ...

where s1==NULL can mean don't copy, or it can equally mean treat as an empty 
string. The latter is handy, but is rather lazy and also cannot apply in all 
situations. So it would up to each function what it might do.

And ideally there would be two versions of the functions: safe and unsafe. 
The safe versions do the checks and apply meanings to null parameters. The 
unsafe version versions work as they are currently defined by the standard. 
But neither set can guarantee no crashes. This is still C.

> /* public key generator. Both parameters must be prime */
> /* this could be fantastically expensive to check */
> BigNum keygen (BigNum p1, BigNum p2);

In this case whatever or whoever created p1 and p2 would be responsible. It 
would be unreasonable to expect the callee to do these checks.

> /* cmp() must terminate */
> /* this could be impossible to verify */
> void sort (T a[], size_t n, int (*cmp) (T, T));

You're jumping a bit from checking for an uninitialised pointer, to proving 
the correctness of potentially thousands of lines of code! So if the latter 
is difficult to do, we do nothing about the simpler cases either?

-- 
Bartc 

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

#12289

On Oct 29, 2:40 pm, "BartC" <b...@freeuk.com> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
> news:110bf1f4-3285-4e02-b039-1359ced22f6d@f36g2000vbm.googlegroups.com...
> > On Oct 28, 11:22 am, gaoqiang <gaoqiangs...@gmail.com> wrote:
> >> On Oct 28, 5:14 pm, Mark Bluemel <mark_blue...@pobox.com> wrote:
> >> > On 10/28/2011 09:49 AM, gaoqiang wrote:

> >> > > a good function should deal with unwanted [invalid?] parameters.
>
> > yes but if the caller *knows* the parameter is valid it can be
> > inefficient to check over and over again
>
> > /* how many times do we have to check s1 isn't NULL? */
> > strcpy (s1, s2);
> > strcpy (s1, s3);
> > ...
> > strcpy (s1, sn);
>
> That's not really a likely piece of code. A better example is:
>
>  strcpy(s2,s1);
>  strcpy(s3,s1);
>  ...

yes, my example was poor

<snip>

> > /* public key generator. Both parameters must be prime */
> > /* this could be fantastically expensive to check */
> > BigNum keygen (BigNum p1, BigNum p2);
>
> In this case whatever or whoever created p1 and p2 would be responsible.

exactly. Why is this different from the strcpy() example?

> It
> would be unreasonable to expect the callee to do these checks.

"what world needs is a simple way to factorise prime numbers"
Bill Gates

> > /* cmp() must terminate */
> > /* this could be impossible to verify */
> > void sort (T a[], size_t n, int (*cmp) (T, T));
>
> You're jumping a bit from checking for an uninitialised pointer, to proving
> the correctness of potentially thousands of lines of code!

I'm pointing out several examples where it becomes increasingly
onerous for a function to check the correctness of its arguments.

> So if the latter
> is difficult to do, we do nothing about the simpler cases either?

the simple cases tend to end up in inner loops. I'd like these
functions to be very efficient. It's the C way. If you want more
protection and slightly (or much) slower code use a higher level
language or decorate your C cocde with checks. Write your own "safe"
versions of the string.h functions if you like.

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

#12197

Mark Bluemel <mark_bluemel@pobox.com> writes:
> On 10/28/2011 09:49 AM, gaoqiang wrote:
>> a good function should deal with unwanted parameters.
>
> That's one point of view. Another point of view is that code should 
> abide by the contract of the api and pass the appropriate arguments to 
> to functions.
>
>> why memcpy,strcmp .etc ,these libc functions, do not
>> accept NULL pointer ? called with NULL, just get  segment
>> fault.  for efficiency ?
>
> For example, my man page for strcmp states "The strcmp() function 
> compares the two strings s1 and s2" - a NULL pointer isn't a string, so 
> why should the function deal with it?

Mine says the same thing -- and it's wrong.  It compares the strings
*pointed to by* s1 and s2.  (Yes, the meaning is clear enough,
but it's potentially misleading to inexperienced C programmers who
might thing that strings are really 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]

#12232

Keith Thompson <kst-u@mib.org> writes:
> Mark Bluemel <mark_bluemel@pobox.com> writes:
> > On 10/28/2011 09:49 AM, gaoqiang wrote:
> >> a good function should deal with unwanted parameters.
> >
> > That's one point of view. Another point of view is that code should 
> > abide by the contract of the api and pass the appropriate arguments to 
> > to functions.
> >
> >> why memcpy,strcmp .etc ,these libc functions, do not
> >> accept NULL pointer ? called with NULL, just get  segment
> >> fault.  for efficiency ?
> >
> > For example, my man page for strcmp states "The strcmp() function 
> > compares the two strings s1 and s2" - a NULL pointer isn't a string, so 
> > why should the function deal with it?
> 
> Mine says the same thing -- and it's wrong.  It compares the strings
> *pointed to by* s1 and s2.  (Yes, the meaning is clear enough,
> but it's potentially misleading to inexperienced C programmers who
> might thing that strings are really pointers.)

I think you've mentioned this flub before on c.l.c. Did you raise it
with c.s.c, or even members of the committee themselves? It's an easy
fix that doesn't need to harm readability, so it would be good if it
was pushed forwards. (One lazy hack fix is to add a "sometimes as
shorthand a pointer to a string will be refered to as a string"
disclaimer at definition time, but that's perhaps too much an
admission of sloppiness.)

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

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

#12234

On Oct 29, 1:11 pm, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
wrote:
> Keith Thompson <ks...@mib.org> writes:
> > Mark Bluemel <mark_blue...@pobox.com> writes:
> > > On 10/28/2011 09:49 AM, gaoqiang wrote:
> > >> a good function should deal with unwanted parameters.
>
> > > That's one point of view. Another point of view is that code should
> > > abide by the contract of the api and pass the appropriate arguments to
> > > to functions.
>
> > >> why memcpy,strcmp .etc ,these libc functions, do not
> > >> accept NULL pointer ? called with NULL, just get  segment
> > >> fault.  for efficiency ?
>
> > > For example, my man page for strcmp states "The strcmp() function
> > > compares the two strings s1 and s2" - a NULL pointer isn't a string, so
> > > why should the function deal with it?
>
> > Mine says the same thing -- and it's wrong.  It compares the strings
> > *pointed to by* s1 and s2.  (Yes, the meaning is clear enough,
> > but it's potentially misleading to inexperienced C programmers who
> > might thing that strings are really pointers.)
>
> I think you've mentioned this flub before on c.l.c. Did you raise it
> with c.s.c, or even members of the committee themselves?

the standard doesn't say that. It says

"The strcmp function compares the string pointed to by s1 to the
string pointed to by s2 ."


> It's an easy
> fix that doesn't need to harm readability, so it would be good if it
> was pushed forwards. (One lazy hack fix is to add a "sometimes as
> shorthand a pointer to a string will be refered to as a string"
> disclaimer at definition time, but that's perhaps too much an
> admission of sloppiness.)

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

#12254

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Mark Bluemel <mark_bluemel@pobox.com> writes:
[...]
>> > For example, my man page for strcmp states "The strcmp() function 
>> > compares the two strings s1 and s2" - a NULL pointer isn't a string, so 
>> > why should the function deal with it?
>> 
>> Mine says the same thing -- and it's wrong.  It compares the strings
>> *pointed to by* s1 and s2.  (Yes, the meaning is clear enough,
>> but it's potentially misleading to inexperienced C programmers who
>> might thing that strings are really pointers.)
>
> I think you've mentioned this flub before on c.l.c. Did you raise it
> with c.s.c, or even members of the committee themselves? It's an easy
> fix that doesn't need to harm readability, so it would be good if it
> was pushed forwards. (One lazy hack fix is to add a "sometimes as
> shorthand a pointer to a string will be refered to as a string"
> disclaimer at definition time, but that's perhaps too much an
> admission of sloppiness.)

It's not an error in the standard, so I haven't mentioned it on c.s.c or
to the committee.  But I should mention it to the maintainers of the
Linux man pages.  Thanks for reminding me.  (A data point: the Solaris 9
man page doesn't make this mistake.)

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

#12171

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".

There's an argument for silently ignoring null pointers in functions.
But it's generally better to segfault, and the require caller to check
for null. That way errors are more likely to be discovered, and it's
more likely that, if the pointer is null, the program will do the
right thing.
--
Programming resources:
http://www.malcolmmclean.site11.com/www

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

#12179

On 2011-10-28, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> 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".
>
> There's an argument for silently ignoring null pointers in functions.
> But it's generally better to segfault, and the require caller to check
> for null. That way errors are more likely to be discovered, and it's
> more likely that, if the pointer is null, the program will do the
> right thing.

A null pointer always is invalid or protected by OS, so you won't to
read/write it.

In fact, when you read/write a protected memory, OS (UNIX) will send
you a message that told you something is wrong.

If you use a different it's not a problem (if the OS don't protect any
memory). You can read/write it correctly.

-- 
Best Regards,
Mike Manilone.

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

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

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

csiph-web