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


Groups > comp.lang.c > #45845

Re: Is this a compiler bug? (Function accepts *ptr when **ptr is specified)

From James Kuyper <jameskuyper@verizon.net>
Newsgroups comp.lang.c
Subject Re: Is this a compiler bug? (Function accepts *ptr when **ptr is specified)
Date 2014-06-12 07:45 -0400
Organization A noiseless patient Spider
Message-ID <lnc3sg$vr5$1@dont-email.me> (permalink)
References <p4pcp95g1suo33d9s89u212mv8belco8oe@4ax.com> <sk5ip9peh7oeed52voaq3350mcti1a9do5@4ax.com>

Show all headers | View raw


On 06/11/2014 11:52 PM, DSF wrote:
> On Mon, 09 Jun 2014 22:46:23 -0400, DSF <notavalid@address.here>
> wrote:
> 
>   Thanks to all that replied.  Both for answering my question.  (So
> void* and void** are not considered different until dereferenced.

No, void* and void** are incompatible types. Any pointer to an object
type can be converted to void* and back again, and void** is a pointer
to object type, but they are still different types.

>   As to the casting of the structures:
> 
> TEXTFILEDATAA and TEXTFILEDATAW are defined as thus:
> typedef struct tag_TEXTFILEDATAA
> {
>   int           id;
>  DWORD  status;
>  DWORD  sysstatus;
>  HANDLE  fh;
>  uint         index;
>  uint        maxlines;
>  uint        longest;
>  bool       unicode;
>  char      **lines;
> } TEXTFILEDATAA;
> typedef struct tag_TEXTFILEDATAW
> {
>   int           id;
>  DWORD  status;
>  DWORD  sysstatus;
>  HANDLE  fh;
>  uint         index;
>  uint         maxlines;
>  uint         longest;
>  bool        unicode;
>  wchar_t **lines;
> } TEXTFILEDATAW;
> 
>   They are used much the same way FILE is in standard C.
>   It is perfectly safe for me to cast the (W)ide version to the (A)NSI
> version in calls to the common routine because the common routine
> deals in raw file data (bytes) and does not touch the "lines" member.

There is a rule that covers this: if two structures share a common
initial sequence of fields, a pointer to one struct type can be used to
access an object that's actually of the other type, but only for the
purpose of accessing fields in the common initial sequence. However,
there's additional requirements that must apply in order for such code
to have defined behavior. The two structs must be members of the same
union type, that union type must currently be in scope, and the object
being accessed has to be an instance of that union type (6.5.2.3p6).

In real life, it is very often the case that you can get away with
ignoring the union restrictions - but the behavior is undefined as far
as the C standard is concerned. It's not just the fact that an
implementation is free to insert padding bytes in one of the two struct
types that are not present in the other - while legal, that's pretty
unlikely to happens.

The most serious issue is that such code violates the anti-aliasing
rules (6.5p7). Therefore, if the union requirements from 6.5.2.3p6 are
not met, such code has undefined behavior. If you write to one of the
common fields using an lvalue of one struct type, and then read the
value of the same field using an lvalue of the other struct type, the
compiler is not required to consider the possibility that those two
lvalues refer to the same location in memory. If the previous value of
that field is already stored in a register, it's allowed to use the
value from the register, rather than doing a fresh read from memory.
Such optimizations are legal because of 6.5p7, are quite common, and are
far more likely to occur than arbitrary differences in the location of
padding bytes.
-- 
James Kuyper

Back to comp.lang.c | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Is this a compiler bug? (Function accepts *ptr when **ptr is specified) DSF <notavalid@address.here> - 2014-06-09 22:46 -0400
  Re: Is this a compiler bug? (Function accepts *ptr when **ptr is specified) Barry Schwarz <schwarzb@dqel.com> - 2014-06-09 21:16 -0700
  Re: Is this a compiler bug? (Function accepts *ptr when **ptr is specified) jt@toerring.de (Jens Thoms Toerring) - 2014-06-10 09:38 +0000
  Re: Is this a compiler bug? (Function accepts *ptr when **ptr is specified) Richard Damon <Richard@Damon-Family.org> - 2014-06-10 07:19 -0400
  Re: Is this a compiler bug? (Function accepts *ptr when **ptr is specified) Ralf Damaschke <rwspam@gmx.de> - 2014-06-10 23:02 +0000
  Re: Is this a compiler bug? (Function accepts *ptr when **ptr is specified) Ike Naar <ike@iceland.freeshell.org> - 2014-06-11 05:56 +0000
    Re: Is this a compiler bug? (Function accepts *ptr when **ptr is specified) gazelle@shell.xmission.com (Kenny McCormack) - 2014-06-11 09:39 +0000
  Re: Is this a compiler bug? (Function accepts *ptr when **ptr is specified) DSF <notavalid@address.here> - 2014-06-11 23:52 -0400
    Re: Is this a compiler bug? (Function accepts *ptr when **ptr is specified) Barry Schwarz <schwarzb@dqel.com> - 2014-06-11 22:38 -0700
    Re: Is this a compiler bug? (Function accepts *ptr when **ptr is specified) James Kuyper <jameskuyper@verizon.net> - 2014-06-12 07:45 -0400

csiph-web