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

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

Hello World in Russian

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

Contents

  Hello World in Russian Joseph Hesse <joeh@gmail.com> - 2022-01-29 05:51 +0200
    Re: Hello World in Russian James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-28 23:27 -0500
      Re: Hello World in Russian Muttley@dastardlyhq.com - 2022-01-29 10:21 +0000
    Re: Hello World in Russian Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-28 22:42 -0800
      Re: Hello World in Russian David Brown <david.brown@hesbynett.no> - 2022-01-29 13:01 +0100
        Re: Hello World in Russian "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-01-29 14:12 +0100
          Re: Hello World in Russian David Brown <david.brown@hesbynett.no> - 2022-01-29 17:34 +0100
        Re: Hello World in Russian James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-30 14:17 -0500
          Re: Hello World in Russian Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-30 20:17 -0800
    Re: Hello World in Russian "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-01-29 11:48 +0100
      Re: Hello World in Russian Paavo Helde <eesnimi@osa.pri.ee> - 2022-01-29 17:39 +0200
        Re: Hello World in Russian "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-01-30 09:18 +0100
          Re: Hello World in Russian Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-30 12:12 +0000
            Re: Hello World in Russian "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-01-30 14:02 +0100
              Re: Hello World in Russian Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-30 14:45 +0000
                Re: Hello World in Russian "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-01-30 21:53 +0100
                  Re: Hello World in Russian Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-30 21:00 +0000
              Re: Hello World in Russian James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-30 14:02 -0500
            Re: Hello World in Russian Muttley@dastardlyhq.com - 2022-01-31 10:23 +0000
              Re: Hello World in Russian scott@slp53.sl.home (Scott Lurndal) - 2022-01-31 16:11 +0000
                Re: Hello World in Russian Muttley@dastardlyhq.com - 2022-01-31 16:36 +0000
                Re: Hello World in Russian Paavo Helde <eesnimi@osa.pri.ee> - 2022-01-31 20:20 +0200
              Re: Hello World in Russian Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-31 16:12 +0000
                Re: Hello World in Russian Muttley@dastardlyhq.com - 2022-01-31 16:39 +0000
                  Re: Hello World in Russian Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-31 23:47 +0000
          Re: Hello World in Russian Manfred <noname@add.invalid> - 2022-01-31 16:45 +0100
          Re: Hello World in Russian Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-31 10:10 -0800
            Re: Hello World in Russian "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-01-31 19:25 +0100
        Re: Hello World in Russian Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-01-30 12:09 +0100
          Re: Hello World in Russian Paavo Helde <eesnimi@osa.pri.ee> - 2022-01-30 14:26 +0200
            Re: Hello World in Russian Richard Damon <Richard@Damon-Family.org> - 2022-01-30 08:59 -0500
              Re: Hello World in Russian Paavo Helde <eesnimi@osa.pri.ee> - 2022-01-30 18:21 +0200
                Re: Hello World in Russian Richard Damon <Richard@Damon-Family.org> - 2022-01-30 12:56 -0500
                  Re: Hello World in Russian Vir Campestris <vir.campestris@invalid.invalid> - 2022-02-07 21:05 +0000

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

#82886

On Mon, 31 Jan 2022 16:11:23 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Sun, 30 Jan 2022 12:12:33 +0000
>>Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
>>>
>>>> My opinion is that C (and hence also C++) text mode is an abomination
>>>> that should never have been introduced, and that in addition, given
>>>> that it was introduced, it's designed in a stupid way with the data
>>>> conversion applied underneath the buffer level so that one can't get a
>>>> clear view of the raw data.
>>>>
>>>> As an example, the design means that Unix `cat` can't be faithfully
>>>> implemented in Windows using only standard C or C++, which IMO is
>>>> extreme.
>>>
>>>I assume you are talking about the cases where cat defaults to reading
>>>stdin and/or writing stdout, If so, it could be argued that it's not the
>>>fault of the C and C++ standards, but more the fault of the
>>>implementations not providing a useful freopen function.
>>
>>I see no reason why cat would need freopen because it probably uses low level
>>I/O anyway and doesn't care where its stdin is coming from if it has to read
>>from it.
>
>cat(1) uses read(2)/write(2)

As I suspected. You don't want the overhead of the higher level I/O functions
for system utilities.

 unless -v is specified, in which case it uses
>getc(3).
>
>int
>cat(fi, fname)
>FILE *fi;
>char *fname;
>{

Its been a while since I've seen K&R style C in the wild.

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

#82890

31.01.2022 18:11 Scott Lurndal kirjutas:
> int
> cat(fi, fname)
> FILE *fi;
> char *fname;
> {
>          register int fi_desc;
>          register int nitems;

'register' has been removed from the C++ language and K&R declarations 
have never been part of it. Just sayin... ;-)

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

#82885

Muttley@dastardlyhq.com writes:

> On Sun, 30 Jan 2022 12:12:33 +0000
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
>>
>>> My opinion is that C (and hence also C++) text mode is an abomination
>>> that should never have been introduced, and that in addition, given
>>> that it was introduced, it's designed in a stupid way with the data
>>> conversion applied underneath the buffer level so that one can't get a
>>> clear view of the raw data.
>>>
>>> As an example, the design means that Unix `cat` can't be faithfully
>>> implemented in Windows using only standard C or C++, which IMO is
>>> extreme.
>>
>>I assume you are talking about the cases where cat defaults to reading
>>stdin and/or writing stdout, If so, it could be argued that it's not the
>>fault of the C and C++ standards, but more the fault of the
>>implementations not providing a useful freopen function.
>
> I see no reason why cat would need freopen because it probably uses low level
> I/O anyway and doesn't care where its stdin is coming from if it has to read
> from it.

"Low level I/O" is not part of standard C, nor (as far as I know)
standard C++.  The issue was: "`cat` can't be faithfully implemented in
Windows using only standard C or C++".

-- 
Ben.

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

#82887

On Mon, 31 Jan 2022 16:12:58 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>Muttley@dastardlyhq.com writes:
>
>> On Sun, 30 Jan 2022 12:12:33 +0000
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
>>>
>>>> My opinion is that C (and hence also C++) text mode is an abomination
>>>> that should never have been introduced, and that in addition, given
>>>> that it was introduced, it's designed in a stupid way with the data
>>>> conversion applied underneath the buffer level so that one can't get a
>>>> clear view of the raw data.
>>>>
>>>> As an example, the design means that Unix `cat` can't be faithfully
>>>> implemented in Windows using only standard C or C++, which IMO is
>>>> extreme.
>>>
>>>I assume you are talking about the cases where cat defaults to reading
>>>stdin and/or writing stdout, If so, it could be argued that it's not the
>>>fault of the C and C++ standards, but more the fault of the
>>>implementations not providing a useful freopen function.
>>
>> I see no reason why cat would need freopen because it probably uses low level
>
>> I/O anyway and doesn't care where its stdin is coming from if it has to read
>> from it.
>
>"Low level I/O" is not part of standard C, nor (as far as I know)

So? Very little is part of standard C if you want to be pedantic and all *nix's
implement open(), read(), write() etc. Unless you thought I meant something 
else by low level.

>standard C++.  The issue was: "`cat` can't be faithfully implemented in
>Windows using only standard C or C++".

I imagine a number of unix utilities are difficult or impossible to implement
properly on Windows.

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

#82892

Muttley@dastardlyhq.com writes:

> On Mon, 31 Jan 2022 16:12:58 +0000
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>Muttley@dastardlyhq.com writes:
>>
>>> On Sun, 30 Jan 2022 12:12:33 +0000
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>>"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
>>>>
>>>>> My opinion is that C (and hence also C++) text mode is an abomination
>>>>> that should never have been introduced, and that in addition, given
>>>>> that it was introduced, it's designed in a stupid way with the data
>>>>> conversion applied underneath the buffer level so that one can't get a
>>>>> clear view of the raw data.
>>>>>
>>>>> As an example, the design means that Unix `cat` can't be faithfully
>>>>> implemented in Windows using only standard C or C++, which IMO is
>>>>> extreme.
>>>>
>>>>I assume you are talking about the cases where cat defaults to reading
>>>>stdin and/or writing stdout, If so, it could be argued that it's not the
>>>>fault of the C and C++ standards, but more the fault of the
>>>>implementations not providing a useful freopen function.
>>>
>>> I see no reason why cat would need freopen because it probably uses low level
>>
>>> I/O anyway and doesn't care where its stdin is coming from if it has to read
>>> from it.
>>
>>"Low level I/O" is not part of standard C, nor (as far as I know)
>
> So? Very little is part of standard C if you want to be pedantic and all *nix's
> implement open(), read(), write() etc. Unless you thought I meant something 
> else by low level.

Why are you asking me?  Ask Alf why he thinks it matters!  He brought it
up, I just bought up the standard C "solution".

-- 
Ben.

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

#82883

On 1/30/2022 9:18 AM, Alf P. Steinbach wrote:
> In some cases the fiction about what's allowed is imperfectly 
> implemented. I remember in the 1990's (when I still worked) I had some 
> fun demonstrating to colleagues how to completely and utterly hide some 
> data on disk, using commands like

Nice trick!

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

#82889

On 1/30/2022 12:18 AM, Alf P. Steinbach wrote:
> 
> This is just a bug in cmd.exe where it fails to check that the file name 
> is "allowed" for ordinary users, so one is able to specify an internal 
> NTFS stream. :-)
> 

But... How is it a bug? Command-line stream access syntax is documented 
by Microsoft.

Or do you think that "ordinary users" should not be allowed to access 
with NTFS streams? If so, why?

-- 
Best regards,
Andrey Tarasevich

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

#82891

On 31 Jan 2022 19:10, Andrey Tarasevich wrote:
> On 1/30/2022 12:18 AM, Alf P. Steinbach wrote:
>>
>> This is just a bug in cmd.exe where it fails to check that the file 
>> name is "allowed" for ordinary users, so one is able to specify an 
>> internal NTFS stream. :-)
>>
> 
> But... How is it a bug? Command-line stream access syntax is documented 
> by Microsoft.
> 
> Or do you think that "ordinary users" should not be allowed to access 
> with NTFS streams? If so, why?

The forward slash support at the API level is also documented by 
Microsoft. <url: 
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea#parameters>

But the Windows user interface in general does not permit forward slash 
as path component separators, and in general it does not permit naming 
of NTFS streams.


[C:\root\temp]
 > type poem.txt:secret
The filename, directory name, or volume label syntax is incorrect.


Which is the reason why I didn't use the `type` command for display.

Since this is inconsistent with the redirection operators in the same 
command interpreter, there is necessarily a bug /somewhere/. It could be 
that all the places that refuse such names are the ones that are buggy, 
and the redirection operators are the ones that have correct filename 
checking. Or it could be that the two single instances of allowing this 
pattern are the buggy ones, and all the rest correct, as per intent.

You're right, however, that when I wrote that it was the redirection 
operators, "this", I couldn't know that with more than 99.999983% 
confidence, but on the third hand, adding weasel language just for that 
very remote possibility would be IMHO be absurd. ;-)

- Alf

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

#82869

Am 29.01.22 um 16:39 schrieb Paavo Helde:
> Nowadays even Notepad has learned to cope with LF linebreaks, so there 
> is essentially no reason any more to use CRLF anywhere at all. As it has 
> happened with utf-8, Microsoft will be finally enforced to give up its 
> stubbornness and join the sane world.

I would wonder if this ever happens.
But many implemetations are tolerant to different line end encodings.

> The whole notion of "text files" is seriously out of date. What's the 
> point of having the file content in memory differ from the content on 
> disk? Especially considering memory mapping, HTTP packets, cloud storage 
> etc.

In HTTP LF w/o CR is not officially supported. ;-)

> I predict the same will happen with backslashes as well, but this might 
> take another 20 years. All the backslash madness in Windows is about to 
> avoid typing a single space after the command name, it's about time to 
> get rid of this.

ntosknrl as well as its predecessor os2knrl can deal with '/' as path 
separator for a long time too. Basically the same as with line ending: 
they are tolerant.
But the command line parsers of may programs can not handle this since 
the use '/' as escape character to denote an option. This makes the use 
of forward slash unhandy.

And although UTF-8 is quite common nowadays it raises several problems 
in certain situations. E.g. database fields with restricted length 
accept different string lengths depending on the number of characters 
with longer UTF-8 encoding used. No user will ever understand this.
In Chinese and several other "non-ASCII" languages the UTF-8 encoding is 
furthermore less compact that UCS2. So the encoding issues will persist too.
And well the fact that on Unix-like OSes file names are just binary 
blobs rather than a string with a known encoding raises further problems.


Marcel

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

#82871

30.01.2022 13:09 Marcel Mueller kirjutas:
> 
> In HTTP LF w/o CR is not officially supported. ;-)

