Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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> |
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 | Next — Previous in thread | Find similar | Unroll 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