about NULL as a parameter to a libc function

[gaoqiang]

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 ?

[Mark Bluemel]

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?

[Malcolm McLean]

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

[gaoqiang]

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 ?

[Mark Bluemel]

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?

[James Kuyper]

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

[James Kuyper]

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

[Eric Sosman]

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
eso...@ieee-dot-org.invalid

[Mike Manilone]

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.

[Ben Bacarisse]

Malcolm McLean <malcolm...@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.

[io_x]

"gaoqiang" <gaoqia...@gmail.com> ha scritto nel messaggio
news:14abde31-4573-45e7...@z28g2000pro.googlegroups.com...

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 ?

[James Kuyper]

On 10/28/2011 08:58 AM, Mike Manilone wrote:
...

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

A null pointer is not invalid for assignment or comparison with other
pointers for equality.

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

Not all systems have protected memory, not all systems are UNIX, and not
all systems give you a message when you dereference a null pointer. On
some systems, you might not discover the bad consequences of doing so
until long after the fact.

[James Kuyper]

On 10/28/2011 08:58 AM, Mike Manilone wrote:
...

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

A null pointer is not invalid for assignment or comparison with other
pointers for equality.

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

[Joe Pfeiffer]

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.

[BartC]

"gaoqiang" <gaoqia...@gmail.com> wrote in message
news:14abde31-4573-45e7...@z28g2000pro.googlegroups.com...

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

[John Gordon]

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
gor...@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

[BartC]

"John Gordon" <gor...@panix.com> wrote in message
news:j8f16r$pgt$1...@reader1.panix.com...

> In <14abde31-4573-45e7...@z28g2000pro.googlegroups.com>
> gaoqiang <gaoqia...@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

[Kaz Kylheku]

On 2011-10-28, gaoqiang <gaoqia...@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

This means that the funtions actually do accept the pointer and try to do
what they are told: move memory to or from the null pointer!

It's your virtual memory managment (CPU feature + operating system) that
doesn't like the null pointer.

If you dereference a null pointer to access memory, you will get this
segfault, no matter what syntax or function you use.

> fault. for efficiency ?

No. It would be more efficient to just accept null inside the
memcpy function (as is already the case in your implementation!) AND also
not have the virtual memory management which catches the fault.

Trapping null to a segfault requires extra circuitry which complicates the
processor and introduces performance penalties (which are difficult to analyze,
since they have to do with the access pattern to pages, and the replacement
strategy of entries the translation cache.)

[John Gordon]

In <j8f2fn$vhu$1...@dont-email.me> "BartC" <b...@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.

[Nobody]

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?

[James Kuyper]

On 10/28/2011 04:13 PM, BartC wrote:
...

> 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);

Often? I just checked the most convenient body of code I had on hand,
consisting of 278 source code files with a total of 107238 lines, and
4017043 bytes of code. A large fraction of that code was written by me.
It contains 85 calls to memcpy(), and not a single instance where the
call was controlled directly by an if() based upon A, B, or N.

There were only two instances where the call was directly controlled by
an if(), but the if tested something other condition entirely - it
determined whether the data needed to be copied, not whether the
pointers were non-null or the count non-zero. Much more common was the
deliberate placement of the memcpy() call in a block that could only be
entered if the relevant pointers were non-null and the count was
non-zero; but that block existed for other reasons than making the
memcpy() safe, so putting the memcpy() call into that block did not
increase the number of conditions that needed to be tested.

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

Given how rarely I need this feature, I prefer the current situation,
where those who need it can implement it just by writing:

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

If they need to do it frequently, they can even make it a macro or an
inline function.

[James Kuyper]

On 10/28/2011 04:33 PM, John Gordon wrote:
> In <j8f2fn$vhu$1...@dont-email.me> "BartC" <b...@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.

[James Kuyper]

I wouldn't recommend such a change, but if it were made, it's often not
that difficult to come up with reasonable definitions of the behavior in
the cases that are currently undefined. In this case, the following
would be one plausible approach:

int strcmp(const char *s1, const char *s2)
{
if(s1 && s2)
return old_strcmp(s1, s2);
return !!s1 - !!s2;
}

[Keith Thompson]

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) ks...@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"

[Keith Thompson]

gaoqiang <gaoqia...@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.

[Kaz Kylheku]

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

[Keith Thompson]

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

[Ben Pfaff]

James Kuyper <james...@verizon.net> writes:

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

There's a GNU extension named mempcpy() that has the return value
semantics that you suggest might be useful for memcpy().

POSIX 2008 standardized a common C library extension called
stpcpy(), that acts like strcpy() except that it returns a
pointer to the null terminator byte written to the destination
string.
--
"To get the best out of this book, I strongly recommend that you read it."
--Richard Heathfield

[Gordon Burditt]

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

[jacob navia]

Le 28/10/11 22:40, Nobody a écrit :

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

Furthermore errno should be set to EINVAL

[Robert Wessel]

On Fri, 28 Oct 2011 16:36:28 -0500, gordon...@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.

[Ben Bacarisse]

Kaz Kylheku <k...@kylheku.com> writes:
<snip>

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

There is a fine tradition that says otherwise. Even in C, x == x is
not always 1 (e.g. when x is NaN).

--
Ben.

[Kaz Kylheku]

On 2011-10-28, gaoqiang <gaoqia...@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.

[Keith Thompson]

"BartC" <b...@freeuk.com> writes:
> "John Gordon" <gor...@panix.com> wrote in message
> news:j8f16r$pgt$1...@reader1.panix.com...

[...]

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

Though it's not required to do so. The behavior is undefined; a seg
fault is not required.

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

One could make exactly the same argument for a simple assignment
(without the N, of course). Perhaps it would be simpler to be able to
write:

*A = *B;

and have it quietly do nothing if either A or B is a null pointer. But
as others have said in parallel followups, when you're writing a
statement that copies data, you should generally have enough awareness
of the context to *know* that there's actually something to be copied.

Do you actually find yourself making such checks in your own code?

There are a nearly unlimited number of ways you can call memcpy()
incorrectly. You can try to copy too few or too many bytes. You can
pass invalid non-null pointers. You can reverse the first and second
arguments. You can pass perfectly valid pointers that just don't happen
to point to the objects you really wanted to copy.

The question is, would it really be worthwhile for memcpy() to detect
just a few kinds of errors (when other equally serious errors are
undetectable)?

How often would having memcpy() check for null pointers make it easier
to write correct code *in practice*?

[...]

[Keith Thompson]

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.

Defining *some* consistent set of behavior wouldn't be difficult.
Getting everyone to agree that it's the right definition would be
impossible. (And leaving things the way they are is, IMHO, the best
approach.)

[Kaz Kylheku]

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.

[Richard Damon]

On 10/28/11 4:17 PM, Kaz Kylheku wrote:
>
> Trapping null to a segfault requires extra circuitry which complicates the
> processor and introduces performance penalties (which are difficult to analyze,
> since they have to do with the access pattern to pages, and the replacement
> strategy of entries the translation cache.)

The trapping of the Null pointer come out basically for free from the
segment/virtual memory processing that allows those computers to run
multiple programs with virtual memory. At most it causes a single if in
the OS to see if the access to unmapped page fault occurs for a page
that should be added to the programs address space or not.

[Keith Thompson]

Keith Thompson <ks...@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.

[Kaz Kylheku]

On 2011-10-28, Keith Thompson <ks...@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.

[Keith Thompson]

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.

[Ben Bacarisse]

Keith Thompson <ks...@mib.org> writes:

> Kaz Kylheku <k...@kylheku.com> writes:
>> On 2011-10-28, Keith Thompson <ks...@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.

[Kaz Kylheku]

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.

[Jorgen Grahn]

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 .

[jacob navia]

Le 29/10/11 00:42, Kaz Kylheku a écrit :

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.

[Nobody]

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.

[Angel]

On 2011-10-29, Nobody <nob...@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

[Phil Carmody]

"BartC" <b...@freeuk.com> writes:
> "gaoqiang" <gaoqia...@gmail.com> wrote in message
> news:14abde31-4573-45e7...@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

[BartC]

"Keith Thompson" <ks...@mib.org> wrote in message
news:lnhb2sl...@nuthaus.mib.org...

> "BartC" <b...@freeuk.com> writes:

>>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).
>
> One could make exactly the same argument for a simple assignment
> (without the N, of course). Perhaps it would be simpler to be able to
> write:
>
> *A = *B;
>
> and have it quietly do nothing if either A or B is a null pointer.

With a basic language statement like assignment, you wouldn't expect it to
be backed up with logic to make sure operands are not null. And it can't be
called remotely, where there would be no opportunity for the writer of the
*A=*B to put in extra checks.

A function (any function really, rather than just memcpy) is different; it
can be called remotely, and it is easy to add checks, and to define specific
behaviours.

> as others have said in parallel followups, when you're writing a
> statement that copies data, you should generally have enough awareness
> of the context to *know* that there's actually something to be copied.
>
> Do you actually find yourself making such checks in your own code?

Yes. Both when calling C functions (and often these are called from
higher-level scripting languages, which use null for empty strings, and can
crash when directly calling a C function), and when writing my own functions
where the caller cannot quite be trusted 100%, and even then I might put
checks in anyway as I don't know what other callers might do in future.

Of course these are not always as performance-critical as memcpy() where
there is less room for manoeuvre. I can understand that requiring extra
checks means the compiler cannot, for example, optimise a 4-byte memcpy into
a couple of inline instructions.

--
Bartc

[Phil Carmody]

James Kuyper <james...@verizon.net> writes:

> On 10/28/2011 04:40 PM, Nobody 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?
>

> I wouldn't recommend such a change, but if it were made, it's often not
> that difficult to come up with reasonable definitions of the behavior in
> the cases that are currently undefined. In this case, the following
> would be one plausible approach:
>
> int strcmp(const char *s1, const char *s2)
> {
> if(s1 && s2)
> return old_strcmp(s1, s2);
> return !!s1 - !!s2;

Why not !s2 - !s1 ?

[Phil Carmody]

Keith Thompson <ks...@mib.org> writes:

> Mark Bluemel <mark_b...@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

[Nick Keighley]

On Oct 28, 3:59 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 10/28/2011 08:58 AM, Mike Manilone wrote:
> ...
>
> > A null pointer always is invalid or protected by OS, so you won't to
> > read/write it.
>
> A null pointer is not invalid for assignment or comparison with other
> pointers for equality.
>
> > In fact, when you read/write a protected memory, OS (UNIX) will send
> > you a message that told you something is wrong.
>
> Not all systems have protected memory, not all systems are UNIX, and not
> all systems give you a message when you dereference a null pointer. On
> some systems, you might not discover the bad consequences of doing so
> until long after the fact.

not even all UNIX have protected memory. I believe some Crays didn't
have virtual memory and so possibly didn't have protected memory. The
C compiler for HPUX made it an option whether dereferencing a null
pointer gave a segmentaion error. I've no idea why (kernel
programming?).

[Nick Keighley]

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

[Ike Naar]

On 2011-10-29, Phil Carmody <thefatphi...@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 ;-)

[James Kuyper]

On 10/29/2011 08:03 AM, Phil Carmody wrote:
> James Kuyper <james...@verizon.net> writes:
...

>> I wouldn't recommend such a change, but if it were made, it's often not
>> that difficult to come up with reasonable definitions of the behavior in
>> the cases that are currently undefined. In this case, the following
>> would be one plausible approach:
>>
>> int strcmp(const char *s1, const char *s2)
>> {
>> if(s1 && s2)
>> return old_strcmp(s1, s2);
>> return !!s1 - !!s2;
>
> Why not !s2 - !s1 ?

Because I didn't think of it. :-(

--
James Kuyper

[Nick Keighley]

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.

[jacob navia]

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.

[Nick Keighley]

On Oct 28, 9:13 pm, "BartC" <b...@freeuk.com> wrote:
> "John Gordon" <gor...@panix.com> wrote in message
>
> news:j8f16r$pgt$1...@reader1.panix.com...
>
>
>
>
>

> > In <14abde31-4573-45e7-bdaf-eb70b2274...@z28g2000pro.googlegroups.com>
> > gaoqiang <gaoqiangs...@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?

the first parameter

> 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- Hide quoted text -
>
> - Show quoted text -

[Nick Keighley]

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

[BartC]

"Nick Keighley" <nick_keigh...@hotmail.com> wrote in message
news:110bf1f4-3285-4e02...@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

[Nick Keighley]

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>

[jacob navia]

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.

[io_x]

"jacob navia" <ja...@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

[Keith Thompson]

"BartC" <b...@freeuk.com> writes:
> "Keith Thompson" <ks...@mib.org> wrote in message
> news:lnhb2sl...@nuthaus.mib.org...
>> "BartC" <b...@freeuk.com> writes:
>>>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).
>>
>> One could make exactly the same argument for a simple assignment
>> (without the N, of course). Perhaps it would be simpler to be able to
>> write:
>>
>> *A = *B;
>>
>> and have it quietly do nothing if either A or B is a null pointer.
>
> With a basic language statement like assignment, you wouldn't expect it to
> be backed up with logic to make sure operands are not null. And it can't be
> called remotely, where there would be no opportunity for the writer of the
> *A=*B to put in extra checks.
>
> A function (any function really, rather than just memcpy) is different; it
> can be called remotely, and it is easy to add checks, and to define specific
> behaviours.

memcpy(), in a very real sense, is a basic language feature. Yes, it's
in the library rather than in the core language, but its performance is
just as important as the performance of an assignment.

And having memcpy() check for null pointers and do nothing makes certain
errors *more difficult to detect*. If I write

memcpy(target, source, size);

and either target or source happens to be a null pointer, it's almost
certainly because I made a mistake. A memcpy() that hides that mistake
from me isn't doing me any favors; it's by no means certain that doing
nothing is the correct behavior that will "fix" the bug.

>> as others have said in parallel followups, when you're writing a
>> statement that copies data, you should generally have enough awareness
>> of the context to *know* that there's actually something to be copied.
>>
>> Do you actually find yourself making such checks in your own code?
>
> Yes. Both when calling C functions (and often these are called from
> higher-level scripting languages, which use null for empty strings, and can
> crash when directly calling a C function), and when writing my own functions
> where the caller cannot quite be trusted 100%, and even then I might put
> checks in anyway as I don't know what other callers might do in future.

