Friday, February 2, 2018

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

"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Feb 01 06:20PM -0800

> On Thursday, February 1, 2018 at 1:59:17 PM UTC-6, Chris M. Thomasson wrote:
 
> Please don't $wear here.
 
I slightly obfuscated the swear word.
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Feb 01 06:24PM -0800

On 2/1/2018 12:55 PM, Alf P. Steinbach wrote:
 
> Andrey evidently posted to the wrong group. He should have posted to
> comp.lang.c.
 
> Disclaimer: I haven't looked at the linked-to article.
 
Fwiw, C aside for a moment, the massive error is the use of a pointer
returned from malloc without checking it for NULL.
"Öö Tiib" <ootiib@hot.ee>: Feb 02 01:57AM -0800

On Friday, 2 February 2018 04:24:14 UTC+2, Chris M. Thomasson wrote:
 
> > Disclaimer: I haven't looked at the linked-to article.
 
> Fwiw, C aside for a moment, the massive error is the use of a pointer
> returned from malloc without checking it for NULL.
 
Karpov just wants to promote his tool and so writes such nausea
and does not care nor understand that incorrect usages of strdup
in some C code isn't topical here.
 
Arrogance and ignorance of author do not make his tool to look better
and so it is most likely unpopular.
David Brown <david.brown@hesbynett.no>: Feb 02 12:42PM +0100

On 01/02/18 20:59, Chris M. Thomasson wrote:
> }
> __________________
 
> Sorry buddy, but you are fired!
 
I presume your complaint is about using malloc in a C++ program? And
compounding that with a missing cast.
 
Certainly it is not /necessarily/ a problem that the return from malloc
is not checked. Rules about always checking for error returns are like
pretty much every other "absolute" rule - it's an excuse for not thinking.
Manfred <noname@invalid.add>: Feb 02 01:31PM +0100

On 2/2/2018 12:42 PM, David Brown wrote:
 
> Certainly it is not /necessarily/ a problem that the return from malloc
> is not checked. Rules about always checking for error returns are like
> pretty much every other "absolute" rule - it's an excuse for not thinking.
 
Still this is off-topic in a C++ newsgroup.
Constructs like
void *myPointer = foo();
if(myPointer == NULL) {
log("something");
exit(EXIT_FAILURE);
}
 
are ubiquitous in C code, but this is one major reason for which Bjarne
introduced exceptions in C++.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 02 08:16AM -0500

On 2/2/2018 4:57 AM, Öö Tiib wrote:
> Karpov just wants to promote his tool...
 
I agree. I know my posts teaching about Jesus Christ bother
people, but Karpov's posts are thinly veiled "Hey, come buy
my software" posts.
 
I find that kind of for-money solicitation quite offensive.
 
--
Thank you! | Indianapolis, Indiana | God is love -- 1 John 4:7-9
Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj
-------------------------------------------------------------------------
Software: LSA, LSC, Debi, RDC/CAlive, ES/1, ES/2, VJr, VFrP, Logician
Hardware: Arxoda Desktop CPU, Arxita Embedded CPU, Arlina Compute FPGA
David Brown <david.brown@hesbynett.no>: Feb 02 02:52PM +0100

On 02/02/18 14:16, Rick C. Hodgin wrote:
 
> I agree. I know my posts teaching about Jesus Christ bother
> people, but Karpov's posts are thinly veiled "Hey, come buy
> my software" posts.
 
His tool is on-topic, being C++ (except when he accidentally talks about
C). It is also available without cost in certain circumstances, and
some of his blog posts can be instructive. And he has been know at
least occasionally to read replies here and enter discussions.
 
So his posts are spam, but not the worst kind of spam. If he were to
take a more active part in discussions here, it would be positive.
(Compare with Mr. Flibble - he talks a lot about neoGFX, which he plans
to sell for money - but in c.l.c++ he talks mainly about the C++ aspects
and leads to interesting discussions, and does not push the sales
aspect. Karpov could learn from that.)
 
> I find that kind of for-money solicitation quite offensive.
 
Your religious solicitations are at least as offensive. If there is the
slightest vein of truth in what you write, the prices being asked and
the prizes offered are worth more than any money - and therefore the
spam is worse than mere commercial postings.
"James R. Kuyper" <jameskuyper@verizon.net>: Feb 02 09:09AM -0500

On 02/02/2018 06:42 AM, David Brown wrote:
 
>> Sorry buddy, but you are fired!
 
> I presume your complaint is about using malloc in a C++ program? And
> compounding that with a missing cast.
 
Using malloc in a C++ program is a poor choice. The missing cast makes
the program ill-formed in C++. However, the failure to check whether r
is null before dereferencing could result in undefined behavior - that's
the firing offense.
 
> Certainly it is not /necessarily/ a problem that the return from malloc
> is not checked. ...
 
Yes, it is necessarily a problem. Any particular return from malloc()
might be the one that will fail, no matter how small it is, and the
potential consequences have no upper limit on how severe they can be.
 
> ... Rules about always checking for error returns are like
> pretty much every other "absolute" rule - it's an excuse for not thinking.
 
Rules intended to avoid the execution of code with undefined behavior
(unless portability of the code is intentionally restricted to contexts
where something other than the C++ standard provides its own definition
for the behavior) are entirely appropriate - "not thinking" about the
consequences is the only excuse for ignoring such rules.
Is there anything that your computer could be programmed do, that you
wouldn't want it to do? Think about the worst such thing - that's one of
the permitted consequences of executing code with undefined behavior.
How far would you be willing to go to prevent that worst case from
happening? That's how far you should go to avoid executing code with
undefined behavior.
"Öö Tiib" <ootiib@hot.ee>: Feb 02 06:16AM -0800

On Friday, 2 February 2018 13:43:07 UTC+2, David Brown wrote:
 
> Certainly it is not /necessarily/ a problem that the return from malloc
> is not checked. Rules about always checking for error returns are like
> pretty much every other "absolute" rule - it's an excuse for not thinking.
 
You mean in situations like that:
* the null pointer access causes guaranteed SIGSEGV on platform
* all checks of failed malloc would do same what SIGSEGV handler does
Or that:
* the platform never fails malloc but instead kills processes with OOM reaper
These feel quite close to most common situations. ;)
David Brown <david.brown@hesbynett.no>: Feb 02 04:23PM +0100

On 02/02/18 15:09, James R. Kuyper wrote:
 
> Yes, it is necessarily a problem. Any particular return from malloc()
> might be the one that will fail, no matter how small it is, and the
> potential consequences have no upper limit on how severe they can be.
 
That is three statements, all of which are incorrect.
 
No, malloc will not necessarily have a possibility of failing -
certainly not if you think in terms of /realistic/ possibilities. If
you run your program on your 8 GB Linux desktop, and it asks for 100 KB
from malloc, it will /not/ fail. There is /no/ realistic chance of it
failing. You would be better worrying about a lightening strike
blasting the PC to bits than worrying about the malloc failing.
 
There is a wide range of programs in which a malloc can reasonably be
expected to fail - but there is also a wide range of circumstances in
which it cannot.
 
Next, there most certainly /can/ be upper limits on the potential
consequences of a failure. These will be highly dependent on the code
in question, the compiler, the OS, etc. But if we again take the
example code above and assume it is running on a reasonably modern Linux
or Windows system, then the consequences will be clear - you will get a
segmentation fault when trying to write to address 0 (or slightly higher
than 0). In some use-cases, that is absolutely fine - having the
program exit in a controlled manner on a critical failure is often
entirely reasonable.
 
You can also consider embedded systems with more specialised libraries
in which there is no way for malloc to return 0 because the system
restarts the whole device rather than return a failure. Or perhaps you
know it can never return 0 because you have calculated the total
malloc'ed allocations you need, and are sure that you have enough heap
space (this is, in fact, extremely common in small embedded systems
where the possibility of a malloc failure is not acceptable as part of
the design - and since it is eliminated by the development process, it
does not need to be checked at run-time).
 
Checking for error results is not free. It takes thought, and lines of
code. It disrupts the flow of the code. It is often difficult or
impossible to test in a sensible manner. Obsessions about "always check
this" lead to poorly considered, poorly documented and poorly tested
error handling that is not necessarily any better than /no/ error
checking. Is an "exit(1)" call /really/ better than a segmentation
fault? Maybe - maybe not. Is passing the null pointer back to the
caller any better? Maybe, maybe not.
 
 
In the particular case of malloc, I fully accept that it is /usually/
important to check the result - the costs are low, and the consequences
of missing a null pointer return are usually substantial. This
particular case was (apparently) from Chrome - a program that will grab
so much memory that it is entirely realistic for malloc to fail. My
point is that this is not always the case, and knee-jerk checks on
malloc returns are not an excuse for not thinking things through.
 
 
> where something other than the C++ standard provides its own definition
> for the behavior) are entirely appropriate - "not thinking" about the
> consequences is the only excuse for ignoring such rules.
 
There is a critical difference between avoiding the execution of
undefined behaviour (which is something all code should strive for), and
following rules "intended to avoid the execution of code with undefined
behaviour".
 
> How far would you be willing to go to prevent that worst case from
> happening? That's how far you should go to avoid executing code with
> undefined behavior.
 
I agree with that.
 
But I do /not/ agree that using malloc without checking the return for 0
is necessarily a risk of executing code with undefined behaviour.
David Brown <david.brown@hesbynett.no>: Feb 02 04:26PM +0100

