[fpc-devel] libc bugreport
Michael Van Canneyt
michael at freepascal.org
Wed May 4 10:20:27 CEST 2005
On Tue, 3 May 2005, zephod wrote:
> I am evaluating fpc as a possible replacement compiler for a large kylix based
> source tree (~200.000 lines of code). In porting the apps I encountered some
> small troubles:
> * packages/base/libc/aineth.inc:
> inp argument of inet_aton should be var instead of in_addr pointer
> since the memory it refers to should exist and be valid at calling time.
> So why not let the compiler do the check for you?
Added as overloaded call.
> * packages/base/libc/nudph.inc :
> typo in libc.pp. It includes the file nupdh.inc (notice the swap
> of 'p' and 'd' chars), which contains no code. Maybe it is best that
> nupdh.inc is moved to the attic to avoid future mistakes.
> * packages/base/libc/nip.inc :
> iphdr and ip records have wrong size (24 bytes instead of 20). The
> first two C fields (version and ihl) are 4 bit integers contained in the
> first byte of the record.
> So instead of declaring flag0 as a word or dword, the type should
> be plain byte.
Hm. The first I checked, and is declared in Kylix' Libc also with Cardinal
But the linux header file says
unsigned int ip_hl:4; /* header length */
unsigned int ip_v:4; /* version */
So I'm assuming that these 2 have total size 8, so a byte should be ok.
(sizes are indeed 20, as reported by GCC)
> * What about send and recv calls in ssocketh.inc? The buffer could be an
> untyped var instead of a regular pointer (Giving nil as buffer argument,
> although not prohibited by libc, makes no sense imho)
Added as overloaded calls.
Regardless of all this, I'd be interested in knowing your assessment of
FPC (be it good or bad). From your email addres I'd say you are Belgian, so
I'm double interested (want to know what future FPC has in this country).
I'd be grateful if you'd send me a private mail with a more detailed assessment
(if company policy permits, that is)
More information about the fpc-devel