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 #defines dont matter as cc never sees them so line 11 is seen as
func(0)
0 will be an int by default. When this call is made a 32 bit int with a
value of 0 will be pushed onto the stack. When func is executed this 32
bit value is cast to a 16 bit short and this causes a warning to be
emitted
On Wed, Nov 08, 2000 at 02:47:40PM +1000, [EMAIL PROTECTED] wrote:
>
> On Tue, 7 Nov 2000, Albert D. Cahalan wrote:
>>
>> 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 to int would be a de
On Tue, 7 Nov 2000, Albert D. Cahalan wrote:
> of a fixed point argument except when the same as the default
> promotion.
> 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
"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
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 caus
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
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 expl
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 dec
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, and conve
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 const
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 explicitly cast them to a long or unsigned
long or plain
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 a pr
13 matches
Mail list logo
