Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Should compiler report redefinition of structure
17 views
Skip to first unread message
Melzzzzz
Feb 11, 2021, 3:50:49 AM2/11/21
to
This morning I had ghost bug as simply assignment of variable
to structure member caused access violation without obvious
reason.
Name of structure is Data. That name. Same name Microsoft
has in stdafx header, and they don't use namespaces.
That will teach me that I should use anonimous namespaces.
I hadn't got single warning about this, and puzzlingly
there is another Data in another cpp file which didn't
caused problem. Sheesh 5 hours of debugging...
--
current job title: senior software engineer
skills: x86 aasembler,c++,c,rust,go,nim,haskell...
press any key to continue or any other to quit...
to structure member caused access violation without obvious
reason.
Name of structure is Data. That name. Same name Microsoft
has in stdafx header, and they don't use namespaces.
That will teach me that I should use anonimous namespaces.
I hadn't got single warning about this, and puzzlingly
there is another Data in another cpp file which didn't
caused problem. Sheesh 5 hours of debugging...
--
current job title: senior software engineer
skills: x86 aasembler,c++,c,rust,go,nim,haskell...
press any key to continue or any other to quit...
Chris M. Thomasson
Feb 11, 2021, 5:13:39 AM2/11/21
to
On 2/11/2021 12:50 AM, Melzzzzz wrote:
> This morning I had ghost bug as simply assignment of variable
> to structure member caused access violation without obvious
> reason.
> Name of structure is Data. That name. Same name Microsoft
> has in stdafx header, and they don't use namespaces.
> That will teach me that I should use anonimous namespaces.
> I hadn't got single warning about this, and puzzlingly
> there is another Data in another cpp file which didn't
> caused problem. Sheesh 5 hours of debugging...
>
No warning at all?
> This morning I had ghost bug as simply assignment of variable
> to structure member caused access violation without obvious
> reason.
> Name of structure is Data. That name. Same name Microsoft
> has in stdafx header, and they don't use namespaces.
> That will teach me that I should use anonimous namespaces.
> I hadn't got single warning about this, and puzzlingly
> there is another Data in another cpp file which didn't
> caused problem. Sheesh 5 hours of debugging...
>
struct xxx { };
struct xxx { };
should barf up something in a compiler.
Chris M. Thomasson
Feb 11, 2021, 5:15:00 AM2/11/21
to
On 2/11/2021 12:50 AM, Melzzzzz wrote:
> This morning I had ghost bug as simply assignment of variable
> to structure member caused access violation without obvious
> reason.
> Name of structure is Data. That name. Same name Microsoft
> has in stdafx header, and they don't use namespaces.
> That will teach me that I should use anonimous namespaces.
> I hadn't got single warning about this, and puzzlingly
> there is another Data in another cpp file which didn't
> caused problem. Sheesh 5 hours of debugging...
>
Humm.... Have not tried it using a precompiled header...
> to structure member caused access violation without obvious
> reason.
> Name of structure is Data. That name. Same name Microsoft
> has in stdafx header, and they don't use namespaces.
> That will teach me that I should use anonimous namespaces.
> I hadn't got single warning about this, and puzzlingly
> there is another Data in another cpp file which didn't
> caused problem. Sheesh 5 hours of debugging...
>
Sam
Feb 11, 2021, 7:36:55 AM2/11/21
to
Melzzzzz writes:
> This morning I had ghost bug as simply assignment of variable
> to structure member caused access violation without obvious
> reason.
> Name of structure is Data. That name. Same name Microsoft
> has in stdafx header, and they don't use namespaces.
> That will teach me that I should use anonimous namespaces.
> I hadn't got single warning about this, and puzzlingly
> there is another Data in another cpp file which didn't
> caused problem. Sheesh 5 hours of debugging...
A one definition rule violation is undefined behavior, no diagnostic
> This morning I had ghost bug as simply assignment of variable
> to structure member caused access violation without obvious
> reason.
> Name of structure is Data. That name. Same name Microsoft
> has in stdafx header, and they don't use namespaces.
> That will teach me that I should use anonimous namespaces.
> I hadn't got single warning about this, and puzzlingly
> there is another Data in another cpp file which didn't
> caused problem. Sheesh 5 hours of debugging...
required. If a compiler/linker manages to detect it, consider it just as an
extra bonus. However the standard does not require a diagnostic.
Melzzzzz
Feb 11, 2021, 8:33:03 AM2/11/21
to
struct xxxx;
us fucking dns api in stdafx
and my Data, 1 obj file, and ms Data other dll.
Melzzzzz
Feb 11, 2021, 8:34:29 AM2/11/21
to
On 2021-02-11, Sam <s...@email-scan.com> wrote:
> This is a MIME GnuPG-signed message. If you see this text, it means that
> your E-mail or Usenet software does not support MIME signed messages.
> The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
> To open this message correctly you will need to install E-mail or Usenet
> software that supports modern Internet standards.
>
> --=_monster.email-scan.com-121687-1613046999-0001
> Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
> Content-Disposition: inline
> Content-Transfer-Encoding: 7bit
Fucking morons. They forward declare struct Data; in header which
every GUI file includes, that is precompiled header.
Bunch of amateurs.
> This is a MIME GnuPG-signed message. If you see this text, it means that
> your E-mail or Usenet software does not support MIME signed messages.
> The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
> To open this message correctly you will need to install E-mail or Usenet
> software that supports modern Internet standards.
>
> --=_monster.email-scan.com-121687-1613046999-0001
> Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
> Content-Disposition: inline
> Content-Transfer-Encoding: 7bit
every GUI file includes, that is precompiled header.
Bunch of amateurs.
Chris M. Thomasson
Feb 11, 2021, 4:46:11 PM2/11/21
to
On 2/11/2021 5:32 AM, Melzzzzz wrote:
> On 2021-02-11, Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>> On 2/11/2021 12:50 AM, Melzzzzz wrote:
>>> This morning I had ghost bug as simply assignment of variable
>>> to structure member caused access violation without obvious
>>> reason.
>>> Name of structure is Data. That name. Same name Microsoft
>>> has in stdafx header, and they don't use namespaces.
>>> That will teach me that I should use anonimous namespaces.
>>> I hadn't got single warning about this, and puzzlingly
>>> there is another Data in another cpp file which didn't
>>> caused problem. Sheesh 5 hours of debugging...
>>>
>>
>>
>> No warning at all?
>>
>> struct xxx { };
>> struct xxx { };
>>
>> should barf up something in a compiler.
>
> Not if it is just
> struct xxxx;
> us fucking dns api in stdafx
> and my Data, 1 obj file, and ms Data other dll.
>
>
Wow. Imvho, the compiler should feel like puking it guts out. Yet it
> On 2021-02-11, Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>> On 2/11/2021 12:50 AM, Melzzzzz wrote:
>>> This morning I had ghost bug as simply assignment of variable
>>> to structure member caused access violation without obvious
>>> reason.
>>> Name of structure is Data. That name. Same name Microsoft
>>> has in stdafx header, and they don't use namespaces.
>>> That will teach me that I should use anonimous namespaces.
>>> I hadn't got single warning about this, and puzzlingly
>>> there is another Data in another cpp file which didn't
>>> caused problem. Sheesh 5 hours of debugging...
>>>
>>
>>
>> No warning at all?
>>
>> struct xxx { };
>> struct xxx { };
>>
>> should barf up something in a compiler.
>
> Not if it is just
> struct xxxx;
> us fucking dns api in stdafx
> and my Data, 1 obj file, and ms Data other dll.
>
>
hides this from you. Just, wow.
Chris M. Thomasson
Feb 11, 2021, 4:46:38 PM2/11/21
to
Chris M. Thomasson
Feb 11, 2021, 4:49:10 PM2/11/21
to
be highly advised. Heck, even a warning shall be emitted to properly
inform the user seems okay with me.
Vir Campestris
Feb 11, 2021, 4:58:20 PM2/11/21
to
On 11/02/2021 21:48, Chris M. Thomasson wrote:
> This is an odd one to me. This seems like a place where a warning should
> be highly advised. Heck, even a warning shall be emitted to properly
> inform the user seems okay with me.
I got bitten by one of those recently. Two files instantiated a template
> This is an odd one to me. This seems like a place where a warning should
> be highly advised. Heck, even a warning shall be emitted to properly
> inform the user seems okay with me.
with a template parameter of the same name. We're trying to reduce the
amount of conditional compilation across platforms, so I changed it to
compile them both. It picked one of the two instantiations. Silently :(.
Andy
Ben Bacarisse
Feb 11, 2021, 6:20:01 PM2/11/21
to
<cut>
general, so it is left up to implementations to do the best they can.
For example, in one file:
#include <iostream>
struct data { int i; };
void inc(data &d);
int main()
{
data d = { 42 };
inc(d);
std::cout << d.i << "\n";
}
and in another:
struct data { float i; };
void inc(data &d) { d.i += 1; }
C and C++ have always shied away from requireing disgnostics for
conditions that can only be detected at link time.
> Heck, even a warning shall be emitted to properly inform the user
> seems okay with me.
The problem is that many implementations would struggle to get that to
work in every case. In fact, with templates, it might even be
uncomputable. (I'd have to think on that some more.)
--
Ben.
>> A one definition rule violation is undefined behavior, no diagnostic
>> required. If a compiler/linker manages to detect it, consider it just
>> as an extra bonus. However the standard does not require a
>> diagnostic.
>
> This is an odd one to me. This seems like a place where a warning
> should be highly advised.
I don't think anyone disputes that. The trouble is that it is hard in
>> required. If a compiler/linker manages to detect it, consider it just
>> as an extra bonus. However the standard does not require a
>> diagnostic.
>
> This is an odd one to me. This seems like a place where a warning
> should be highly advised.
general, so it is left up to implementations to do the best they can.
For example, in one file:
#include <iostream>
struct data { int i; };
void inc(data &d);
int main()
{
data d = { 42 };
inc(d);
std::cout << d.i << "\n";
}
and in another:
struct data { float i; };
void inc(data &d) { d.i += 1; }
C and C++ have always shied away from requireing disgnostics for
conditions that can only be detected at link time.
> Heck, even a warning shall be emitted to properly inform the user
> seems okay with me.
work in every case. In fact, with templates, it might even be
uncomputable. (I'd have to think on that some more.)
--
Ben.
0 new messages