Debian Bug report logs - #431480
manpages-dev: incomplete utimes(2) man page and typo

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: manpages-dev: incomplete utimes(2) man page and typo

Date: Mon, 2 Jul 2007 23:34:10 +0200

Package: manpages-dev
Version: 2.56-1
Severity: normal

1. The utimes(2) man page mentions:

       int utime(const char *filename, const struct utimbuf *buf);
       int utimes(const char *filename, const struct timeval times[2]);

and describes the case where buf is a null pointer, but not the case
where times is a null pointer, though this is allowed by POSIX:

  http://www.opengroup.org/onlinepubs/009695399/functions/utimes.html

2. In the 3rd paragraph of the description, replace "buf must is" by
"buf is".

3. You should say "a null pointer" instead of "NULL" ("NULL" isn't
necessarily a pointer and is a C notion, and both the C standard and
POSIX use the term "a null pointer").

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (900, 'testing'), (900, 'stable'), (200, 'unstable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.18-3-powerpc
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages manpages-dev depends on:
ii  manpages                      2.49-1     Manual pages about using a GNU/Lin

manpages-dev recommends no packages.

-- no debconf information

Message #10 received at 431480@bugs.debian.org (full text, mbox, reply):

From: Michael Kerrisk <mtk-manpages@gmx.net>

To: Vincent Lefevre <vincent@vinc17.org>, 431480@bugs.debian.org

Cc: debc <control@bugs.debian.org>

Subject: Re: Bug#431480: manpages-dev: incomplete utimes(2) man page and typo

Date: Fri, 20 Jul 2007 08:31:03 +0200

tags 431480 fixed-upstream
thanks

Hello Vincent,

The changes described below will be in upstream 2.65.

> 1. The utimes(2) man page mentions:
> 
>        int utime(const char *filename, const struct utimbuf *buf);
>        int utimes(const char *filename, const struct timeval times[2]);
> 
> and describes the case where buf is a null pointer, but not the case
> where times is a null pointer, though this is allowed by POSIX:
>
>   http://www.opengroup.org/onlinepubs/009695399/functions/utimes.html

The existing text kind of implies the behaviour:

     The function utimes() is similar, ....

but I agree, that the point could be clearer.  I've updated this part of
the page to say:

   utimes()
       The  function  utimes()  is similar, but allows a resolution of 1
       microsecond.  The timeval structure is:

              struct timeval {
                  long tv_sec;        /* seconds */
                  long tv_usec;       /* microseconds */
              };

       times[0] specifies the new access time,  and  times[1]  specifies
       the new modification time.  If times is NULL, then analogously to
       utime(), the access and modification times of the file are set to
       the current time.

> 2. In the 3rd paragraph of the description, replace "buf must is" by
> "buf is".

Thanks.

> 3. You should say "a null pointer" instead of "NULL" ("NULL" isn't
> necessarily a pointer and is a C notion, and both the C standard and
> POSIX use the term "a null pointer").

The copy of POSIX.1-2001 I am looking at is littered with the use of terms
like:

NULL
NULL pointer
non-NULL
a NULL pointer
non-NULL value
if ... is [not] NULL

and so on.  So one of us is confused by your last point; at the moment, I
think it is you ;-).  (I don't disagree that "NULL" is a "C construct", but
I do think the use in the man page is quite acceptable.)

Cheers,

Michael

-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7

Want to help with man page maintenance?  Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages/
read the HOWTOHELP file and grep the source files for 'FIXME'.

Message #17 received at 431480@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.org>

To: Michael Kerrisk <mtk-manpages@gmx.net>

Cc: 431480@bugs.debian.org

Subject: Re: Bug#431480: manpages-dev: incomplete utimes(2) man page and typo

Date: Fri, 20 Jul 2007 12:27:06 +0200

On 2007-07-20 08:31:03 +0200, Michael Kerrisk wrote:
> The copy of POSIX.1-2001 I am looking at is littered with the use of terms
> like:
> 
> NULL
> NULL pointer
> non-NULL
> a NULL pointer
> non-NULL value
> if ... is [not] NULL
> 
> and so on. So one of us is confused by your last point; at the
> moment, I think it is you ;-).

No, this seems to have been fixed in the 2004 edition of POSIX (Issue 6).
See

  http://www.opengroup.org/onlinepubs/009695399/functions/utimes.html

It only uses the term "null pointer". Since it is the standard wording,
the man pages should be fixed too.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Message #22 received at 431480@bugs.debian.org (full text, mbox, reply):

From: "Michael Kerrisk" <mtk-manpages@gmx.net>

To: Vincent Lefevre <vincent@vinc17.org>

Cc: 431480@bugs.debian.org

Subject: Re: Bug#431480: manpages-dev: incomplete utimes(2) man page and typo

Date: Thu, 26 Jul 2007 10:16:07 +0200

-------- Original-Nachricht --------
Datum: Fri, 20 Jul 2007 12:27:06 +0200
Von: Vincent Lefevre <vincent@vinc17.org>
An: Michael Kerrisk <mtk-manpages@gmx.net>
CC: 431480@bugs.debian.org
Betreff: Re: Bug#431480: manpages-dev: incomplete utimes(2) man page and	typo

> On 2007-07-20 08:31:03 +0200, Michael Kerrisk wrote:
> > The copy of POSIX.1-2001 I am looking at is littered with the use of
> terms
> > like:
> > 
> > NULL
> > NULL pointer
> > non-NULL
> > a NULL pointer
> > non-NULL value
> > if ... is [not] NULL
> > 
> > and so on. So one of us is confused by your last point; at the
> > moment, I think it is you ;-).
> 
> No, this seems to have been fixed in the 2004 edition of POSIX (Issue 6).
> See
> 
>   http://www.opengroup.org/onlinepubs/009695399/functions/utimes.html
> 
> It only uses the term "null pointer". Since it is the standard wording,
> the man pages should be fixed too.

How do you deduce that it is the "standard: wording?  Because 
it uses that terminology that on one page?

The wording of this particular spec may have changed (I'll
take your word for it), but that doesn't change the point
that the terms that I mentioned above are used throughout
the standard (even in the POSIX.1 revision that is currently
in progress..  I sere no problem with them.

Cheers,

Michael
-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages , 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.

Message #27 received at 431480@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.org>

To: "Michael Kerrisk" <mtk-manpages@gmx.net>

Cc: 431480@bugs.debian.org

Subject: Re: Bug#431480: manpages-dev: incomplete utimes(2) man page and typo

Date: Thu, 26 Jul 2007 11:27:38 +0200

On 2007-07-26 10:16:07 +0200, Michael Kerrisk wrote:
> > No, this seems to have been fixed in the 2004 edition of POSIX (Issue 6).
> > See
> > 
> >   http://www.opengroup.org/onlinepubs/009695399/functions/utimes.html
> > 
> > It only uses the term "null pointer". Since it is the standard wording,
> > the man pages should be fixed too.
> 
> How do you deduce that it is the "standard: wording?  Because 
> it uses that terminology that on one page?

The following pages also use the term "null pointer":
  http://www.opengroup.org/onlinepubs/009695399/functions/malloc.html
  http://www.opengroup.org/onlinepubs/009695399/functions/fopen.html
  http://www.opengroup.org/onlinepubs/009695399/functions/free.html
  http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_01.html
for instance (and I didn't find any other wording).

> The wording of this particular spec may have changed (I'll
> take your word for it),

This is not a particular spec.

> but that doesn't change the point that the terms that I mentioned
> above are used throughout the standard (even in the POSIX.1 revision
> that is currently in progress.. I sere no problem with them.

This is wrong. The current revision (P1003.1 Draft 3, 15 June 2007)
uses the term "null pointer" (defined in 3.243).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Message #32 received at 431480@bugs.debian.org (full text, mbox, reply):

From: "Michael Kerrisk" <mtk-manpages@gmx.net>

To: Vincent Lefevre <vincent@vinc17.org>, 431480@bugs.debian.org

Cc: 431480@bugs.debian.org

Subject: Re: Bug#431480: manpages-dev: incomplete utimes(2) man page and typo

Date: Thu, 26 Jul 2007 12:07:10 +0200

Vincent,

> On 2007-07-26 10:16:07 +0200, Michael Kerrisk wrote:
> > > No, this seems to have been fixed in the 2004 edition of POSIX (Issue
> > > 6). See
> > > 
> > >   http://www.opengroup.org/onlinepubs/009695399/functions/utimes.html
> > > 
> > > It only uses the term "null pointer". Since it is the standard
> > > wording, the man pages should be fixed too.
> > 
> > How do you deduce that it is the "standard: wording?  Because 
> > it uses that terminology that on one page?
> 
> The following pages also use the term "null pointer":
>   http://www.opengroup.org/onlinepubs/009695399/functions/malloc.html
>   http://www.opengroup.org/onlinepubs/009695399/functions/fopen.html
>   http://www.opengroup.org/onlinepubs/009695399/functions/free.html
>  
> http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_01.html
> for instance (and I didn't find any other wording).

Well, I find numerous other wordings...

> > The wording of this particular spec may have changed (I'll
> > take your word for it),
> 
> This is not a particular spec.

(By "particular spec", I meant the specification of utimes();
I'm not sure if that was clear...)

> > but that doesn't change the point that the terms that I mentioned
> > above are used throughout the standard (even in the POSIX.1 revision
> > that is currently in progress.. I sere no problem with them.
> 
> This is wrong. The current revision (P1003.1 Draft 3, 15 June 2007)
> uses the term "null pointer" (defined in 3.243).

Of course it uses that term.  But it *ALSO* uses other
terminology.  Frequently.  See below.

Cheers,

Michael


$ grep 'is NULL' austin-d3r.txt | sed 's/     */  /'
16320  is NULL, the behavior shall be as if the thread were created with the detachstate attribute set to
19353  asynchronous I/O control block for a particular request to be canceled. If aiocbp is NULL, then
22205  resolution of the specified clock shall be stored in the location pointed to by res. If res is NULL,
22362  the rmtp argument is NULL, the remaining time is not returned. The absolute clock_nanosleep( )
23634  current controlling terminal for the current process. If s is NULL, the return value of ctermid( )   is
34008  terminated string. If the node argument is NULL or the nodelen argument is zero, the node name
34014  as a null-terminated string. If the service argument is NULL or the servicelen argument is zero,
39621  sig is NULL, then no asynchronous notification shall occur. If sig is not NULL, asynchronous
42871  If notification is NULL and the process is currently registered for notification by the specified
42888  [EINVAL] The notification argument is NULL and the process is currently not registered.
42962  unspecified. If attr is NULL, the message queue shall be created with
43914  point to the same object. If the rmtp argument is NULL, the remaining time is not returned.
45858  If the value of the attrp pointer is NULL, then the default values are used.
47256  call. If the argument attr is NULL, the default attributes shall be used. The attr attributes object
50014  attributes referenced by attr. If attr is NULL, the default condition variable attributes shall be
50545  process. If attr is NULL, the default attributes shall be used. If the attributes specified by attr are
51432  specified by attr. If attr is NULL, the default mutex attributes are used; the effect shall be the
52668  attr. If attr is NULL, the default read-write lock attributes shall be used; the effect is the same as
60897  argument is NULL, so the POSIX Threads Extension sigwait( )   function can be implemented as a
64135  when command is NULL.
64204  It was explicitly decided that when command is NULL, system( )   should not be required to check
65322  463) when the timer expires. If the evp argument is NULL, the effect is as if the evp argument
119126  lock attributes object is NULL. In cases where the default attributes are appropriate, the


$ grep 'NULL pointer' austin-d3r.txt | sed 's/     */  /'
19672  NULL pointers, which are ignored. If this array contains pointers that refer to aiocb structures
33312  suggested for the size of this buffer. A NULL pointer shall be returned at the location pointed to |
33437  value suggested for the size of this buffer. A NULL pointer is returned at the location pointed to |
34603  suggested for the size of this buffer. A NULL pointer shall be returned at the location pointed to |
34733  suggested for the size of this buffer. A NULL pointer shall be returned at the location pointed to |
36251  NULL pointer and set errno to indicate the error.
36282  An array of structures identifying local interfaces. A NULL pointer is returned upon an error,
39653  If sig->sigev_notify is SIGEV_THREAD and sig->sigev_notify_attributes is a non-NULL pointer
58473  NULL pointer as the locale. The NULL pointer is a special directive to setlocale( )   that tells it to
58494  If the string does not correspond to a valid locale, setlocale( )   shall return a NULL pointer
60828  MON     immediately with an error. If timeout is the NULL pointer, the behavior is unspecified. If the
60904  with a NULL pointer for timeout.
67541  receive a non-NULL pointer to a siginfo_t structure that describes a child process for

$ grep 'is not NULL' austin-d3r.txt | sed 's/     */  /'
19361  If aiocbp is not NULL, then if fildes does not have the same value as the file descriptor with which
19665  function, or, if timeout is not NULL, until the time interval specified by timeout has passed. If any
22204  implementation-defined and cannot be set by a process. If the argument res is not NULL, the
39621  sig is NULL, then no asynchronous notification shall occur. If sig is not NULL, asynchronous
42864  If the argument notification is not NULL, this function shall register the calling process to be
42991  [EINVAL] O_CREAT was specified in oflag, the value of attr is not NULL, and either
43053  If the argument msg_prio is not NULL, the priority of the selected message shall be stored in the
45797  If file_actions is not NULL, then the file descriptors open in the child process shall be those open
45896  If the file_actions argument is not NULL, and specifies any close, dup2, or open actions to be
65338  TSA        If evp->sigev_sigev_notify is SIGEV_THREAD and sev->sigev_notify_attributes is not NULL, if the
65507  If the argument ovalue is not NULL, the timer_settime( )   function shall store, in the location

$ grep 'non-NULL' austin-d3r.txt | sed 's/     */  /'
17513  any) associated with thread-specific data keys for which the thread has non-NULL values will
22360  argument is non-NULL, the timespec structure referenced by it shall be updated to contain the
23601  functions, it shall ensure that the ctermid( )   function is called with a non-NULL parameter.
34006  If the node argument is non-NULL and the nodelen argument is non-zero, then the node argument
34012  If the service argument is non-NULL and the servicelen argument is non-zero, then the service
39653  If sig->sigev_notify is SIGEV_THREAD and sig->sigev_notify_attributes is a non-NULL pointer
42963  implementation-defined default message queue attributes. If attr is non-NULL
42967  non-NULL, but the calling process does not have the appropriate privilege on
43233  If omqstat is non-NULL, the mq_setattr( )   function shall store, in the location referenced by
43911  value of -1 and set errno to indicate the interruption. If the rmtp argument is non-NULL, the
45868  child process to the parent process, in the variable pointed to by a non-NULL pid argument, and
45870  value stored into the variable pointed to by a non-NULL pid is unspecified, and an error number
51011  [ENOMEM] Insufficient memory exists to associate the non-NULL value with the key.
51037  to ``to associate the non-NULL value with the key''.
51050  pthread_join( )   call with a non-NULL value_ptr argument, the value passed to pthread_exit( )   by
51153  value has a non-NULL destructor pointer, and the thread has a non-NULL value associated with
51157  If, after all the destructors have been called for all non-NULL values with associated destructors,
51158  there are still some non-NULL values with associated destructors, then the process is repeated.
51160  outstanding non-NULL values, there are still some non-NULL values with associated
51162  destructors until no non-NULL values with associated destructors exist, even though this might
51312  threads with non-NULL data and potentially keep them from creating more thread-
60838  NULL. If the info argument is non-NULL, the sigwaitinfo( )   function shall be equivalent to
60841  signal, the first such queued value shall be dequeued and, if the info argument is non-NULL, the
65320  The evp argument, if non-NULL, points to a sigevent structure. This structure, allocated by the
65783  tmpnam( )   function is called with a non-NULL parameter.
67541  receive a non-NULL pointer to a siginfo_t structure that describes a child process for
67710  functions, the application shall ensure that the wcrtomb( )   function is called with a non-NULL ps
68356  functions, the application shall ensure that the wcsrtombs( )   function is called with a non-NULL
119328  applications when their arguments are non-NULL.

-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages , 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.

Message #42 received at 431480@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.org>

To: "Michael Kerrisk" <mtk-manpages@gmx.net>

Cc: 431480@bugs.debian.org

Subject: Re: Bug#431480: manpages-dev: incomplete utimes(2) man page and typo

Date: Thu, 26 Jul 2007 13:48:26 +0200

On 2007-07-26 12:07:10 +0200, Michael Kerrisk wrote:
> > On 2007-07-26 10:16:07 +0200, Michael Kerrisk wrote:
> > > How do you deduce that it is the "standard: wording?  Because 
> > > it uses that terminology that on one page?
> > 
> > The following pages also use the term "null pointer":
> >   http://www.opengroup.org/onlinepubs/009695399/functions/malloc.html
> >   http://www.opengroup.org/onlinepubs/009695399/functions/fopen.html
> >   http://www.opengroup.org/onlinepubs/009695399/functions/free.html
> >  
> > http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_01.html
> > for instance (and I didn't find any other wording).
> 
> Well, I find numerous other wordings...

I had just looked at a few pages, for the most common functions,
in particular (i.e. some parts that should have been read by most
people).

> > > The wording of this particular spec may have changed (I'll
> > > take your word for it),
> > 
> > This is not a particular spec.
> 
> (By "particular spec", I meant the specification of utimes();
> I'm not sure if that was clear...)

In fact, I thought you meant "on only one page".

> > > but that doesn't change the point that the terms that I mentioned
> > > above are used throughout the standard (even in the POSIX.1 revision
> > > that is currently in progress.. I sere no problem with them.
> > 
> > This is wrong. The current revision (P1003.1 Draft 3, 15 June 2007)
> > uses the term "null pointer" (defined in 3.243).
> 
> Of course it uses that term.  But it *ALSO* uses other
> terminology.  Frequently.  See below.

But then I assume that this should be regarded more or less as a bug.
As "null pointer" is defined in POSIX and other terminology is not
(and has a different meaning in other context, e.g. NULL is a macro),
I'd say that "null pointer" is the only terminology that should have
been chosen in this context. I don't see the point of using different
terminologies in a standard, in particular ambiguous ones (e.g., the
expansion of the NULL macro isn't necessarily a pointer, and having a
standard or other documentation that doesn't make the difference is
quite bad).

Do you know if there has been some discussion in austin-group-l (or
some other places) about the terminology for null pointers in POSIX?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Message #47 received at 431480@bugs.debian.org (full text, mbox, reply):

From: "Michael Kerrisk" <mtk-manpages@gmx.net>

To: Vincent Lefevre <vincent@vinc17.org>

Cc: 431480@bugs.debian.org

Subject: Re: Bug#431480: manpages-dev: incomplete utimes(2) man page and typo

Date: Thu, 26 Jul 2007 14:49:49 +0200

> > > > but that doesn't change the point that the terms that I mentioned
> > > > above are used throughout the standard (even in the POSIX.1 
> > > > revision
> > > > that is currently in progress.. I sere no problem with them.
> > > 
> > > This is wrong. The current revision (P1003.1 Draft 3, 15 June 2007)
> > > uses the term "null pointer" (defined in 3.243).
> > 
> > Of course it uses that term.  But it *ALSO* uses other
> > terminology.  Frequently.  See below.
> 
> But then I assume that this should be regarded more or less as a bug.
> As "null pointer" is defined in POSIX and other terminology is not
> (and has a different meaning in other context, e.g. NULL is a macro),
> I'd say that "null pointer" is the only terminology that should have
> been chosen in this context. I don't see the point of using different
> terminologies in a standard, in particular ambiguous ones (e.g., the
> expansion of the NULL macro isn't necessarily a pointer, and having a
> standard or other documentation that doesn't make the difference is
> quite bad).
> 
> Do you know if there has been some discussion in austin-group-l (or
> some other places) about the terminology for null pointers in POSIX?

Not that I know of, but I could easily have missed that, or it 
could have occurred in a time before I followed the Austin 
group much.

Cheers,

Michael
-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages , 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.

Message #52 received at 431480@bugs.debian.org (full text, mbox, reply):

From: "Michael Kerrisk" <mtk-manpages@gmx.net>

To: Vincent Lefevre <vincent@vinc17.org>

Cc: 431480@bugs.debian.org

Subject: Re: Bug#431480: manpages-dev: incomplete utimes(2) man page and typo

Date: Thu, 26 Jul 2007 15:43:07 +0200

> > > This is wrong. The current revision (P1003.1 Draft 3, 15 June 2007)
> > > uses the term "null pointer" (defined in 3.243).
> > 
> > Of course it uses that term.  But it *ALSO* uses other
> > terminology.  Frequently.  See below.
> 
> But then I assume that this should be regarded more or less as a bug.
> As "null pointer" is defined in POSIX and other terminology is not
> (and has a different meaning in other context, e.g. NULL is a macro),
> I'd say that "null pointer" is the only terminology that should have
> been chosen in this context. I don't see the point of using different
> terminologies in a standard, in particular ambiguous ones (e.g., the
> expansion of the NULL macro isn't necessarily a pointer, and having a
> standard or other documentation that doesn't make the difference is
> quite bad).
> 
> Do you know if there has been some discussion in austin-group-l (or
> some other places) about the terminology for null pointers in POSIX?

By the way, note the following in the spec of <stddef.h>:

11296  CX  NULL Null pointer constant. The macro shall expand to an integer constant expression +
11297      with the value 0 cast to type void *.

-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages , 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.

Message #57 received at 431480@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.org>

To: "Michael Kerrisk" <mtk-manpages@gmx.net>

Cc: 431480@bugs.debian.org

Subject: Re: Bug#431480: manpages-dev: incomplete utimes(2) man page and typo

Date: Thu, 26 Jul 2007 17:37:58 +0200

On 2007-07-26 15:43:07 +0200, Michael Kerrisk wrote:
> By the way, note the following in the spec of <stddef.h>:
> 
> 11296  CX  NULL Null pointer constant. The macro shall expand to an integer constant expression +
> 11297      with the value 0 cast to type void *.

Yes, "The macro shall expand to an integer constant expression with
the value 0 cast to type void *" was not in Issue 6. Now, note that
the type of a null pointer is not necessarily void *, and a null
pointer is not necessarily constant! So, if you say NULL instead
of "null pointer", the behavior remains unspecified if the pointer
is null and not constant. Remember that the C standard allows to
implement functions of the standard library as macros, so that an
implementation may be able to do the difference between a constant
value and a non-constant value, something in this style:

#define mpfr_cmp_ui(_f,_u)                 \
 (__builtin_constant_p (_u) && (_u) == 0 ? \
   mpfr_sgn (_f) :                         \
   mpfr_cmp_ui_2exp ((_f),(_u),0))

(this is taken from the MPFR source code, but this is just to show
you the possible implications).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Message #62 received at 431480-close@bugs.debian.org (full text, mbox, reply):

From: Martin Schulze <joey@infodrom.org>

To: 431480-close@bugs.debian.org

Subject: Bug#431480: fixed in manpages 2.65-1

Date: Mon, 12 Nov 2007 11:47:25 +0000

Source: manpages
Source-Version: 2.65-1

We believe that the bug you reported is fixed in the latest version of
manpages, which is due to be installed in the Debian FTP archive:

manpages-dev_2.65-1_all.deb
  to pool/main/m/manpages/manpages-dev_2.65-1_all.deb
manpages_2.65-1.diff.gz
  to pool/main/m/manpages/manpages_2.65-1.diff.gz
manpages_2.65-1.dsc
  to pool/main/m/manpages/manpages_2.65-1.dsc
manpages_2.65-1_all.deb
  to pool/main/m/manpages/manpages_2.65-1_all.deb
manpages_2.65.orig.tar.gz
  to pool/main/m/manpages/manpages_2.65.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 431480@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Martin Schulze <joey@infodrom.org> (supplier of updated manpages package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Mon, 05 Nov 2007 22:43:23 +0100
Source: manpages
Binary: manpages manpages-dev
Architecture: source all
Version: 2.65-1
Distribution: unstable
Urgency: low
Maintainer: Martin Schulze <joey@debian.org>
Changed-By: Martin Schulze <joey@infodrom.org>
Description: 
 manpages   - Manual pages about using a GNU/Linux system
 manpages-dev - Manual pages about using GNU/Linux for development
Closes: 431480 435415 435885 437112 439560 445085 445086 445087 445088 445089
Changes: 
 manpages (2.65-1) unstable; urgency=low
 .
   * New upstream version
     . Spelling and formatting fixes (closes: Bug#439560)
     . Correction of EINVAL in swapon(2) (closes: Bug#435885)
     . Clarify utimes() behaviour in utime(2) (closes: Bug#431480)
     . remove ambiguity in description in copysign(3) (closes: Bug#435415)
     . document stolen time in proc(5) (closes: Bug#437112)
   * Fix spelling error in iso_8859-2(7) (closes: Bug#445085)
   * Fixed typo in missing(7) (closes: Bug#445087)
   * Fixed typos in ip(7) (closes: Bug#445088)
   * Fixed typo in hier(7) (closes: Bug#445086)
   * Improvement to services(5) by A. Costa (closes: Bug#445089)
Files: 
 488233a627242111810be6b0b4067545 584 doc important manpages_2.65-1.dsc
 8dcdc34d0314a148513f5502a3f17377 1267435 doc important manpages_2.65.orig.tar.gz
 1a1558531f901fef4c483e08acebdfda 57767 doc important manpages_2.65-1.diff.gz
 c9c35669a07a00b1e8e13e67ee1c19d9 531534 doc important manpages_2.65-1_all.deb
 ba6ebed1192c98882c481d5ac911651f 1289244 doc optional manpages-dev_2.65-1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHMCFAW5ql+IAeqTIRAqlVAJ4yhsPOwDbin4RI1fQQllsBdTaY2gCdHo+m
pIggNd2zvyJSpaaF4fcqs9Q=
=EvU8
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.