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


Groups > comp.lang.c++.moderated > #1481

Re: codecvt problem

Message-ID <4DF9DC4B.2090602@sh.cvut.cz> (permalink)
Newsgroups comp.lang.c++.moderated
From Vaclav Haisman <v.haisman@sh.cvut.cz>
Subject Re: codecvt problem
Organization Czech Technical University
References (2 earlier) <isig0g$rj7$1@dont-email.me> <4DED2A8A.1090106@sh.cvut.cz> <df50fa73-a52b-43ca-bf7b-25c1dc4c10c4@c26g2000vbq.googlegroups.com> <4DEF96B7.9070009@sh.cvut.cz> <ispb7b$k8f$1@usenet.stanford.edu>
Date 2011-06-16 17:04 -0600

Show all headers | View raw


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! ]

Back to comp.lang.c++.moderated | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web