[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#576501: marked as done (libc6-dev: Overeager nonnull attributes in function prototypes)

Your message dated Wed, 19 May 2010 17:17:21 +0200
with message-id <20100519151721.GB20912@hall.aurel32.net>
and subject line Re: Bug#576501: Retraction of proposed resolution
has caused the Debian Bug report #576501,
regarding libc6-dev: Overeager nonnull attributes in function prototypes
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
576501: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576501
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libc6-dev
Version: 2.10.2-6
Severity: normal

I just started playing with clang's static analyzer. It nicely warns
whenever a function parameter that has been marked with nonnull attribute
gets a NULL as parameter. The problem is that there are several functions
where it's actually valid to give it a NULL pointer, as long as the size
parameter is zero. For example these are valid:

 - memcpy(dest, src=NULL, size=0)
 - same for memmove()
 - qsort(base=NULL, nmemb=0, ..)
 - lots of others too, but the above ones are what I mostly care about.

I guess the question is if these nonnulls ever help programmers, or if
they're there just because "it looks nice", but mainly give false positive
warnings.

Here's an example of what type of code triggered it for me:

void foo(const char *src)
{
        char *dest;
        unsigned int len;

        len = src == NULL ? 0 : strlen(src);
        dest = malloc(len + 2);
        if (dest == NULL) return;

        dest[0] = '>';
        memcpy(dest + 1, src, len);
        dest[len] = '\0';
}

So src=NULL, but len=0 so it doesn't matter. Adding an extra if check there
would just make the code uglier.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-rc3-00056-g9dc251d-dirty (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6-dev depends on:
ii  libc-dev-bin                  2.10.2-6   Embedded GNU C Library: Developmen
ii  libc6                         2.10.2-6   Embedded GNU C Library: Shared lib
ii  linux-libc-dev                2.6.32-5   Linux support headers for userspac

Versions of packages libc6-dev recommends:
ii  bcc [c-compiler]              0.16.17-3  16-bit x86 C compiler
ii  gcc [c-compiler]              4:4.4.3-1  The GNU C compiler
ii  gcc-3.3 [c-compiler]          1:3.3.6-15 The GNU C compiler
ii  gcc-3.4 [c-compiler]          3.4.6-10   The GNU C compiler
ii  gcc-4.1 [c-compiler]          4.1.2-27   The GNU C compiler
ii  gcc-4.2 [c-compiler]          4.2.4-6    The GNU C compiler
ii  gcc-4.3 [c-compiler]          4.3.4-6    The GNU C compiler
ii  gcc-4.4 [c-compiler]          4.4.3-5    The GNU C compiler

Versions of packages libc6-dev suggests:
pn  glibc-doc                     <none>     (no description available)
ii  manpages-dev                  3.23-1     Manual pages about using GNU/Linux

-- debconf-show failed

--- End Message ---
--- Begin Message --- 
On Wed, May 12, 2010 at 07:37:27PM +1000, Peter Moulder wrote:
> Since writing that last message, I've been convinced that NULL is
> not in fact valid for memcpy etc.  I give my (revised) reasoning at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44081#c8
> 
> Consequently, I retract my last message, and now suggest rejecting the bug
> as invalid.
> 
> (Original submitter cc'd to ensure opportunity to express acceptance or
>  rejection of this revised reading and consequent suggested rejection of
>  the bug.  Apologies if this results in you getting more than one copy:
>  I've heard of a case where the original submitter claimed not to have
>  automatically received replies to the bug, so I'm cc'ing just in case.)
> 

This is indeed a wrong bug, especially the standards says:

| "Where an argument declared as size_t n specifies the length of the array 
| for a function, n can have the value zero on a call to that function. 
| Unless explicitly stated otherwise in the description of a particular 
| function in this subclause, pointer arguments on such a call shall still 
| have valid values, as described in 7.1.4."

Closing the bug with this mail.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---
Reply to: