- How to get the next line character(s) - 4 Updates
| jak <please@nospam.ty>: Feb 17 01:54PM +0100 Il 16/02/2018 17:57, James R. Kuyper ha scritto: > meaning was quite different. Several of the other hits I got were > English text, poorly written by people with Italian names, supporting > the idea that it's an Italian idiom poorly translated into English. Oh, so now you will understand how difficult it is for me to understand without misunderstanding, that river of words that you answer to me every time. When I read the OP question, I found it interesting because the tendency to write multi-platform programs is more present every day. Among all the problems that can be encountered, the two most common are: identifying the separator character of the paths and how the system encodes the end of the text line. For the latter problem, most of the proposed solutions suggest to open a file in text mode, write in a \ n ', reopen it in binary mode and read how it has been encoded. Looking for alternative solutions, I found someone who thought of using a pipe channel instead of a file. this seemed interesting and I proposed it by writing a very short piece of code with the intention of presenting the idea. 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. Then you added: the array is not initialized. I do not care if the variable is used initially to the left of a = or 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. Then again you said: there can be multiple types of end of line ("\n", "\r", "\n\r", "\r\n"). From my point of view it is not important. The compiler will be suitable for that system and that code should tell me how it encoded the "\n". Add again: there may be text files where the first byte indicates the length from 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. Furthermore the aim was to understand how the system encodes the end line in text mode, not to read a file. 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. If you fear about my problems by manipulating files, please do not. When the CLIPPER was decommissioned I had to write a library in C to access the db produced by it and the only help came from hexdump of the index files (no internet, no google, no newsgroups, all these did not yet exist). regards |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 17 08:56PM +0200 On 17.02.2018 14:54, jak wrote: > decommissioned I had to write a library in C to access the db produced > by it and the only help came from hexdump of the index files (no > internet, no google, no newsgroups, all these did not yet exist). Feel safe, nobody here cares if you can manipulate files or not. Also, nobody cares what you find important or do not. You have not posted in this forum long enough to convince anyone that the things you find important are actually important for other people, or vice versa. All of this thread is nitpicking about a problem which in practice does not exist or can be solved trivially by an "#ifdef _WIN32", but which in theory is very non-trivial and the question itself is probably ill-formed. All this nitpicking is done by patrons finding some interest in this strange (non-)problem, there is nothing personal (at least not yet), so you should not feel offended! So let the nit-picking continue! Instead of trying to neglect the questions by labeling them as not important, try to explain why your pipe/_pipe program produces a wrong result in Visual C++, but not in Cygwin. If there is an actual reason for that we all might get a bit wiser. Cheers Paavo |
| jak <please@nospam.ty>: Feb 17 08:43PM +0100 Il 17/02/2018 19:56, Paavo Helde ha scritto: > Cygwin. If there is an actual reason for that we all might get a bit wiser. > Cheers > Paavo I'm doing it but because I'm interested in it and not because you're saying it. |
| jak <please@nospam.ty>: Feb 17 09:08PM +0100 Il 16/02/2018 16:58, Paavo Helde ha scritto: >> me is interesting. Can I ask you in which environment did you try? >> (operating system, compiler, msys / msys2, other ...) > Windows 7 Enterprise, SP1, Visual C++ 2017, x64. Hi, I found, on the microsoft site, a document that talks about _pipe function that says 2 things. the first of these is that to enable the end-line coding it is necessary to use a different flag with respect to the one used _O_TEXT. I tried it but works in the same way. The second info, talks about the need not to use the reading descriptor and the writing descriptor in the same process/thread if you do not want to encounter problems. This thing happens in my program. I also found an example program where, to use both descriptors in the same process, they are duplicated and used their duplications. As soon as I find some time I will try if using the descriptors in separate processes the mechanism will work correctly. Unfortunately, even if it will work it will result an excessive work only to know how the system encodes the end of line. |
| 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