Opened 16 years ago

Closed 6 years ago

#2696 closed bug (fixed)

unimplemented functions

Reported by: kaliber Owned by: nobody
Priority: normal Milestone: R1
Component: System/libroot.so Version: R1/pre-alpha1
Keywords: Cc: haiku@…, planche2k@…, przemub@…
Blocked By: #2564 Blocking:
Platform: All

Description

I wrote a buggy script which detects declared but not implemented functions (symbols) in Haiku. It found (not a full list yet):

stdio.h:
	_ftell

setjmp.h:
	_setjmp

nl_types.h:
	catclose
	catgets
	catopen

math.h:
	__fpclassifyl
	__signbitf
	gamma_r
	gammaf_r

iconv.h:
	functions implemented in libtextencoding?

search.h:
	hcreate
	hdestroy
	hsearch
	remque

stdlib.h:
	random_r
	setstate_r
	srandom_r

wctype.h:
	towctrans

wchar.h:
	fgetws
	getwchar
	wcsftime

libio.h:
	_IO_feof_unlocked
	_IO_ferror_unlocked
	_IO_getc_unlocked ?
	_IO_peekc_unlocked ?
	_IO_putc_unlocked ?

Attachments (4)

scripts.zip (917 bytes ) - added by kaliber 16 years ago.
scripts to detect unimplemented functions
header.txt (2.3 KB ) - added by scottmc 14 years ago.
changed the quotes to the regular quote character, should be easier to read now.
headers.txt (2.0 KB ) - added by deangenovski 14 years ago.
That's a compare list aginst posix specifications.
raport (v2) (1.1 KB ) - added by richienyhus 12 years ago.
Lastest info

Download all attachments as: .zip

Change History (37)

comment:1 by andreasf, 16 years ago

Blocked By: 2564 added
Cc: andreas.faerber@… added
Component: - GeneralSystem/libroot.so

comment:2 by andreasf, 16 years ago

#2564 was about __signbitf

comment:3 by scottmc, 16 years ago

Cc: haiku@… added

comment:4 by korli, 16 years ago

added remque in hrev27422

comment:5 by scottmc, 16 years ago

This one is blocking HaikuPorts Ticket #70, which affects building the CVS version of CVS. So until the libio.h functions are implemented we won't have a Haiku native CVS. Good news is that the BeOS CVS has been working ok as far as I can tell.

comment:6 by umccullough, 16 years ago

Is it true that no native version can be built?

It seems the CVS here:

http://haiku-files.org/files/optional-packages/

May be a native version already. At least, it seems to be built for /boot/common already.

IIRC, this was provided by stippi, but I can't confirm that.

comment:7 by scottmc, 16 years ago

In that zip file the .OptionalPackageDescription said it was the BeOS version... It's possible to build 1.12.13 with a bit of hacking along the way, which is what I'll probably do. But no use in sending in patches for that as the cvs version of cvs has dropped a lot of files some of which need to be patched on 1.12.13. Andreas got it mosted working: http://ports.haiku-files.org/wiki/dev-util/cvs I'll take another look at in the next few days here. But the cvs version of cvs is stuck util the functions actually exist.

comment:8 by axeld, 16 years ago

libio.h is not a POSIX header, and the functionality doesn't seem to be standardized anywhere. If CVS is using it now for whatever reason (poor maintainer IMO), I would think we could easily live with an older version of it.

comment:9 by scottmc, 16 years ago

@Kaliber
Can you post your buggy script here? Might be useful in rechecking these from time to time.

comment:10 by harsha, 16 years ago

so far found the following functions already in haiku math.h:

fpclassifyl -> system/libroot/posix/glibc/arch/x86/s_fpclassifyl.c

signbitf -> system/libroot/posix/glibc/arch/generic/s_signbitf.c

gamma_r -> system/libroot/posix/glibc/arch/generic/e_gamma_r.c

gammaf_r -> /system/libroot/posix/glibc/arch/generic/e_lgamma_r.c

wctype.h

towctrans -> system/libroot/posix/glibc/wctype/towctrans.c

I added the following functions nl_types.h:

catclose

catgets

catopen

when i am building they are not linking . can anybody tell me what i am missing. I added the files under glibc and doing a normal build. and this is what my target vmware image contains

$>strings Haiku-IDE_0-1.vmdk | grep "catclose"

/* SYSCALLS.c:385:NC */ extern int catclose (nl_catd);

by kaliber, 16 years ago

Attachment: scripts.zip added

scripts to detect unimplemented functions

comment:11 by kaliber, 16 years ago

Here is updated report (hrev30960). It covers everything except compatibility headers (bsd):

stdio.h:
	_ftell (_IO_ftell)

math.h:
	gammaf_r (__ieee754_gammaf_r)
	gamma_r (__ieee754_gamma_r)
	lgammal (__ieee754_lgammal_r)

search.h:
	hcreate
	hdestroy
	hsearch

iconv.h:
	iconv (libiconv)
	iconv_close (libiconv_close) 
	iconv_open (libiconv_open)

dirent.h:
	seekdir
	telldir

setjmp.h:
	_setjmp (setjmp)

wchar.h:
	wcsftime

Please close the ticket #2702

in reply to:  5 comment:12 by scottmc, 16 years ago

Replying to scottmc:

This one is blocking HaikuPorts Ticket #70, which affects building the CVS version of CVS. So until the libio.h functions are implemented we won't have a Haiku native CVS. Good news is that the BeOS CVS has been working ok as far as I can tell.

HaikuPorts ticket 70 has been closed as fixed.

comment:13 by andreasf, 15 years ago

Cc: andreas.faerber@… removed

comment:14 by andreasf, 15 years ago

Cc: planche2k@… added

comment:15 by michaelvoliveira, 14 years ago

some news for _setjmp?

Premake need that

comment:16 by michaelvoliveira, 14 years ago

Ignore it

I already manage the problem

in reply to:  11 comment:17 by scottmc, 14 years ago

Replying to kaliber:

Here is updated report (hrev30960). It covers everything except compatibility headers (bsd):

Kaliber, can you rerun your check on these so we can see where it stands now?

comment:18 by kaliber, 14 years ago

Still missing hrev39652:

math.h:
	lgammal
	gamma_r
	gammaf_r

search.h:
	hcreate
	hdestroy
	hsearch

comment:19 by korli, 14 years ago

The problem I saw this week is that our posix headers might be incomplete, so checking for missing implementations is not enough.

in reply to:  19 comment:20 by bonefish, 14 years ago

Replying to korli:

The problem I saw this week is that our posix headers might be incomplete, so checking for missing implementations is not enough.

Yep. This should really be approached thoroughly:

  1. Check against the POSIX specs which headers should be there and make a complete list.
  2. For each header compare what the specs require with what we have and note all differences (in tickets or in the wiki).

Then things can be worked on individually and crossed off the list.

The script is nice to see, if we have forgotten to implement something, though.

by scottmc, 14 years ago

Attachment: header.txt added

changed the quotes to the regular quote character, should be easier to read now.

comment:22 by michaelvoliveira, 14 years ago

FILE is needed for the OpenAL port

could help a lot if Haiku implement that

comment:24 by umccullough, 14 years ago

Futhermore, it would seem that stdarg.h and stddef.h are already part of GCC's included headers, and thus we do not provide separate versions of these (they should get installed into the appropriate gcc header directory when the development tools are added to the haiku image):

http://dev.haiku-os.org/browser/buildtools/trunk/gcc/gcc/ginclude

by deangenovski, 14 years ago

Attachment: headers.txt added

That's a compare list aginst posix specifications.

comment:25 by umccullough, 14 years ago

You can probably remove the "can't find FILE" part as well.

it's defined in stdio.h (via the include of stdio_pre.h) - as type _IO_FILE - which is defined in libio.h here:

http://dev.haiku-os.org/browser/haiku/trunk/headers/posix/libio.h#L117

comment:26 by jprostko, 14 years ago

I just wanted to mention that several students for Google Code-in have taken on this task to complete. Depending on how things go, I'll post patches here for review prior to committing to trunk.

in reply to:  26 comment:27 by bonefish, 14 years ago

Replying to jprostko:

I just wanted to mention that several students for Google Code-in have taken on this task to complete. Depending on how things go, I'll post patches here for review prior to committing to trunk.

Great! Please take care not to add/change stuff that isn't actually supported by the implementation.

deangenovski, thanks, that's a start. scottmc and umccullough are right, though: Some headers don't define all the stuff required by POSIX themselves, but include other headers that do (which is just fine), and some headers are provided by the compiler. Moreover, POSIX requires dozens of headers of which Haiku is definitely missing quite a few, and likely has a good deal of headers that don't fully conform to the specification.

I think it would be best to organize the information either in a wiki or in hierarchical tickets. I.e. one overview section/ticket listing all the non-conforming/missing (and maybe even the conforming) headers, for each header a section/ticket listing the defects in the header, and per defect (or group of defects) a subsection/ticket detailing on them. As written earlier IMO the best approach is to compile a complete list of headers first and then iterate through them and add details. The second step can be parallelized wonderfully.

comment:28 by scottmc, 14 years ago

We've broken #4947 down into a few GCI tasks to have students research and provide a list of what's missing. From those results we will then open/update trac tickets to take on each of the missing parts. There's also some other tasks being worked on to implement some of the missing functions. A wiki checkoff list would be a good thing to add as well.

comment:29 by przemub, 12 years ago

Cc: przemub@… added

by richienyhus, 12 years ago

Attachment: raport (v2) added

Lastest info

comment:30 by bonefish, 12 years ago

The list is largely incorrect. Haiku provides all of the functionality listed under <signal.h>, <sys/select.h>, <sys/stat.h>, <sys/times.h>, <time.h>, <unistd.h>. That's just what I can tell off the top of my head. I haven't checked the other stuff.

comment:31 by richienyhus, 12 years ago

Och, although not my fault as it its the work of a GCI2012 student.

comment:32 by axeld, 8 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:33 by waddlesplash, 6 years ago

Resolution: fixed
Status: assignedclosed

Closing as probably fixed then; at this point unimplemented functions deserve their own tickets.

Note: See TracTickets for help on using tickets.