what does this warning mean ?

[John J. Smith]

MSVC++ says:
------------------------------------------------
twarn1.c(11) : warning C4057: 'initializing' : 'int *' differs in
indirection to slightly
different base types from 'long *'
twarn1.c(12) : warning C4057: 'initializing' : 'unsigned int *' differs
in indirection to
slightly different base types from 'unsigned long *'
twarn1.c(14) : warning C4057: 'initializing' : 'unsigned char *' differs
in indirection to
slightly different base types from 'char *'
-----------------------------------------------
only at the highest warning level (-W4)

At the default level absolutely NO warnings are issued.

I am ready to change the compiler if any contradiction
to the standard is detected. I do not see here why a
warning is mandatory however.

Well if nothing else, it would definitely help discover portability
issues since plain int and long (and pointers thereto) are not
necessarily the same size and/or representation. I also think the
parent article to my response was wondering whether signed and
unsigned quantities should be treated differently.

context was


I can confirm that lcc-win32 (version 3.8) issues a warning for
the statement marked 'line 12:' but not for the statement marked
'line 13:'. (MSVC warns in both cases)

Is lcc-win32's behaviour really intentional?

 

[Joachim Schmitz]

[...]
[1] We would get "bug reports" on things like "isleap() says that
the year 2000 is a leap year", [...]

The response to that one was a classic. It circulated
widely on the Net even before there was a Web, and can still
be found: Google "11-60903".

I've seen that before, many years ago.

However, our response at the time was basically "Not a bug -- the
year 2000 _is_ a leap year."

While this is short, correct and to the point, the other is certainly more
fun to read

Bye, Jojo

 

[Charlie Gordon]

"Keith Thompson" <[email protected]> a écrit dans le message de (e-mail address removed)... [...]

Does MS really define a type LONG, distinct from long, or did you put
LONG in all-caps for emphasis?

As was already mentioned elsethread, MS typedefs a truckload of all caps
types such as BYTE, WORD, LONG and DWORD intrinsically hard-wired for
widths
of 8, 16 and 32 bits. After 20 years of brainwashing, it was impossible
to
change the width of LONG or long for the WIN64 architecture.

[...]

But long and LONG are the same size, right? Right???

They are and shall remain 32 bits in width for seculae seculorum, amen.

 

[Kenneth Brody]

Kenneth Brody wrote:
[...]
[1] We would get "bug reports" on things like "isleap() says that
the year 2000 is a leap year", [...]

The response to that one was a classic. It circulated
widely on the Net even before there was a Web, and can still
be found: Google "11-60903".

I've seen that before, many years ago.

However, our response at the time was basically "Not a bug -- the
year 2000 _is_ a leap year."

While this is short, correct and to the point, the other is certainly more
fun to read

True. But, at the time, Windows 95 was still called Chicago, the
search engines weren't as all-encompassing as they are now, and I
probably didn't know about that link at the time.

On the other hand, I did like replying to the occasional "but my
$MS_APPLICATION says that 2000 isn't a leap year" with something
along the lines of "well, then Microsoft got it wrong, and you
should send them a bug report". (Somehow that was more satisfying
than correcting those who simply said that "century years aren't
leap years".)


[Begin lame attempt to bring this back to clc.]

So, did K&R get it right in their first library?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Flash Gordon]

John J. Smith wrote, On 01/10/07 01:45:

jacob navia wrote:



I can confirm that lcc-win32 (version 3.8) issues a warning for
the statement marked 'line 12:' but not for the statement marked
'line 13:'. (MSVC warns in both cases)

Is lcc-win32's behaviour really intentional?

If it does not produce a diagnostic in standard conforming mode then it
is a bug since the standard requires a diagnostic.

 

[Richard Bos]

"Keith Thompson" <[email protected]> a écrit dans le message de news: [...]

Does MS really define a type LONG, distinct from long, or did you put
LONG in all-caps for emphasis?

As was already mentioned elsethread, MS typedefs a truckload of all caps
types such as BYTE, WORD, LONG and DWORD intrinsically hard-wired for widths
of 8, 16 and 32 bits. After 20 years of brainwashing, it was impossible to
change the width of LONG or long for the WIN64 architecture.

But long and LONG are the same size, right? Right???

*Sigh* We can only hope. But I would never bet money on it remaining
that way. For instance, did you know that INT is typically not
typedef'ed in the same header as LONG and CHAR, but in the one which
also typedefs FLOAT and WORD? The way M$ design their systems never
ceases to amaze me, and the liberties they take with C are stunning.

Richard

 

[David Thompson]

Note that
a) main is not required to have a prototype; and

Not required by the standard. M Navia is apparently helping to enforce
a coding style that requires prototypes, which is probably a good idea
(at least when optional as he has said this is) and certainly legal.

b) a function definition _is_ a prototype, if no previous prototype
has been provided, and provided it has parameters - see 6.9.1 .

It is a prototype if it uses the (new) parameter-type-list syntax,
whether or not that declares any parameters. It is not if it has
parameters declared in the old (K&R1) style with identifier-list and
separate following declaration-list.

If there was a previous prototype (which must have been a declaration
because there can't be two definitions) then a prototype(d) definition
is still a prototype, and must be compatible with the previous
declaration(s) (else CV), but is redundant in the sense that it gives
the compiler no new information to use in compiling calls.

It is also a reasonable coding style to require a prototype
_declaration_ for all functions, or at least all with external
linkage, even if they have prototype definitions. If you follow the
convention that the declaration is in the header file and that (same)
header file is #included in both the implementation and all callers,
this checks that all callers are compatible with the callee even if
you change the interface. (Well, assuming you recompile everything
needed as with make or similar, or just recompile everything period;
AND that both/all sites actually get the same header file not some
variant or conflictingly-named one; AND nothing (important) in that
header file is affected by things e.g. typedefs or macros that are
different in the different #include'r environments. Bleah.)

In my view, whatever else is the case, since main is not required to
have a prototype, it is simply misleading to generate errors
suggesting otherwise.

See above.

- formerly david.thompson1 || achar(64) || worldnet.att.net