Tuesday, December 20, 2022

Digest for comp.lang.c++@googlegroups.com - 12 updates in 3 topics

Andrey Tarasevich <andreytarasevich@hotmail.com>: Dec 20 12:46PM -0800

On 12/18/2022 12:00 PM, Roman P wrote:
> 1) What happens when you divide an int variable by 0?
> 2) What happens when you divide a double variable by 0?
 
Undefined behavior.
 
Nevertheless: what does "divide" mean in this context? There's more than
one way to perform arithmetic division in C and C++.
 
> 3) What happens when you overflow an int variable, that is, set it to a
> value beyond its range?
 
"Set"? What does "set" mean in this context?
 
Behavior of variables in out-of-range situations depends critically on
_how_ you attempt to produce an out-of-range value in it. For example,
assignment is one thing, while side effect of `++` is a completely
different thing.
 
> 4) What is the difference between x = y++; and x = ++y;?
 
Quite possibly, none. There's no reason to believe this code has any
observable behavior.
 
> 6) What are the three parts of a for statement and which of them are
> required?
 
Even under superficial observation, for-statement has way more than
three parts.
 
> 8) Does the following statement compile?
 
> for ( ; ; ) ;
 
In C++: no way to say. An infinite loop that has no observable behavior
produces undefined behavior. Possible manifestations of undefined
behavior include failure to compile.
 
> 9) What does the underscore _ represent in a switch expression?
 
Nonsensical question. There's no such thing as "switch expression"
neither in C nor in C++.
 
--
Best regards,
Andrey
Paavo Helde <eesnimi@osa.pri.ee>: Dec 20 11:49PM +0200

20.12.2022 22:46 Andrey Tarasevich kirjutas:
 
>> 4) What is the difference between x = y++; and x = ++y;?
 
> Quite possibly, none. There's no reason to believe this code has any
> observable behavior.
 
I guess he got you there. The value of x is observable. Too well-defined
question?
Andrey Tarasevich <andreytarasevich@hotmail.com>: Dec 20 02:00PM -0800

On 12/20/2022 1:49 PM, Paavo Helde wrote:
>> observable behavior.
 
> I guess he got you there. The value of x is observable. Too well-defined
> question?
 
I don't know what you are trying to say by "the value of x is
observable", but let me reiterate: there's no reason to believe this
code has any observable behavior. (Feel free to look up the definition.)
Let alone the fact that in C++ it has no specific semantics at all.
 
--
Best regards,
Andrey
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 20 02:01PM -0800

On 12/18/2022 2:57 PM, Siri Cruise wrote:
 
>> Undefined behavior.
 
> https://www.youtube.com/watch?v=JOiZP8FS5Ww
 
> Saved by zero.
 
the null lines:
 
https://youtu.be/MC4yCPbdbT4
(lord of the null lines)
Paavo Helde <eesnimi@osa.pri.ee>: Dec 21 12:13AM +0200

21.12.2022 00:00 Andrey Tarasevich kirjutas:
> observable", but let me reiterate: there's no reason to believe this
> code has any observable behavior. (Feel free to look up the definition.)
> Let alone the fact that in C++ it has no specific semantics at all.
 
The questions were cross-posted to C so I'm assuming int.
 
#include <iostream>
 
void f1() {
int y = 0;
int x = y++;
std::cout << "x = " << x << "\n";
}
 
void f2() {
int y = 0;
int x = ++y;
std::cout << "x = " << x << "\n";
}
 
int main() {
f1();
f2();
}
 
Output:
 
x = 0
x = 1
 
Different enough?
Andrey Tarasevich <andreytarasevich@hotmail.com>: Dec 20 02:38PM -0800

On 12/20/2022 2:13 PM, Paavo Helde wrote:
 
> x = 0
> x = 1
 
> Different enough?
 
Oh, yes. Quite different. But this is really an answer to a different
question. Say
 
What is the difference between
 
int y = 0;
int x = y++;
std::cout << "x = " << x << "\n";
 
and
 
int y = 0;
int x = ++y;
std::cout << "x = " << x << "\n";
 
?
 
--
Best regards,
Andrey
Paavo Helde <eesnimi@osa.pri.ee>: Dec 20 08:29PM +0200


> Yet oddly at least 3 generations of unix devs have coped with abbreviated
> posix function names such as ioctl(), getuid(), uname() etc without struggling
> to understand the code. Not to mention standard C functions such as fopen().
 
I recall the authors of those names are generally happy with them,
except for one abbreviation: creat().
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Dec 20 10:30AM -0800

People are of course free to continue posting in this thread, but I
suggest that it's gone beyond the point where any further discussion
would be constructive. No new points have been made in some time, and
no minds will be changed.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
"daniel...@gmail.com" <danielaparker@gmail.com>: Dec 20 11:20AM -0800

On Tuesday, December 20, 2022 at 12:40:06 PM UTC-5, David Brown wrote:
 
> "auto" gives you the correct type because it is the type returned by the
> multiplication - that does not mean it is the type you really wanted for
> the code, or that following code uses it correctly.
 
???
 
Within intermediate calculations
 
(A + B + C) * D
 
yes, but the final result is intended to decay to a non-proxy type,
the proxy is intended to be hidden from the user. Much as
a std::vector<bool>::reference proxy is intended to decay to
a bool. auto defeats that.
 
> Surely if making a copy of a proxy is inappropriate, the proxy class
> should disallow copying?
 
Because of RVO, it's hard to defeat `auto x = foo()`.

My understanding is that the committee has discussed the 2017 paper
previously linked to, and concluded that there is no solution within current C++.
It would require a language change.
 
In the meantime, it would appear that the use of auto should be
approached with some caution in C++, more so than with var in other
languages.
 
Daniel
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Dec 20 10:43AM -0800

On Tuesday, December 20, 2022 at 6:13:59 PM UTC, Öö Tiib wrote:
 
> target of code injection attacks. That can be viewed as sabotage by whatever
> organisation you code for. So if you do it for yourself then you should be as
> harsh you only can with yourself. ;)
 
 
They can't include their own header files nor link with their own libraries so the damage they can do is limited to what can be achieved with the C++ standard library. So I just need to make a list of stuff to outlaw:
system,remove,ifstream,ofstream,etc.
And then devise a way to prevent these things from being accessed, perhaps by using preprocessor macroes.
Paavo Helde <eesnimi@osa.pri.ee>: Dec 20 08:56PM +0200

20.12.2022 20:01 Frederick Virchanza Gotham kirjutas:
 
> I've written a GUI program for desktop PC's that acts as a 'man in the middle', it intercepts traffic and modifies it before forwarding it.
 
> I was thinking it would be cool to allow the user to write some C++ code in a text box in my GUI application to describe a text filter,
 
> So then I would compile this translation unit to a dynamic shared library, e.g. "custom_filter.dll" on MS-Windows or "libcustom_filter.so" on Linux/Mac. Then I would load this library into my program using "LoadLibrary" or "dlopen". I would compile the library with "-fsanitize" to make sure it dies as soon as there's a memory access violation.
 
You only get memory access violation if the program attempts to write
into non-mapped memory. Nothing prevents it to just write over your own
vital data structures in your own program. Suggesting to run it as a
separate process, not as a shared library.
 
 
> So the question is how can I make it as safe as possible?
 
You don't need to do any anything. If this is a desktop app, only the
desktop user can enter code pieces, and they can delete their files or
format their drives easily without the help of your program. You just
need to take care the compiled code runs with the same privileges than
the user has.
 
If your program has a web interface and untrusted remote users can enter
code, you are screwed anyway. There is no way to sanitize or sandbox a
piece of general C++ code, so there is no point to bother. If you really
want to do this, compile and run the program in a short-living docker
container, or something like that.
"Öö Tiib" <ootiib@hot.ee>: Dec 20 11:03AM -0800

On Tuesday, 20 December 2022 at 20:43:51 UTC+2, Frederick Virchanza Gotham wrote:
> They can't include their own header files nor link with their own libraries so the damage they can do is limited to what can be achieved with the C++ standard library. So I just need to make a list of stuff to outlaw:
> system,remove,ifstream,ofstream,etc.
> And then devise a way to prevent these things from being accessed, perhaps by using preprocessor macroes.
 
Don't be naive. Windows metafile .wmf file is considered vector graphics
file that only IE does display. But Windows is actually treating its contents
as arguments to GDI API calls. Note, just arguments to graphic API. I
think after that the GDI dll was debugged by skyscraper of MS developers
and the flow of patches continued to this century. All kind of
attacks were possible just by victim clicking a link in IE under
Windows 2000 leading to page that did show "a .wmf picture" carefully
prepared.
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: