- How to get the next line character(s) - 1 Update
- Moons - 1 Update
| "James R. Kuyper" <jameskuyper@verizon.net>: Feb 20 09:19AM -0500 On 02/17/2018 07:54 AM, jak wrote: ... > At this point you have questioned me that using the fgets on a file open > in binary mode is a bad idea. > I replied: I know, sorry, it worked and I left the code unchanged. The purpose of the code was to determine how line endings are represented on the current platform. There's only a limited number of ways that line endings can be represented, where your program would give the correct result. Those ways are among the most common ways, which is why it's not implausible that your program worked on the systems where you tested it. However, did you test it on any system where a line ending is represented in one of the ways that I said your program would handle incorrectly? You might not care about such systems, but the OP said nothing to suggest that he wasn't interested in them, so your code might not be a proper solution to the OP's question. > passed to a function that intends to write in it. If the function does > not work or works but writes bad data to my array, then it's a badly > written function. You seem to misunderstand the problem with uninitialized data. It has nothing to do with something going wrong when the data does eventually get initialized. It has to do with reading data before it has been initialized, which your code will do when it passes that value to printf(). The standard says that the elements of such an array have indeterminate values, and that any evaluation of such objects has undefined behavior (11.6p12). It lists some exceptions, and one of those exceptions covers your code. However, I get the distinct impression that you don't know what those exceptions are, so the fact that your code has defined behavior is purely an accident. ... > Add again: there may be text files where the first byte indicates the > length from the line. More accurately, I said that there were systems where the standard text file format uses fixed-sized blocks, with each line starting a new block, and there's a count at the start of each block indicating how many bytes of that block are used; a count smaller than the block size occurs only in the block containing the end of the line. > First of all it should not be called a text file because this should be > readable by any text editor / viewer and would not be the case with this > file. ... Text editors targeted for such systems will be written to understand files in the format described. On some such systems that is the only format allowed for text files - a text editor targeting such a system would NOT work properly when viewing files you would be willing to call "text files". What you would be willing to call "text files" would need to be converted when ported to such systems, to use the correct text format for those systems. > Honestly I do not understand if you answer me for your pleasure to > contradict me or if you are trying to explain something that, in your > opinion, I do not know or do not understand. ... The latter - and this message tends to confirm that opinion. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 20 08:39AM On 19/02/2018 09:18, Rick C. Hodgin wrote: > On Sunday, February 18, 2018 at 6:53:32 PM UTC-5, Rick C. Hodgin wrote: >> If natural disasters are... > I, the real Rick C. Hodgin... I, the real Rick C. Hodgin, did not write that reply. Please examine the headers to see that there is someone usurping my identity (and without my permission). I post from Giganews and Google Groups only. -- Thank you, Rick C. Hodgin |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment