Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Warnings in lcc-win

Reply
Thread Tools

Warnings in lcc-win

 
 
CBFalconer
Guest
Posts: n/a
 
      09-28-2007
Jack Klein wrote:
> CBFalconer <(E-Mail Removed)> wrote in comp.lang.c:
>> Jack Klein wrote:
>>>

>> ... snip ...
>>>
>>> I agree with the first one completely, assuming that it is not
>>> the default and the user has asked for a higher warning level.
>>>
>>> But I do not like the wording for the second one. I think it is
>>> confusing, because the wording is not specific. I will describe
>>> what I mean.
>>>
>>> If the warning is given because the function definition:
>>>
>>> return_type func() { /* body */ }
>>>
>>> ...does not provide a prototype, then I think better wording
>>> would be:

>>
>> That deserves no warning whatsoever. However, calling the
>> function earlier in the source, without having a prototype, is
>> an error (not a warning).

>
> I disagree, I would not mind having such a warning as an _option_.
> I consider it an "error" in new code (note C does not define this
> term), and would turn the option off for legacy code if necessary.


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). In the main
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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      09-28-2007
Eric Sosman wrote:
> Does the compiler really treat `int' and `long' as
> identical? If so, what does it do with
>
> int value = 42;
> long *ptr = &value;
> or with
> extern long global;
> extern int global;
> or with
> int func(void);
> long func(void) { return 42L; }
>
> ? Diagnostics are required for these -- if the compiler
> is able to emit them it must be "aware" at some level that
> `int' and `long' are different, even though they share a
> common representation.
>


I wrote this test program:
extern long global;
extern int global;
int func(void);
int fn(void) {
int value = 42;
long *ptr = &value;
}

long func(void) { return 42; }

At default diagnostic level lcc-win produces:

d:\lcc\test>lcc twarn.c
Error twarn.c: 2 redefinition of 'global'
Error twarn.c: 1 Previous definition of 'global' here
Warning twarn.c: 7 missing return value
Error twarn.c: 9 redefinition of 'func'
Error twarn.c: 3 Previous definition of 'func' here
4 errors, 1 warning

With extended diagnostics turned ON:
d:\lcc\mc68\test>lcc -A twarn.c
Error twarn.c: 2 redefinition of 'global'
Error twarn.c: 1 Previous definition of 'global' here
Warning twarn.c: 6 assignment of pointer to int to pointer to long int
Warning twarn.c: 6 ptr is assigned a value that is never used
Warning twarn.c: 7 missing return value
Error twarn.c: 9 redefinition of 'func'
Error twarn.c: 3 Previous definition of 'func' here
4 errors, 3 warnings

Note that lcc-win is much more strict than MSVC that
issues no errors, just warnings:

twarn.c(2) : warning C4142: benign redefinition of type
twarn.c(9) : warning C4142: benign redefinition of type
d:\lcc\test\twarn.c(7) : warning C4716: 'fn' : must return a value

-------------------------------------------------------------
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.
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      09-28-2007
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.

lcc-win generates code for some DSP 16 bits also.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-28-2007
CBFalconer <(E-Mail Removed)> writes:
> Jack Klein wrote:
>>

> ... snip ...
>>
>> I agree with the first one completely, assuming that it is not
>> the default and the user has asked for a higher warning level.
>>
>> But I do not like the wording for the second one. I think it is
>> confusing, because the wording is not specific. I will describe
>> what I mean.
>>
>> If the warning is given because the function definition:
>>
>> return_type func() { /* body */ }
>>
>> ...does not provide a prototype, then I think better wording would be:

>
> That deserves no warning whatsoever. However, calling the function
> earlier in the source, without having a prototype, is an error (not
> a warning).


That definition does not provide a prototype.

More concretely:

void foo()
{
}

int main(void)
{
foo(42);
return 0;
}

The definition of 'foo' does not provide a prototype. The incorrect
call 'foo(42)' is not a constraint violation, though it does invoke
undefined behavior.

On the other hand, if the definition of foo were:

void foo(void)
{
}

then the call would be a constraint violation.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      09-28-2007
CBFalconer said:

<snip>

> Some people use [prototypes] 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). In the main
> 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.


I disagree that using prototypes to free the code from a strict ordering is
a bad idea. Yes, okay, the presence of two got-to-match prototypes rather
than one is a weakness, but so is the reliance on a strict ordering.
Either can be broken during maintenance (and the fix for each is trivial).

If you want to use up-front prototypes to get rid of the problem of
reliance on strict ordering, without suffering the problem of two
got-to-match sections of code, I advance the following, not entirely
serious, suggestion:

#define PROTOTYPE_FOO double foo(char *x, int y)

PROTOTYPE_FOO ;

PROTOTYPE_FOO
{
/* write foo()'s body here */
}



--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      09-28-2007
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?

--
Ian Collins.
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      09-28-2007
Ian Collins wrote:
> 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.

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.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-28-2007
CBFalconer <(E-Mail Removed)> writes:
[...]
> 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). In the main
> 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.


I think you're using the word "prototype" to refer only to function
declarations that are not also definitions. But that's not what the
word means. Any function declaration that specifies the types of the
arguments is a prototype, whether it's part of a definition or not.

Even if you strictly order your functions within a single file so that
each one is defined before it's called, each function should still
have a prototype (even though the language doesn't require it). For
example, this:

void foo(void) { /* ... */ }
void bar(void) { foo(); }

rather than this:

void foo() { /* ... */ }
void bar() { foo(); }

With the latter version, calls to foo are not checked for the correct
number and type(s) of arguments, even though the definition of foo
precedes the call.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Pietro Cerutti
Guest
Posts: n/a
 
      09-28-2007
jacob navia wrote:
> Ian Collins wrote:
>> 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?

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



--
Pietro Cerutti

PGP Public Key:
http://gahr.ch/pgp
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      09-28-2007
Keith Thompson wrote:
> I think you're using the word "prototype" to refer only to function
> declarations that are not also definitions. But that's not what the
> word means. Any function declaration that specifies the types of the
> arguments is a prototype, whether it's part of a definition or not.
>
> Even if you strictly order your functions within a single file so that
> each one is defined before it's called, each function should still
> have a prototype (even though the language doesn't require it). For
> example, this:
>
> void foo(void) { /* ... */ }
> void bar(void) { foo(); }
>
> rather than this:
>
> void foo() { /* ... */ }
> void bar() { foo(); }
>
> With the latter version, calls to foo are not checked for the correct
> number and type(s) of arguments, even though the definition of foo
> precedes the call.
>


I think this should go in the FAQ...

It is very important to see that with those "old style"
definitions you have no longer those checks we are used
to rely on.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Help with syntesis warnings JnCodesigns VHDL 2 04-30-2007 06:31 PM
there are too many warnings (you are about to....etc etc forever) after installing Firefox trevor_smithson@yahoo.com Firefox 2 10-13-2005 07:35 PM
What to do with "Unconnected output port" warnings? Herb T VHDL 1 04-04-2005 09:24 AM
use warnings; and use Warnings; give different results Ted Sung Perl Misc 1 08-30-2004 10:22 PM
disabling certain warnings in synopsys dc Tuukka Toivonen VHDL 1 05-11-2004 01:51 PM



Advertisments