[haiku-commits] Re: haiku: hrev52133 - src/apps/mediaconverter

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Thu, 26 Jul 2018 11:26:21 +0200

Hi,

Am 25.07.2018 um 22:16 schrieb Dario Casalinuovo:

On Wed, Jul 25, 2018 at 10:06 PM Adrien Destugues <pulkomandy@xxxxxxxxxxxxx <mailto:pulkomandy@xxxxxxxxxxxxx>> wrote:

    On Wed, Jul 25, 2018 at 09:38:11PM +0200, Stephan Aßmus wrote:
     > Hi,
     >
     > Am 25.07.2018 um 18:37 schrieb Adrien Destugues:
     > > On Wed, Jul 25, 2018 at 06:06:48PM +0200, Dario Casalinuovo wrote:
     > > > In any case I expect people to review correctly, in this case
    it seems 3
     > > > devs accepted code they didn't understand.
     > >
     > > Using Clear instead of memset seems fine, so that particular
    patch is
     > > right in the current context. How we implement Clear - or
    wether it is
     > > needed at all - should have been fixed earlier already.
     > >
     > > The previous patch where the problem lies is
     > > https://review.haiku-os.org/#/c/haiku/+/215/ . I simply missed
    the fact
     > > that Clear() was just a memset, which of course still isn't
    appropriate
     > > even if hidden in a method. No one is perfect, and there were
    just 2
     > > devs (not 3) reviewing it.
     >
     > But media_format contains only POD fields, and it is a nested
    union, meaning
     > the same memory would be initialized more than once if done field
    by field.
     > All the fields are arranged in that way, that a value of "0" means
     > uninitialized. Also, POD fields are not initialized in a
    constructor by the
     > compiler, that's why it needed to happen manually. Some part of
    the patch
     > re-used media_format instances in a loop and needed to reset
    them, hence the
     > use of memset() and now Clear(). So why, exactly, is using
    memset() not
     > correct? Is it because media_format /may/ be extended with
    non-POD fields in
     > the future? Is it because on some CPU architecture "0" may not
    mean 0 for
     > some data types? I don't get it. Also, the whole reasoning why
    the patch is
     > supposedly bad is only given now. Before it was just being called
    "shit"
     > with no actual reason given.

    Right, the constructor is responsible for initializing things, and the
    struct will be cleared to 0 only in the cases where it would have in C:
    when allocating with new() or as a global. But not when used on the
    stack. Hence the constructor memsetting itself.


Again media_format is non-POD.

Can you please elaborate? I am aware you said "memset, can be problematic with non PODs ..."

You did /not/ say media_format ist not a POD type. Above you said it in general terms, and that is something I already know. To make it clear: Until now, I was thinking that media_format is effectively a POD type, because it only consists of POD fields. And you yourself say "but from a fast check the other day it seems we may be safe to do it in ctor." So you would be contradicting yourself that still using memset() is "shit". Is there a problem with using memset() or not? Or to phrase it more precisely: Does memset() do anything else besides setting all the POD fields to 0? If so, what is it?


Absolutely not! Do not memset unions, if you want to follow the C++ standard.
Reasons in the above post.

No, you didn't give any. Please do. Feel free to give an URL. When I try to google this, I can find nothing that memset() on a struct or union with only POD fields would do something unexpected. On some non-mainstream architectures, NULL pointers may not actually have the value 0 in all their bytes, and floating point types may not represent "0.0" with 0 in all bytes. I already mentioned that, but nobody replied to it. It is not relevant here unless we plan to support non-mainstream architectures eventually. So... anything other than that?

Best regards,
-Stephan



Other related posts: