OpenEuphoria

Re: EuCOM : Attn Matt : String Return Value

• Posted by Matt Lewis <matthewwalkerlewis at gmai?.c?m> Oct 08, 2007
• 681 views

CChris wrote:
> 
> Matt Lewis wrote:
> > 
> > Bernie Ryan wrote:
> > > 
> > > Matt Lewis wrote:
> > > > 
> > > > Yeah, all I'm concerned about is the actual data, not the null
> > > > terminator.
> > > > 
> > > > 
> > > > Yeah, there should probably be two nulls appended (that's what you're 
> > > > asking, right?).  I'm not sure why I didn't do that.  It's never been
> > > > a problem, though.
> > > > 
> > > 
> > > Matt:
> > > 
> > > This may cause intermitent exception errors.
> > > Remember that your peek_bstr() and peek_unicode() depend on two NULLS.
> > 
> > I agree that this should be fixed.  However, I can confirm that it's not the
> > 
> > culprit in this particular case.
> > 
> > Matt
> 
> Perhaps could you, at the same time; fix the problem Bernie had recently
> pointed
> out by removing any namespace references to _parts_ of a library
> (w32support.e,
> as its name says, is not a standalone file).

It's not, but IIRC, there was a point where this 

Yeah, I think at one point I had actually included it in the library.  EuCOM
has had an odd history of being more or less decoupled from win32lib.  It's
been a few years since I've touched the code, so I've got to go back in and
see what's what before making any significant changes.

> Because namespaces are not inherited - if we had named packages and the
> ability
> to namespace a package, the issue wouldn't arise at all -, namespacing part
> of a library is a lock on its structure, which is bad coding unless the coder
> also is the maintainer-for-life of said library. Otherwise, something has to
> give: the code which uses the library - which is what just happened - or the
> library itself, whose structure becomes constrained by locks put on it by
> programs
> that use named parts of it, without the library maintainer being necessarily
> aware or informed of it. Internal structures should be black boxes really.

Actually, namespaces will be inherited (and are inherited, for code at the
head of the svn repository) in the next release.  I typically run this 
code, which is probably why I haven't noticed the bug.

I had thought that I'd included the file in question with the library, but
looking now, I see that's not so...I believe that it moved previously from
the tk_* file structure to the w32* structure (which was probably when the
file dropped out of the distribution).  I moved from tk_mem.e to 
w32support.e in v2.06 (previous release) apparently to avoid namespace
conflicts.

Some serious thought needs to be applied to this.  I will likely just
supply a eucom version of w32support.e, likely renamed to remove 
ambiguity.  Of course, this may make it more difficult for people who 
write win32lib based eucom programs.  This will only be a problem for
people using 3.1.* versions of euphoria with v0.70.* versions of win32lib,
which seems to have some other compatibility problems, so maybe the 
best course is to wait and see what happens there first. 

Matt