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

Groups > comp.lang.c++.moderated > #1364 > unrolled thread

codecvt problem

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

Contents

  codecvt problem  Rafał Moniuszko <rafal.lists@gmail.com> - 2011-06-05 07:25 -0600
    Re: codecvt problem Vaclav Haisman <v.haisman@sh.cvut.cz> - 2011-06-05 21:41 -0600
      Re: codecvt problem  Jeff Flinn <TriumphSprint2000@hotmail.com> - 2011-06-06 12:50 -0600
        Re: codecvt problem Vaclav Haisman <v.haisman@sh.cvut.cz> - 2011-06-06 15:31 -0600
          Re: codecvt problem  Martin Bonner <martinfrompi@yahoo.co.uk> - 2011-06-08 02:06 -0600
            Re: codecvt problem  Vaclav Haisman <v.haisman@sh.cvut.cz> - 2011-06-08 17:24 -0600
              Re: codecvt problem  Seungbeom Kim <musiphil@bawi.org> - 2011-06-09 07:02 -0600
                Re: codecvt problem Vaclav Haisman <v.haisman@sh.cvut.cz> - 2011-06-16 17:04 -0600
                  Re: codecvt problem Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2011-06-17 06:42 -0600
                    Re: codecvt problem Seungbeom Kim <musiphil@bawi.org> - 2011-06-18 07:38 -0600
                      Re: codecvt problem Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2011-06-20 13:16 -0600
                        Re: codecvt problem Seungbeom Kim <musiphil@bawi.org> - 2011-06-23 14:42 -0600
          Re: codecvt problem  Seungbeom Kim <musiphil@bawi.org> - 2011-06-09 07:01 -0600
        Re: codecvt problem Daniel Krügler <daniel.kruegler@googlemail.com> - 2011-06-06 15:31 -0600
          Re: codecvt problem Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2011-06-07 03:07 -0600
            Re: codecvt problem  Daniel Krügler <daniel.kruegler@googlemail.com> - 2011-06-07 10:31 -0600
    Re: codecvt problem  Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2011-06-06 12:47 -0600

#1364 — codecvt problem

{ Thought this seems trivial, I'm allowing it in the hope it raises
thoughtful responses. -mod/ddv }

When you compile and run code available here:
http://www.cplusplus.com/reference/std/locale/codecvt/out/, you get
following output from valgrind:

==9451== Memcheck, a memory error detector
==9451== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et
al.
==9451== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright
info
==9451== Command: ../AAA-build-desktop/AAA
==9451==
==9451== Conditional jump or move depends on uninitialised value(s)
==9451==    at 0xB14D83: __gconv_transform_internal_ascii (in /lib/
libc-2.13.so)
==9451==    by 0xB7A604: wcsnrtombs (in /lib/libc-2.13.so)
==9451==    by 0x5A8D446: std::codecvt<wchar_t, char,
__mbstate_t>::do_out(__mbstate_t&, wchar_t const*, wchar_t const*,
wchar_t const*&, char*, char*, char*&) const (in /usr/lib/libstdc++.so.
6.0.14)
==9451==    by 0x8048C32: std::__codecvt_abstract_base<wchar_t, char,
__mbstate_t>::out(__mbstate_t&, wchar_t const*, wchar_t const*,
wchar_t const*&, char*, char*, char*&) const (codecvt.h:121)
==9451==    by 0x8048AED: main (main.cpp:30)
==9451==
Translation successful: foo
==9451==
==9451== HEAP SUMMARY:
==9451==     in use at exit: 4 bytes in 1 blocks
==9451==   total heap usage: 2 allocs, 1 frees, 32 bytes allocated
==9451==
==9451== LEAK SUMMARY:
==9451==    definitely lost: 4 bytes in 1 blocks
==9451==    indirectly lost: 0 bytes in 0 blocks
==9451==      possibly lost: 0 bytes in 0 blocks
==9451==    still reachable: 0 bytes in 0 blocks
==9451==         suppressed: 0 bytes in 0 blocks
==9451== Rerun with --leak-check=full to see details of leaked memory
==9451==
==9451== For counts of detected and suppressed errors, rerun with: -v
==9451== Use --track-origins=yes to see where uninitialised values
come from
==9451== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 16 from
8)

What is wrong?


--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [next] | [standalone]

#1367

Rafał Moniuszko wrote, On 5.6.2011 15:25:
[...]
> ==9451== Conditional jump or move depends on uninitialised value(s)
I think that this is likely because of uninitialized mystate variable. Add
#include <cstring> and do std::memset (&mystate, 0, sizeof(mystate));:


// codecvt::out example
#include <iostream>
#include <locale>
#include <string>
#include <cstring> // XXX

using namespace std;

int main ()
{
  locale mylocale;
  mbstate_t mystate;

  wstring mywstring;

  const codecvt<wchar_t,char,mbstate_t>& myfacet =
    use_facet<codecvt<wchar_t,char,mbstate_t> >(mylocale);

  codecvt<wchar_t,char,mbstate_t>::result myresult;

  cout << "Enter sentence: ";
  getline (wcin,mywstring);

  size_t length = mywstring.length();
  char* pstr= new char [length+1];

  const wchar_t* pwc;
  char* pc;

  std::memset (&mystate, 0, sizeof(mystate)); // XXX
  // translate characters:
  myresult = myfacet.out (mystate,
      mywstring.c_str(), mywstring.c_str()+length+1, pwc,
      pstr, pstr+length+1, pc);

  if ( myresult == codecvt<wchar_t,char,mbstate_t>::ok )
	  cout << "Translation successful: " << pstr << endl;
  return 0;
}


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

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

#1380

Vaclav Haisman wrote:
> Rafał Moniuszko wrote, On 5.6.2011 15:25:
> [...]
>> ==9451== Conditional jump or move depends on uninitialised value(s)
> I think that this is likely because of uninitialized mystate variable. Add
> #include <cstring> and do std::memset (&mystate, 0, sizeof(mystate));:

Why not mbstate_t mystate = {0};

{ trailing irrelevant quotation removed. -mod }


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

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

#1382

Jeff Flinn wrote, On 6.6.2011 20:50:
> Vaclav Haisman wrote:
>> Rafał Moniuszko wrote, On 5.6.2011 15:25:
>> [...]
>>> ==9451== Conditional jump or move depends on uninitialised value(s)
>> I think that this is likely because of uninitialized mystate variable. Add
>> #include <cstring> and do std::memset (&mystate, 0, sizeof(mystate));:
> 
> Why not mbstate_t mystate = {0};
Because the last time I tried that I got a warning about bad/wrong
initializer in case of mbstate_t being an int.

-- 
VH


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

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

#1394

On Jun 6, 10:31 pm, Vaclav Haisman <v.hais...@sh.cvut.cz> wrote:
> Jeff Flinn wrote, On 6.6.2011 20:50:> Vaclav Haisman wrote:
>>> Rafał Moniuszko wrote, On 5.6.2011 15:25:
>>> [...]
>>>> ==9451== Conditional jump or move depends on uninitialised value(s)
>>> I think that this is likely because of uninitialized mystate variable. Add
>>> #include <cstring> and do std::memset (&mystate, 0, sizeof(mystate));:
> 
>> Why not mbstate_t mystate = {0};
> 
> Because the last time I tried that I got a warning about bad/wrong
> initializer in case of mbstate_t being an int.

But memset produces undefined behaviour if mbstate_t is (for example)
void *.  I /think/ the only way to fix this is something like:

namespace { mbstate_t zerostate; }
int main () { mbstate_t mystate = zerostate;...}

But that's an awful faf.


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

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

#1413

Martin Bonner wrote, On 8.6.2011 10:06:
> 
> On Jun 6, 10:31 pm, Vaclav Haisman <v.hais...@sh.cvut.cz> wrote:
>> Jeff Flinn wrote, On 6.6.2011 20:50:> Vaclav Haisman wrote:
>>>> Rafał Moniuszko wrote, On 5.6.2011 15:25:
>>>> [...]
>>>>> ==9451== Conditional jump or move depends on uninitialised value(s)
>>>> I think that this is likely because of uninitialized mystate variable. Add
>>>> #include <cstring> and do std::memset (&mystate, 0, sizeof(mystate));:
>> 
>>> Why not mbstate_t mystate = {0};
>> 
>> Because the last time I tried that I got a warning about bad/wrong
>> initializer in case of mbstate_t being an int.
> 
> But memset produces undefined behaviour if mbstate_t is (for example)
> void *.  I /think/ the only way to fix this is something like:
Why does it produce undefined behaviour? You can always take address of a
void pointer and zero the pointer.

> 
> namespace { mbstate_t zerostate; }
> int main () { mbstate_t mystate = zerostate;...}
> 
> But that's an awful faf.
That would be usable. Ideal would be if we had some
std::mbstate_init(mbstate_t &) function or similar.

-- 
VH



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

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

#1420

On 2011-06-08 16:24, Vaclav Haisman wrote:
> Martin Bonner wrote, On 8.6.2011 10:06:
>>
>> But memset produces undefined behaviour if mbstate_t is (for example)
>> void *.  I /think/ the only way to fix this is something like:
> Why does it produce undefined behaviour? You can always take address of a
> void pointer and zero the pointer.

That has never been guaranteed by either the C or the C++ standard:
the object representation that has all zero bits does not necessarily
yield the value representation of a null pointer.

Nevertheless, the habit of "using memset for everything" seems to be
quite widespread, which I consider an abomination.

>> namespace { mbstate_t zerostate; }
>> int main () { mbstate_t mystate = zerostate;...}
>>
>> But that's an awful faf.
> That would be usable. Ideal would be if we had some
> std::mbstate_init(mbstate_t &) function or similar.

Or an initializer macro could be better, as in:

    pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

What we need ideally is not an initialization function or initializer
macro for each type whose variable needs to be initialized, but a uniform
syntax to initialize a variable of any type. That's what the C++0x uniform
initializer syntax brought to us. Unfortunately, that came too late,
and we have different sets of available methods in C, C++03, and C++0x,
and initializing an object of an opaque type has become a pain.

-- 
Seungbeom Kim


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

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

#1481

Seungbeom Kim wrote, On 9.6.2011 15:02:
> 
> On 2011-06-08 16:24, Vaclav Haisman wrote:
>> Martin Bonner wrote, On 8.6.2011 10:06:
>>> 
>>> But memset produces undefined behaviour if mbstate_t is (for example)
>>> void *.  I /think/ the only way to fix this is something like:
>> Why does it produce undefined behaviour? You can always take address of a
>> void pointer and zero the pointer.
> 
> That has never been guaranteed by either the C or the C++ standard:
> the object representation that has all zero bits does not necessarily
> yield the value representation of a null pointer.
First, I cannot imagine, with current interfaces and without extensions etc.,
any implementation that would be usable, that would be defining mbstate_t
from a pointer type. Second, there is no UB in the sense the standard uses
the term. Such memset'd value of mbstate_t would be initialized, so no UB
there, and no sane implementation would dereference it (if it were at all
possible to use such kind of mbstate_t), no UB there either. Is there any
other situation that could be potential UB? I do not think so. And since
std::mbstate_t needs to be compatible with C (and probably POSIX too),
memset() is about the only usable way of giving it some sane and
deterministic value.

IOW, IMHO, your argument is wrong.

> [...]

-- 
VH


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

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

#1489

Vaclav Haisman wrote:
> Seungbeom Kim wrote, On 9.6.2011 15:02:
>> On 2011-06-08 16:24, Vaclav Haisman wrote:
>>> Martin Bonner wrote, On 8.6.2011 10:06:
>>>>
>>>> But memset produces undefined behaviour if mbstate_t is (for example)
>>>> void *.

I hope this is not the point of confusion here, but this statement is
actually wrong. You can memset() the pointer, but you can't use it
afterwards, see below...


>>>> I /think/ the only way to fix this is something like:
>>> Why does it produce undefined behaviour? You can always take address of
>>> a void pointer and zero the pointer.
>>
>> That has never been guaranteed by either the C or the C++ standard:
>> the object representation that has all zero bits does not necessarily
>> yield the value representation of a null pointer.
>
> First, I cannot imagine, with current interfaces and without extensions
> etc., any implementation that would be usable, that would be defining
> mbstate_t from a pointer type.

I could imagine it to point to a translation table that defines the current
mapping between internal and external encoding. I could also imagine it to
contain such a pointer and contain further state info, e.g. to create a
table-driven UTF-8 encoder/decoder.


> Second, there is no UB in the sense the standard uses the term. Such
> memset'd value of mbstate_t would be initialized, so no UB there, and
> no sane implementation would dereference it (if it were at all possible
> to use such kind of mbstate_t), no UB there either. Is there any other
> situation that could be potential UB? I do not think so.

If you declare a pointer without initialising it or after destroying the
object it points to, merely reading the pointer yields undefined behaviour.
The thing is called "singular value", IIRC. Now, consider this case:

   void* p;
   memset(&p, 0, sizeof p);

If you do this, you are not guaranteed that the value of p is actually a
null pointer value. Someone mentioned a platform that uses 0xffffffff as
signal value for invalid pointers, because there is actually RAM at address
zero that can validly be addressed. Further, the standard doesn't require
the value to be "all bits zero". So, you could actually have an illegal,
singular value that can't even be read without causing UB.


> And since std::mbstate_t needs to be compatible with C (and probably
> POSIX too), memset() is about the only usable way of giving it some
> sane and deterministic value.

According to my manpage of mbstate_t, you _must_ initialize it using
memset(). That means that any implementation defining it as a pointer must
not actually read it as a pointer, but only use access variants like
memcpy(), memcmp() etc. This means that all "clean" initialisations
mentioned in this thread (e.g. "mbstate_t s = {};" or "mbstate_t s =
mbstate_t();") are actually not guaranteed to work.


Uli

-- 
Domino Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

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

#1495

On 2011-06-17 05:42, Ulrich Eckhardt wrote:
> 
> According to my manpage of mbstate_t, you _must_ initialize it using
> memset(). That means that any implementation defining it as a pointer must
> not actually read it as a pointer, but only use access variants like
> memcpy(), memcmp() etc.

An implementation may guarantee further details and rely upon others that
the language standard does not, so I guess in that case the implementation
relies either on the fact that all-bits-zero is actually a null pointer,
or on the fact that mbstate_t is not a pointer, and guarantees that memset
will work. It's hard for me to imagine such an implementation that defines
mbstate_t as a pointer and bothers to access the value only through memcpy,
memcmp, etc., though one is possible.

I think it's a defect in the language standard (probably that of C) that
it mentions "an initial conversion state" several times but fails to
provide a means to achieve one. All the C standard says is:

"A zero-valued mbstate_t object is (at least) one way to describe
an initial conversion state." (7.24.6/3)

The language standard should have provided an initializer, or specified
further on what types mbstate_t could be so that more explicit forms of
initializers could be used.

> This means that all "clean" initialisations
> mentioned in this thread (e.g. "mbstate_t s = {};" or "mbstate_t s =
> mbstate_t();") are actually not guaranteed to work.

I cannot understand why not. Can you explain it further?

-- 
Seungbeom Kim


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

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

#1501

Seungbeom Kim wrote:
> On 2011-06-17 05:42, Ulrich Eckhardt wrote:
>> This means that all "clean" initialisations
>> mentioned in this thread (e.g. "mbstate_t s = {};" or "mbstate_t s =
>> mbstate_t();") are actually not guaranteed to work.
>
> I cannot understand why not. Can you explain it further?

1. a null pointer doesn't have to have all its bits zero
2. memset(&ptr, 0, sizeof ptr) only guarantees that all bits are zero, but
not that 'ptr' becomes a null pointer
3. above mentioned "clean" initialisations of pointers yield null pointers

With that, assuming the spec requires an initialisation with memset(), 
other
initialisations where a pointer might become a null pointer are actually 
not
portable, because they give a different result.


That said, I agree that this is a point where the standards could be
improved, especially in the light of what you quoted from the C standard,
where it allows a "zero-valued" object as initial state.

Uli

-- 
Domino Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

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

#1528

On 2011-06-20 12:16, Ulrich Eckhardt wrote:
> Seungbeom Kim wrote:
>> On 2011-06-17 05:42, Ulrich Eckhardt wrote:
>>> This means that all "clean" initialisations
>>> mentioned in this thread (e.g. "mbstate_t s = {};" or "mbstate_t s =
>>> mbstate_t();") are actually not guaranteed to work.
>>
>> I cannot understand why not. Can you explain it further?
> 
> 1. a null pointer doesn't have to have all its bits zero
> 2. memset(&ptr, 0, sizeof ptr) only guarantees that all bits are zero, but
> not that 'ptr' becomes a null pointer
> 3. above mentioned "clean" initialisations of pointers yield null pointers
> 
> With that, assuming the spec requires an initialisation with memset(),
other
> initialisations where a pointer might become a null pointer are actually
not
> portable, because they give a different result.

I see your point. I highly doubt that such implementations that ask
users to use memset will not work with real null pointers produced by
"clean" initialisations; i.e. I expect that they are based on the
assumption, or guarantee, that memset does produce a real null pointer;
i.e. that a null pointer is all-bits-zero.

-- 
Seungbeom Kim


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

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

#1421

On 2011-06-06 14:31, Vaclav Haisman wrote:
> 
> Jeff Flinn wrote, On 6.6.2011 20:50:
>>
>> Why not mbstate_t mystate = {0};
> Because the last time I tried that I got a warning about bad/wrong
> initializer in case of mbstate_t being an int.

It's not "wrong", because the C++ standard guarantees that:

"If T is a scalar type, then a declaration of the form
    T x = { a };
is equivalent to
    T x = a;
" (8.5/13), as well as the C standard:

"The initializer for a scalar shall be a single expression,
optionally enclosed in braces." (6.7.8/11)

Being considered "bad" (in terms of style) is a different matter, though.
(But what alternatives do you have, especially in C? So far, only the
file scope variable method, which is not very elegant.)

-- 
Seungbeom Kim


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

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

#1383

Am 06.06.2011 20:50, schrieb Jeff Flinn:
> Vaclav Haisman wrote:
>> Rafał Moniuszko wrote, On 5.6.2011 15:25:
>> [...]
>>> ==9451== Conditional jump or move depends on uninitialised value(s)
>> I think that this is likely because of uninitialized mystate variable.
>> Add
>> #include <cstring> and do std::memset (&mystate, 0, sizeof(mystate));:
> 
> Why not mbstate_t mystate = {0};

Or rely on aggregate-initialization with an empty initializer:

mbstate_t mystate = {};

Greetings from Bremen,

Daniel Krügler


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

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

#1387

Daniel Krügler wrote:
> Am 06.06.2011 20:50, schrieb Jeff Flinn:
>> Vaclav Haisman wrote:
>>> Rafał Moniuszko wrote, On 5.6.2011 15:25:
>>> [...]
>>> Add #include <cstring> and do 
>>> std::memset (&mystate, 0, sizeof(mystate));:
>> 
>> Why not mbstate_t mystate = {0};
> 
> Or rely on aggregate-initialization with an empty initializer:
> 
> mbstate_t mystate = {};

Just wondering is that the same or are there subtle differences? Also, what
about this C++ solution:

  mbstate_t mystate = mbstate_t();


Greetings!

Uli

-- 
Domino Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

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

#1388

On 2011-06-07 11:07, Ulrich Eckhardt wrote:
> Daniel Krügler wrote:
>> Am 06.06.2011 20:50, schrieb Jeff Flinn:
>>> Vaclav Haisman wrote:
>>>> Rafał Moniuszko wrote, On 5.6.2011 15:25:
>>>> [...]
>>>> Add #include<cstring>  and do
>>>> std::memset (&mystate, 0, sizeof(mystate));:
>>>
>>> Why not mbstate_t mystate = {0};
>>
>> Or rely on aggregate-initialization with an empty initializer:
>>
>> mbstate_t mystate = {};
>
> Just wondering is that the same or are there subtle differences?

It is not guaranteed to be portable in C++03, because empty-list
initialization is only specified for aggregates, not for other types
(like scalar types), and mbstate_t is just specified to be a non-array
object type, therefore it may be an aggregate or not. It is portable in
C++0x because of the new concept of "list-initialization" and because of
a subtle change of a zero-initialization border case, see below.

In response to your actual question I would say that it should have the
same effects, assuming that mbstate_t is a C compatible object type (and
I don't think that anything else makes sense). In this case {} has the
effect of value-initializing all components of an aggregate and it has
the effect of value-initializing an object of scalar type.
Initializing an aggregate or a scalar with {0} is equivalent to the
effects that value-initialization has for such types, because in the end
we have a zero-initialization of all scalar sub-parts and this has the
effects of "set to the value of 0 (zero) converted to T;". This is near
to identical to memset, except for (to the best of my knowledge)

a) padding bytes before C++0x, but the FDIS has approved the core issue

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#694

fixing this subtle difference and

b) pointer types, because memset does not guarantee to have the same
effects as zero-initializing. In the latter case it is guaranteed to
have a null pointer value, but memset applied to a pointer value may be
something different.

I would say that especially the second difference is more a pro argument
to rely on value-initialization instead of using memset.

> Also, what
> about this C++ solution:
>
>    mbstate_t mystate = mbstate_t();

I would say that this is the best compromise if you want to support both
C++03 and C++0x code targets. It has the effect of value-initialization,
so it is equivalent to {} in C++0x and {0} in C++03 (for the subset of
types that I mentioned one or two special cases mentioned above.

HTH & Greetings from Bremen,

Daniel Krügler



-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

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

#1372

Rafał Moniuszko wrote:
> When you compile and run code available here:
> http://www.cplusplus.com/reference/std/locale/codecvt/out/, you get
> following output from valgrind:
[...]
> ==9451== Conditional jump or move depends on uninitialised value(s)

Vaclav seems to have covered this already, so a simple

  memset(&mystate, 0, sizeof mystate);

should do the job. In any case, it is not wrong and the recommended way to
init mbstate_t objects.


> ==9451== HEAP SUMMARY:
> ==9451==     in use at exit: 4 bytes in 1 blocks
> ==9451==   total heap usage: 2 allocs, 1 frees, 32 bytes allocated

This looks trivial, it's the unbalanced use of new[] and delete[]. An even
better approach would have been to use a vector<char> of course, as that's
trivial to make exception-safe.


Uli


-- 
Domino Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [standalone]

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

csiph-web