false positive, but a workaround...

Ed Sutter ed.sutter at alcatel-lucent.com
Wed Jun 24 15:51:00 UTC 2015

On 6/24/2015 11:48 AM, Gedare Bloom wrote:
> On Wed, Jun 24, 2015 at 11:44 AM, Ed Sutter
> <ed.sutter at alcatel-lucent.com> wrote:
>> On 6/24/2015 10:57 AM, Joel Sherrill wrote:
>>> On 6/24/2015 9:40 AM, Ed Sutter wrote:
>>>> On 6/24/2015 10:41 AM, Jarielle Catbagan wrote:
>>>>> On Wed, Jun 24, 2015 at 6:10 AM, Ed Sutter
>>>>> <ed.sutter at alcatel-lucent.com> wrote:
>>>>>> Jarielle,
>>>>>> Well, it took almost 5 hours to build the tools last night. Obviously I
>>>>>> need
>>>>>> to upgrade the machine I have
>>>>>> this stuff running on at home!
>>>>>> Anyway, this AM I was able to walk through what I thought I had done in
>>>>>> work
>>>>>> yesterday, and unfortunately due
>>>>>> to the fact that I am working in two different locations on two
>>>>>> different
>>>>>> machines (very very inefficient, but I'm
>>>>>> stuck in this mode at the moment); I fooled myself yesterday thinking I
>>>>>> had
>>>>>> stubbed out the __ctype_ptr__
>>>>>> declarations from docmd.c...  Unfortunately, I didn't :-(, so what I
>>>>>> thought
>>>>>> built clean didn't.
>>>>>> Anyway, I want to get you over this hump quickly 'cause this isn't what
>>>>>> I'd
>>>>>> like you to be working on.  I really
>>>>>> want you to concentrate on beaglebone-specific stuff. That's the
>>>>>> important
>>>>>> stuff.  Today I brought my beaglebone
>>>>>> board to the office, and I've got it working clean now using a local
>>>>>> set of
>>>>>> ctype.h and ctypetbl.c files as I had in
>>>>>> umon1.19.  For now this is temporary, but it may turn out to be the
>>>>>> most
>>>>>> efficient way to get around this.
>>>>> These files would conflict with the licenses, am I right? Would a
>>>>> permanent solution be to implement a new local ctype.h?
>>>> Yep, that's exactly what I'm looking in to.  :-)
>>>> Just wanted to get you rolling meanwhile...
>>> All code in newlib has appropriate licenses. It would be easier to
>>> selectively pull in files from there. We just need to be careful
>>> to ensure we know versions so updates can occur. But that's true
>>> for every place you could grab from.
>>> New software has new bugs.
>>> Do you happen to have a master list of what methods you used
>>> in the original source base?
>> Back when I originally gave Amar the tarball, I stripped out all that I
>> thought was questionable for RTEMS.
>> The two blocks of code that are not mine are zlib and glib.
>> zlib: I got this from Mark Adler decades ago (umon/main/zlib/README).
>> glib: subset of libc code i pulled in from a freebsd github
>> (umon/main/glib/getglib)
> zlib is fine we include it's source in RTEMS too.
> I don't know about glib, but if it is in freebsd / has BSD headers it
> should be ok.
Regarding the current ctype problem, I was going to incorporate a 
modified version of this file:
Is that legal for RTEMS?

>> I have not updated them since original incorporation into uMon.
>> If necessary, I suppose I could update the glib files to be sourced from
>> newlib (lemme know).
>> Aside from a few other files that Cogent and a few other uMon users
>> contributed,
>> I wrote the rest.
>>>>>> So, attached to this are three files:
>>>>>> ctypetbl.c:  put this under main/glib
>>>>>> ctype.h:      put this under main/common
>>>>>> mydiffs:     small list of diffs based on the tree after installing
>>>>>> your
>>>>>> initial set of 24 patches.
>>>>>>                       most of these changes you probably have, the
>>>>>> important
>>>>>> one is in main/make/common.make so that ctypetbl.c is built.
>>>>>> If you can incorporate these changes into a tree that starts with the
>>>>>> master
>>>>>> and has your initial 24 patches applied,
>>>>>> you should be good to go.  I know I should be using git to email you
>>>>>> patches, but I'm still trying to figure out how to
>>>>>> do that and I don't want you to be delayed by that.
>>>>>> Does this make sense to you?
>>>>> Yes.  Ok, I'll incorporate those files and I believe you are right
>>>>> that everything should be all set.
>>>>>> Ed
>>>>>> _______________________________________________
>>>>>> umon-devel mailing list
>>>>>> umon-devel at rtems.org
>>>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>> _______________________________________________
>> umon-devel mailing list
>> umon-devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/umon-devel

More information about the umon-devel mailing list