On 02/02/18 15:16, Öö Tiib wrote:
> Or that:
> * the platform never fails malloc but instead kills processes with OOM reaper
> These feel quite close to most common situations. ;)
 
If your code is used in such situations, then yes, that would be valid
reasons for /not/ checking the return of malloc.
 
(I think it goes without saying that such assumptions need to be
documented, and if possible statically checked.)
"James R. Kuyper" <jameskuyper@verizon.net>: Feb 02 11:06AM -0500

On 02/02/2018 10:23 AM, David Brown wrote:
> On 02/02/18 15:09, James R. Kuyper wrote:
...
> where the possibility of a malloc failure is not acceptable as part of
> the design - and since it is eliminated by the development process, it
> does not need to be checked at run-time).
 
If you can afford to restrict the portability of your programs to
systems that provide particular definitions for behavior that is
undefined by the C standard, it's perfectly fine to rely upon those
definitions - but you should remember that the code is non-portable.
 
Just because there's no possibility of your 100KB allocation failing on
your Linux system, doesn't mean that the same is true of other systems.
On some systems, the fact that something else running at the same time
has already used up all but 50KB of the available memory will not only
allow, but guarantee, that your 100KB allocation will fail.
 
The same implementation-dependence applies to writing to memory at
location 0. If your code only needs to be portable to systems that
guarantee that writing through a null pointer will do nothing worse than
abort your program, then you are indeed entitled to rely upon that
guarantee.
Paavo Helde <myfirstname@osa.pri.ee>: Feb 02 06:19PM +0200

On 2.02.2018 17:23, David Brown wrote:
> from malloc, it will /not/ fail. There is /no/ realistic chance of it
> failing. You would be better worrying about a lightening strike
> blasting the PC to bits than worrying about the malloc failing.
 
On Linux this might even hold as the offending memory eaters are killed
by the kernel. On Windows however I have seen it happen several times -
one program (typically mine, but that's besides the point) consumes up
all the memory and then random other processes start crashing as they
have been written with exactly this assumption that a 100 byte malloc
will never fail.
scott@slp53.sl.home (Scott Lurndal): Feb 02 05:10PM


> If
>you run your program on your 8 GB Linux desktop, and it asks for 100 KB
>from malloc, it will /not/ fail.
 
That's entirely a function of the workload on the desktop and
the memory requirements of the set of running applications vice
the available DRAM + swap resources.
 
I've seen it happen, and recently.
red floyd <dont.bother@its.invalid>: Feb 02 09:55AM -0800

> Please don't $wear here.
 
Go fuck yourself and your holier-than-thou attitude.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 02 01:12PM -0500

On 2/2/2018 12:55 PM, red floyd wrote:
> On 2/1/2018 3:21 PM, woodbrian77@gmail.com wrote:
>> Please don't $wear here.
 
> Go .. yourself and your holier-than-thou attitude.
 
It's not "holier-than-thou," red floyd. It's decency. It's common
respect for your fellow man. It's meeting people where they are and
placing them above yourself, recognizing that their natural demeanor
and ways may be different than your own.
 
You are very forceful in your attacks on people. You're not supposed
to be that way. It's not a holier-than-thou attitude, but it is the
one taught to us by God. He teaches us to love one another as we do
ourselves.
 
Do you not love yourself to treat others that way?
 
--
Thank you! | Indianapolis, Indiana | God is love -- 1 John 4:7-9
Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj
-------------------------------------------------------------------------
Software: LSA, LSC, Debi, RDC/CAlive, ES/1, ES/2, VJr, VFrP, Logician
Hardware: Arxoda Desktop CPU, Arxita Embedded CPU, Arlina Compute FPGA
Geoff <geoff@invalid.invalid>: Feb 02 10:21AM -0800

On Thu, 1 Feb 2018 11:59:01 -0800, "Chris M. Thomasson"
>}
>__________________
 
>Sorry buddy, but you are fired!
 
Chris M. Thomasson gets points for actually bothering to read the
blog.
 
If anyone had even casually read the blog and followed the references
they would know this particular example exists in
/yasm/tools/re2c/substr.h, lines 48-55 of the yasm project code, the
source of which is available on GitHub and http://yasm.tortall.net/
YASM is a re-write of NASM. This function definition does not exist in
NASM.
 
Yasm is written in C. The Chromium project apparently depends on it
which is why it's cited as a warning in the PVS-Studio output. That
the Chromium project would include and depend on libraries with bugs
like this is somewhat concerning but the yasm code never uses or
refers to this particular function and there is no evidence to support
any belief that Chromium would call it directly.
 
Karpov's error is to state:
 
"Yes, in Chromium itself these functions are not used almost anywhere.
In Chromium only containers or operator new are applied. However, once
there are errors in the libraries, then, we can say that they are in
Chromium. Of course, some parts of the libraries may not be used when
running Chromium, but it is difficult and unnecessary to define it. It
is necessary to correct all errors anyway."
 
This is the job of the yasm maintainers, not of Chromium.
 
Does this invalidate the argument that use of a tool like PVS-Studio
is invalid?
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Feb 02 11:54AM -0800

On 2/1/2018 6:24 PM, Chris M. Thomasson wrote:
 
>> Disclaimer: I haven't looked at the linked-to article.
 
> Fwiw, C aside for a moment, the massive error is the use of a pointer
> returned from malloc without checking it for NULL.
 
Argh! I should say even if the returned pointer passes the NULL check,
well, the size used for the malloc better not be zero! Afaict, you
should not store anything in a location pointed to by a non-null pointer
returned from malloc(0).
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Feb 02 12:00PM -0800

On 2/2/2018 4:31 AM, Manfred wrote:
> }
 
> are ubiquitous in C code, but this is one major reason for which Bjarne
> introduced exceptions in C++.
 
C++ is a very nice tool to have in the box! :^)
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Feb 02 12:27PM -0800

On 2/2/2018 10:12 AM, Rick C. Hodgin wrote:
 
>> Go .. yourself and your holier-than-thou attitude.
 
> It's not "holier-than-thou," red floyd.  It's decency.  It's common
> respect for your fellow man.
 
Perhaps when I swear on here, it should look like Q-Bert is talking.
 
Ah ?$%?!
 
https://youtu.be/0yrhee8W7II?t=8
 
;^)
 
 
David Brown <david.brown@hesbynett.no>: Feb 02 10:23PM +0100

On 02/02/18 18:10, Scott Lurndal wrote:
 
> That's entirely a function of the workload on the desktop and
> the memory requirements of the set of running applications vice
> the available DRAM + swap resources.
 
Of course it is. My point is not that I think malloc never fails, or it
is a good idea to write code that assumes it can't fail and then let
that same code be used again in a different system. I just want to
point out that sometimes /not/ checking the result of malloc is
perfectly reasonable coding - indeed, it can be a /better/ choice than
testing it. Such cases are rare - of that there is no doubt. But they
do exist.
 
In my own programming, I rarely use malloc - and I /never/ use it in a
case where it might fail.
 
David Brown <david.brown@hesbynett.no>: Feb 02 10:24PM +0100

On 02/02/18 20:44, Stefan Ram wrote:
> one never knows whether there is enough memory for
> another function incarnation. And these languages do
> not even provide any means to learn this at runtime.
 
In my embedded systems, I /always/ know there is enough memory for the
function call.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 02 09:16PM

If God is able microwave a burrito so that it is too hot even for God to
eat then surely God isn't omnipotent as the burrito is too hot even for
God to eat.
 
God is a category error.
 
--
 
Thank you,
Rick C. Hodgin
ram@zedat.fu-berlin.de (Stefan Ram): Feb 02 05:58PM

>the program ill-formed in C++. However, the failure to check whether r
>is null before dereferencing could result in undefined behavior - that's
>the firing offense.
 
I make a difference between (at least) /two/ requirement types:
 
1. "sunshine code"
 
This is supposed to work as long as the weather is fine.
 
Say, one is in a competition and needs to decode a file,
so one needs a buffer for the file, and one uses malloc
to allocate it (assuming the program is being written in C).
 
One does not check the result of malloc directly, but
one obtains results that make sense. There is little
additional advantage in checking the result of malloc
here, as time to write the code is precious since the
competition has a near deadline. Time is so precious
that one does even not write a proper documentation
and user's manual for one's code.
 
The competition will only judge whether one's results
are correct, they will not judge the quality of one's
code.
 
2. "library-grade code"
 
This is code that will or might end up in a library
where it is called under unknown circumstances. It needs
to fulfill the contract from its documentation.
 
Here we need to check all attempts to obtain a resource
and supply reasonable code for both possibilities
(success and failure).
 
In C++, of course, the library also needs to fulfill
the guarantees that its documentation gives about
exception safety.
 
Of course, documentation is of utmost importance here.
A library function that might show undefined behavior
at will sometimes might even be deemed "library-grade"
as long as its documentation clearly says so.
 
As others have observed long ago, under many operating
systems which use an external device to swap memory, one
never actually sees malloc returning 0 (when the size is not
too large), but one sees his whole system getting slower and
slower up to the point where it does not even react to user
actions anymore at all in a reasonable amount of time.
ram@zedat.fu-berlin.de (Stefan Ram): Feb 02 07:44PM

>Here we need to check all attempts to obtain a resource
>and supply reasonable code for both possibilities
>(success and failure).
 
And then, there is the elephant in the room:
 
Whenever one calls a function in either C or C++,
one never knows whether there is enough memory for
another function incarnation. And these languages do
not even provide any means to learn this at runtime.
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)