Serious bug in lcc-win32

T

Tea Strainer

Here is a common situation. You have a header file containing a
#pragma once
directive.

The header file is located on a network store and happens to get #included
more than once with different (aliased) paths.

In this case, lcc-win will fail to observe the #pragma.

This serious bug needs to be fixed as soon as possible. Suggested
solution: make a hash of the contents of each #included header file rather
than relying on path-names alone.
 
F

Flash Gordon

Tea said:
Here is a common situation. You have a header file containing a
#pragma once
directive.

That is not a standard pragma and may well behave differently on
different implementations. if you really need it then you need to
discuss it on the group where your particular implementation is topical.
There is an lcc news group and the author of lcc-win has been known to
be active there. However, if you use the more conventional methof of
include guards...

#ifdef H_SOME_HEADER
#define H_SOME_HEADER

#endif

you won't have the problems. You obviously need some convention for how
you name the include guards, preferable one that avoids names starting
with an E
The header file is located on a network store and happens to get #included
more than once with different (aliased) paths.

In this case, lcc-win will fail to observe the #pragma.

That is a very difficult problem to solve. In fact, the solution would
(in general) involve reading the entire header thus removing the main
advantage of the non-standard pragma over the solution that would work
with any compiler.
This serious bug needs to be fixed as soon as possible. Suggested
solution: make a hash of the contents of each #included header file rather
than relying on path-names alone.

I don't think it is a bug. I think it is just a perfectly reasonable
limitation. I see no reason for Jacob to spend time on it.

Either don't have multiple aliases for the same file or use standard
include guards.
 
U

user923005

Here is a common situation. You have a header file containing a
#pragma once
directive.

The header file is located on a network store and happens to get #included
more than once with different (aliased) paths.

In this case, lcc-win will fail to observe the #pragma.

This serious bug needs to be fixed as soon as possible. Suggested
solution: make a hash of the contents of each #included header file rather
than relying on path-names alone.

Has LCC documented the use of non-standard:
#pragma once
As a method to make headers idempotent?

If it has, then you have a complaint. If it does not recommend the
use of this pragma, then the error is yours and not LCC's.
 
H

Harald van Dijk

user923005 said:
Has LCC documented the use of non-standard:
#pragma once
As a method to make headers idempotent?

If it has, then you have a complaint. If it does not recommend the
use of this pragma, then the error is yours and not LCC's.

All recognised pragmas must be documented, and all unrecognised pragmas must
be ignored. See C99 6.10.6p1. If the documentation does not mention #pragma
once, and lcc would recognise it anyway, then _that_ would be cause for a
complaint.

(I suspect there is no conformance issue. I don't have lcc installed to
check, but I recall other compilers' documentation for #pragma once being
rather vague.)
 
K

Keith Thompson

blargg said:
In the meantime, you can fix it by using the standard include guard
idiom. I'm curious as to why you consider this serious;
[snip]

"Tea Strainer", or someone posting under several similar names,
occasionally finds some minor bug or non-bug in lcc-win32 and posts it
here, greatly exaggerating its importance. I doubt that he *really*
considers it serious.
 
R

Richard Bos

Or it differs in opinion with you on what constitutes "the same file".
Has LCC documented the use of non-standard:
#pragma once
As a method to make headers idempotent?

If it has, then you have a complaint.

That depends on how it documents that.

Richard
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top