Re: [lwip-devel] [task #6994] Redesign Socket Layer withLWIP_TCPIP_CORE_LOCKING

[David Empson]

[Sorry for replying to the mailing list directly - the task is marked 
private and I can't access it.]

Simon Goldschmidt wrote:
> Frédéric Bernon wrote:
> > Is what you say is that a handle can't be a pointer? Why? Is
> > there lot of environements where "int" and "pointer" don't have
> > same size ? Perhaps some old ones?
>
> What about windows on 64-bit platforms? Isn't an int 32-bit there while a
> pointer is 64-bit?

There are also a fair number of mid-sized 16-bit embedded platforms where 
pointers are 32 bits and int is 16 bits. One current example is the Renesas 
M32C/80, which the company I work for is using with lwip (raw api only, so 
the socket layer doesn't affect us yet).

C99 has a stdint.h header file which defines types like intptr_t, which is 
an "integer type large enough to hold a pointer". On a platform where 
sizeof(int) and sizeof(void*) are both 4, intptr_t will be int. On a hybrid 
platform like the M32C/80, intptr_t will be long. (There is also a 
corresponding uintptr_t type, which is unsigned rather than signed.)

Using this sort of type in generic code such as lwip is difficult, because 
you can't require all systems to implement the full feature set of C99. My 
compiler isn't C99 compliant, but I added my own header file to define these 
types.

> Going back to the original discussion, we have two points here:
> - replacing 'int' by a pointer casted to int: by now, I favour not to do
> this, since it doesn't work for all cases and we might to have to change 
> it
> later if we want to implement select.

That seems a good idea. Building in assumptions like 
sizeof(void*)==sizeof(int) is a trap waiting to bite an unsuspecting user on 
an unusual platform.