Monday, January 31, 2022

Digest for comp.lang.c++@googlegroups.com - 11 updates in 2 topics

Andrey Tarasevich <andreytarasevich@hotmail.com>: Jan 30 08:17PM -0800

On 1/30/2022 11:17 AM, James Kuyper wrote:
> answer mentioning any of the details that you just mentioned. I think
> she just said something about being able to figure out the intended
> meaning from context.
 
Depends on how advanced your classes were and how "old-school" your
teacher was. This is one of those intricate topics where, firstly, the
choice between Accusative and Genitive is not always clearly defined.
And secondly, modern users often tend to simplify the usage and just opt
for Accusative in all cases.
 
See for example
 
http://www.abc-russian.com/2016/09/or.html
 
or section "Russian Genitive Case: Abstract Or Indefinite Objects" here:
https://storylearning.com/learn/russian/russian-tips/russian-genitive-case
 
--
Best regards,
Andrey Tarasevich
Muttley@dastardlyhq.com: Jan 31 10:23AM

On Sun, 30 Jan 2022 12:12:33 +0000
>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. Other utilities (eg ls) otoh will use isatty() on stdout to see if
its connected to a terminal or a pipe/file and act accordingly (ls only formats
it output if its going to a terminal).
Manfred <noname@add.invalid>: Jan 31 04:45PM +0100

On 1/30/2022 9:18 AM, Alf P. Steinbach wrote:
> 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!
scott@slp53.sl.home (Scott Lurndal): Jan 31 04:11PM


>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) unless -v is specified, in which case it uses
getc(3).
 
int
cat(fi, fname)
FILE *fi;
char *fname;
{
register int fi_desc;
register int nitems;
 
fi_desc = fileno(fi);
 
/*
* While not end of file, copy blocks to stdout.
*/
 
while ((nitems=read(fi_desc,buffer,BUFSIZ)) > 0) {
if ((errnbr = write(1,buffer,(unsigned)nitems)) != nitems) {
 
...
 
vcat(fi)
FILE *fi;
{
register int c;
 
while ((c = getc(fi)) != EOF)
{
/*
* For non-printable and non-cntrl chars, use the "M-x" notation.
*/
if (!ISPRINT(c, wp) &&
!iscntrl(c) && !ISSET2(c) && !ISSET3(c))
{
putchar('M');
putchar('-');
c-= 0200;
}
...
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 31 04:12PM


> 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.
Muttley@dastardlyhq.com: Jan 31 04:36PM

On Mon, 31 Jan 2022 16:11:23 GMT
>>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
>FILE *fi;
>char *fname;
>{
 
Its been a while since I've seen K&R style C in the wild.
Muttley@dastardlyhq.com: Jan 31 04:39PM

On Mon, 31 Jan 2022 16:12:58 +0000
 
>> 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.
Andrey Tarasevich <andreytarasevich@hotmail.com>: Jan 31 10:10AM -0800

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
Paavo Helde <eesnimi@osa.pri.ee>: Jan 31 08:20PM +0200

31.01.2022 18:11 Scott Lurndal kirjutas:
> {
> 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... ;-)
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Jan 31 07:25PM +0100

On 31 Jan 2022 19:10, Andrey Tarasevich wrote:
> 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
olcott <NoOne@NoWhere.com>: Jan 31 11:15AM -0600

On 1/31/2022 11:05 AM, Mr Flibble wrote:
 
>> FAIL.
 
> You both need to be sectioned IMO. Give it a fucking rest.
 
> /Flibble
 
This is my lifetime legacy and the FLIPI index projects that I will die
by next December.
 
https://www.mdcalc.com/follicular-lymphoma-international-prognostic-index-flipi
 
Halting problem undecidability and infinitely nested simulation (V3)
 
https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3
 
 
 
 
--
Copyright 2021 Pete Olcott
 
Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer
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: