Re: GCC 3.3.1, new warnings with limits
David Leimbach wrote: Gcc needs a #pragma to disable specific warnings as a one-shot. This was discussed in detail on the GCC mailing list. True... but I don't think I was talking about a one-shot disabling of the message. I was thinking more about how a compliant C++ compiler can determine the signedness of a datatype without type introspection or type metadata available at compile time. [which seems to be what numeric_limitsT is all about doesn't it?] I don't think there's a good answer available that's also portable. What you need is an implementation that doesn't care about the signedness of the type. You could do some really ugly tricks that would work. For example, calling a helper function with the same argument twice, and setting one of the arguments to zero, and using *that* to do the compare (the types would always match). using two compares swapping the values would tell you what you needed. You'd probably want to mark the helper private, or at least protected, and call it something like _docompare to put it in the implementation space. As I said... really ugly tricks. 8-). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
David Leimbach wrote: This is a good policy in general, however, one could easily argue that what is trying to be determined with signedness and such being less-than-compared to 0 isn't really a big deal and possibly the only way to implement this numeric_limitsT::digits thing without any type introspection which C++ currently lacks. The following would work for example in a template function: [ ... ] Gcc needs a #pragma to disable specific warnings as a one-shot. This was discussed in detail on the GCC mailing list. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Monday, July 14, 2003, at 01:33PM, Terry Lambert [EMAIL PROTECTED] wrote: David Leimbach wrote: This is a good policy in general, however, one could easily argue that what is trying to be determined with signedness and such being less-than-compared to 0 isn't really a big deal and possibly the only way to implement this numeric_limitsT::digits thing without any type introspection which C++ currently lacks. The following would work for example in a template function: [ ... ] True... but I don't think I was talking about a one-shot disabling of the message. I was thinking more about how a compliant C++ compiler can determine the signedness of a datatype without type introspection or type metadata available at compile time. [which seems to be what numeric_limitsT is all about doesn't it?] Dave Gcc needs a #pragma to disable specific warnings as a one-shot. This was discussed in detail on the GCC mailing list. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
In message: [EMAIL PROTECTED] Craig Rodrigues [EMAIL PROTECTED] writes: : I think that this is a FreeBSD issue. I compiled : the same file under Linux, with a GCC 3.3.1 checked out on 7/11 : and did not encounter this warning. keep in mind that on linux the -wno-system-headers is default, while it isn't default on freebsd, which is why we see it and you don't there... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
In message: [EMAIL PROTECTED] Alexander Kabaev [EMAIL PROTECTED] writes: : Short of fixing offending files in FSF libstdc++ or turning warning : suppression back on for standard C++ include files selectively, I have : no suggestion. In the past I know that FSF has accepted patches back, so maybe the right thing to do is: o figure out the fix(es) that we need. o submit them to fsf o if they accpet them, then we can import them on the vendor branch or disable warnings in the system headers if not The warnings are quite annoying, and we'll get a lot of grief from the growing number of large c++ ports. I'd be happy to come up with a patch. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Saturday, July 12, 2003, at 11:05PM, Alexander Kabaev wrote:
On Sat, 12 Jul 2003 23:13:12 -0400
Craig Rodrigues [EMAIL PROTECTED] wrote:
I am guessing that the C preprocessor does not think that it is
in a system header, and thus prints out the warning.
We specifically disable automatic warning suppression for system
headers, because we _want_ to know about them. Your Linux distribution
apparently does not care.
This is a good policy in general, however, one could easily argue that
what
is trying to be determined with signedness and such being
less-than-compared
to 0 isn't really a big deal and possibly the only way to implement this
numeric_limitsT::digits thing without any type introspection which
C++ currently
lacks.
The following would work for example in a template function:
template typname T
void foo(T const f)
{
if (numeric_limitsT::digits % 2)
//type is signed
else
//type is unsigned
}
However to implement digits we have that nasty macro that makes the
comparison
which is meaningless for unsigned types of 0.
This is probably a perfect example of where the C++ standards committee
folks should
be queried about the best way to implement numeric_limitsT::digits.
Some of them
have had no trouble pointing out that C99's tgmath.h header cannot be
implemented in
pure standard C99. This may also be true of numeric_limitsT::digits.
I am going to the newsgroups... My old college advisor is/was a
moderator on
comp.lang.c++.moderated and he may just know the answer :).
Any GCC/FreeBSD expert care to comment? ;)
Short of fixing offending files in FSF libstdc++ or turning warning
suppression back on for standard C++ include files selectively, I have
no suggestion.
I'd rather we fix the problem in gcc but this extra verbosity when
there is nothing
wrong with user code also seems incorrect. I think the gcc developers
should have a
separate command line option for internal headers don't you?
--
Alexander Kabaev
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sunday, July 13, 2003, at 8:13AM, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Craig Rodrigues [EMAIL PROTECTED] writes: : I think that this is a FreeBSD issue. I compiled : the same file under Linux, with a GCC 3.3.1 checked out on 7/11 : and did not encounter this warning. keep in mind that on linux the -wno-system-headers is default, while it isn't default on freebsd, which is why we see it and you don't there... Ah, excellent... this is exactly what I was looking for. :) Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sun, Jul 13, 2003 at 12:43:31AM -0400, Craig Rodrigues wrote: The warnings seemed to be caused by this code in /usr/include/c++/3.3/limits: = 630 static const int digits = __glibcpp_digits (unsigned int); 631 static const int digits10 = __glibcpp_digits10 (unsigned int); = The macros are defined in the same file here: 134 #define __glibcpp_signed(T) ((T)(-1) 0) 142 #define __glibcpp_digits(T) \ 143 (sizeof(T) * __CHAR_BIT__ - __glibcpp_signed (T)) The expanded macros look like: static const int digits = (sizeof(unsigned int) * 8 - ((unsigned int)(-1) 0)); static const int digits10 = ((sizeof(unsigned int) * 8 - ((unsigned int)(-1) 0)) * 643 / 2136); Perhaps this would work: #define __glibcpp_signed(T) (!((T)(-1) 0)) I have tried this with GCC 3.2 (5.1-BETA i386, -W -Wall), and a plain C program (not C++). cc and c++ do the same. The old macro gives the warning about comparing signed types, but the new one does not. They both work for int, u_int, unsigned int and char. The compiler moans about (T)(-1) = 0 as well. Is the assumption that (unsigned type)(-1) is never zero valid? If it's not, try (!((T)(-1) 0 || (T)(-1) == 0)). GCC does not seem to moan about that, even though it's exactly the same as using =. Jilles Tjoelker ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
In message: [EMAIL PROTECTED] Jilles Tjoelker [EMAIL PROTECTED] writes: : The compiler moans about (T)(-1) = 0 as well. Is the assumption that : (unsigned type)(-1) is never zero valid? yes. There are no known machines where -1 == 0 for types of different signs. Further, the C standard says that it must behave as if it is a two's complement machine, and I think that C++ says so too. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
: 134 #define __glibcpp_signed(T) ((T)(-1) 0) : #define __glibcpp_signed(T) (!((T)(-1) 0)) Why not the simpler: #define __glibcpp_signed(T) ((T)(-1) = 0) that way we have an overlap on the range of the two types, so we won't get a warning. We know for a fact that -1 != 0 for all known machine types (all machines are two's complement, or are required to behave as if they are two's complement, per the standard). (unsigned int) -1 == 0x (assuming 32-bit int). even on a one's complement's machine, without the standard conversion, the 'type punning' conversion of -1 would yield 0xfffe, which is still 0. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sunday, July 13, 2003, at 1:11PM, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Jilles Tjoelker [EMAIL PROTECTED] writes: : The compiler moans about (T)(-1) = 0 as well. Is the assumption that : (unsigned type)(-1) is never zero valid? yes. There are no known machines where -1 == 0 for types of different signs. Further, the C standard says that it must behave as if it is a two's complement machine, and I think that C++ says so too. I am pretty certain you can do one's compliment in the C99 standard, and that some of that is implementation/platform dependant. See section 6.2.6.2 of the C99 standard which enumerates the following 3 negative number representations: ¡Xthe corresponding value with sign bit 0 is negated (sign and magnitude); ¡Xthe sign bit has the value-(2^N )(two¡¦s complement); ¡Xthe sign bit has the value-(2^N -1) (one¡¦s complement). further: Which of these applies is implementation-defined, as is whether the value with sign bit 1 and all value bits zero (for the first two), or with sign bit and all value bits 1 (for one¡¦s complement), is a trap representation or a normal value. Inthe case of sign and magnitude and one¡¦scomplement, if this representation is a normal value it is called a negative zero. Yes... a negative 0. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sun, Jul 13, 2003 at 08:23:54AM -0500, David Leimbach wrote: This is a good policy in general, however, one could easily argue that what is trying to be determined with signedness and such being less-than-compared to 0 isn't really a big deal and possibly the only way to implement this numeric_limitsT::digits thing without any type introspection which C++ currently lacks. What about? #define issigned(T) (((T)(0)(T)(~0)) ? 1 : 0) -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sunday, July 13, 2003, at 1:23PM, M. Warner Losh wrote: : 134 #define __glibcpp_signed(T) ((T)(-1) 0) : #define __glibcpp_signed(T) (!((T)(-1) 0)) Why not the simpler: #define __glibcpp_signed(T) ((T)(-1) = 0) that way we have an overlap on the range of the two types, so we won't get a warning. We know for a fact that -1 != 0 for all known machine types (all machines are two's complement, or are required to behave as if they are two's complement, per the standard). You keep saying this... where is this must behave as two's compliment stated? (unsigned int) -1 == 0x (assuming 32-bit int). or with a valid one's compliment C99 compliant system (unsigned int) -1 = 0xfffe; even on a one's complement's machine, without the standard conversion, the 'type punning' conversion of -1 would yield 0xfffe, which is still 0. Correct :). I still don't think C enforces two's compliment. Dave Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sun, Jul 13, 2003 at 01:25:45PM -0500, David Leimbach wrote: On Sunday, July 13, 2003, at 1:11PM, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Jilles Tjoelker [EMAIL PROTECTED] writes: : The compiler moans about (T)(-1) = 0 as well. Is the assumption that : (unsigned type)(-1) is never zero valid? yes. There are no known machines where -1 == 0 for types of different signs. Further, the C standard says that it must behave as if it is a two's complement machine, and I think that C++ says so too. I am pretty certain you can do one's compliment in the C99 standard, and that some of that is implementation/platform dependant. snip You seem to be confused. While signed integers certainly can use the one's complement representation, the conversion of an negative value to an unsigned type is a different matter. The relevant quote from C99 is: 6.3.1.3 Signed and unsigned integers 2 Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type.49) Regards, Stefan Farfeleder ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sun, Jul 13, 2003 at 01:37:32PM -0500, David Leimbach wrote: On Sunday, July 13, 2003, at 1:23PM, M. Warner Losh wrote: : 134 #define __glibcpp_signed(T) ((T)(-1) 0) : #define __glibcpp_signed(T) (!((T)(-1) 0)) Why not the simpler: #define __glibcpp_signed(T) ((T)(-1) = 0) that way we have an overlap on the range of the two types, so we won't get a warning. We know for a fact that -1 != 0 for all known machine types (all machines are two's complement, or are required to behave as if they are two's complement, per the standard). You keep saying this... where is this must behave as two's compliment stated? (unsigned int) -1 == 0x(assuming 32-bit int). or with a valid one's compliment C99 compliant system (unsigned int) -1 = 0xfffe; Only if UINT_MAX happens to be0xfffe, which it probablky won't be. For all C99 compliant systems you have that: (unsigned int) -1 == UINT_MAX even on a one's complement's machine, without the standard conversion, the 'type punning' conversion of -1 would yield 0xfffe, which is still 0. Correct :). I still don't think C enforces two's compliment. C doesn't require two's compliment, but it encourages it. If you take a signed value and convert it to the corresponding unsigned type , the result must be equal modulo 2^N to the original value (where N is the number of bits in the unsigned type. (Ignoring any padding bits.)) (Actually it is modulo a value one greater than the largest value representable by the unsigned type, but this amounts to the same thing.) This means that -1 converted to an unsigned type will always be the largest number representable by that unsigned type. This is true regardless of how negative numbers are represented. For two's complement there is no need to change the representation when converting signed to unsigned values, while this can be needed when using sign-magnitude or one's-complement. And to answer the original question: It is valid to assume that -1 converted to an unsigned integer type will never be equal to 0. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
C doesn't require two's compliment, but it encourages it. If you take a signed value and convert it to the corresponding unsigned type , the result must be equal modulo 2^N to the original value (where N is the number of bits in the unsigned type. (Ignoring any padding bits.)) (Actually it is modulo a value one greater than the largest value representable by the unsigned type, but this amounts to the same thing.) This means that -1 converted to an unsigned type will always be the largest number representable by that unsigned type. This is true regardless of how negative numbers are represented. For two's complement there is no need to change the representation when converting signed to unsigned values, while this can be needed when using sign-magnitude or one's-complement. So for the one way conversion of signed to unsigned it will behave like 2's compliment all the time. What about back to signed? I assume that it defaults back to the platform's implementation of the signed type which due to the conversion to unsigned would also, logically, be encouraged to behave as a 2's compliment signed number. Cute way to make the standard seem flexible. The overhead of type conversion is often overlooked in coding it seems... On some platforms like the PPC going from int to float takes a lot longer than one might think... but that is another story :). [no need to answer this... unless we take it out of this thread] And to answer the original question: It is valid to assume that -1 converted to an unsigned integer type will never be equal to 0. No arguments here. :) Sorry if we wandered off too far. It was at least enlightening for me and hopefully others. Dave -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
In message: [EMAIL PROTECTED] David Leimbach [EMAIL PROTECTED] writes: : You keep saying this... where is this must behave as two's compliment : stated? Read the fine print on the signed to unsigned conversion and you find that it must be done modulo 2^N. Also, I never stated that the standard requires the machine use two's complement representation, but it has to behave as if that were the case. From the standard: 6.3.1.3 Signed and unsigned integers [#1] When a value with integer type is converted to another integer type other than _Bool, if the value can be represented by the new type, it is unchanged. [#2] Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type. The argument runs like this: o assume int is 32 bits, but the argument can be run for other word sizes. o the largest value is 0x. largest plus 1 is 0x1. o -1 increased by 'one more than the maximum value' is 0x. That's behaving as if the type was two's complement. : (unsigned int) -1 == 0x (assuming 32-bit int). : : or with a valid one's compliment C99 compliant system : (unsigned int) -1 = 0xfffe; That's an invlaid conversion. While -1 might be represented by the bit pattern 0xfffe, (unsigned int) -1 must evaluate to 0x. : even on a one's complement's machine, without the standard conversion, : the 'type punning' conversion of -1 would yield 0xfffe, which is : still 0. : : Correct :). I still don't think C enforces two's compliment. You are partially right. An 'int' containing '-1' might have a bit pattern of 0xfffe or even 0x80001, but converting it to 'unsigned' must result in 0x. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
In message: [EMAIL PROTECTED] David Leimbach [EMAIL PROTECTED] writes: : : On Sunday, July 13, 2003, at 1:11PM, M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : Jilles Tjoelker [EMAIL PROTECTED] writes: : : The compiler moans about (T)(-1) = 0 as well. Is the assumption that : : (unsigned type)(-1) is never zero valid? : : yes. There are no known machines where -1 == 0 for types of different : signs. Further, the C standard says that it must behave as if it is a : two's complement machine, and I think that C++ says so too. : : : I am pretty certain you can do one's compliment in the C99 standard, : and that : some of that is implementation/platform dependant. : : See section 6.2.6.2 of the C99 standard which enumerates the following 3 : negative number representations: : : ¡Xthe corresponding value with sign bit 0 is negated (sign and : magnitude); : ¡Xthe sign bit has the value-(2^N )(two¡¦s complement); : ¡Xthe sign bit has the value-(2^N -1) (one¡¦s complement). : I'm aware of that. However, the section that I quoted in my other mail (assuming it went out) says that when converting from signed to unsigned must be done in a way as if it was two's complement. : further: : Which of these applies is implementation-defined, as is whether the : value with sign bit 1 and all value bits zero (for the first two), or : with sign bit and all value bits 1 (for one¡¦s complement), is a trap : representation or a normal value. Inthe case of sign and magnitude and : one¡¦scomplement, if this representation is a normal value it is called : a negative zero. : : Yes... a negative 0. Yes. that's true, but never with unsigned types. Again, the standard specifies math such that you must make things behave as if it is two's complement, even if it isn't represented like that in the underlying bits. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
In message: [EMAIL PROTECTED] David Leimbach [EMAIL PROTECTED] writes: : So for the one way conversion of signed to unsigned it will behave like : 2's compliment : all the time. What about back to signed? Same way. It will be reduced by the maximum value of the range plus one to do the conversion. See section for 6.3.1.3 for the details. That's why I said 'as if' in my other mail. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sun, Jul 13, 2003 at 02:28:38PM -0500, David Leimbach wrote: C doesn't require two's compliment, but it encourages it. If you take a signed value and convert it to the corresponding unsigned type , the result must be equal modulo 2^N to the original value (where N is the number of bits in the unsigned type. (Ignoring any padding bits.)) (Actually it is modulo a value one greater than the largest value representable by the unsigned type, but this amounts to the same thing.) This means that -1 converted to an unsigned type will always be the largest number representable by that unsigned type. This is true regardless of how negative numbers are represented. For two's complement there is no need to change the representation when converting signed to unsigned values, while this can be needed when using sign-magnitude or one's-complement. So for the one way conversion of signed to unsigned it will behave like 2's compliment Signed to unsigned will always give the same result, regardless of how negative numbers are represented, yes. (And for two's complement this is the same as the natural way of doing it, while for other representations some extra work might be needed.) all the time. What about back to signed? I assume that it defaults back to the If you have try to convert a value to a signed type and the type in question cannot that value, then the result is implementation-defined. Implementation-defined means the implementation is free to do whatever it wants, but it must document what it will do. Typically implementations won't do anything special but will just keep the same representation, but this is not something that portable programs can depend on. So, on a one's complement machine one would probably have that: (int)UINT_MAX == 0 (Since UINT_MAX would have the same representation as a negative zero on such a machine.) On a sign-magnitude machine it would probably be (int)UINT_MAX == INT_MIN and on a two's complement machine one would probably have (int)UINT_MAX == -1 but an implementation is also free to trap on integer overflow, just as it usually does with division by zero. (Or it might do something else.) Unsigned arithmetic is well-defined in C. Signed arithmetic less so. platform's implementation of the signed type which due to the conversion to unsigned would also, logically, be encouraged to behave as a 2's compliment signed number. Cute way to make the standard seem flexible. The overhead of type conversion is often overlooked in coding it seems... On some platforms like the PPC going from int to float takes a lot longer than one might think... That depends on how long one thinks it should take, doesn't it? :-) but that is another story :). [no need to answer this... unless we take it out of this thread] And to answer the original question: It is valid to assume that -1 converted to an unsigned integer type will never be equal to 0. No arguments here. :) Sorry if we wandered off too far. It was at least enlightening for me and hopefully others. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sun, Jul 13, 2003 at 01:48:38PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] David Leimbach [EMAIL PROTECTED] writes: : So for the one way conversion of signed to unsigned it will behave like : 2's compliment : all the time. What about back to signed? Same way. It will be reduced by the maximum value of the range plus one to do the conversion. No, this case is implementation-defined if the value cannot be represented by the signed type it is converted to. (If it can be represented then the value will be preserved.) See section for 6.3.1.3 for the details. Yes, please do. That's why I said 'as if' in my other mail. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sun, 13 Jul 2003, Marcel Moolenaar wrote: On Sun, Jul 13, 2003 at 08:23:54AM -0500, David Leimbach wrote: This is a good policy in general, however, one could easily argue that what is trying to be determined with signedness and such being less-than-compared to 0 isn't really a big deal and possibly the only way to implement this numeric_limitsT::digits thing without any type introspection which C++ currently lacks. What about? #define issigned(T) (((T)(0)(T)(~0)) ? 1 : 0) This is worse than any version that uses -1 instead of ~0, since ~0 gives implementation-defined behaviour. I think it can set trap bits. Anyway, the value of ~0 is unclear. I think it is -0 == 0 on 1's complement machines. Since its value is unclear, the result of converting this value to even an unsigned type T is also unclear. I think the above actually does work for the 3 representations in C99 iff ~0 has no trap bits, but this is unclear. These problems are avoided by using plain -1. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sun, 13 Jul 2003, Erik Trulsson wrote:
On Sun, Jul 13, 2003 at 01:37:32PM -0500, David Leimbach wrote:
You keep saying this... where is this must behave as two's compliment
stated?
(unsigned int) -1 == 0x (assuming 32-bit int).
or with a valid one's compliment C99 compliant system
(unsigned int) -1 = 0xfffe;
Only if UINT_MAX happens to be0xfffe, which it probablky won't be.
Probabilty zero on C99 conformant systems :-). UFOO_MAX is (2^N - 1)
where N is the number of value bits in the representation of type FOO.
See 6.2.6.2. (UFOO_MAX may still be represented differently in memory
than as N lower bits all set.)
[Someone wrote]
even on a one's complement's machine, without the standard conversion,
the 'type punning' conversion of -1 would yield 0xfffe, which is
still 0.
Correct :). I still don't think C enforces two's compliment.
I don't think there is any requirement that the layout of the bits in
representations of unsigned types has anything to do with the layout
for signed types, so type punning might set implementation-specific wrong
{value, trap, padding} bits.
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
Heh that's because the offending macro __glibcpp_digits calls
__glibcpp_signed (T)
on an unsigned type which does a compareison.
std::numeric_limits signed long::digits on a 32bit FBSD will yield 31
because its
got 31 bits for magnitude.
Unfortunately the way it seems to go about calculating that stuff at
compile time
seems to be invalid due to the fact that it does 0 compares on
unsigned types.
Is this a gcc issue or a FBSD issue? [is this the original gcc c++
header file or has
it been tweaked?]
Dave
On Saturday, July 12, 2003, at 10:53AM, Craig Rodrigues wrote:
Hi,
If I compile the following program:
#include iostream
int main(int argc, char *argv[] { return 0; }
with the following flags:
g++ -W -Wall b.cc
I get lots of warnings that did not appear in GCC 3.2:
In file included from /usr/include/c++/3.3/bits/locale_facets.tcc:43,
from /usr/include/c++/3.3/locale:47,
from /usr/include/c++/3.3/bits/ostream.tcc:37,
from /usr/include/c++/3.3/ostream:535,
from /usr/include/c++/3.3/iostream:45,
from b.cc:1:
/usr/include/c++/3.3/limits:630: warning: comparison of unsigned
expression 0
is always false
/usr/include/c++/3.3/limits:631: warning: comparison of unsigned
expression 0
is always false
/usr/include/c++/3.3/limits:730: warning: comparison of unsigned
expression 0
is always false
/usr/include/c++/3.3/limits:731: warning: comparison of unsigned
expression 0
is always false
/usr/include/c++/3.3/limits:830: warning: comparison of unsigned
expression 0
is always false
/usr/include/c++/3.3/limits:831: warning: comparison of unsigned
expression 0
is always false
Is there a way to fix the limits header file?
--
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sat, Jul 12, 2003 at 09:50:21PM -0500, David Leimbach wrote: Heh that's because the offending macro __glibcpp_digits calls __glibcpp_signed (T) on an unsigned type which does a compareison. std::numeric_limits signed long::digits on a 32bit FBSD will yield 31 because its got 31 bits for magnitude. Unfortunately the way it seems to go about calculating that stuff at compile time seems to be invalid due to the fact that it does 0 compares on unsigned types. Is this a gcc issue or a FBSD issue? [is this the original gcc c++ header file or has it been tweaked?] Hi, I think that this is a FreeBSD issue. I compiled the same file under Linux, with a GCC 3.3.1 checked out on 7/11 and did not encounter this warning. I looked in the source code of gcc and found this: /usr/src/contrib/gcc/c-common.c 2597 case LT_EXPR: 2598 if (extra_warnings !in_system_header 2599! (TREE_CODE (primop0) == INTEGER_CST 2600 ! TREE_OVERFLOW (convert (c_common_signed_typ e (type), 2601 primop0 2602 warning (comparison of unsigned expression 0 is alway s false); 2603 value = boolean_false_node; 2604 break; I am guessing that the C preprocessor does not think that it is in a system header, and thus prints out the warning. If I take the following preprocessed source (test.ii) and compile it under FreeBSD with g++ -W -c test.ii: === # 1 test.cc # 1 built-in # 1 command line # 1 test.cc # 1 /usr/include/c++/3.3/iostream 1 3 # 43 /usr/include/c++/3.3/iostream 3 static const int digits = (sizeof(unsigned int) * 8 - ((unsigned int)(-1) 0)); === I get: In file included from test.cc:1: /usr/include/c++/3.3/iostream:44: warning: comparison of unsigned expression 0 is always false If I compile the same file on my Linux box, with a gcc checked out from the FSF CVS repository (gcc version 3.3.1 20030711 (prerelease)), I do not get the warning. I am not an expert on the GNU C preprocessor format, but I changed two of the lines in the above file to: # 1 /usr/include/c++/3.3/iostream 1 # 43 /usr/include/c++/3.3/iostream and when I recompiled it under Linux, I also got the warning: In file included from test.cc:1: /usr/include/c++/3.3/iostream:44: warning: comparison of unsigned expression 0 is always false Any GCC/FreeBSD expert care to comment? ;) -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
Hi, I think that this is a FreeBSD issue. I compiled the same file under Linux, with a GCC 3.3.1 checked out on 7/11 and did not encounter this warning. I think you hit it on the head. I looked in the source code of gcc and found this: /usr/src/contrib/gcc/c-common.c 2597 case LT_EXPR: 2598 if (extra_warnings !in_system_header 2599! (TREE_CODE (primop0) == INTEGER_CST 2600 ! TREE_OVERFLOW (convert (c_common_signed_typ e (type), 2601 primop0 2602 warning (comparison of unsigned expression 0 is alway s false); 2603 value = boolean_false_node; 2604 break; I am guessing that the C preprocessor does not think that it is in a system header, and thus prints out the warning. If I take the following preprocessed source (test.ii) and compile it under FreeBSD with g++ -W -c test.ii: === # 1 test.cc # 1 built-in # 1 command line # 1 test.cc # 1 /usr/include/c++/3.3/iostream 1 3 # 43 /usr/include/c++/3.3/iostream 3 static const int digits = (sizeof(unsigned int) * 8 - ((unsigned int)(-1) 0)); === I get: In file included from test.cc:1: /usr/include/c++/3.3/iostream:44: warning: comparison of unsigned expression 0 is always false If I compile the same file on my Linux box, with a gcc checked out from the FSF CVS repository (gcc version 3.3.1 20030711 (prerelease)), I do not get the warning. I am not an expert on the GNU C preprocessor format, but I changed two of the lines in the above file to: # 1 /usr/include/c++/3.3/iostream 1 # 43 /usr/include/c++/3.3/iostream and when I recompiled it under Linux, I also got the warning: In file included from test.cc:1: /usr/include/c++/3.3/iostream:44: warning: comparison of unsigned expression 0 is always false Any GCC/FreeBSD expert care to comment? ;) -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sat, 12 Jul 2003 23:13:12 -0400 Craig Rodrigues [EMAIL PROTECTED] wrote: I am guessing that the C preprocessor does not think that it is in a system header, and thus prints out the warning. We specifically disable automatic warning suppression for system headers, because we _want_ to know about them. Your Linux distribution apparently does not care. Any GCC/FreeBSD expert care to comment? ;) Short of fixing offending files in FSF libstdc++ or turning warning suppression back on for standard C++ include files selectively, I have no suggestion. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sun, Jul 13, 2003 at 12:05:59AM -0400, Alexander Kabaev wrote: On Sat, 12 Jul 2003 23:13:12 -0400 Craig Rodrigues [EMAIL PROTECTED] wrote: I am guessing that the C preprocessor does not think that it is in a system header, and thus prints out the warning. We specifically disable automatic warning suppression for system headers, because we _want_ to know about them. Your Linux distribution apparently does not care. How do you disable/enable warning suppression for system headers? I am not familiar enough with how GCC works in this area. Any GCC/FreeBSD expert care to comment? ;) Short of fixing offending files in FSF libstdc++ or turning warning suppression back on for standard C++ include files selectively, I have no suggestion. Hmm, I'm not sure what to recommend here either. I'd like to see this fixed somewhere, because this increases the warning output for some large C++ projects that I work with (I like to see warnings also). The warnings seemed to be caused by this code in /usr/include/c++/3.3/limits: = 630 static const int digits = __glibcpp_digits (unsigned int); 631 static const int digits10 = __glibcpp_digits10 (unsigned int); = The macros are defined in the same file here: 134 #define __glibcpp_signed(T) ((T)(-1) 0) 142 #define __glibcpp_digits(T) \ 143 (sizeof(T) * __CHAR_BIT__ - __glibcpp_signed (T)) The expanded macros look like: static const int digits = (sizeof(unsigned int) * 8 - ((unsigned int)(-1) 0)); static const int digits10 = ((sizeof(unsigned int) * 8 - ((unsigned int)(-1) 0)) * 643 / 2136); I don't really know how to fix this. Maybe introduce a new macro? #define __glibcpp_unsigned_digits(T) \ (sizeof(T) * __CHAR_BIT__ and then use that macro only for unsigned quantities? Thanks. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
