lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Strict ANSI checking


From: K.J. Mansley
Subject: Re: [lwip-users] Strict ANSI checking
Date: 21 Sep 2004 10:54:54 +0100

On Tue, 2004-09-21 at 07:47, Jan Hyla [Yahoo Account] wrote:

> e.g. in raw.c (1.0.0) I get:
>  
>  
> 'error: conflicting types for `raw_recv'
>  
> and
>  
> 'warning: assignment from incompatible pointer type' for the function
> below (for the second parameter being passed)

[snip]

> Prior to being posted to 'contrib' it should really have tested to
> compile with strict ANSI checking. 
>  

I'm a bit confused here, as I've looked at all the definitions of
raw_recv and they're identical apart from whitespace and the name of one
variable (but not the type, so it shouldn't matter).  Also, there's no
raw.c in the contrib module at all, so maybe I'm looking at the wrong
thing?

There is this in the CHANGELOG though:

2004-07-21 Tony Mountifield <address@hidden>
  * api_msg.c Changed recv_raw() from int to u8_t, to match prototype
    of raw_recv() in raw.h and so avoid compiler error.

...which suggests that the problem you describe was fixed a couple of
months ago, but this would mean 1.0.0 wouldn't have it, and you say
that's the version you're using.

> I've got quite a few similar problems.
>  
> Questions:
> 1. Is the 'contrib' code supposed to be 'clean'?

No.  It's code contributed and maintained by other people, as and when
they can.  Obviously we like them to try and keep it up to date, but for
example at the moment many of the ports in contrib have not been brought
into line with the 1.0 changes, and so are still compatible with 0.7.x
instead.  In general I'd encourage people to make it as 'clean' as they
can, but if it's a choice between a mostly working port and no port at
all for that particularly architecture, a mostly working port is more
useful as a starting point for others.

> 2. What does everyone think about strict ANSI checking?

It's probably a good thing, in most cases, particularly as we're trying
to target compilers that will be much less capable than gcc

Kieran





reply via email to

[Prev in Thread] Current Thread [Next in Thread]