false positive, but a workaround...

Wed Jun 24 17:23:05 UTC 2015

On Wed, Jun 24, 2015 at 12:07 PM, Ed Sutter
<ed.sutter at alcatel-lucent.com> wrote:
> On 6/24/2015 12:00 PM, Joel Sherrill wrote:
>>
>> 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.
>
> So things like this:
> http://www.menie.org/georges/embedded/crc16.c
This is fine. It requires non-attribution which is OK.

> and this:
> http://read.pudn.com/downloads10/sourcecode/math/41641/EE.C__.htm
> are not acceptable for RTEMS, correct?
Yeah this is bad.

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