Fixed encoding is better than random encoding. In HTTP headers one must 
indeed use CR LF. But the (text) files themselves are sent as HTTP 
bodies and there is zero reason to convert them to some other 
representation than they have on the server disk.

> 
>> I predict the same will happen with backslashes as well, but this 
>> might take another 20 years. All the backslash madness in Windows is 
>> about to avoid typing a single space after the command name, it's 
>> about time to get rid of this.
> 
> ntosknrl as well as its predecessor os2knrl can deal with '/' as path 
> separator for a long time too. Basically the same as with line ending: 
> they are tolerant.
> But the command line parsers of may programs can not handle this since 
> the use '/' as escape character to denote an option. This makes the use 
> of forward slash unhandy.

The slash can be still used as an option, there is no need to change 
that. One just needs to start to demand to separate options by spaces, 
something what a sane person has always done anyway, so that

dir C:/B

would list the file B in the root folder and

dir C: /B

would list all files in cwd of C: in bare format.

> 
> And although UTF-8 is quite common nowadays it raises several problems 
> in certain situations. E.g. database fields with restricted length 
> accept different string lengths depending on the number of characters 
> with longer UTF-8 encoding used. No user will ever understand this.

In real world UCS-2 is rarely used. Windows SDK, Java et al are using 
UTF-16, which has the same string length problem. And UCS-4 is 
definitely wasting space.

> In Chinese and several other "non-ASCII" languages the UTF-8 encoding is 
> furthermore less compact that UCS2.

I have heard this claim is not supported by actual data. In real usage 
Chinese is most often heavily interspersed with punctuation, numbers and 
English keywords so that there is little or no benefit in using UCS2 
over UTF-8.

> And well the fact that on Unix-like OSes file names are just binary 
> blobs rather than a string with a known encoding raises further problems.

This has actually helped to standardize them all to UTF-8 in practice.

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

#82873

On 1/30/22 7:26 AM, Paavo Helde wrote:

> The slash can be still used as an option, there is no need to change 
> that. One just needs to start to demand to separate options by spaces, 
> something what a sane person has always done anyway, so that
> 
> dir C:/B
> 
> would list the file B in the root folder and
> 
> dir C: /B
> 
> would list all files in cwd of C: in bare format.
> 

and what should dir /B do?

Both path and options are optional.


When it was decided to use / as the options separator, it essentially 
forced the use of some other character for the directory separator in 
that context.

In hindsight, maybe it was the wrong choice, but that was a LONG time ago.

But remember, at that point in time filenames were 8.3 ASCII only, with 
limited special characters. Using - in the file name as a 'word' 
separator wasn't uncommon, so - was an allowed filename character, so 
not good for the option leadin character, that would make dir -B 
ambiguous, so using / made some sense.

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

#82875

30.01.2022 15:59 Richard Damon kirjutas:
> On 1/30/22 7:26 AM, Paavo Helde wrote:
> 
>> The slash can be still used as an option, there is no need to change 
>> that. One just needs to start to demand to separate options by spaces, 
>> something what a sane person has always done anyway, so that
>>
>> dir C:/B
>>
>> would list the file B in the root folder and
>>
>> dir C: /B
>>
>> would list all files in cwd of C: in bare format.
>>
> 
> and what should dir /B do?

In 'dir /B', /B would be an option. To specify a file, one would need to 
use 'dir C:/B' for example. That's the same as needing to use special 
syntax like 'ls ./-filename' in Unix for filenames starting with a dash.

> 
> Both path and options are optional.
> 
> 
> When it was decided to use / as the options separator, it essentially 
> forced the use of some other character for the directory separator in 
> that context.

IIRC, / as the option separator came from an OS (CP/M?) which did not 
support subdirectories, so there was no problem at that point.

> 
> In hindsight, maybe it was the wrong choice, but that was a LONG time ago.
> 
> But remember, at that point in time filenames were 8.3 ASCII only, with 
> limited special characters. Using - in the file name as a 'word' 
> separator wasn't uncommon, so - was an allowed filename character, so 
> not good for the option leadin character, that would make dir -B 
> ambiguous, so using / made some sense.

Even though '-' is allowed in file names, I believe there has never been 
many people wanting to *start* their filenames with it.

Also, '-' is allowed in Unix file names as well, and they can somehow 
cope with this, see the ./-filename example above.