Are these scripting languages of your own design? Perhaps using null
for empty strings wasn't the best choice. Is there a way to represent
an empty string using a non-null pointer? If so, do you really gain
much benefit from having two distinct representations for the same
thing? You'd have to do extra checks on almost every string operation.

Perhaps you have a good reason for doing it that way -- but then you
have to expect some overhead.

As for untrusted callers, when you check for an error condition, you
have to know how to handle it. How do you know that the way you handle
it (say, doing nothing for a null pointer) is the correct behavior?

> Of course these are not always as performance-critical as memcpy() where
> there is less room for manoeuvre. I can understand that requiring extra
> checks means the compiler cannot, for example, optimise a 4-byte memcpy into
> a couple of inline instructions.

Welcome to C.

[Keith Thompson]

Phil Carmody <thefatphi...@yahoo.co.uk> writes:
> Keith Thompson <ks...@mib.org> writes:
>> Mark Bluemel <mark_b...@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.)

[BartC]

"Keith Thompson" <ks...@mib.org> wrote in message

news:lnzkgjk...@nuthaus.mib.org...

> "BartC" <b...@freeuk.com> writes:

>> With a basic language statement like assignment, you wouldn't expect it
>> to
>> be backed up with logic to make sure operands are not null.

>> A function (any function really, rather than just memcpy) is different;

> memcpy(), in a very real sense, is a basic language feature. Yes, it's
> in the library rather than in the core language, but its performance is
> just as important as the performance of an assignment.
>
> And having memcpy() check for null pointers and do nothing makes certain
> errors *more difficult to detect*. If I write
>
> memcpy(target, source, size);
>
> and either target or source happens to be a null pointer, it's almost
> certainly because I made a mistake.

If size is zero, that's quite likely to be a mistake too. Yet the standard
defines the behaviour in that case. (I've been looking at the Python
implementation code; checking for size being zero is the most common check
before calling memcpy(), even though it is not actually needed. Checks for
destination or source being null are rarer.)

> A memcpy() that hides that mistake
> from me isn't doing me any favors; it's by no means certain that doing
> nothing is the correct behavior that will "fix" the bug.

Letting some code deliberately crash seems a rather drastic way of telling
you something is wrong! And not crashing doesn't mean nothing else is wrong.

>> Yes. Both when calling C functions (and often these are called from
>> higher-level scripting languages, which use null for empty strings, and
>> can
>> crash when directly calling a C function),

> Are these scripting languages of your own design? Perhaps using null
> for empty strings wasn't the best choice. Is there a way to represent
> an empty string using a non-null pointer?

(I use counted strings, which also have a tag saying if it's a string or
not. Having a length=0 and ptr=0 was the simplest way of
doing things. It's not a big deal, I need to do extra fixing-up of string
arguments. (And that reminds me I'm planning to do away with
zero-terminators too, a bigger headache when calling C and Windows
functions.))

> As for untrusted callers, when you check for an error condition, you
> have to know how to handle it. How do you know that the way you handle
> it (say, doing nothing for a null pointer) is the correct behavior?

Sometimes I start writing a function before fully documenting it or knowing
exactly how it will be used, or whether a null parameter is even likely.
It's simplest to just put checks for null right from the start. Usually it
doesn't hurt. If the value *shouldn't* have been null, then I will find out
when the program doesn't do what I want!

--
Bartc

[Keith Thompson]

"BartC" <b...@freeuk.com> writes:
> "Keith Thompson" <ks...@mib.org> wrote in message
> news:lnzkgjk...@nuthaus.mib.org...
>> "BartC" <b...@freeuk.com> writes:
>
>>> With a basic language statement like assignment, you wouldn't expect it
>>> to
>>> be backed up with logic to make sure operands are not null.
>
>>> A function (any function really, rather than just memcpy) is different;
>
>> memcpy(), in a very real sense, is a basic language feature. Yes, it's
>> in the library rather than in the core language, but its performance is
>> just as important as the performance of an assignment.
>>
>> And having memcpy() check for null pointers and do nothing makes certain
>> errors *more difficult to detect*. If I write
>>
>> memcpy(target, source, size);
>>
>> and either target or source happens to be a null pointer, it's almost
>> certainly because I made a mistake.
>
> If size is zero, that's quite likely to be a mistake too. Yet the standard
> defines the behaviour in that case. (I've been looking at the Python
> implementation code; checking for size being zero is the most common check
> before calling memcpy(), even though it is not actually needed. Checks for
> destination or source being null are rarer.)

