Undocumented features?

[angros47]

I just saw this example on the wiki:

https://www.freebasic.net/wiki/FaqPgbloadworkaround

It uses "fb_fileput" and "fb_fileget", that are not mentioned in the official wiki, nor are part of the official command set. They are functions in the runtime library, but wouldn't they require to be declared, to be accessed in a FreeBasic source? How many other internal functions are implicitly declared like those one? Also, if new functions are added to the runtime library, would they become accessible in the same way?

[marcov]

I just saw this example on the wiki:

https://www.freebasic.net/wiki/FaqPgbloadworkaround

It uses "fb_fileput" and "fb_fileget", that are not mentioned in the official wiki, nor are part of the official command set. They are functions in the runtime library, but wouldn't they require to be declared, to be accessed in a FreeBasic source? How many other internal functions are implicitly declared like those one? Also, if new functions are added to the runtime library, would they become accessible in the same way?

If not documented, they are not features, but details of a certain implementation that happen to be exploitable.

[coderJeff]

I just saw this example on the wiki:

https://www.freebasic.net/wiki/FaqPgbloadworkaround

It uses "fb_fileput" and "fb_fileget", that are not mentioned in the official wiki, nor are part of the official command set.

Thanks for pointing that out. First time just seeing this example and I don't know why would be written that way. Why not just use GET # and PUT #? Also, no error checking, '_bload' will create empty files, 'CLOSE' will close all files? So a number of issues.

They are functions in the runtime library, but wouldn't they require to be declared, to be accessed in a FreeBasic source?

fbc implicitly declares some functions, maybe you might call them built-ins to support many statements. And almost certainly if the fbc statement has special parsing (quirks) that need to be translated to a function call.

How many other internal functions are implicitly declared like those one?

There is a kind of list in the unit tests just to check for consistency of the implicitly declared support functions (built-ins).
tests/warnings/rtl-prototypes.bas
But they are not intended for direct user use.

Also, if new functions are added to the runtime library, would they become accessible in the same way?

Some functions may become available that way when added to the runtime and implicitly declared to support some fbc feature, and some functions added to the run time support other functions and would not be implicitly declared and made available that way.

Sometimes it is a simple one-to-one mapping - one statement in fbc equals one function in run time library

But usually fbc will select different support functions or generate extra code before / after the call, so an fbc statement may map to multiple support functions.

For example, GET # is actually implemented by these implicitly declared function (built-ins):

Code: Select all

fb_FileGet
fb_FileGetLarge
fb_FileGetStr
fb_FileGetWstr
fb_FileGetStrLarge
fb_FileGetWstrLarge
fb_FileGetArray
fb_FileGetArrayLarge
fb_FileGetIOB
fb_FileGetLargeIOB
fb_FileGetStrIOB
fb_FileGetWstrIOB
fb_FileGetStrLargeIOB
fb_FileGetWstrLargeIOB
fb_FileGetArrayIOB
fb_FileGetArrayLargeIOB

And PUT # are these:

Code: Select all

fb_FilePut
fb_FilePutLarge
fb_FilePutStr
fb_FilePutStrLarge
fb_FilePutWstr
fb_FilePutWstrLarge
fb_FilePutArray
fb_FilePutArrayLarge

And then internal to rtlib and not implicitly declared by the compiler would be additional support functions not implicitly declared to support those functions and should probably never be called directly by the user.

[angros47]

Thanks for pointing that out. First time just seeing this example and I don't know why would be written that way. Why not just use GET # and PUT #? Also, no error checking, '_bload' will create empty files, 'CLOSE' will close all files? So a number of issues.

You forgot another issue: it doesn't use any sort of header, so it saves and loads in a format that is not compatible with the BSAVE/BLOAD routines provided by the graphic libraries.

Actually, all those issues are, in my opinion, caused by the obsolete nature of BSAVE/BLOAD: their original purpose is long time gone. They made sense on 8 bit home computers, to load pieces of code in machine language, and they still were useful in gw-basic, but already in Quick Basic, that allowed to use external libraries, they were much less useful, and in FreeBasic they are pointless, since GET and PUT work much better and in a more intuitive way.

Keeping compatibility with QBASIC is not really achieved, because pictures saved by QBASIC in any screen mode but SCREEN 13 would be in a format that makes no sense for FreeBasic.

This is why I was suggesting, in another post, to repurpose them. Or maybe to remove them completely, and use something like ImageLoad and ImageSave (to have a syntax consistent with ImageCreate)

Some functions may become available that way when added to the runtime and implicitly declared to support some fbc feature, and some functions added to the run time support other functions and would not be implicitly declared and made available that way.

Sometimes it is a simple one-to-one mapping - one statement in fbc equals one function in run time library

But usually fbc will select different support functions or generate extra code before / after the call, so an fbc statement may map to multiple support functions.

I asked because there are some functions that in my opinion could be added to the runtime library: as I said some days ago, stb_image and stb_image_write could improve the graphic library, also (I might have mentioned it in the past) libco could be added to the runtime library to add support for coroutines