0;
19}
Even though I have a cast at line 9 that one would expect to inhibit
There is?
such a warning, the warning remains. This is what happens when one
tries to compile programs that use umask(2) with -Wconversion. Macros
umask is taking a 16 bit number off a 32 bit stack...
M
Giorgos Keramidas writes:
3#define VALUE 0
My original question was if this is not behavior that should be
considered buggy, since the size of VALUE has not been determined to be
equal to sizeof(int) when the #define occurs, or has it?
The size of VALUE is not the issue; the
While trying to compile libskey with various warnings enabled, I
discovered the following funny thing about -Wconversion and umask(2),
which caused libskey to fail to compile, because it compiles by default
with -Werror which makes every warning fatal.
I found that the warning is caused when
enabled, I
discovered the following funny thing about -Wconversion and umask(2),
which caused libskey to fail to compile, because it compiles by default
with -Werror which makes every warning fatal.
I found that the warning is caused when a program that calls umask(2) is
compiled
On Tue, Nov 07, 2000 at 12:17:34PM +0200, Peter Pentchev wrote:
In my experience, the problem is not only with umask(2) - GCC *is*
a bit stubborn about -Wconversion; I wonder if this is really a GCC bug :(
I'm having the same problems with many other functions when passing
integer constants
On Tue, 7 Nov 2000, Giorgos Keramidas wrote:
discovered the following funny thing about -Wconversion and umask(2),
I spent quite a while trying to silence that warning in one of my programs
the otherday but I decided it was probably harmless and left it.
and vice versa
On Tue, Nov 07, 2000 at 11:30:05PM +1000, [EMAIL PROTECTED] wrote:
On Tue, 7 Nov 2000, Giorgos Keramidas wrote:
discovered the following funny thing about -Wconversion and umask(2),
I spent quite a while trying to silence that warning in one of my programs
the otherday but I decided
On Tue, 7 Nov 2000, Peter Pentchev wrote:
In my experience, the problem is not only with umask(2) - GCC *is*
a bit stubborn about -Wconversion; I wonder if this is really a GCC bug :(
I'm having the same problems with many other functions when passing
integer constants - even if I
On Tue, Nov 07, 2000 at 11:32:11AM -0500, Chris BeHanna wrote:
On Tue, 7 Nov 2000, Peter Pentchev wrote:
In my experience, the problem is not only with umask(2) - GCC *is*
a bit stubborn about -Wconversion; I wonder if this is really a GCC bug :(
I'm having the same problems with many
Peter Pentchev writes:
As you can see, I'm passing a short i as a first arg, a short f
as second, and a short b as third; and yet, gcc with BDECFLAGS
complains about ALL the arguments!
Yes, no kidding. That's what you asked gcc to do.
`-Wconversion'
Warn if a prototype causes
"Albert D. Cahalan" writes:
The C language is crufty. In the absense of a prototype, "short" is
promoted to "int". You wanted to be warned about that; you got it!
To avoid the warning, avoid passing anything but "int" and "double".
Maybe "long" is OK too, I forget.
I'm not sure which C
On Tue, 7 Nov 2000, Albert D. Cahalan wrote:
of a fixed point argument except when the same as the default
promotion.
snip
The C language is crufty. In the absense of a prototype, "short" is
promoted to "int". You wanted to be warned about that; you got it!
short going
at one would expect to inhibit
such a warning, the warning remains. This is what happens when one
tries to compile programs that use umask(2) with -Wconversion. Macros
defined in sys/stat.h header, much like VALUE above are passed to a
function that expects a `short', and the warning is
13 matches
Mail list logo