A size of zero isn't nearly as likely to be a mistake as a null
pointer. For example, suppose you have an array of (whatever) and
a count of how many elements of the array are currently meaningful.
It makes sense to use memcpy() to copy only the meaningful elements.
The fact that the behavior for size==0 is well defined means you
don't need to code that as a special case.

If you insist on treating a null pointer as if it were a pointer to
an empty (whatever), you can certainly do that -- but don't expect
memcpy() to have special-case code to check for null pointers just
so you don't have to.

I don't think anybody has claimed that the C standard library is a model
of consistency. It's evolved over the years from earlier libraries,
some of them independently developed, many of them optimized for much
smaller and slower systems. But I personally find the way memcpy() is
defined to be reasonable, and I think most other C programmers do as
well. (If you're saying that you don't like the way C is defined,
you're certainly not alone.)

>> A memcpy() that hides that mistake
>> from me isn't doing me any favors; it's by no means certain that doing
>> nothing is the correct behavior that will "fix" the bug.
>
> Letting some code deliberately crash seems a rather drastic way of telling
> you something is wrong! And not crashing doesn't mean nothing else is wrong.

Letting code deliberately crash is intended to tell *the developer*
that something is wrong. It's not just a random occurrence;
there's a lot of carefully crafted code in your operating system
that's designed to cause, handle, and report crashes.

[...]

> Sometimes I start writing a function before fully documenting it or knowing
> exactly how it will be used, or whether a null parameter is even likely.
> It's simplest to just put checks for null right from the start. Usually it
> doesn't hurt. If the value *shouldn't* have been null, then I will find out
> when the program doesn't do what I want!

Will you *always* find out? Not all bugs are detected when they should
be. If my code is buggy, I'd much rather have it crash early than
quietly behave in some way other than what I intended.

[Jonathan Leffler]

On 10/28/11 1: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?
>
> any idea?

ISO/IEC 9899:1999 says, in §7.1.4 "Use of library Functions":

Each of the following statements applies unless explicitly stated
otherwise in the detailed descriptions that follow: If an argument to a
function has an invalid value (such as a value outside the domain of the
function, or a pointer outside the address space of the program,
or a null pointer, or a pointer to non-modifiable storage when the
corresponding parameter is not const-qualified) or a type (after
promotion) not expected by a function with variable number of arguments,
the behavior is undefined. If a function argument is
described as being an array, the pointer actually passed to the function
shall have a value such that all address computations and accesses to
objects (that would be valid if the pointer did point to the first
element of such an array) are in fact valid. [...]


So, the C standard explicitly says that you invoke undefined behaviour
if you pass null pointers to a function that does not expect them. And
that in turn means that any behaviour is correct.

You should also look at the TR24731-1 'Safe' functions (available from
the JTC1/SC22/WG14 - C Standard Committee web site:
http://www.open-std.org/jtc1/sc22/wg14/).

--
Jonathan Leffler <jlef...@earthlink.net> #include <disclaimer.h>

[James Kuyper]

On 10/30/2011 02:41 AM, Jonathan Leffler wrote:
> On 10/28/11 1: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?
>>
>> any idea?
>
> ISO/IEC 9899:1999 says, in �7.1.4 "Use of library Functions":

...
> So, the C standard explicitly says that you invoke undefined behaviour
> if you pass null pointers to a function that does not expect them. And
> that in turn means that any behaviour is correct.

The OP's question was, essentially, why those particular functions were
not defined as expecting null pointers. memcmp(), for instance, could
have been defined as either doing nothing, or returning some kind of
error indication, whenever either of it's pointer arguments is null. It
was not so defined, and gaoqiang wants to know why.

I think we have answered that question; but you've answered a different one.
--
James Kuyper

[Nick Keighley]

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

[Nick Keighley]

quite

[Seebs]

On 2011-10-29, Kaz Kylheku <k...@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...@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.

[Patrick Scheible]

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

> On 2011-10-29, Kaz Kylheku <k...@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

[Robert Wessel]

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

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.

[Phil Carmody]

Robert Wessel <robert...@yahoo.com> writes:
> On Sun, 30 Oct 2011 23:43:33 -0700, Patrick Scheible <k...@zipcon.net>
> wrote:
>
> >Seebs <usenet...@seebs.net> writes:
> >
> >> On 2011-10-29, Kaz Kylheku <k...@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*. ...

[Seebs]

On 2011-10-31, Patrick Scheible <k...@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.

[jgharston]

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

[Robert Wessel]

On 31 Oct 2011 12:42:21 +0200, Phil Carmody

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.

[ImpalerCore]

On Oct 28, 4:40 pm, 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?

Ideally, I would love to see the behavior dependent on preprocessor
flag.

If DEBUG is defined,

Constraint violation: s2 != NULL, file example.c, line 9, function
strcmp
[crash]

If DEBUG is not defined: [crash]

Whether adding explicit argument constraint checking to the standard
library is a good idea, I don't know. Do I think it would be useful,
absolutely. My opinion is that unless NULL is explicitly allowed as a
valid representation of a string in the standard, the result should be
a crash, even if NULL in the statement 'strcmp( NULL, NULL );' can be
thought of in some scenarios as equivalent.

If someone requires a function with defensive programming behavior
that allows NULL pointer values as arguments, it should not be named
'strcmp'.

Best regards,
John D.

[Kenneth Brody]

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

[Kenneth Brody]

On 10/28/2011 8:58 AM, Mike Manilone wrote:
[...]
> A null pointer always is invalid or protected by OS, so you won't to
> read/write it.

Well, it's "invalid" as far as C is concerned. Nothing in C that returns a
pointer to a valid object will ever return a null pointer. (Except as a
"special case". However that "special case" will never be a pointer to a
valid object.)

Whether it's "valid" as far as the O/S and hardware are concerned is outside
the realm of the C language itself.

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. For example, it would be legal (AFAIK) for
an implementation to do something like this:

extern char __NULL__;
#define NULL ((void *)(&__NULL__))

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

I do know that some Unix systems actually have a "page" of all-bits-zero at
the address pointed to by NULL. The memory is read-only, but it is there,
and therefore things like strlen(NULL) or strcpy(buffer,NULL) will "work",
in the sense that *(char*)NULL=='\0', and therefore (char*)NULL is read the
same as an empty string.

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

I guess it depends on what you mean by "correctly".

Of course, it's also acceptable for an implementation to define what it
means to dereference a null pointer.

--
Kenneth Brody

[Kaz Kylheku]

On 2011-11-03, Kenneth Brody <kenb...@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?

[Kenneth Brody]

On 10/28/2011 11:00 AM, James Kuyper wrote:

> On 10/28/2011 08:58 AM, Mike Manilone wrote:
[...]

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

> Not all systems have protected memory, not all systems are UNIX, and not
> all systems give you a message when you dereference a null pointer. On
> some systems, you might not discover the bad consequences of doing so
> until long after the fact.

Consider MS-DOS. A "near" NULL pointer would point to the "program segment
prefix", where some critical data was stored. A "far" NULL pointer would
point to the hardware interrupt table. (Even under Win9x, this was still
true in the MS-DOS emulator[1].)

Nasty things could happen if you overwrote them. Sometimes the consequences
would be immediate, sometimes not until much later.


[1] As I recall, the following code on a Win9x box would immediately
hard-lock the system:

void far *vector = MAKE_FP(0,48); /* Makes a far pointer to 0000:0030 */
void far *int21 = *(void far **)vector;

*(long far *)int21 = 0;

Basically, it overwrites the first 4 bytes of the INT21 system call handler.

--
Kenneth Brody

[Kenneth Brody]

On 10/28/2011 4:13 PM, BartC wrote:
> "John Gordon" <gor...@panix.com> wrote in message
[...]
>> 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).

So, memcpy() should lie to you? When you say "copy 50 bytes from NULL to
foo", it should just do nothing?

While it could be argued that, if N is zero, a NULL pointer should be
"legal", what about non-zero-length requests?

What you are saying is that memcpy() should have the overhead of checking
every call to it, even if the caller guarantees that the pointers are valid,
rather than having the caller be responsible to check in the cases where
there might be a NULL pointer. And, if it's possible that one of the
pointers could be zero, shouldn't it be up to the caller to decide how to
handle it?

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

memcpy() returns the first parameter. In ye olde days, this was probably to
allow the buffer to be "efficiently" passed to some other function to be
handled. (Besides, the only other "reasonable" return would be nothing at all.)

How would returning "the number of bytes actually copied" be useful? It's
guaranteed (assuming no UB) to the the number of bytes passed to it.

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

"Deliberately crash" is a bit misleading. The crash, on those systems which
do crash, is a side effect of invoking UB. It's not like the implementation
has:

if ( s1 == NULL ) CrashProgram();


--
Kenneth Brody

[Kenneth Brody]

On 10/28/2011 4:40 PM, Nobody 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?

I know of at least one system which would return zero, as the system
purposely reserves an all-bits-zero "page" of read-only memory at address zero.

On some other system, it would return non-zero, as there was data at address
zero which would not be '\0'. (Unless "far" pointers were being used, in
which case, the byte may or may not have been '\0'.)

However, on just about any system I use today, I would expect the program to
crash.

--
Kenneth Brody

[James Kuyper]

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.

What is permitted is for NULL to expand into a particular form of null
pointer constant that will be converted, when it occurs in a pointer
context, into a pointer which happens to point at __NULL__. It would
require a fair amount of compiler magic, however, to make that happen
without also having 0 == &__NULL__.

[James Kuyper]

On 11/03/2011 11:26 AM, Kenneth Brody wrote:
...

> memcpy() returns the first parameter. In ye olde days, this was probably to
> allow the buffer to be "efficiently" passed to some other function to be
> handled. (Besides, the only other "reasonable" return would be nothing at all.)

It would have been marginally more useful for memcpy(dest, source,
count) to have returned either (void*)((char*)dest+count) or
(void*)((char*)source+count).

> How would returning "the number of bytes actually copied" be useful? It's
> guaranteed (assuming no UB) to the the number of bytes passed to it.

He's suggesting that it no longer be UB if one or both of the pointer
arguments is null, in which case returning 0 as the number of bytes
copied would have some use. Not a lot, but some.

[Kaz Kylheku]

On 2011-11-03, James Kuyper <james...@verizon.net> wrote:
> 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).

Since __NULL__ is an external name in the implementation space, and this is
supposed to be some implementation's definition of NULL anyway, those rules are
moot. The implementation could arrange for &__NULL__ to be a constant
expression to make this all work.

[James Kuyper]

On 11/03/2011 01:08 PM, Kaz Kylheku wrote:
> On 2011-11-03, James Kuyper <james...@verizon.net> wrote:
>> On 11/03/2011 11:00 AM, Kenneth Brody wrote:
...

>>> ... 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).
>
> Since __NULL__ is an external name in the implementation space, and this is
> supposed to be some implementation's definition of NULL anyway, those rules are
> moot. The implementation could arrange for &__NULL__ to be a constant
> expression to make this all work.

I don't think your argument is valid. Where is it stated in the standard
that those conditions render those rules moot? If your argument were
valid, it would render the requirement that NULL expand into a null
pointer constant (7.17p3) meaningless. I doubt that it was intended to
be meaningless.

[Kaz Kylheku]

6.6 10 An implementation may accept other forms of constant expressions.

This sort of thing only makes a difference to highly contrived program
which does something like this:

#define STR(X) #X
#define STRE(X) STR(X)

if (!is_null_pointer_constant(STRE(NULL))) {
printf("unconventional null pointer constant");
}

Where is_null_pointer_constant is a function which lexically analyzes
and parses the stringified expansion of NULL, and validates what kind
of expression it is.

Since implementation can accept other forms of constant expressions,
this program cannot conclude that the implementation is nonconforming
(and is itself not maximally portable since its output depends on
the implementation.)

[James Kuyper]

On 11/03/2011 01:28 PM, Kaz Kylheku wrote:
> On 2011-11-03, James Kuyper <james...@verizon.net> wrote:
>> On 11/03/2011 01:08 PM, Kaz Kylheku wrote:
>>> On 2011-11-03, James Kuyper <james...@verizon.net> wrote:
>>>> On 11/03/2011 11:00 AM, Kenneth Brody wrote:
>> ...
>>>>> ... 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).
>>>
>>> Since __NULL__ is an external name in the implementation space, and this is
>>> supposed to be some implementation's definition of NULL anyway, those rules are
>>> moot. The implementation could arrange for &__NULL__ to be a constant
>>> expression to make this all work.
>>
>> I don't think your argument is valid. Where is it stated in the standard
>> that those conditions render those rules moot? If your argument were
>> valid, it would render the requirement that NULL expand into a null
>> pointer constant (7.17p3) meaningless. I doubt that it was intended to
>> be meaningless.
>
> 6.6 10 An implementation may accept other forms of constant expressions.

Yes, I've seen that argument before, and addressed it in one of the
paragraphs you've snipped from one of my earlier messages. Those forms
are "other" than "integer constants, enumeration constants, character
constants, ... and floating constants", which are the only kinds allowed
in ICE. The "other forms of constant expressions" that "an
implementation may accept" don't meet the requirements of any of the
standard-named categories of constants, so they only fall into the
"other" category. They can be used anywhere that the standard requires a
constant expression, without specifying a particular type of constant
expression; they cannot be used as when a specific type of constant
expression is required, as is indeed the case for null pointer
constants, which require an integer constant expression.

Note that an implementation doesn't need to use 6.6p10 to make &__NULL__
qualify as a constant expression; it already qualifies under the
category "address constant expression" (6.6p9).

[Kaz Kylheku]

&__NULL__ can be a contant integral expression evaluating to zero, if the
implementors so want.

[James Kuyper]

Perhaps, though I doubt that the fact that __NULL__ is a reserved word
gives an implementation permission to ignore the standard semantics of
'&', which can never appear as the first token of an expression with
integer type. If the __NULL__ occurred in user code, it would be a
different matter - but if the user code contains NULL, the
implementation's not allowed to invoke "undefined behavior" as a result
of a feature of that expansion, as an excuse to violate the
standard-defined semantics of '&'.

However, null pointer constants are defined as involving an "integer
constant expression", a phrase whose meaning as a whole is defined in
6.6p6. That definition is not merely the combination of the definitions
of integer, constant, and expression - many constant expressions with
integral type fail to qualify as integer constant expressions.

[Ike Naar]

--
i...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

[Ben Pfaff]

James Kuyper <james...@verizon.net> writes:

> Perhaps, though I doubt that the fact that __NULL__ is a reserved word
> gives an implementation permission to ignore the standard semantics of
> '&', which can never appear as the first token of an expression with
> integer type.

Did you mean to add more qualifiers? I believe that &x - &x is
an expression with integer type, for appropriately defined 'x'.
--
"Welcome to the wonderful world of undefined behavior, where the demons
are nasal and the DeathStation users are nervous." --Daniel Fox

[James Kuyper]

On 11/03/2011 02:22 PM, Ben Pfaff wrote:
> James Kuyper <james...@verizon.net> writes:
>
>> Perhaps, though I doubt that the fact that __NULL__ is a reserved word
>> gives an implementation permission to ignore the standard semantics of
>> '&', which can never appear as the first token of an expression with
>> integer type.
>
> Did you mean to add more qualifiers? I believe that &x - &x is
> an expression with integer type, for appropriately defined 'x'.

You've got a point there. I stated my point too generally, and I'm not
sure how to reword it to cover such issues. I'll concede that &__NULL__
could have integer type if __NULL__ were a macro whose expansion had a
form like that. But that's not the meaning for __NULL__ that was suggested.

[Ike Naar]

On 2011-11-03, Ike Naar <i...@sverige.freeshell.org> wrote:
> On 2011-11-03, Kaz Kylheku <k...@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.

[Kaz Kylheku]

On 2011-11-03, James Kuyper <james...@verizon.net> wrote:
> On 11/03/2011 01:55 PM, Kaz Kylheku wrote:
>> On 2011-11-03, James Kuyper <james...@verizon.net> wrote:
>>> Note that an implementation doesn't need to use 6.6p10 to make &__NULL__
>>> qualify as a constant expression; it already qualifies under the
>>> category "address constant expression" (6.6p9).
>>
>> &__NULL__ can be a contant integral expression evaluating to zero, if the
>> implementors so want.
>
> Perhaps, though I doubt that the fact that __NULL__ is a reserved word
> gives an implementation permission to ignore the standard semantics of

__NULL__ being a reserved word means that demons can fly out of the
programmer's nose when it is used.

[Kaz Kylheku]

On a DeathStation 9000, &__NULL__ overwrites the partition table on your
root disk. :)

[James Kuyper]

On 11/03/2011 03:47 PM, Kaz Kylheku wrote:
> On 2011-11-03, James Kuyper <james...@verizon.net> wrote:
>> On 11/03/2011 01:55 PM, Kaz Kylheku wrote:
>>> On 2011-11-03, James Kuyper <james...@verizon.net> wrote:
>>>> Note that an implementation doesn't need to use 6.6p10 to make &__NULL__
>>>> qualify as a constant expression; it already qualifies under the
>>>> category "address constant expression" (6.6p9).
>>>
>>> &__NULL__ can be a contant integral expression evaluating to zero, if the
>>> implementors so want.
>>
>> Perhaps, though I doubt that the fact that __NULL__ is a reserved word
>> gives an implementation permission to ignore the standard semantics of
>
> __NULL__ being a reserved word means that demons can fly out of the
> programmer's nose when it is used.

No, that would be true only if the user code "declares or defines"
__NULL__ (7.1.3p2). Using NULL counts as neither a declaration nor a
definition of __NULL__. Since, in most contexts, using an identifier
that has neither been declared or defined is either a syntax error or a
constraint violation, user code which uses __NULL__ in any way would
also be a problem, though for a different reason.

However, for the purposes of 7.1.3p2, the expansion of NULL wouldn't
count as such a declaration or definition of __NULL__ even if the
expansion did happen to contain one, because the existence of that
feature is the implementation's responsibility, and it's the
implementation's additional responsibility to ensure that whatever NULL
expands to causes no such problems for strictly conforming code.

While that expansion may contain features that would render the behavior
undefined if they occurred in user code, when they occur in the
expansion of a C standard macro, the behavior is not allowed to be
anything inconsistent with what the C standard specifies for that macro.
What the standard specifies for NULL is a null pointer constant, and it
does not specify any relaxation of the rules determining what a null
pointer constant is.

In any event, the suggested implementation of NULL contained neither a
declaration nor a definition of __NULL__, just a use of __NULL__ as an
operand in an address constant expression. Since the suggested
implementation of NULL also specified that a declaration for __NULL__
appeared inside the standard header, it also doesn't count as a use of
an undeclared identifier.

[James Kuyper]

Except when it is found in the expansion of a standard macro. Otherwise
it's not fully conforming, and as we all know, the DS9000 is a paragon
of conformance. :-)