Of course it is hard to foresee all future implications of current 
decisions. But when it becomes clear some decision was wrong, it should 
be corrected, with some gradual switch-over period if needed. For 
example, the Windows Explorer and standard file dialogs could easily 
have a regime to display file paths with forward slashes. This would 
make my life a bit easier, for copy-pasting file paths from-to Cygwin 
bash terminal or program code. I also keep hearing Windows has a Linux 
inside nowadays, I am sure it is also using forward slashes.

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

#82876

On 1/30/22 11:21 AM, Paavo Helde wrote:
> 30.01.2022 15:59 Richard Damon kirjutas:
>> On 1/30/22 7:26 AM, Paavo Helde wrote:
>>
>>> The slash can be still used as an option, there is no need to change 
>>> that. One just needs to start to demand to separate options by 
>>> spaces, something what a sane person has always done anyway, so that
>>>
>>> dir C:/B
>>>
>>> would list the file B in the root folder and
>>>
>>> dir C: /B
>>>
>>> would list all files in cwd of C: in bare format.
>>>
>>
>> and what should dir /B do?
> 
> In 'dir /B', /B would be an option. To specify a file, one would need to 
> use 'dir C:/B' for example. That's the same as needing to use special 
> syntax like 'ls ./-filename' in Unix for filenames starting with a dash.

But that isn't the same!!!

It might need to be dir A:/B or dir B:/B or D:/D, the omission of the 
drive is an intentional feature.

> 
>>
>> Both path and options are optional.
>>
>>
>> When it was decided to use / as the options separator, it essentially 
>> forced the use of some other character for the directory separator in 
>> that context.
> 
> IIRC, / as the option separator came from an OS (CP/M?) which did not 
> support subdirectories, so there was no problem at that point.

Right, and backwards compatibility can be a bitch.

I thought CP/M did eventually add sub-directories as file system got 
bigger, they just weren't that needed initially on the small 8" floppy 
with only 1/4 MB of storage.

Also, when CP/M started, Unix was a small niche OS so compatibility with 
it wasn't that important, at that time there were LOTS of different and 
incompatible systems in use.

> 
>>
>> In hindsight, maybe it was the wrong choice, but that was a LONG time 
>> ago.
>>
>> But remember, at that point in time filenames were 8.3 ASCII only, 
>> with limited special characters. Using - in the file name as a 'word' 
>> separator wasn't uncommon, so - was an allowed filename character, so 
>> not good for the option leadin character, that would make dir -B 
>> ambiguous, so using / made some sense.
> 
> Even though '-' is allowed in file names, I believe there has never been 
> many people wanting to *start* their filenames with it.

It was a common character to put things at the top of the alphabetical 
sort list. -README.TXT was at one point a very common file name.

> 
> Also, '-' is allowed in Unix file names as well, and they can somehow 
> cope with this, see the ./-filename example above.

Yes, and ./ always works to indicate a file in the current directory 
(but does normally kill path lookups if applicable for the file), the 
problem is adding C: as a prefix doesn't always work, and definitely 
wouldn't on the early systems, it would have more likely have been A: 
then (but might have been B:)

> 
> Of course it is hard to foresee all future implications of current 
> decisions. But when it becomes clear some decision was wrong, it should 
> be corrected, with some gradual switch-over period if needed. For 
> example, the Windows Explorer and standard file dialogs could easily 
> have a regime to display file paths with forward slashes. This would 
> make my life a bit easier, for copy-pasting file paths from-to Cygwin 
> bash terminal or program code. I also keep hearing Windows has a Linux 
> inside nowadays, I am sure it is also using forward slashes.

Note, that operation system itself supports using either / or \ as the 
path separator, and I thought there was even an system option (just not 
set by default) to change the option character from / to -, so you CAN 
do what you want, it just isn't that way be default.

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

#82963

On 30/01/2022 17:56, Richard Damon wrote:
> Right, and backwards compatibility can be a bitch.
> 
> I thought CP/M did eventually add sub-directories as file system got 
> bigger, they just weren't that needed initially on the small 8" floppy 
> with only 1/4 MB of storage.
> 
> Also, when CP/M started, Unix was a small niche OS so compatibility with 
> it wasn't that important, at that time there were LOTS of different and 
> incompatible systems in use.

I don't think CP/M ever supported directories.

It evolved into Concurrent DOS, and that supported MS's FAT filesystem. 
It may have supported others, but it's a long time ago...

Wiki tells me it evolved further after I went in a different direction.

Andy

[toc] | [prev] | [standalone]

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

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

csiph-web