Not a problem, the Enclave stuff can be very confusing the first time through, thus my recommendation to review the intel documentation https://software.intel.com/en-us/downlo … oper-guide
Imagine the Enclave as a black box of nothingness. It isn't allowed to do anything you don't let it IE if you do not provide it functionality it won't know what it is. I am referring to things we might take for granted in typical programming such as scanf, printf, DEBUG_LOGGING (writing to a file stream) etc. The enclave doesn't know what a file stream is, it doesn't even know what a file is unless you tell it. Anything that involves I/O (reading/writing) will have to occur outside the enclave in the untrusted space. You can then pass things into the enclave by either:
A) pass a buffer pointer out of the enclave to be written to
B) Pass a buffer pointer into the enclave for the enclave to read from
We have to specifically note these types of calls as untrusted however because it is information being gathered from outside the enclave or passed into the enclave from the untrusted execution space. IE if a malicious actor gained full control of the system that malicious actor still could do nothing about the code running inside the enclave but they might be able to pass in stuff via untrusted out_calls so we map those in the untrusted section of the .edl. Anyway, please take time to peruse the intel documentation it will help give a much more thorough understanding of the execution space and you'll start to see patterns of what types of things (IE "close being undefined") are expected and how to resolve them.