what does this warning mean ?

[Kenneth Brody]

Eric Sosman wrote:
[...]

There is no ambiguity. The committee reviewed the
report of the defect, responded that there was none (and
explained their reasoning), and closed the DR.

The fact that a defect report is filed does not prove
that a defect actually exists. Observe how strenuously
you yourself are denying any defect in lcc-win32 despite
the defect report that originated this very thread!

[...]

I would expect most software developers to know the difference between
a "defect report" and a "defect". The general populace, on the other
hand...

The company I work for used to keep a list of "bug reports" and their
status publicly available on the website. This stopped when TPTB at
the company that bought the company objected, stating that they were
getting complaints along the line of "why would be buy a software
package with 600 bugs?"

The fact that this list included all reports, including real bugs
that were fixed long ago, as well as non-bugs[1], seemed to elude
some people. Adding a disclaimer to that effect wasn't enough for
TPTB, and the list was removed from the publicly accessible part of
the site.


[1] We would get "bug reports" on things like "isleap() says that
the year 2000 is a leap year", or "on a DT-100 terminal, the
vertical lines don't connect", or things that were simply
pure user error. These were all included in the list.

--
+-------------------------+--------------------+-----------------------+
| 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]>

 

[Charlie Gordon]

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.

Microsoft is not a good example to follow (most of the regulars think it's
obvious, but in this case it is blatant).

When they moved from 16 to 32 bits with the Win32 API, back in 1993, they
made int and LONG the same size, but engraved WORD and LONG as 16 and 32
bits in memory and file based data structures. Since then, there has been a
growing confusion between these two types, and they never prevented it with
appropriate warnings in their tools. Pretending that 'unsigned int *' and
unsigned long *' be just indirections to *slightly* different base types is
calling for a beating.

No surprise, when came time to make choices for a Win64 API, the confusion
had settled in so deeply into every corner of the API that it was hopeless
to try and change the size of any of these types. As far as Windows is
concerned, int and long and LONG will remain 32 bits forever, while size_t
became 64 bits (unsigned long long), yuk!.

You seem to make the same confusion: you consider int and long to be
typedefs to the same int32_t base type, and quickly lose sight of the actual
original type. This is a bogus approximation that does not work for border
cases. I don't know if the original lcc had this approach, but as was
demonstrated elsethread, it produces a non-conformant (aka broken) compiler.

I have no idea how difficult it would be to fix this in lcc-win32, only you
know.

 

[Keith Thompson]

Absolutely!.... I couldn't agree more . Though the US can keep Blair

<SARCASM>
Yes, an international political debate is *exactly* what this
newsgroup needs.
</SARCASM>

Followups redirected.

 

[jacob navia]

<SARCASM>
Yes, an international political debate is *exactly* what this
newsgroup needs.
</SARCASM>

Yes, Let's go back to what they were discussing before... What was it?

Ahhh yes!

Why jacob is a "Frog".

Very on topic!

 

[Mark McIntyre]

This is the definition of a function with an unspecified
number of arguments.

No. This is the definition of a function with _no_ arguments.

I do not think so. But I am not a language lawyer.

Well you bloody well should be, if you intend to claim you have
written a C compiler. Good grief.

This means that main has no prototype since you did NOT
provide a prototype and main *IS* always called!

Note that
a) main is not required to have a prototype; and
b) a function definition _is_ a prototype, if no previous prototype
has been provided, and provided it has parameters - see 6.9.1 .

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.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Eric Sosman]

[...]
[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".

 

[Eric Sosman]

Yes, Let's go back to what they were discussing before... What was it?

Ahhh yes!

Why jacob is a "Frog".

Very on topic!

"It's not that easy bein' green." -- K

 

[jacob navia]

No. This is the definition of a function with _no_ arguments.

If I write

int foo() { return 5; }

int main() { foo(10); }

neither MSVC nor gcc will complain even at the HIGHEST
warning level (Wall -W4 respectively) ???

Because the function definition of foo DOES NOT GIVE A PROTOTYPE
as specified in the Defect Report 317 where the question was
explicitly posed to the standard committee that clearly answered:
NO, there is NO prototype produced by
int foo()

So you are just WRONG.

Well you bloody well should be, if you intend to claim you have
written a C compiler. Good grief.

I am correct according to DR 317.

And I am still not a lawyer.

 

[Mark McIntyre]

Mark McIntyre wrote:

....the function definition of foo DOES NOT GIVE A PROTOTYPE

So you are just WRONG.

Apparently as well as being not a language lawyer, you also can't
read.

I did not say it was a prototype.

I am correct according to DR 317.

DR 317 relates to whether or not the definition void f() {} is a
prototype. Its not. I have not said otherwise. I've said it defines a
function with no arguments.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[jacob navia]

Apparently as well as being not a language lawyer, you also can't
read.

I did not say it was a prototype.


DR 317 relates to whether or not the definition void f() {} is a
prototype. Its not. I have not said otherwise. I've said it defines a
function with no arguments.

Yes a function with no arguments and no prototype.
THAT IS WHY MY WARNING IS:

missing prototype for "foo".

 

[Mark McIntyre]

THAT IS WHY MY WARNING IS:
missing prototype for "foo".

However I was commenting on your statement that foo() {} defined a
function with an unspecified number of arguments.

If you want to retract the statement, this is probably a good time.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Keith Thompson]

If I write

int foo() { return 5; }

int main() { foo(10); }

neither MSVC nor gcc will complain even at the HIGHEST
warning level (Wall -W4 respectively) ???

Because the function definition of foo DOES NOT GIVE A PROTOTYPE
as specified in the Defect Report 317 where the question was
explicitly posed to the standard committee that clearly answered:
NO, there is NO prototype produced by
int foo()

So you are just WRONG.

[snip]

jacob, *please* calm down. Your habit of (figuratively) jumping up
and down and shouting whenever you think you're right and somebody
else is wrong comes across as being quite childish. We all make
mistakes here. I often correct other people's mistakes, and other
people often correct my mistakes. Most of the time, it's done calmly
and politely, and I'm grateful when someone points out that I've
gotten something wrong. You're acting as if your being right is a
rare event, a cause for celebration; I really don't think that's the
impression you want to convey.

Now I suggest you re-read the above very carefully. Part of the
context was snipped; the orginal example was:

int main()
{
...
}

You said that this is the definition of a function with an unspecified
number of arguments. You were mistaken. Mark said that it's the
definition of a function with no arguments. Apart from the use of the
word "arguments" rather than "parameters", he was right. It defines a
function with no parameters. If you don't believe me, try writing
some code to replace the '..." that refers to a parameter of main.

It's true that the above definition does not provide a prototype for
main (but Mark never said that it does). It's true that, since there
is no prototype, compilers typically do not diagnose calls that
attempt to pass extra arguments (but Mark never said that they do).

The above definition *defines* main as a function with no parameters,
but it *declares* main as a function with an unspecified number and
type of parameters. I presume I don't have to explain to you the
difference between a declaration and a definition.

Mark was right. You were right in some of the things you wrote, but
you were wrong in asserting that Mark was wrong; you refuted things
that he never said.

 

[Keith Thompson]

Microsoft is not a good example to follow (most of the regulars think it's
obvious, but in this case it is blatant).

When they moved from 16 to 32 bits with the Win32 API, back in 1993, they
made int and LONG the same size, but engraved WORD and LONG as 16 and 32
bits in memory and file based data structures. Since then, there has been a
growing confusion between these two types, and they never prevented it with
appropriate warnings in their tools. Pretending that 'unsigned int *' and
unsigned long *' be just indirections to *slightly* different base types is
calling for a beating.

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

[...]

You seem to make the same confusion: you consider int and long to be
typedefs to the same int32_t base type, and quickly lose sight of the actual
original type. This is a bogus approximation that does not work for border
cases. I don't know if the original lcc had this approach, but as was
demonstrated elsethread, it produces a non-conformant (aka broken) compiler.

I have no idea how difficult it would be to fix this in lcc-win32, only you
know.

My understanding, based on what jacob has posted here, is that
lcc-win32 treats int and long as the same type only in later parts of
its analysis. Actual type conflicts, such as assigning an int* to a
long*, are correctly caught because that checking is done early. The
(non-required) checking of printf format is done later, which is what
led to the bug we've been discussing here. (I'm using the word "bug"
in this case, to refer to a false statement in a warning message, not
to any non-conformance.)

I don't *think* it's been demostrated here that lcc-win32 does
anything non-conforming as a result of its conflating of int and long.

Now if I were writing a compiler from scratch, I would maintain int
and long as separate types through all processing phases. The
internal compiler data structures that describe those types might
include referenes to some common machine-level information. For
example, there might be an internal "WORD" pseudo-type. The
pseudo-type WORD would be used only for code generation; everything
visible to the user, particularly diagnostic messages, would refer to
the language-defined types int and long, which would remain distinct.

I don't intend this as a criticism of lcc-win32; I'm just thinking out
loud about the best way to structure a compiler to avoid problems like
the ones we've seen here.

 

[pete]

If I write

int foo() { return 5; }

int main() { foo(10); }

neither MSVC nor gcc will complain even at the HIGHEST
warning level (Wall -W4 respectively) ???

Because the function definition of foo DOES NOT GIVE A PROTOTYPE
as specified in the Defect Report 317 where the question was
explicitly posed to the standard committee that clearly answered:
NO, there is NO prototype produced by
int foo()

So you are just WRONG.

[snip]

jacob, *please* calm down. Your habit of (figuratively) jumping up
and down and shouting whenever you think you're right and somebody
else is wrong comes across as being quite childish. We all make
mistakes here. I often correct other people's mistakes, and other
people often correct my mistakes. Most of the time, it's done calmly
and politely, and I'm grateful when someone points out that I've
gotten something wrong. You're acting as if your being right is a
rare event, a cause for celebration; I really don't think that's the
impression you want to convey.

Now I suggest you re-read the above very carefully. Part of the
context was snipped; the orginal example was:

int main()
{
...
}

You said that this is the definition of a function with an unspecified
number of arguments. You were mistaken. Mark said that it's the
definition of a function with no arguments. Apart from the use of the
word "arguments" rather than "parameters", he was right. It defines a
function with no parameters. If you don't believe me, try writing
some code to replace the '..." that refers to a parameter of main.

It's true that the above definition does not provide a prototype for
main (but Mark never said that it does). It's true that, since there
is no prototype, compilers typically do not diagnose calls that
attempt to pass extra arguments (but Mark never said that they do).

The above definition *defines* main as a function with no parameters,
but it *declares* main as a function with an unspecified number and
type of parameters. I presume I don't have to explain to you the
difference between a declaration and a definition.

You might have to.

Mark was right. You were right in some of the things you wrote, but
you were wrong in asserting that Mark was wrong; you refuted things
that he never said.

Mark was righter than that.
jacob navia even quoted Mark's
explanation of the point of confusion,
and then disagreed with it,
and then followed the diagreement with something
that almost looks like an apology:

"> You're right that in a DECLARATION, they are different:

>
> int main(); /* main takes an unspecified number of parameters */
> int main(void); /* main takes no parameters */
>
> So the warning is indeed bogus and incorrect.
>

I do not think so. But I am not a language lawyer.
"

 

[Mark McIntyre]

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

MS define a whole slew of types in ALL CAPS, including LONG. .
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Charlie Gordon]

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.

[...]

You seem to make the same confusion: you consider int and long to be
typedefs to the same int32_t base type, and quickly lose sight of the
actual
original type. This is a bogus approximation that does not work for
border
cases. I don't know if the original lcc had this approach, but as was
demonstrated elsethread, it produces a non-conformant (aka broken)
compiler.

I have no idea how difficult it would be to fix this in lcc-win32, only
you
know.

My understanding, based on what jacob has posted here, is that
lcc-win32 treats int and long as the same type only in later parts of
its analysis. Actual type conflicts, such as assigning an int* to a
long*, are correctly caught because that checking is done early. The
(non-required) checking of printf format is done later, which is what
led to the bug we've been discussing here. (I'm using the word "bug"
in this case, to refer to a false statement in a warning message, not
to any non-conformance.)

Yes, I agree.

I don't *think* it's been demostrated here that lcc-win32 does
anything non-conforming as a result of its conflating of int and long.

Not exactly from conflating int and long, but from general confusion of
integer types: in a thread early this month (Re: Visual C++ Express Edition
or lcc-win32?) someone pointed out that some of the definitions in stdin.h
were incorrect:

#define INT8_MIN -128
#define INT16_MIN -32768
#define INT32_MIN -2147483648

Jacob probably corrected the missing parentheses by now, but the issue is
more sublte:

-2147483648 is a long long in C99, but lcc-win32 treats it as an int/long:

sizeof -2147483648 should evaluate to 8, but it produces 4.

The correct definition of INT_MIN should be:

#define INT_MIN (-2147483647 - 1) or
#define INT_MIN (-INT_MAX - 1)

Now if I were writing a compiler from scratch, I would maintain int
and long as separate types through all processing phases. The
internal compiler data structures that describe those types might
include referenes to some common machine-level information. For
example, there might be an internal "WORD" pseudo-type. The
pseudo-type WORD would be used only for code generation; everything
visible to the user, particularly diagnostic messages, would refer to
the language-defined types int and long, which would remain distinct.

I don't intend this as a criticism of lcc-win32; I'm just thinking out
loud about the best way to structure a compiler to avoid problems like
the ones we've seen here.

Neither do I, I would gladly help Jacob if his compiler was open source.
btw. open source does not have to mean free (as in free speech), nor free
(as in free beer), which lcc-win32 is already for non-commercial use.

 

[Army1987]

[...]
[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".

It suggests that leap seconds are due to the small inaccuracy of
the Gregorian calendar, whereas in fact they are due to the fact
that the Earth's rotation is slowing down. The proposed correction
to Gregorian calendar is to make years multiple of 4000 non-leap
(though actually the Gregorian calendar falls by about one day
in 8000 years, so accepting that proposal only for multiples of
8000 would make more sense; but anyway, the increment of the
duration of the day (the one for which leap seconds are for) will
cause the duration of the year measured in days to decrease, and
the precise rate of that is unpredictable (for example, in the
early 2000s Earth's rotation sped up, so in those years we didn't
have any leap seconds for 7 years) and therefore deciding now
changes which will apply 1993 or 5993 years from now is pointless).

 

[Keith Thompson]

"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???

 

[Kenneth Brody]

[...]
[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."

I also found a link to the actual text of the Act which changed the
British empire (including the U.S.A-to-be) to the Gregorian calendar.
I don't recall which URL it was at that time, but here is one that
works today:

http://webexhibits.org/calendars/year-text-British.html

--
+-------------------------+--------------------+-----------------------+
| 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]>

 

[Mark McIntyre]

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

You would think so, wouldn't you?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan