Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #83684 > unrolled thread

getline() problem

Back to article view | Back to comp.lang.c++

Contents

  getline() problem Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-04-23 19:07 +0200
    Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-23 10:17 -0700
      Re: getline() problem Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-04-23 19:40 +0200
        Re: getline() problem Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-04-23 19:59 +0200
          Re: getline() problem Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-23 21:47 +0300
            Re: getline() problem Juha Nieminen <nospam@thanks.invalid> - 2022-04-25 06:00 +0000
              Re: getline() problem Öö Tiib <ootiib@hot.ee> - 2022-04-25 00:12 -0700
              Re: getline() problem Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-25 11:40 +0300
              Re: getline() problem James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-25 11:37 -0400
                Re: getline() problem Vir Campestris <vir.campestris@invalid.invalid> - 2022-04-25 16:54 +0100
                  Re: getline() problem James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-25 12:29 -0400
                    Re: getline() problem scott@slp53.sl.home (Scott Lurndal) - 2022-04-25 17:29 +0000
                    Re: getline() problem Manfred <noname@add.invalid> - 2022-04-25 20:17 +0200
                  Re: getline() problem Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-25 10:19 -0700
                  Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-25 10:41 -0700
                  Re: getline() problem Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-25 21:58 +0300
                Re: getline() problem scott@slp53.sl.home (Scott Lurndal) - 2022-04-25 15:56 +0000
                  Re: getline() problem James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-25 13:12 -0400
                  Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-25 11:03 -0700
                    Re: getline() problem scott@slp53.sl.home (Scott Lurndal) - 2022-04-25 19:05 +0000
                      Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-25 12:48 -0700
                      Re: getline() problem Ben <ben.usenet@bsb.me.uk> - 2022-04-25 21:46 +0100
                    Re: getline() problem Juha Nieminen <nospam@thanks.invalid> - 2022-04-26 05:43 +0000
                      Re: getline() problem David Brown <david.brown@hesbynett.no> - 2022-04-26 09:36 +0200
                        Re: getline() problem Juha Nieminen <nospam@thanks.invalid> - 2022-04-26 09:18 +0000
                          Re: getline() problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-26 02:47 -0700
                            Re: getline() problem Juha Nieminen <nospam@thanks.invalid> - 2022-04-26 11:06 +0000
                          Re: getline() problem David Brown <david.brown@hesbynett.no> - 2022-04-26 15:52 +0200
                          Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-26 07:04 -0700
                          Re: getline() problem Manfred <noname@add.invalid> - 2022-04-26 16:49 +0200
                          Re: getline() problem James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-26 12:01 -0400
                      Re: getline() problem James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-26 11:49 -0400
                  Re: getline() problem Manfred <noname@add.invalid> - 2022-04-25 20:23 +0200
              Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-25 10:33 -0700
                Re: getline() problem "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-04-25 10:52 -0700
                  Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-25 11:08 -0700
                    Re: getline() problem "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-04-25 21:18 -0700
                      Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-25 22:04 -0700
                Re: getline() problem Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-25 22:06 +0300
                  Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-25 13:02 -0700
          Re: getline() problem Barry Schwarz <schwarzb@delq.com> - 2022-04-23 12:54 -0700
          Re: getline() problem Montmorency <none@none.com> - 2022-04-23 14:45 -0700
            Re: getline() problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-23 16:49 -0700
              Re: getline() problem Ben <ben.usenet@bsb.me.uk> - 2022-04-24 01:04 +0100
                Re: getline() problem Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-23 18:24 -0700
                  Re: getline() problem Ben <ben.usenet@bsb.me.uk> - 2022-04-24 03:16 +0100
                    Re: getline() problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-24 22:51 -0700
                      Re: getline() problem Ben <ben.usenet@bsb.me.uk> - 2022-04-25 11:07 +0100
              Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-23 17:15 -0700
                Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-23 18:23 -0700
            Re: getline() problem Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-04-24 05:28 +0200
    Re: getline() problem Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-04-25 12:41 +0200
      Re: getline() problem Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-25 14:33 +0300
      Re: getline() problem Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-04-25 18:53 +0200
        Re: getline() problem Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-25 22:08 +0300
          Re: getline() problem Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-04-26 09:01 +0200
            Re: getline() problem Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-26 11:15 +0300

Page 3 of 3 — ← Prev page 1 2 [3]

#83689

On Sat, 23 Apr 2022 19:59:52 +0200, Jivanmukta
<jivanmukta@poczta.onet.pl> wrote:

>W dniu 23.04.2022 o 19:40, Jivanmukta pisze:
>> W dniu 23.04.2022 o 19:17, Andrey Tarasevich pisze:
>>> On 4/23/2022 10:07 AM, Jivanmukta wrote:
>>>> I have a text file (with PHP source code) containing such two lines:
>>>>
>>>> SebastianBergmann\Diff\Line\00content";s:7:"2222222";}}}}}}
>>>> EOL;
>>>
>>> What is this supposed to mean? Do you actually have a binary 0 byte in 
>>> the file right after "Line"? Or is it plain text consisting of "\" 
>>> character followed by "00" characters?
>>>
>>> I presume it's the latter.
>> 
>> plain text consisting of "\" character followed by "00" characters
>
>Sorry my mistake: I opened the file in VSCode and now I see that the 
>file contains NUL bytes.
>How to read in C++ line of text finished with newline and containing NUL 
>bytes?

Another option is to open the file in binary mode, read the desired
number of bytes, and parse the resulting array of char manually as
needed.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#83690

On 4/23/2022 10:59 AM, Jivanmukta wrote:
> 
> Sorry my mistake: I opened the file in VSCode and now I see that the 
> file contains NUL bytes.
> How to read in C++ line of text finished with newline and containing NUL 
> bytes?

Zero bytes have no special meaning in stream I/O, neither in binary nor 
in text. There's no need to do anything special. So, again, I suspect 
that everything is working properly in your case, at least with regard 
to I/O. Whatever "problems" you perceive are either debugger illusions 
or your own problems in post-processing.

The real question is: what are zero bytes doing in what you previously 
called "PHP source code"?

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#83692

On Saturday, 23 April 2022 at 22:46:10 UTC+1, Montmorency wrote:
> On 4/23/2022 10:59 AM, Jivanmukta wrote: 
> > 
> > Sorry my mistake: I opened the file in VSCode and now I see that the 
> > file contains NUL bytes. 
> > How to read in C++ line of text finished with newline and containing NUL 
> > bytes?
> Zero bytes have no special meaning in stream I/O, neither in binary nor 
> in text. There's no need to do anything special. So, again, I suspect 
> that everything is working properly in your case, at least with regard 
> to I/O. Whatever "problems" you perceive are either debugger illusions 
> or your own problems in post-processing. 
>
Nul bytes will break most text-based reading functions, because they return
text as C strings, and C strings are Nul-terminated. However std::strings can
have embedded nuls without special processing. You just have to be careful
not to pass them to any function that coverts them to C strings. In practice
that probably means taking action against the nuls at an early stage.  
>
> The real question is: what are zero bytes doing in what you previously 
> called "PHP source code"?
> 

[toc] | [prev] | [next] | [standalone]

#83693

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> Nul bytes will break most text-based reading functions, because they return
> text as C strings, and C strings are Nul-terminated. However std::strings can
> have embedded nuls without special processing. You just have to be careful
> not to pass them to any function that coverts them to C strings. In practice
> that probably means taking action against the nuls at an early stage.

This is comp.lang.c++ not comp.lang.c!

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#83696

Ben <ben.usenet@bsb.me.uk> writes:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> Nul bytes will break most text-based reading functions, because they return
>> text as C strings, and C strings are Nul-terminated. However std::strings can
>> have embedded nuls without special processing. You just have to be careful
>> not to pass them to any function that coverts them to C strings. In practice
>> that probably means taking action against the nuls at an early stage.
>
> This is comp.lang.c++ not comp.lang.c!

Yes, of course.

To be fair, C++ includes most of the C standard library by reference,
and if you have a std::string containing a null character, you have to
be careful what you do with it.  And C++ string literals still represent
C-style strings.  For example, this will print "3":

    std::cout << std::string("abc\0def").size() << "\n";

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#83697

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Ben <ben.usenet@bsb.me.uk> writes:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> Nul bytes will break most text-based reading functions, because they return
>>> text as C strings, and C strings are Nul-terminated. However std::strings can
>>> have embedded nuls without special processing. You just have to be careful
>>> not to pass them to any function that coverts them to C strings. In practice
>>> that probably means taking action against the nuls at an early stage.
>>
>> This is comp.lang.c++ not comp.lang.c!
>
> Yes, of course.

Sure, but the question was about getline.

> To be fair, C++ includes most of the C standard library by reference,
> and if you have a std::string containing a null character, you have to
> be careful what you do with it.  And C++ string literals still represent
> C-style strings.  For example, this will print "3":
>
>     std::cout << std::string("abc\0def").size() << "\n";

But this is not a std::string with a null in it.  The constructor uses
the first null to determine the length of the std::string to build.  The
version

     std::cout << std::string("abc\0def", 7).size() << "\n";

will print 7 and

     std::cout << std::string("abc\0def", 7) << "\n";

will print the string, null and all.

Maybe more to the point, getline will read and embed null quite
happily.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#83702

On Sunday, 24 April 2022 at 03:17:12 UTC+1, Ben wrote:
> Keith Thompson <Keith.S.T...@gmail.com> writes: 
> 
> > Ben <ben.u...@bsb.me.uk> writes: 
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes: 
> >> 
> >>> Nul bytes will break most text-based reading functions, because they return 
> >>> text as C strings, and C strings are Nul-terminated. However std::strings can 
> >>> have embedded nuls without special processing. You just have to be careful 
> >>> not to pass them to any function that coverts them to C strings. In practice 
> >>> that probably means taking action against the nuls at an early stage. 
> >> 
> >> This is comp.lang.c++ not comp.lang.c! 
> > 
> > Yes, of course.
> Sure, but the question was about getline.
>
Most medium-sized to large C++ programs contain routines which accept or,
more rarely, return C strings. We use a API which was first developed before
std::string was invented. It has grown since then. It has it's own Unicode
String() class, then there's an entirely separate Unicode character type
which is used for communicating with the GUI. There's not actually much
use of std::strings in the API, though we use them quite a bit in our own
code.
So strings are a bit of a mess. As is typical. Embedded nuls in std::strings
are definitely an accident waiting to happen in our code

[toc] | [prev] | [next] | [standalone]

#83711

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Sunday, 24 April 2022 at 03:17:12 UTC+1, Ben wrote:
>> Keith Thompson <Keith.S.T...@gmail.com> writes: 
>> 
>> > Ben <ben.u...@bsb.me.uk> writes: 
>> >> Malcolm McLean <malcolm.ar...@gmail.com> writes: 
>> >> 
>> >>> Nul bytes will break most text-based reading functions, because they return 
>> >>> text as C strings, and C strings are Nul-terminated. However std::strings can 
>> >>> have embedded nuls without special processing. You just have to be careful 
>> >>> not to pass them to any function that coverts them to C strings. In practice 
>> >>> that probably means taking action against the nuls at an early stage. 
>> >> 
>> >> This is comp.lang.c++ not comp.lang.c! 
>> > 
>> > Yes, of course.
>>
>> Sure, but the question was about getline.
>>
> Most medium-sized to large C++ programs contain routines which accept or,
> more rarely, return C strings. We use a API which was first developed before
> std::string was invented. It has grown since then. It has it's own Unicode
> String() class, then there's an entirely separate Unicode character type
> which is used for communicating with the GUI. There's not actually much
> use of std::strings in the API, though we use them quite a bit in our own
> code.

I think we are talking at cross purposes.  std::getline has no trouble
with nulls (though I think it may be permitted to, if you see what I
mean).  In general, C++ std::string avoids a lot of the trouble the C
has with its raw strings.

> So strings are a bit of a mess. As is typical. Embedded nuls in std::strings
> are definitely an accident waiting to happen in our code

They are likely be a problem in lots of code bases, but that's not
related to the point that came up.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#83694

On 4/23/2022 4:49 PM, Malcolm McLean wrote:
> On Saturday, 23 April 2022 at 22:46:10 UTC+1, Montmorency wrote:
>> On 4/23/2022 10:59 AM, Jivanmukta wrote:
>>>
>>> Sorry my mistake: I opened the file in VSCode and now I see that the
>>> file contains NUL bytes.
>>> How to read in C++ line of text finished with newline and containing NUL
>>> bytes?
>> Zero bytes have no special meaning in stream I/O, neither in binary nor
>> in text. There's no need to do anything special. So, again, I suspect
>> that everything is working properly in your case, at least with regard
>> to I/O. Whatever "problems" you perceive are either debugger illusions
>> or your own problems in post-processing.
>>
> Nul bytes will break most text-based reading functions, because they return
> text as C strings, and C strings are Nul-terminated. 

I don't know what "text-based reading functions" you are talking about 
here. C standard library functions are rather clearly and strictly 
specified: they read all characters/any characters until some 
stop-condition is met. Functions that treat input characters as "text" 
do not provide any special treatment to null characters read from the 
input stream. It is not part of their stop-condition. If you know a 
standard "text-based" I/O function with special treatment for null 
character - let's hear about it. Be specific. Provide an example.

And no, these functions don't "return strings". Nowhere in the standard 
it is stated that way. What they really do is they "read characters into 
an array". They simply fill recipient buffers in accordance with their 
specification. For example, format `%s` in `fscanf` will null-terminate 
its recipient buffer, but it still does not prohibit this buffer from 
having an extra null character in the middle. If that's the case, the 
resultant buffer as a whole won't be a C-string. But it is not a problem 
at all as far as `fscanf` is concerned.

So, it is not clear what "return strings" you are talking about. C-style 
I/O functions do not "return strings". They fill character arrays. What 
you do with these arrays afterwards is your responsibility. Whatever 
mistakes you make are entirely yours.

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#83695

On 4/23/2022 5:15 PM, Andrey Tarasevich wrote:
> On 4/23/2022 4:49 PM, Malcolm McLean wrote:
>> On Saturday, 23 April 2022 at 22:46:10 UTC+1, Montmorency wrote:
>>> On 4/23/2022 10:59 AM, Jivanmukta wrote:
>>>>
>>>> Sorry my mistake: I opened the file in VSCode and now I see that the
>>>> file contains NUL bytes.
>>>> How to read in C++ line of text finished with newline and containing 
>>>> NUL
>>>> bytes?
>>> Zero bytes have no special meaning in stream I/O, neither in binary nor
>>> in text. There's no need to do anything special. So, again, I suspect
>>> that everything is working properly in your case, at least with regard
>>> to I/O. Whatever "problems" you perceive are either debugger illusions
>>> or your own problems in post-processing.
>>>
>> Nul bytes will break most text-based reading functions, because they 
>> return
>> text as C strings, and C strings are Nul-terminated. 
> 
> I don't know what "text-based reading functions" you are talking about 
> here. C standard library functions are rather clearly and strictly 
> specified: they read all characters/any characters until some 
> stop-condition is met. Functions that treat input characters as "text" 
> do not provide any special treatment to null characters read from the 
> input stream. It is not part of their stop-condition. If you know a 
> standard "text-based" I/O function with special treatment for null 
> character - let's hear about it. Be specific. Provide an example.
> 
> And no, these functions don't "return strings". Nowhere in the standard 
> it is stated that way. What they really do is they "read characters into 
> an array". They simply fill recipient buffers in accordance with their 
> specification. For example, format `%s` in `fscanf` will null-terminate 
> its recipient buffer, but it still does not prohibit this buffer from 
> having an extra null character in the middle. If that's the case, the 
> resultant buffer as a whole won't be a C-string. But it is not a problem 
> at all as far as `fscanf` is concerned.
> 
> So, it is not clear what "return strings" you are talking about. C-style 
> I/O functions do not "return strings". They fill character arrays. What 
> you do with these arrays afterwards is your responsibility. Whatever 
> mistakes you make are entirely yours.

In the above I use the acronym "I/O" rather nonchalantly, without giving 
it too much thought. Of course, I should be really talking about I 
(input), which is the topic here. And input is what I meant to talk about.

As for O (output)... yes, text-mode stream output functions may treat 
non-printable characters in a special way, which includes null 
character. But that's a wholly different story.

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#83698

> The real question is: what are zero bytes doing in what you previously 
> called "PHP source code"?
> 

They are part of text data in heredoc.

[toc] | [prev] | [next] | [standalone]

#83713

W dniu 23.04.2022 o 19:07, Jivanmukta pisze:
> I have a text file (with PHP source code) containing such two lines:
> 
> SebastianBergmann\Diff\Line\00content";s:7:"2222222";}}}}}}
> EOL;
> 
> I need to read the line into variable: string line. I wrote:
> 
> getline(in_file, line);
> 
> The problem is that in variable line I receive:
> 
> ...\Diff\Line:"LineEOL;
> 
> I think problem is with \00 characters, probably getline() does not read 
> it correctly.
> 
> How to read it correctly in my C++ program?

I want to check if a file contains NUL character.

inline std::string file_get_contents(const std::string &file_path) { // 
a la PHP
     std::ifstream fin(file_path);
     std::stringstream buffer;
     buffer << fin.rdbuf();
     return buffer.str();
}
...
     for (char c : file_get_contents(file)) {
         if (c == '\0') {
             m += "File " + file + " should not contain NUL character 
(ASCII 0). ";
         }
     }

This solution does not work.
How to do it?

[toc] | [prev] | [next] | [standalone]

#83717

25.04.2022 13:41 Jivanmukta kirjutas:
> W dniu 23.04.2022 o 19:07, Jivanmukta pisze:
>> I have a text file (with PHP source code) containing such two lines:
>>
>> SebastianBergmann\Diff\Line\00content";s:7:"2222222";}}}}}}
>> EOL;
>>
>> I need to read the line into variable: string line. I wrote:
>>
>> getline(in_file, line);
>>
>> The problem is that in variable line I receive:
>>
>> ...\Diff\Line:"LineEOL;
>>
>> I think problem is with \00 characters, probably getline() does not 
>> read it correctly.
>>
>> How to read it correctly in my C++ program?
> 
> I want to check if a file contains NUL character.
> 
> inline std::string file_get_contents(const std::string &file_path) { // 
> a la PHP
>      std::ifstream fin(file_path);
>      std::stringstream buffer;
>      buffer << fin.rdbuf();
>      return buffer.str();
> }
> ...
>      for (char c : file_get_contents(file)) {
>          if (c == '\0') {
>              m += "File " + file + " should not contain NUL character 
> (ASCII 0). ";
>          }
>      }
> 
> This solution does not work.
> How to do it?

One possibility is that your file contains other special characters 
besides NUL and gets truncated when read in text mode. If so, you should 
open it in binary mode.

You should also check that the file opening and reading succeeded:

inline std::string file_get_contents(const std::string& file_path) { 		
	std::ifstream fin(file_path, std::ios::binary);
	if (!fin) {
		throw std::runtime_error("Cannot open: " + file_path);
	}
	std::stringstream buffer;
	if (!(buffer << fin.rdbuf())) {
		throw std::runtime_error("Cannot read: " + file_path);
	}
	return buffer.str();
}

[toc] | [prev] | [next] | [standalone]

#83740

W dniu 25.04.2022 o 14:56, Stefan Ram pisze:
> Jivanmukta <jivanmukta@poczta.onet.pl> writes:
>> I want to check if a file contains NUL character.
> ...
>> buffer << fin.rdbuf();
> ...
>> This solution does not work.
> 
>    Maybe it has to do with "buffer <<".
> 
>> How to do it?
> 
>    Without error handling in the loop:
> 
> #include <string>
> #include <iostream>
> #include <fstream>
> 
> int main()
> { auto file{ ::std::ifstream{ R"(example.bin)" }};
>    if( !file )::std::cerr << "Can't open input file.\n";
>    else
>    { auto zero_byte_found{ false };
>      while( !file.eof() )
>      { auto const byte{ file.get() };
>        if( !byte ){ zero_byte_found = true; break; }}
>      ::std::cout << zero_byte_found << '\n'; }}
> 
>    .
> 
> 
I have written:

     string m = "";
     auto f { ::std::ifstream { file_str } };
     if (f) {
         bool zero_byte_found = false;
         while (!f.eof()) {
             auto const byte { f.get() };
             if (!byte) {
                 zero_byte_found = true;
                 break;
             }
         }
         if (zero_byte_found) {
             m += "File " + file_str + " should not contain NUL 
character (ASCII 0). ";
         }
     }

and I have m == "" for the file with NUL characters (VSCode shows me NUL 
bytes in this file).

[toc] | [prev] | [next] | [standalone]

#83756

25.04.2022 19:53 Jivanmukta kirjutas:
> W dniu 25.04.2022 o 14:56, Stefan Ram pisze:
>> Jivanmukta <jivanmukta@poczta.onet.pl> writes:
>>> I want to check if a file contains NUL character.
>> ...
>>> buffer << fin.rdbuf();
>> ...
>>> This solution does not work.
>>
>>    Maybe it has to do with "buffer <<".
>>
>>> How to do it?
>>
>>    Without error handling in the loop:
>>
>> #include <string>
>> #include <iostream>
>> #include <fstream>
>>
>> int main()
>> { auto file{ ::std::ifstream{ R"(example.bin)" }};
>>    if( !file )::std::cerr << "Can't open input file.\n";
>>    else
>>    { auto zero_byte_found{ false };
>>      while( !file.eof() )
>>      { auto const byte{ file.get() };
>>        if( !byte ){ zero_byte_found = true; break; }}
>>      ::std::cout << zero_byte_found << '\n'; }}
>>
>>    .
>>
>>
> I have written:
> 
>      string m = "";
>      auto f { ::std::ifstream { file_str } };
>      if (f) {
>          bool zero_byte_found = false;
>          while (!f.eof()) {
>              auto const byte { f.get() };
>              if (!byte) {
>                  zero_byte_found = true;
>                  break;
>              }
>          }
>          if (zero_byte_found) {
>              m += "File " + file_str + " should not contain NUL 
> character (ASCII 0). ";
>          }
>      }
> 
> and I have m == "" for the file with NUL characters (VSCode shows me NUL 
> bytes in this file).

You still have not added the binary flag.

[toc] | [prev] | [next] | [standalone]

#83766

W dniu 25.04.2022 o 21:08, Paavo Helde pisze:
> 25.04.2022 19:53 Jivanmukta kirjutas:
>> W dniu 25.04.2022 o 14:56, Stefan Ram pisze:
>>> Jivanmukta <jivanmukta@poczta.onet.pl> writes:
>>>> I want to check if a file contains NUL character.
>>> ...
>>>> buffer << fin.rdbuf();
>>> ...
>>>> This solution does not work.
>>>
>>>    Maybe it has to do with "buffer <<".
>>>
>>>> How to do it?
>>>
>>>    Without error handling in the loop:
>>>
>>> #include <string>
>>> #include <iostream>
>>> #include <fstream>
>>>
>>> int main()
>>> { auto file{ ::std::ifstream{ R"(example.bin)" }};
>>>    if( !file )::std::cerr << "Can't open input file.\n";
>>>    else
>>>    { auto zero_byte_found{ false };
>>>      while( !file.eof() )
>>>      { auto const byte{ file.get() };
>>>        if( !byte ){ zero_byte_found = true; break; }}
>>>      ::std::cout << zero_byte_found << '\n'; }}
>>>
>>>    .
>>>
>>>
>> I have written:
>>
>>      string m = "";
>>      auto f { ::std::ifstream { file_str } };
>>      if (f) {
>>          bool zero_byte_found = false;
>>          while (!f.eof()) {
>>              auto const byte { f.get() };
>>              if (!byte) {
>>                  zero_byte_found = true;
>>                  break;
>>              }
>>          }
>>          if (zero_byte_found) {
>>              m += "File " + file_str + " should not contain NUL 
>> character (ASCII 0). ";
>>          }
>>      }
>>
>> and I have m == "" for the file with NUL characters (VSCode shows me 
>> NUL bytes in this file).
> 
> You still have not added the binary flag.
I don't understand you. I have binary flag zero_byte_found.

[toc] | [prev] | [next] | [standalone]

#83770

26.04.2022 10:01 Jivanmukta kirjutas:
> W dniu 25.04.2022 o 21:08, Paavo Helde pisze:
>>
>> You still have not added the binary flag.
> I don't understand you. I have binary flag zero_byte_found.

Look at my prev post in this thread for code example how to use 
std::ios::binary.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c++

csiph-web