 |
lua-l archive |
|
|
||
|
On 20/02/2014 13.34, Francisco Olarte wrote:
AAMOF, on disk files, so does windows ( nt, windows 16 was just the gui ) and MSDOS, it is the C library implementation which does the magic stuff. But NT ands it users are always problematic. My running problem with them is how an OS which has been unicode ( 16 ) from the start makes it so difficult for their users to spit UTF-8 files ( without the pseudo-bom at the start ).
I'll add a note: Lua is also used on embedded systems, whose compilers sometimes have proprietary C libraries; it should work everywhere.
I don't have access to the current standard definition and I cannot check what the guaranteed behaviour of fgets() for binary-opened files should be (assuming it's defined). Based on second-hand references and on good old K&R, it should *probably* accept any character value [*] but it would be better to base any design on the 'legal' definition... and, this being the real world, on the actual implementations.
[*] K&R 2nd ed. says:<< fgets reads at most the next n-1 characters into the array s, stopping if a newline is encountered; the newline is included in the array, which is terminated by '\0'. [etc.]. >>
A library implementor could be forgiven here for thinking that a '\0' in the file should not happen, or that it could be considered a terminator (either while reading the file or, more correctly, when copying the line from a system buffer to the 's' array): after all, copying data beyond the destination end ('\0') would be a waste of CPU cycles.
-- Enrico