Warnings in lcc-win

[Pietro Cerutti]

jacob navia wrote:
Ian Collins wrote:
Richard Heathfield wrote:
Ian Collins said:

<snip>

If you treat [long and int] as the same internally, you'll be
buggered
when porting to any LP64 64 bit system. That is any 64 bit
Linux/Unix
platform.
Ian, considering the attitude of the purported author of lcc-win32
towards, and his knowledge of, portability, do you seriously think
there is even the remotest chance of a trouble-free port to any
significantly disparate system?

I thought he has a Linux port?

lcc-win has been ported to linux (32 and 64 bits) to AIX (64 bits),
and to windows 64 bits.

So you have already differentiated between int and long?

In 64 bit linux I have hacked the lexer!

When I see a "long" keyword, I return "long long". Internally
"long" is still never used. This works quite OK.

The problem with "long" is that it is always just a synonym for either
int or long long. There is no point in maintaining a basic type that
isn't really one.

Where does this statement come from?
What prevents long to be a type by itself?

What prevents long to be^H^H^H^H^H from being a type by itself?

 

[jacob navia]

What prevents long to be^H^H^H^H^H from being a type by itself?

I was speaking about lccc-win. In C long *is* a type by itself.

 

[Richard Bos]

Now why would you say that? To my mind, prototypes have just two
purposes: 1. Expose the calling sequence to other files, and 2.
Resolve indirect recursive calls. A third may exist, in order to
provide the outline of a function pointer to be passed.

Some people use them further to reorder their code, but I consider
that foolish, since the presence of a prototype requires perfect
matching with the actual definition, and the best match is attained
with no prototype (other than the definition proper).

I reorder my code, not for the implementation's delectation, but for my
own comfort. However I may like to write it, I prefer _reading_ code in
a top-down order. This means main() at the top, other functions below,
with subsidiary functions below their higher-level callers.
As for prototypes, I put those in a header.

all this requires is definition before use. The presence of a
redundant prototype calls for errors at some point in time, maybe
initially, maybe years later during revisions.

Not if they're in a header. Then, it means better error checking, not
more errors.

Richard

 

[Army1987]

On Thu, 27 Sep 2007 18:18:38 -0400, Eric Sosman wrote:

[about lcc-win32]

Are other sets of types similarly confounded? For
example, is `char' a full-fledged type of its own, or is
it just an alias for `signed char' or `unsigned char'?

Considering int8_t is a typedef for char...
(Note that char is by definition neither a signed type nor an
unsigned type, even though it is required to behave either
identically to signed char or to unsigned char. So to be pedantic
int8_t should be a typedef for signed char, though it is
impossible that that breaks any program.)

 

[Eric Sosman]

[...]
In all this "easy" cases, the diagnostics are issued before
the evaluation and transformation of types is done. In the
case of printf however, the tests are done just before
the function call, well after they have been prepared to
be put in the stack, hence the problems. Of course I should
test before, but that is quite a lot of work.

Well, it's a relief to hear that the compiler *does* know
the difference between `int' and `long', and doesn't rely on
some internal `#define long int' or `typedef int long;' magic!

It seems to me (though I am ignorant of the internal
organization of the compiler) that the format-string validation
might be easier and would certainly be more accurate if it were
done while more information about types is still available. Or
equivalently, if the type information were carried along further
before being turned into undecorated representational data. How
big a job that would be isn't for me to say, but it would improve
the diagnostic power of the compiler if it could be done.

 

[Eric Sosman]

[...]
However, calling the function
earlier in the source, without having a prototype, is an error (not
a warning).

Chapter and verse?

(Hypothesis: You may have meant to write "declaration"
rather than "prototype.")

 

[Default User]

Ian Collins said:

For the benefit of the folks from Missouri, would you care to back
that statement with a URL?

Actually, I'm not all that interested. There may be some other MO
people that are though.




Brian

 

[Jack Klein]

Now why would you say that? To my mind, prototypes have just two
purposes: 1. Expose the calling sequence to other files, and 2.
Resolve indirect recursive calls. A third may exist, in order to
provide the outline of a function pointer to be passed.

I think we are talking about two different things, here? I am talking
about defining a function, possibly with external linkage, with a K&R
style definition, I am NOT talking about K&R style declaration versus
prototype declaration, not definition:

type func() { /* body */ }

....or even:

static type func() { /* body */ }

For the moment, let's assume the latter. This is a definition, that
also happens to be a declaration, as all functions definitions are
also function declarations.

Are you saying that as long as this appears before any call to func()
in the translation unit, there is no reason to prefer func() over
func(void) in the definition?

Or are we, as I suspect, just addressing two slightly different
points?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Jack Klein]

Ian Collins wrote:
Richard Heathfield wrote:
Ian Collins said:

<snip>

If you treat [long and int] as the same internally, you'll be buggered
when porting to any LP64 64 bit system. That is any 64 bit Linux/Unix
platform.
Ian, considering the attitude of the purported author of lcc-win32
towards, and his knowledge of, portability, do you seriously think
there is even the remotest chance of a trouble-free port to any
significantly disparate system?

I thought he has a Linux port?

lcc-win has been ported to linux (32 and 64 bits) to AIX (64 bits),
and to windows 64 bits.

So you have already differentiated between int and long?

In 64 bit linux I have hacked the lexer!

When I see a "long" keyword, I return "long long". Internally
"long" is still never used. This works quite OK.

The problem with "long" is that it is always just a synonym for either
int or long long. There is no point in maintaining a basic type that
isn't really one.

Another thing would be if we had
int 32 bits
long 64 bits
long long 128 bits.

In *that* case long would be a proper type.

Does that mean that you don't differentiate pointers either?

If I have a prototype (in 32-bit code):

int func(int *);

....and a snippet like this:

void other_func(void)
{
long l = 42L;
func(&l);
}

....do your versions of lcc accept this without a diagnostic?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Richard Heathfield]

Default User said:

Actually, I'm not all that interested. There may be some other MO
people that are though.

Ah well, so much for the "Show Me!" state.

 

[jacob navia]

Jack Klein wrote:
[snip]

If I have a prototype (in 32-bit code):

int func(int *);

...and a snippet like this:

void other_func(void)
{
long l = 42L;
func(&l);
}

...do your versions of lcc accept this without a diagnostic?

At the default warning level there are no warnings.
At the highest warning level it says:

Warning twarn2.c: 7 assignment of pointer to long int to pointer to int

jacob

 

[Army1987]

Great. If I do

long long foo(void);
int main(void) { return foo; }
long foo(void) { return 0L; }

what diagnostics do I get?

 

[Joachim Schmitz]

Great. If I do

long long foo(void);
int main(void) { return foo; }

here you'd most probably get an error like 'return value type does not match
the function type'
If you change it to
main(void) { return foo(); }
I'd expect a warning 'implicit conversion from "long long" to "int":
rounding, sign extension, or loss of accuracy may result'

long foo(void) { return 0L; }

whether or not you get an error 'declaration is incompatible with "long long
foo(void)" (declared at line 1)' is I guess the one you're interested in?

what diagnostics do I get?

Bye, Jojo

 

[Flash Gordon]

jacob navia wrote, On 29/09/07 08:34:

Jack Klein wrote:
[snip]

If I have a prototype (in 32-bit code):

int func(int *);

...and a snippet like this:

void other_func(void)
{
long l = 42L;
func(&l);
}

...do your versions of lcc accept this without a diagnostic?

At the default warning level there are no warnings.

In that case at the default warning level it does not conform to the C
standard.

At the highest warning level it says:

Warning twarn2.c: 7 assignment of pointer to long int to pointer to int

In my opinion it should warn (or better yet error) on the default
warning level. It certainly has to produce a diagnostic in whatever mode
it claims to conform to any version of the C standard.

 

[Richard Heathfield]

Army1987 said:

Great. If I do

long long foo(void);
int main(void) { return foo; }
long foo(void) { return 0L; }

what diagnostics do I get?

Well? What diagnostics /do/ you get?

(Translation: I can't find any evidence that a Linux implementation of
lcc-win32 exists.)

 

[jacob navia]

Great. If I do

long long foo(void);
int main(void) { return foo; }
long foo(void) { return 0L; }

what diagnostics do I get?

root@ubuntu:/tmp# lcc twarn.c
Error /tmp/twarn.c: twarn.c: 2 illegal return type; found 'pointer to
long long function(void)' expected 'int'
Error /tmp/twarn.c: twarn.c: 3 redefinition of 'foo'
Error /tmp/twarn.c: twarn.c: 1 Previous definition of 'foo' here
3 errors, 0 warnings

This is in 32 Bit linux. Under 64 bit linux will do that
when I reconstruct my 64 bit linux since debian refuses to run
in my machine (screen 1900x1200 not recognized, X windows doesn't
work, etc)

 

[jacob navia]

Army1987 said:



Well? What diagnostics /do/ you get?

(Translation: I can't find any evidence that a Linux implementation of
lcc-win32 exists.)

For all people (except heathfield) I can mail a version of lcc-win under
linux in a tar.gz file. There will be a public URL for the 32 bit
version tomorrow where everybody will be able to download it.

 

[Chris Hills]

jacob navia wrote, On 29/09/07 08:34:

Jack Klein wrote:
[snip]

If I have a prototype (in 32-bit code):

int func(int *);

...and a snippet like this:

void other_func(void)
{
long l = 42L;
func(&l);
}

...do your versions of lcc accept this without a diagnostic?

At the default warning level there are no warnings.

In that case at the default warning level it does not conform to the C
standard.

Which C standard? Virtually no compiler fully conforms to ISO9899:1999
+ TC1+TC2+TC3

Lcc-win is not different to any other in that respect.

Having just discussed standards adherence with most of the main stream
embedded compiler writes world wide*. Standards adherence is not a
priority for them Lcc is not different to any other in this respect.
Some of the more popular compilers are not the most standards compliant

* Any compiler (or other C tool) company who wants an input to or
updates about MISRA-C:2010 please email me

 

[Mark McIntyre]

jacob navia wrote, On 29/09/07 08:34:

In that case at the default warning level it does not conform to the C
standard.

But thats ok - hardly any compilers warn properly at the default
level.

In my opinion it should warn (or better yet error) on the default
warning level.

Sure - but you might want to mention this to all the other compiler
writers too...
--
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

 

[Flash Gordon]

Chris Hills wrote, On 29/09/07 13:34:

jacob navia wrote, On 29/09/07 08:34:

Jack Klein wrote:
[snip]

If I have a prototype (in 32-bit code):

int func(int *);

...and a snippet like this:

void other_func(void)
{
long l = 42L;
func(&l);
}

...do your versions of lcc accept this without a diagnostic?
At the default warning level there are no warnings.

In that case at the default warning level it does not conform to the C
standard.

Which C standard? Virtually no compiler fully conforms to ISO9899:1999
+ TC1+TC2+TC3

All of them. You failed to quote the part where I stated that my comment
applied to all versions.

Lcc-win is not different to any other in that respect.

You failed to quote the part where I made the point that a diagnostic is
required in whatever mode

Having just discussed standards adherence with most of the main stream
embedded compiler writes world wide*. Standards adherence is not a
priority for them Lcc is not different to any other in this respect.

It is relevant because Jacob has repeatedly stated that his compiler has
a mode in which it conforms to one of the versions of the C standard. If
it does not generate a diagnostic in that mode (which he has not made
clear) then this is a bug in his compiler.

Are you saying that we should not point out to compiler writers where
there compilers have bugs and/or fail to comply to any standard (current
or not) that they claim to meet?

Some of the more popular compilers are not the most standards compliant

I'm talking about a specific compiler which the author claims has a
standard compliant mode, so that is not relevant to the discussion.

No tell me in which version of the standard a diagnostic is NOT required
for the code in question.