[Top][All Lists]

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

RE : RE : [lwip-users] LWIP_COMPAT_SOCKETS in sockets.h

From: Frédéric BERNON
Subject: RE : RE : [lwip-users] LWIP_COMPAT_SOCKETS in sockets.h
Date: Wed, 6 Sep 2006 19:24:29 +0200

Yes Kieran,

I'm agree with you about your pseudo code. Even with LWIP_IO_SOCKETS undefined, 
you will got a runtime error. That's why read, write and close don't have to be 
define in lwip if the OS already implements them.

In my application, I have comment these three "define", because I got an OS 
which already implements these calls. But I can use "recv", "send" and 
"closesocket". I have defined LWIP_COMPAT_SOCKETS because I port my application 
on several embedded target (and all implement BSD-like sockets interface). 
Using LWIP_IO_SOCKETS would be a way for users to tell if their OS already 
implement or nor these calls. If OS doesn't define these functions, we can 
define LWIP_IO_SOCKETS. It have to be undefined is OS implements them.

In my target, If I wanted to write a  pseudo code like yours, I could undefined 
LWIP_IO_SOCKETS (to avoid the compilation error), and I could write a "IO 
Driver" for my OS to implement call redirections for read, write and close 
(this is a possibility in my OS to extend the IO System) to avoid the runtime 

Perhaps LWIP_IO_SOCKETS is not the good name, and something like 

I hope you understand my problem now (because my english isn't perfect)...
Frédéric BERNON 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 

-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de Kieran Mansley
Envoyé : mercredi 6 septembre 2006 17:35
À : Mailing list for lwIP users
Objet : Re: RE : [lwip-users] LWIP_COMPAT_SOCKETS in sockets.h

On Wed, 2006-09-06 at 17:13 +0200, Frédéric BERNON wrote:
> Hi Kieran,
> Yes, read, write and close are usually used for files in "unistd.h". 
> So, if in a same code, you have to use files and sockets, there is a 
> problem. You got compilation errors like :
> "...\include\unistd.h (89) : error: declaration is incompatible with 
> "int lwip_write(int, void *, int)" (declared at line 256 of "C:\lwip
> \sockets.h") "

Yes, I understand the compile error - that's why we have the 
LWIP_COMPAT_SOCKETS option.  I was trying to work out why you'd want to define 
LWIP_COMPAT_SOCKETS and not have read, write, and close renamed, but looks like 
it is because those are used for things other than sockets.

Seems like you have a fairly sensible solution to your problem, but I wonder 
what will happen when your code that uses both files and sockets calls read or 
write or close on a socket rather than file?  I assume you must have manually 
modified the application to not use read, write or close for sockets, and to 
use lwip_read etc directly instead.

I worry that with a simple compile time option to get rid of the errors as you 
suggest, others using the code might not realise that there is a problem that 
they need to modify the application to solve.  i.e. You've effectively replaced 
a fairly easy to debug compile error with a rather more difficult to debug run 
time error.

e.g. If I have a simple app along the lines of (pseudo-code):

#include <unistd.h>
#include <lwip_sockets.h>
fd = open(); //a file descriptor
sock = socket(); //a socket

I try to compile with lwip (with LWIP_COMPAT_SOCKET=1 and
LWIP_IO_SOCKETS=1) and I'll get the compile error alerting me that I've got a 
problem (mixed use of file descriptors and sockets).  However, if I then saw 
the LWIP_IO_SOCKETS option, I might try with that turned off. It would now 
compile fine using the definitions of read, write and close from unistd.h, but 
when I came to run it I'd be rather confused about why the write() call didn't 

Hope that makes sense!


lwip-users mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-users

reply via email to

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