Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 Apr 2008 13:18:45 +0300
From:      Giorgos Keramidas <keramida@ceid.upatras.gr>
To:        Bernard van Gastel <bvgastel@bitpowder.com>
Cc:        hackers@freebsd.org, Garrett Cooper <yanefbsd@gmail.com>, Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org>
Subject:   Re: strdup(NULL) supposed to create SIGSEGV?
Message-ID:  <87ej8w3md6.fsf@kobe.laptop>
In-Reply-To: <5F412E73-29FC-4876-A6F0-9BC269876192@bitpowder.com> (Bernard van Gastel's message of "Wed, 23 Apr 2008 10:30:39 %2B0200")
References:  <7d6fde3d0804222240j6b42b77yd86d8accb5a959fa@mail.gmail.com> <20080423025048.6b51a580@bhuda.mired.org> <5F412E73-29FC-4876-A6F0-9BC269876192@bitpowder.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 23 Apr 2008 10:30:39 +0200, Bernard van Gastel <bvgastel@bitpowder.com> wrote:
> Op 23 apr 2008, om 08:50 heeft Mike Meyer het volgende geschreven:
>> On Tue, 22 Apr 2008 22:40:21 -0700
>> "Garrett Cooper" <yanefbsd@gmail.com> wrote:
>>
>>> Hi all,
>>>     I made an oops in a program, which uncovered "feature" in
>>> strdup(2)
>>> that I wasn't aware of before. So I was wondering, is strdup(pointer
>>> = NULL)
>>> supposed to segfault should this just return NULL and set errno?
>>
>> Yes, it's supposed to segfault. Check out what, say, strcpy does if
>> you ask it to copy a NULL pointer. And this is an improvement from the
>> bad old days, when they would happily walk through memory starting at
>> 0.....
>
> I don't like it this way. I would like:
>
> strdup(NULL) = NULL
> strdup(string) = copy of string
>
> strcpy(NULL, NULL) = NULL
> strcpy(s1, NULL) = ERROR
> strcpy(NULL, s2) = NULL (with s2 unchanged)
> strcpy(s1, s2) = normal
>
> But I am not sure of the implications. Maybe in some situation it is
> bad... Anyone?

Well-written programs already check for NULL before they call strdup(),
so they won't be affected by changing strdup() to return NULL when a
null pointer is passed to strdup().

What is more likely to happen is that _badly_ written programs will
crash further down, at the place where the null pointer is actually
used.  So we'll be "hiding" the bug of strdup(NULL) and causing faults
in other, possibly very far places in the program's execution path.

That's not really a very good idea :(

>> Besides, errno is used to signal errors from system calls. strdup
>> isn't a system call, it's a library function (says so at the top of
>> the man page).
>
> But strdup uses malloc, which is a system call (from the strdup manual:
> If insufficient memory is available, NULL is returned and  errno is set
> to ENOMEM.)

I have to disagree I'm afraid.  The malloc() function is *not* a system
call, although it may be mapped to low-level primitives like sbrk() or
mmap().

In general, malloc() is a `special' library function that abstracts away
the implementation specific details of obtaining memory from the kernel.
There are implementations of malloc() out there that rely on certain
system-specific features but are, otherwise, implemented *entirely* in
userland code.  Our own is one.  The sources of FreeBSD's malloc() are
in `/usr/src/lib/libc/stdlib/malloc.c' for anyone interested to read the
source and see all the cool things Jason has done :)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87ej8w3md6.fsf>