 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : ascii text file
| Author | Message | ||||
| isochronic Guru  Joined: 21/01/2012 Location: AustraliaPosts: 689 |
Considering the use of text files to store data readings etc as text - I am wondering, will an ascii file (text only) ever contain null bytes ? |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
CHR$(0) is generally a perfectly valid character however they are sometimes interpreted before your code gets a sniff at them; for instance in C they terminate a string and if you really want to work with them it can be tricky. I would experiment by creating a file full of 0x00 characters (ASCII NUL) then read it back and see what I got. Out of interest, what platform is this? might help to define answers. Interesting that MMBasic V5.04.04 won't accept any number character under 32 in the STRING$() function - I don't like that as it rules out the ASCII control characters - I think this might have been covered before. Assigning a variable to CHR$(0) is fine though. |
||||
twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
In my understanding, it's a question of definition. What is a "text" file? Generally I would say that a (ASCII) text file should not contain CHR$(0). No control characters also. causality ≠ correlation ≠ coincidence |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
The background is, I have made a widget that reads SD card files and makes the content available via a standard spi connection. It is working ok however it would be good to have a end-of-file-reached flag so that when a user tries to read more data than a file contains, in error, it is handled properly. A not-wonderful but simple way would be be to return a null to the spi read, which depends on the file never having a null. But I guess it really should use an extra connection to the main device, for control/feedback etc. It would be good to avoid an extra wire though. (added) another option would be to send each byte using extra bits, maybe 16 bit. Which would slow it down and need extra handling at the receive, hmm. |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
I see what you are getting at - a "text" file should contain printable characters only... what about CR & LF?  but you are right... "text" is a conceptual thing - it's all numbers at the end of the day, just how you interpret them that applies the model. |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
Programs such as XMODEM will add end-of-file characters to the end of the text to pad the file size to a 128 byte boundary. This is left over from the CPM days. This end-of-file character can be either CTRL-Z or zero according to the XMODEM standard and I have seen both used. Some terminal programs quietly drop any zeros, others don't. I would play safe and assume that there might be zero bytes in any text file. CR LF etc including CTRL-G (bell) and many others may be present. If you create the file, you obviously have full control over the contents but if it is intended for general use, anything goes... Jim VK7JH MMedit |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
You are correct!  causality ≠ correlation ≠ coincidence |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
MMBasic is happy writing and reading any character from 0 to 255 (decimal). Your experience with other systems reading the files can vary. Geoff Geoff Graham - http://geoffg.net |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
