false positive, but a workaround...

Wed Jun 24 16:00:10 UTC 2015

On 6/24/2015 10:51 AM, Ed Sutter wrote:
> 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:
> http://fxr.watson.org/fxr/source/sys/ctype.h
> Is that legal for RTEMS?
Sure. Just avoid any BSD license which requires author attribution.

And try to get it all from a consistent version like FreeBSD 10.

And I agree with keeping it all in simple portable C without cpu-specific
versions is the way to go.

>>
>>> 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
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985