I/O functions on file descriptors

[nd2s]

Is there any reason why the fd save/load functions are internal? I'd like to be able to print the network to stdout or serialise it and save it in a database.

[broken-pen]

As far as I can tell, this is likely an oversight. The functions fann_save_internal, fann_create_from_file, fann_save_trian_internal and fann_read_train_from_file are all only small shims around their fd-counterparts.

@bukka, @andersfylling, do you think it makes sense to add public functions that take a FILE pointer? I could prepare a PR in that case.

[jeffreyknight]

I was wondering if it would be possible to add in one more thing that is related to these functions. It would also be nice to have another function that instead of fann_save_internal_fd, would also allow save to buffer, like

fann_save_internal_buff(struct fann *ann, void *buffer, unsigned int save_as_fixed)

so you can store the network in variable format. I wasn't sure if I should open a new issue or add this in here, because it's very similar to this enhancement.

[phschafft]

Generally a way to interact with the files other than filenames would be most welcome. (POSIX) File descriptors would be a start. Also working with a buffer would be. However I think FILE* is a problem. libvorbis documents the problem with FILE* on windows e.g. at https://xiph.org/vorbis/doc/vorbisfile/ov_open.html#winfoot:

Under Windows, stdio file access is implemented in each of many variants of crt.o, several of which are typically installed on any one Windows machine. If libvorbisfile and the application using libvorbisfile are not linked against the exact same version/variant/build of crt.o (and they usually won't be, especially using a prebuilt libvorbis DLL), FILE * handles cannot be opened in the application and then passed to vorbisfile to be used by stdio calls from vorbisfile's different version of CRT. For this reason, using ov_open() under Windows without careful, expert linking will typically cause a protection fault. Windows programmers should use ov_fopen() (which will only use libvorbis's crt.o) or ov_open_callbacks() (which will only use the application's crt.o) instead.

This warning only applies to Windows and only applies to ov_open(). It is perfectly safe to use ov_open() on all other platforms.

For more information, see the following microsoft pages on C runtime library linking and a specific description of restrictions on passing CRT objects across DLL boundaries.

Sadly the links to Microsoft return a 404 now. (If anyone has working ones feel free to share.)