kern/175759: Correct data types for fields of struct qm_trace{} from <sys/queue.h>

Andrey Simonenko simon at comsys.ntu-kpi.kiev.ua
Fri Feb 1 13:50:02 UTC 2013


The following reply was made to PR kern/175759; it has been noted by GNATS.

From: Andrey Simonenko <simon at comsys.ntu-kpi.kiev.ua>
To: Gleb Smirnoff <glebius at FreeBSD.org>
Cc: FreeBSD-gnats-submit at freebsd.org
Subject: Re: kern/175759: Correct data types for fields of struct qm_trace{}
 from <sys/queue.h>
Date: Fri, 1 Feb 2013 15:49:07 +0200

 On Fri, Feb 01, 2013 at 05:04:27PM +0400, Gleb Smirnoff wrote:
 > On Fri, Feb 01, 2013 at 01:43:46PM +0200, Andrey Simonenko wrote:
 > A> If QUEUE_MACRO_DEBUG is defined and WARNS >= 4, then a program that
 > A> uses some macro definitions from <sys/queue.h> cannot be built because
 > A> of "warning: assignment discards qualifiers from pointer target type"
 > A> warnings.
 > 
 > Can you please provide a sample file? I can reproduce this with simple
 > declaration of TAILQ_HEAD for example, neither with gcc nor clang.
 
 Tested on 9.1-STABLE with gcc (from the base system) and clang (from ports).
 
 queue.c:
 -------------------------------------------------------------------------
 #include <sys/queue.h>
 #include <stdlib.h>
 
 struct foo {
 	int x;
 };
 
 TAILQ_HEAD(foo_tailq, foo);
 
 int
 main(void)
 {
 	struct foo_tailq foo_tailq;
 
 	TAILQ_INIT(&foo_tailq);
 	return (0);
 }
 -------------------------------------------------------------------------
 
 Makefile:
 -------------------------------------------------------------------------
 PROG=queue
 
 DEBUG_FLAGS=-DQUEUE_MACRO_DEBUG
 
 WARNS=4
 
 NO_MAN=
 
 .include <bsd.prog.mk>
 -------------------------------------------------------------------------
 
 > 
 > A> 1. File name fields should have "const char *" type.
 > 
 > Paragraph 6.10.8 of standard says that __FILE__ is "a character string
 > literal". It doesn't say that it can be referenced only by a pointer
 > with const qualifier.
 > 
 > However, the proposed change definitely makes sence.
 
 Yes, but values these pointers are pointed to are not expected
 to be modified and pointing (char *) to __FILE__ will generate above
 given warning message.
 
 > 
 > A> 2. Line number fields should have "long" or "unsigned long" type,
 > A>    considering C99 standard and its values for [U]INT_MAX, __LINE__
 > A>    and #line.
 > 
 > Paragraph 6.10.8 of standard says that __LINE__ is "an integer constant".
 > 
 > Paragraph 6.4.4.1 on integer constants says that "The type of an integer
 > constant is the first of the corresponding list in which its value can
 > be represented." The corresponding list starts with "int". According to
 > paragraph 6.10.4 line number can't get bigger that 2147483647 (INT_MAX),
 > and this value can be represented by int.
 > 
 > Thus, I don't see where standard says that line number should be long.
 
 5.2.4.2.1 says "Their implementation-defined values shall be equal or
 greater in magnitude (absolute  value) to those shown, with the same sign."
 
          -- maximum value for an object of type int
             INT_MAX                     +32767 // 2^15-1
          -- maximum value for an object of type unsigned int
             UINT_MAX                     65535 // 2^16-1
          -- maximum value for an object of type long int
             LONG_MAX               +2147483647 // 2^31-1
          -- maximum value for an object of type unsigned long int
             ULONG_MAX               4294967295 // 2^32-1
 
 According to this information the closest integer data type to the maximum
 value of a line number given in #line is "long" or "unsigned long".
 
 Even if we assume that INT_MAX is bigger that 2^31-1 then specifying
 "unsigned long" in that structure (without changing the order of its fields)
 will not change its size on i386 and amd64.
 
 Also I think there is sense to give initial values for TRACEBUF in
 TAILQ_HEAD_INITIALIZER, since gcc and clang generate warnings for WARNS>=3.


More information about the freebsd-bugs mailing list