Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
A few questions regarding how to use some of the functions declared in the fxcg-10/20's version of "stdio.h":


Bfile_OpenFile_OS seems rather awkward for many reasons: first off, why does it need a pointer to a string of unsigned shorts? Is this for 2 byte character sets? It compiles fine with a pointer to a string of chars, (of course it throws a warning, but no error) but do I need to manually input byte sequences to access non-ASCII characters (that was worded bad, but basically, do I need to input different characters to represent the same ones if this parameter is not meant for ASCII characters)?

Secondly, files have to start with "\\fls0\" -- though PrizmWiki doesn't tell how the rest of the file extension has to be represented. Is "\\fls0\city.pcc" as valid extension?

Thirdly, for Bfile_CreateEntry_OS, what type of modes are available (apparently I should use mode (int) 1, but are there other options?) and what do they do? Why in god's name do we need to pass the parameter for size as a pointer to the int that holds the size value? How do you specify where to save it?

For those interested, here's a snippet of code dealing with it (from my contest entry, but I snipped out everything not in question with a "...":


Code:
   int SAVE_HANDLE = Bfile_OpenFile_OS("\\fls0\city.pcc", 0x03);
   if(SAVE_HANDLE < 0) {

      ...

   Bfile_CreateEntry_OS("city.pcc", 1, size_needed);
   } else { ... }
hmm.. bump.
Ashbad wrote:
hmm.. bump.


Sorry for the slow response; had this open in a tab since yesterday.

Quote:
Bfile_OpenFile_OS seems rather awkward for many reasons: first off, why does it need a pointer to a string of unsigned shorts?
You hit the nail on the head: tokenized special characters, which are one or two bytes.

Quote:
Secondly, files have to start with "\\fls0\" -- though PrizmWiki doesn't tell how the rest of the file extension has to be represented. Is "\\fls0\city.pcc" as valid extension?
Sounds to me like you should experiment and find out. Since you can load arbitrary files when using the calculator as a mass storage device, I tend to think it cares not about the filename and extension.

Quote:
Thirdly, for Bfile_CreateEntry_OS, what type of modes are available (apparently I should use mode (int) 1, but are there other options?) and what do they do?
I'm not sure, I need to look at some documentation. It's either a text/binary flag, a truncate/append flag, or both.

Quote:
Why in god's name do we need to pass the parameter for size as a pointer to the int that holds the size value? How do you specify where to save it?
I presume so that as you and/or the OS updates it, you both know where to look, up until you close the handle?
Interesting.. Thanks for the ideas Kerm. I'll do some more tests regarding the I/O functions today and post any results I find.
Ashbad wrote:
Interesting.. Thanks for the ideas Kerm. I'll do some more tests regarding the I/O functions today and post any results I find.
Excellent, I look forward to your results. I'll learn something too, especially with being unable to access the Prizm wiki.
I think I now realize what's wrong, after I saw GCC didn't know what escape sequence '\c' was...

Since the "\\fls0\" isn't escaped, it's not represented right. It should be "\\\\fls0\\" instead. Found the error Smile

EDIT: nope, still non-working :/
Ashbad wrote:
I think I now realize what's wrong, after I saw GCC didn't know what escape sequence '\c' was...

Since the "\\fls0\" isn't escaped, it's not represented right. It should be "\\\\fls0\\" instead. Found the error Smile

EDIT: nope, still non-working :/

Try something like L"\\\\fls0\\" for the filename to pass a wide-character string to the function. This assumes that wchar_t is the same size as short, though. It might be 32 bits wide, which probably won't work for this function.
I thought there was a W prefix somewhere, is there not? I could have sworn I ran across that in the C99 spec when I was writing my own compiler.
SimonLoathar has suggested using Bfile_StrToName_ncpy() to change a normal string to a file compatible one. Will try, and edit in results.
Ashbad wrote:
SimonLoathar has suggested using Bfile_StrToName_ncpy() to change a normal string to a file compatible one. Will try, and edit in results.
Do you have any explanation of what that function actually does?
KermMartian wrote:
Ashbad wrote:
SimonLoathar has suggested using Bfile_StrToName_ncpy() to change a normal string to a file compatible one. Will try, and edit in results.
Do you have any explanation of what that function actually does?


It seems, from what he said and the name, to take an string of characters and make them into a file-name compatible short* string.

EDIT: and by jove's name, *it works now* Very Happy Thank you Kerm, Christop, Simon, et al.
In addition, so that others know *exactly* what to do in the future, here's some code to achieve opening files:


Code:
unsigned short*file_name = malloc(256); // will hold new name
int size_needed = 1000; // will need actual variable for size
Bfile_StrToName_ncpy(file_name, (const unsigned char*) "\\\\fls0\\name.ext\0", 128); // fixes name
int SAVE_HANDLE = Bfile_OpenFile_OS(file_name, 0x03); // save the handle!
if(SAVE_HANDLE < 0) { /* if no file created */
Bfile_CreateEntry_OS(file_name, 1, &size_needed); // create new one!
} else {
/* do whatever with file */ }


I found that you *must* close the file withBfile_CloseFile_OS( int HANDLE ) because if you don't, or if you open the same file twice, until the next mem clear (like a system error or a battery pull), the file cannot be deleted on-machine, and will return an error on subsequent opens and creates with the same name. Probably obvious, but documentation_for_the_masses++
That just means that the OS doesn't close the file properly, but if you already have it open and they leave your app I assume the OS would keep another app from editing it.
That's unfortunate that the OS doesn't deal with closing open files for you, but I bet it has something to do with the [MENU] sort of design, since programs only stop running when another program starts running. Ashbad, nice code, although I have some criticisms. Using magic numbers like 0x03 and 256 and 1000 in your code instead of named CONSTANT_POUND_DEFINES is frowned upon. Other than that, well done.
Here's how the cool kids use the Bfile_* functions using gnu++0x:


Code:
Bfile_OpenFile_OS((unsigned short*)(u"\\\\fls0\\test.txt\0"), OPENMODE_READ); // OPENMODE_* are enums


You must be using C++ and compiling with -std=gnu++0x
AHelper wrote:
Here's how the cool kids use the Bfile_* functions using gnu++0x:


Code:
Bfile_OpenFile_OS((unsigned short*)(u"\\\\fls0\\test.txt\0"), OPENMODE_READ); // OPENMODE_* are enums


You must be using C++ and compiling with -std=gnu++0x


I'm not sure that'll always work, considering the Prizm uses some weird 2-byte character defines at times; I still suggest using Bfile_StrToName_ncpy for conversion.
The u means that it will use 16-bit shorts instead of 8 bit chars. Just like L"abc" gives you 32-bit wchar_ts.
AHelper wrote:
The u means that it will use 16-bit shorts instead of 8 bit chars. Just like L"abc" gives you 32-bit wchar_ts.


Well, that's not the problem with it, it's just that I'm not sure all prizm 16-bit character defines match up with what GCC would be doing to convert them (i.e., the ASCII values may change because casio is dumb at times, and that syscall I threw out there also may format the string specially for use before use)
AHelper wrote:
Here's how the cool kids use the Bfile_* functions using gnu++0x:


Code:
Bfile_OpenFile_OS((unsigned short*)(u"\\\\fls0\\test.txt\0"), OPENMODE_READ); // OPENMODE_* are enums


You must be using C++ and compiling with -std=gnu++0x
False. The cool kids use them like this:


Code:
#define TEST_FILE_PATH u"\\\\fls0\\test.txt\0"
Bfile_OpenFile_OS((unsigned short*)(TEST_FILE_PATH), OPENMODE_READ); // OPENMODE_* are enums


Edit: I was going to complain that the \0 in there was unnecessary, but now I'm not so sure. I _think_ that the u prefix means GCC will append a two-byte \0 to the end on its own without the \0 inside, but I'm suddenly doubting myself.
I should have taken the \0 out, my fault. The u prefix was an addition to allow more control on UTF-xx strings, proposed and used since gcc 4.4 here. u makes the string UTF-16 of the type char16_t*
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement