Circular #include between lstate.h and ltm.h

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Circular #include between lstate.h and ltm.h

Jon Chesterfield
Hi,

I was directed here from github https://github.com/lua/lua/pull/18

Deleting #include "lstate.h" from ltm.h looks like the right fix to me.

Cheers,

Jon
Reply | Threaded
Open this post in threaded view
|

Re: Circular #include between lstate.h and ltm.h

Ryan
Because of the ifndef guard, the code will still compile so this is essentially a non-issue (at least as far as compiling).  My guess is that any time one of those is included they want both of them included.

On Sat, May 19, 2018 at 9:43 PM, Jon Chesterfield <[hidden email]> wrote:
Hi,

I was directed here from github https://github.com/lua/lua/pull/18

Deleting #include "lstate.h" from ltm.h looks like the right fix to me.

Cheers,

Jon

Reply | Threaded
Open this post in threaded view
|

Re: Circular #include between lstate.h and ltm.h

Roberto Ierusalimschy
In reply to this post by Jon Chesterfield
> I was directed here from github https://github.com/lua/lua/pull/18
>
> Deleting #include "lstate.h" from ltm.h looks like the right fix to me.

The problem in that link is stated like this:

  lstate.h uses TM_N from ltm.h and lstate.h uses nothing from ltm.h

Maybe I am missing something, but that statement seems slightly
contradictory.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Circular #include between lstate.h and ltm.h

云风 Cloud Wu
Roberto Ierusalimschy <[hidden email]>于2018年5月22日周二 下午7:08写道:

The problem in that link is stated like this:

  lstate.h uses TM_N from ltm.h and lstate.h uses nothing from ltm.h

Maybe I am missing something, but that statement seems slightly
contradictory.


 I guess the motivation is ltm.h use `G(l)` for  macro `fasttm` , and the macro G(l) need know the detail of struct lua_State to expand.
Reply | Threaded
Open this post in threaded view
|

Re: Circular #include between lstate.h and ltm.h

Jon Chesterfield
In reply to this post by Jon Chesterfield

Message: 2
Date: Tue, 22 May 2018 08:08:16 -0300
From: Roberto Ierusalimschy <[hidden email]>
Subject: Re: Circular #include between lstate.h and ltm.h
To: Lua mailing list <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii

> I was directed here from github https://github.com/lua/lua/pull/18
>
> Deleting #include "lstate.h" from ltm.h looks like the right fix to me.

The problem in that link is stated like this:

  lstate.h uses TM_N from ltm.h and lstate.h uses nothing from ltm.h

Maybe I am missing something, but that statement seems slightly
contradictory.

-- Roberto

Hi Roberto,

Good point, well made. ltm.h uses nothing from lstate.h. 

What I actually did after seeing the circular include was delete one, notice the build break, then delete the other and see that the build & test was fine. Then actually check the contents of the headers and the order in which they're included in various files.

Cheers!

Jon
Reply | Threaded
Open this post in threaded view
|

Re: Circular #include between lstate.h and ltm.h

Andrew Gierth
>>>>> "Jon" == Jon Chesterfield <[hidden email]> writes:

 Jon> Good point, well made. ltm.h uses nothing from lstate.h.

Except as already pointed out, it does use G(l) from lstate.h.

Nothing breaks in the build because ltm.h is included nowhere that
doesn't also include lstate.h first, and in any event the G() is only in
a macro expansion so it would only fail if something used the macro
without also having included lstate.h.

But in fact the inclusion of lstate.h in ltm.h is pointless, because if
you tried to include ltm.h on its own, this would happen:

1. ltm.h defines ltm_h
2. ltm.h includes lstate.h
3. lstate.h includes ltm.h
4. nested include of ltm.h does nothing, because ltm_h is already
   defined
5. lstate.h fails on undefined TM_N

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: Circular #include between lstate.h and ltm.h

Jon Chesterfield
On Wed, May 23, 2018 at 2:18 PM, Andrew Gierth <[hidden email]> wrote:
>>>>> "Jon" == Jon Chesterfield <[hidden email]> writes:

 Jon> Good point, well made. ltm.h uses nothing from lstate.h.

Except as already pointed out, it does use G(l) from lstate.h.

Was that pointed out by Ryan? I got the following reply which was difficult to parse. Not sure what gmail is doing here. I get a few hundred emails a day through various mailing lists and only see this on lua-l.

From: Ryan <[hidden email]>
Subject: Re: Circular #include between lstate.h and ltm.h
To: Lua mailing list <[hidden email]>
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

QmVjYXVzZSBvZiB0aGUgaWZuZGVmIGd1YXJkLCB0aGUgY29kZSB3aWxsIHN0aWxsIGNvbXBpbGUg
c28gdGhpcyBpcwplc3NlbnRpYWxseSBhIG5vbi1pc3N1ZSAoYXQgbGVhc3QgYXMgZmFyIGFzIGNv
bXBpbGluZykuICBNeSBndWVzcyBpcyB0aGF0CmFueSB0aW1lIG9uZSBvZiB0aG9zZSBpcyBpbmNs
dWRlZCB0aGV5IHdhbnQgYm90aCBvZiB0aGVtIGluY2x1ZGVkLgoKT24gU2F0LCBNYXkgMTksIDIw
MTggYXQgOTo0MyBQTSwgSm9uIENoZXN0ZXJmaWVsZCA8CmpvbmF0aGFuY2hlc3RlcmZpZWxkQGdt
YWlsLmNvbT4gd3JvdGU6Cgo+IEhpLAo+Cj4gSSB3YXMgZGlyZWN0ZWQgaGVyZSBmcm9tIGdpdGh1
YiBodHRwczovL2dpdGh1Yi5jb20vbHVhL2x1YS9wdWxsLzE4Cj4KPiBEZWxldGluZyAjaW5jbHVk
ZSAibHN0YXRlLmgiIGZyb20gbHRtLmggbG9va3MgbGlrZSB0aGUgcmlnaHQgZml4IHRvIG1lLgo+
Cj4gQ2hlZXJzLAo+Cj4gSm9uCj4KLS0tLS0tLS0tLS0tLS0gbmV4dCBwYXJ0IC0tLS0tLS0tLS0t
LS0tCkFuIEhUTUwgYXR0YWNobWVudCB3YXMgc2NydWJiZWQuLi4KVVJMOiBodHRwOi8vbGlzdG1h
c3Rlci5wZXBwZXJmaXNoLm5ldC9jZ2ktYmluL21haWxtYW4vcHJpdmF0ZS9sdWEtbC1saXN0cy5s
dWEub3JnL2F0dGFjaG1lbnRzLzIwMTgwNTE5LzlkZjYyNTFlL2F0dGFjaG1lbnQtMDAwMS5odG1s
Cg==

I missed the macro. So there is an actual cyclic dependency between the headers.

I think I'd be inclined to go with s/gfasttm(G(l), et, e)/gfasttm(l->l_G, et, e)/ to break the cycle.
Otherwise the G() macro could get it's own header that is included in both files with the same effect.

But in fact the inclusion of lstate.h in ltm.h is pointless, because if
you tried to include ltm.h on its own, this would happen:

1. ltm.h defines ltm_h
2. ltm.h includes lstate.h
3. lstate.h includes ltm.h
4. nested include of ltm.h does nothing, because ltm_h is already
   defined
5. lstate.h fails on undefined TM_N


Yes. The C #include model is pretty straightforward. Are we in agreement that cyclic includes are bad and worth removing? It's the only one in your codebase.
Reply | Threaded
Open this post in threaded view
|

Re: Circular #include between lstate.h and ltm.h

Andrew Gierth
>>>>> "Jon" == Jon Chesterfield <[hidden email]> writes:

 >> Except as already pointed out, it does use G(l) from lstate.h.

 Jon> Was that pointed out by Ryan?

No, by Cloud Wu.

 Jon> I got the following reply which was difficult to parse. Not sure
 Jon> what gmail is doing here. I get a few hundred emails a day through
 Jon> various mailing lists and only see this on lua-l.

Are you subscribed in digest mode or normally?

Both Cloud Wu's message and Ryan's message arrived at my mailserver as
multipart/alternative with two quoted-printable parts (NOT base64), one
text/plain and one text/html. The MIME structure seems valid to me (and
to my mail system, which is a lot more picky about that than most).

Your message also arrived as multipart/alternative with text/plain and
text/html parts, but the text/plain part was in (implied) 7bit and only
the html part in quoted-printable.

The message in base64 that you quoted elsewhere contains the text "An
HTML attachment was scrubbed..." with a pepperfish.net URL. This
suggests to me that you have some different option set on the mailing
list (because I don't see that), but if you're not using digest mode I
don't see any option that it could be.

 Jon> I missed the macro. So there is an actual cyclic dependency
 Jon> between the headers.

 Jon> I think I'd be inclined to go with s/gfasttm(G(l), et,
 Jon> e)/gfasttm(l->l_G, et, e)/ to break the cycle.

That wouldn't break it, because l->l_G is as much a dependency on
lstate.h as G() itself is.

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: Circular #include between lstate.h and ltm.h

Jon Chesterfield
Ah, Cloud Wu was similarly encoded. I am using digest mode. There's an option on the list management page called "Get MIME or Plain Text Digests?" which seems likely to fix things. Thank you!

That wouldn't break it, because l->l_G is as much a dependency on
lstate.h as G() itself is.

Ah. Yes, indeed. This clearly warrants more thought than I've given it.

Cheers
Reply | Threaded
Open this post in threaded view
|

Re: Circular #include between lstate.h and ltm.h

Daniel Silverstone
On Wed, May 23, 2018 at 15:33:28 +0100, Jon Chesterfield wrote:
> Ah, Cloud Wu was similarly encoded. I am using digest mode. There's an
> option on the list management page called "Get MIME or Plain Text Digests?"
> which seems likely to fix things. Thank you!

In general, if you're in Digest mode, don't expect to be able to interact with
the list effectively.  Digest mode was meant for people who had slow Internet
connections (9600 baud etc) and thus needed the reduction in overhead.  It's
sub-optimal in a number of ways for dealing with a mailing list and in the
modern world there should be no need for it.  While I'll be trying to improve
matters with respect to digest mode, I strongly recommend you simply stop using
it.

D.

--
Daniel Silverstone                         http://www.digital-scurf.org/
PGP mail accepted and encouraged.            Key Id: 3CCE BABE 206C 3B69