The following reply was made to PR kern/175759; it has been noted by GNATS.
From: Andrey Simonenko <si...@comsys.ntu-kpi.kiev.ua>
To: Gleb Smirnoff <gleb...@freebsd.org>
Cc: freebsd-gnats-sub...@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.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
