On 11/26/2014 01:12 AM, Sebastian Huber wrote:
On 25/11/14 23:25, Joel Sherrill wrote:
How long is this test supposed to run?
It takes 4:42 using sis on my computer which is a 2.9 Ghz i7 .
SIS is a slow simulator. On Qemu it runs much faster.
Is there anything to do? Split it?
Splitting it
On 11/26/2014 01:27 AM, Sebastian Huber wrote:
Hello Joel,
I fixed it like this:
http://git.rtems.org/rtems/commit/?id=d6f0ca64a5932ee38fb5891dbce886e0b10f63e7
OK. I will commit the CodeSonar patches minus the
sync() one and run Coverity again.
It is a long holiday weekend and I don't expect
On 11/26/2014 01:05 AM, Sebastian Huber wrote:
On 26/11/14 00:02, Joel Sherrill wrote:
From: Josh Oguin
CodeSonar spotted that the return values were being ignored.
---
cpukit/libcsupport/src/sync.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/cpukit/libcsuppor
On 11/26/2014 01:32 AM, Sebastian Huber wrote:
Hello Joel,
On 25/11/14 20:30, Joel Sherrill wrote:
Coverity Id 1255348 in fs-rtems.c can't be ignored on the grounds
the JFFS2 project will see it.
this is one-to-one copy from the eCos code. I don't know how and why it
works.
Based on history
Hi
Chris asked me about the valid use of B0 in termios. I
recalled it had special meaning and decided to dig it up.
It means hang up.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/termios.h.html
tcsetattr() is clearer and says "the modem control lines shall no longer be
asserted. Nor
On Tue, Nov 25, 2014 at 6:02 PM, Joel Sherrill
wrote:
> From: Josh Oguin
>
> ---
> c/src/lib/libbsp/shared/bspinit.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/c/src/lib/libbsp/shared/bspinit.c
> b/c/src/lib/libbsp/shared/bspinit.c
> inde
In the future, please add more in the comment to explain for example
that the same variable initialization happens earlier. I had to go
look at the code to see why it was OK to delete this line.
-Gedare
On Tue, Nov 25, 2014 at 6:02 PM, Joel Sherrill
wrote:
> From: Josh Oguin
>
> This was flagged
To be clear, I meant the commit comment. Obviously don't add a source
comment about a deleted line.
On Wed, Nov 26, 2014 at 10:11 AM, Gedare Bloom wrote:
> In the future, please add more in the comment to explain for example
> that the same variable initialization happens earlier. I had to go
> l
Again, I don't know why this is unecessary. Because str is never used?
On Tue, Nov 25, 2014 at 6:02 PM, Joel Sherrill
wrote:
> From: Josh Oguin
>
> This was flagged by CodeSonar.
> ---
> cpukit/libcsupport/src/mount.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/cpukit/libcsupport/sr
On November 26, 2014 9:17:34 AM CST, Gedare Bloom wrote:
>Again, I don't know why this is unecessary. Because str is never used?
Yes.
>On Tue, Nov 25, 2014 at 6:02 PM, Joel Sherrill
> wrote:
>> From: Josh Oguin
>>
>> This was flagged by CodeSonar.
>> ---
>> cpukit/libcsupport/src/mount.c | 1
On 11/26/2014 09:08 AM, Gedare Bloom wrote:
On Tue, Nov 25, 2014 at 6:02 PM, Joel Sherrill
wrote:
From: Josh Oguin
---
c/src/lib/libbsp/shared/bspinit.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/c/src/lib/libbsp/shared/bspinit.c
b/c/src
Just a general comment that I think it better to have the last line be
the "good" return value, that is, check for an error and return EIO,
otherwise default to return RC_OK. Usually you want to have errors
cause short-circuits, while non-error execution proceeds to the end.
On Tue, Nov 25, 2014 a
On 11/26/2014 09:12 AM, Gedare Bloom wrote:
To be clear, I meant the commit comment. Obviously don't add a source
comment about a deleted line.
OK. Gotcha. These are pretty obvious from the CodeSonar report.
And I don't think we have anymore of these.
The biggest category left is possible NUL
On 11/26/2014 09:22 AM, Gedare Bloom wrote:
Just a general comment that I think it better to have the last line be
the "good" return value, that is, check for an error and return EIO,
otherwise default to return RC_OK. Usually you want to have errors
cause short-circuits, while non-error executio
I did not look at this, but in general we should consider to relocate
the tools subdirectory to a different repo.
On Tue, Nov 25, 2014 at 6:02 PM, Joel Sherrill
wrote:
> From: Josh Oguin
>
> This code is built without warnings and ignored by Coverity Scan.
> CodeSonar found a wide range of issue
On Tue, Nov 25, 2014 at 6:02 PM, Joel Sherrill
wrote:
> From: Josh Oguin
>
> This was flagged by CodeSonar. It should be impossible to get an
> incorrect baud number back but ensure this in debug mode. The _Assert()
> keeps their scanner from evaluating for divide by 0 past this point.
> ---
> c
On Wed, Nov 26, 2014 at 2:36 AM, Chris Johns wrote:
>
> On 26/11/2014 10:02 am, Joel Sherrill wrote:
>>
>> From: Josh Oguin
>>
>> This was flagged by CodeSonar. It should be impossible to get an
>> incorrect baud number back but ensure this in debug mode. The _Assert()
>> keeps their scanner from
On Wed, Nov 26, 2014 at 8:55 AM, Joel Sherrill
wrote:
> On 11/26/2014 01:05 AM, Sebastian Huber wrote:
>>
>> On 26/11/14 00:02, Joel Sherrill wrote:
>>>
>>> From: Josh Oguin
>>>
>>> CodeSonar spotted that the return values were being ignored.
>>> ---
>>>cpukit/libcsupport/src/sync.c | 6 --
Say so in the commit.
On Wed, Nov 26, 2014 at 10:18 AM, Joel Sherrill
wrote:
>
>
> On November 26, 2014 9:17:34 AM CST, Gedare Bloom wrote:
>>Again, I don't know why this is unecessary. Because str is never used?
>
> Yes.
>
>>On Tue, Nov 25, 2014 at 6:02 PM, Joel Sherrill
>> wrote:
>>> From: Jos
These are minor nits, but I'll bring them up anyway because as I review these
changes I keep thinking about them.
If you have a small-codespace target that can togenerate faults on
low-address-space accesses then these NULL dereferences are going to be caught
in the exception handler and don't
Hi,
On Tue, Nov 25, 2014 at 8:21 PM, Gedare Bloom wrote:
> I'm pretty sure STACK_ALIGNMENT just does the initial stack align for
> the start of the stack. The compiler is responsible for laying out the
> frames after that, and for generating aligned entries in the stack
> itself. Probably the co
On November 26, 2014 10:34:16 AM CST, Hesham Moustafa
wrote:
>Hi,
>
>
>On Tue, Nov 25, 2014 at 8:21 PM, Gedare Bloom wrote:
>
>I'm pretty sure STACK_ALIGNMENT just does the initial stack align for
>the start of the stack. The compiler is responsible for laying out the
>frames after that, and f
Howdy,
I feel the time is right to once again make noise about establishing
an "RTEMS Project" NGO. Benefits are many, including clearer
organizational identity, community fund-raising, access to
infrastructure for non-profits e.g. [1], and more.
I know this has been looked into before. Is there
Smells like a compiler-toolchain problem to me. -Gedare
On Wed, Nov 26, 2014 at 11:34 AM, Hesham Moustafa
wrote:
> Hi,
>
> On Tue, Nov 25, 2014 at 8:21 PM, Gedare Bloom wrote:
>>
>> I'm pretty sure STACK_ALIGNMENT just does the initial stack align for
>> the start of the stack. The compiler is r
On Wed, Nov 26, 2014 at 11:29 AM, Peter Dufault wrote:
> These are minor nits, but I'll bring them up anyway because as I review these
> changes I keep thinking about them.
>
> If you have a small-codespace target that can togenerate faults on
> low-address-space accesses then these NULL derefer
On November 26, 2014 10:29:26 AM CST, Peter Dufault wrote:
>These are minor nits, but I'll bring them up anyway because as I review
>these changes I keep thinking about them.
>
>If you have a small-codespace target that can togenerate faults on
>low-address-space accesses then these NULL derefer
On 11/26/2014 10:47 AM, Gedare Bloom wrote:
Howdy,
I feel the time is right to once again make noise about establishing
an "RTEMS Project" NGO. Benefits are many, including clearer
organizational identity, community fund-raising, access to
infrastructure for non-profits e.g. [1], and more.
I kn
On Wed, Nov 26, 2014 at 4:46 PM, Joel Sherrill
wrote:
>
>
>
> On November 26, 2014 10:34:16 AM CST, Hesham Moustafa
> wrote:
> >Hi,
> >
> >
> >On Tue, Nov 25, 2014 at 8:21 PM, Gedare Bloom wrote:
> >
> >I'm pretty sure STACK_ALIGNMENT just does the initial stack align for
> >the start of the st
> On Nov 26, 2014, at 11:40 , Gedare Bloom wrote:
>
> What is the difference between the previous two variants? Would you
> expect to optimize out "Assert_known" in all production code?
>
"Assert_known_not_NULL" implies that either someone broke the code (the known
assertion no longer applies
On November 26, 2014 9:33:57 AM CST, Gedare Bloom wrote:
>On Wed, Nov 26, 2014 at 2:36 AM, Chris Johns wrote:
>>
>> On 26/11/2014 10:02 am, Joel Sherrill wrote:
>>>
>>> From: Josh Oguin
>>>
>>> This was flagged by CodeSonar. It should be impossible to get an
>>> incorrect baud number back but
On Wed, Nov 26, 2014 at 12:06 PM, Hesham Moustafa
wrote:
> On Wed, Nov 26, 2014 at 4:46 PM, Joel Sherrill
> wrote:
>>
>>
>>
>> On November 26, 2014 10:34:16 AM CST, Hesham Moustafa
>> wrote:
>> >Hi,
>> >
>> >
>> >On Tue, Nov 25, 2014 at 8:21 PM, Gedare Bloom wrote:
>> >
>> >I'm pretty sure STA
On Wed, Nov 26, 2014 at 12:32 PM, Peter Dufault wrote:
>
>> On Nov 26, 2014, at 11:40 , Gedare Bloom wrote:
>>
>> What is the difference between the previous two variants? Would you
>> expect to optimize out "Assert_known" in all production code?
>>
>
> "Assert_known_not_NULL" implies that either
On 11/26/2014 08:12 AM, Sebastian Huber wrote:
> On 25/11/14 23:25, Joel Sherrill wrote:
>> How long is this test supposed to run?
>>
>> It takes 4:42 using sis on my computer which is a 2.9 Ghz i7 .
>
> SIS is a slow simulator. On Qemu it runs much faster.
I agree, qemu runs crypt01 in about
On 26/11/14 23:42, Jiri Gaisler wrote:
On 11/26/2014 08:12 AM, Sebastian Huber wrote:
On 25/11/14 23:25, Joel Sherrill wrote:
How long is this test supposed to run?
It takes 4:42 using sis on my computer which is a 2.9 Ghz i7 .
SIS is a slow simulator. On Qemu it runs much faster.
I agree,
34 matches
Mail list logo
