Re: [PATCH] Return NULL for zero size allocations

2021-05-04 Thread Chris Johns
On 5/5/21 4:52 pm, Sebastian Huber wrote: > In POSIX, zero size memory allocations are implementation-defined > behaviour. The implementation has two options: > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/malloc.html > > https://pubs.opengroup.org/onlinepubs/9699919799/functions

[PATCH] Return NULL for zero size allocations

2021-05-04 Thread Sebastian Huber
In POSIX, zero size memory allocations are implementation-defined behaviour. The implementation has two options: https://pubs.opengroup.org/onlinepubs/9699919799/functions/malloc.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html Linux and FreeBSD return a uniqu

Re: [PATCH v2] bsps/shared/ofw: Fix coverity defects

2021-05-04 Thread Niteesh G. S.
On Mon, May 3, 2021 at 11:23 PM Gedare Bloom wrote: > Hi Niteesh, > > This looks good to me. What/how did you test it? > I tested it using the ofw01 test https://git.rtems.org/rtems/tree/testsuites/libtests/ofw01/init.c and read EEPROM using i2c. > Gedare > > On Sat, May 1, 2021 at 6:31 AM G S

Re: [PATCH v4] rtems-debugger: Fixed 32bit pointers

2021-05-04 Thread Gedare Bloom
On Tue, May 4, 2021 at 1:34 PM Stephen Clark wrote: > > Using 32bit types like uint32_t for pointers creates issues on 64 bit > architectures like AArch64. Replaced occurrences of these with uintptr_t, > which will work for both 32 and 64 bit architectures. Added hex_decode_addr > function to rtem

[no subject]

2021-05-04 Thread Stephen Clark
This patch has been tested on a beaglebone black. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

[PATCH v4] rtems-debugger: Fixed 32bit pointers

2021-05-04 Thread Stephen Clark
Using 32bit types like uint32_t for pointers creates issues on 64 bit architectures like AArch64. Replaced occurrences of these with uintptr_t, which will work for both 32 and 64 bit architectures. Added hex_decode_addr function to rtems-debugger. --- .../rtems/debugger/rtems-debugger-server.h

Re: [PATCH v1 1/5] libcsupport: Added futimens() and utimensat()

2021-05-04 Thread Gedare Bloom
On Tue, May 4, 2021 at 10:04 AM Ryan Long wrote: > > > > -Original Message- > From: Sebastian Huber > Sent: Tuesday, May 4, 2021 12:04 AM > To: Ryan Long ; devel@rtems.org > Subject: Re: [PATCH v1 1/5] libcsupport: Added futimens() and utimensat() > > On 03/05/2021 15:40, Ryan Long wrote:

RE: [PATCH v1 2/5] libcsupport: Implement utime() in terms of utimensat()

2021-05-04 Thread Ryan Long
-Original Message- From: Sebastian Huber Sent: Monday, May 3, 2021 11:54 PM To: Ryan Long ; devel@rtems.org Subject: Re: [PATCH v1 2/5] libcsupport: Implement utime() in terms of utimensat() On 03/05/2021 15:40, Ryan Long wrote: > utime() now calls utimensat() to update file access a

Re: [PATCH rtems-net-legacy v2] bsp_drivers: Use os.path for compatibility with non Unix host

2021-05-04 Thread Vijay Kumar Banerjee
On Tue, May 4, 2021 at 1:01 AM Gedare Bloom wrote: > > looks good to me > Thanks. Pushed. > On Mon, May 3, 2021 at 4:37 PM Vijay Kumar Banerjee wrote: > > > > Is this Ok to push? > > > > On Mon, Apr 19, 2021 at 11:32 AM Vijay Kumar Banerjee > > wrote: > > > > > > On Mon, Apr 19, 2021 at 11:30

Re: [PATCH rtems-net-legacy] Re-license copyright texts

2021-05-04 Thread Vijay Kumar Banerjee
On Tue, May 4, 2021 at 1:02 AM Gedare Bloom wrote: > > ok Pushed. Thanks. > > On Mon, May 3, 2021 at 4:37 PM Vijay Kumar Banerjee wrote: > > > > --- > > bsp_drivers.py | 3 ++- > > netlegacy.py| 3 ++- > > testsuites/ftp01/wscript| 3 ++- > > testsui

RE: [PATCH v1 1/5] libcsupport: Added futimens() and utimensat()

2021-05-04 Thread Ryan Long
-Original Message- From: Sebastian Huber Sent: Tuesday, May 4, 2021 12:04 AM To: Ryan Long ; devel@rtems.org Subject: Re: [PATCH v1 1/5] libcsupport: Added futimens() and utimensat() On 03/05/2021 15:40, Ryan Long wrote: > Created futimens.c and utimensat.c to add support for the POSI

Re: About finding the bsp for qemu ( t2080rdb)

2021-05-04 Thread Richi Dubey
I understand, thank you for the detailed explanation. I will try (if required all the bsps) and post here if something works :) On Tue, May 4, 2021 at 11:11 AM Karel Gardas wrote: > > I've tried all variants IIRC of qoriq (e550/e5500/e6500) in qemu > sometime ago (5.x development branch) and i

Re: [PATCH] Make zero size allocation result consistent

2021-05-04 Thread Sebastian Huber
On 04/05/2021 15:57, Gedare Bloom wrote: On Tue, May 4, 2021 at 6:55 AM Sebastian Huber wrote: On 04/05/2021 14:52, Joel Sherrill wrote: On Tue, May 4, 2021, 7:12 AM Sebastian Huber mailto:sebastian.hu...@embedded-brains.de>> wrote: On 04/05/2021 14:07, Joel Sherrill wrote: > Th

Re: [PATCH] Make zero size allocation result consistent

2021-05-04 Thread Gedare Bloom
On Tue, May 4, 2021 at 6:55 AM Sebastian Huber wrote: > > On 04/05/2021 14:52, Joel Sherrill wrote: > > > > > > On Tue, May 4, 2021, 7:12 AM Sebastian Huber > > > > wrote: > > > > On 04/05/2021 14:07, Joel Sherrill wrote: > > > This is undefined

Re: [PATCH] Make zero size allocation result consistent

2021-05-04 Thread Sebastian Huber
On 04/05/2021 14:52, Joel Sherrill wrote: On Tue, May 4, 2021, 7:12 AM Sebastian Huber > wrote: On 04/05/2021 14:07, Joel Sherrill wrote: > This is undefined behaviour and I would rather they all return NULL. As far as I understood the

Re: [PATCH] Make zero size allocation result consistent

2021-05-04 Thread Joel Sherrill
On Tue, May 4, 2021, 7:12 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 04/05/2021 14:07, Joel Sherrill wrote: > > This is undefined behaviour and I would rather they all return NULL. > > As far as I understood the POSIX text, it is implementation-defined > behaviour and POS

Re: [PATCH] Make zero size allocation result consistent

2021-05-04 Thread Sebastian Huber
On 04/05/2021 14:07, Joel Sherrill wrote: This is undefined behaviour and I would rather they all return NULL. As far as I understood the POSIX text, it is implementation-defined behaviour and POSIX gives two valid implementation options. The patch removed some code (less code is always good)

Re: [PATCH] Make zero size allocation result consistent

2021-05-04 Thread Joel Sherrill
This is undefined behaviour and I would rather they all return NULL. No portable program should ever do this. In fact, it should be something caught in debug mode. On Tue, May 4, 2021, 6:45 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 04/05/2021 08:49, Gedare Bloom wrote:

Re: [PATCH] Make zero size allocation result consistent

2021-05-04 Thread Sebastian Huber
On 04/05/2021 08:49, Gedare Bloom wrote: ok. This could break applications in strange ways if they depended on the old behavior. A clear note will be needed in release. I added this to the release notes: https://git.rtems.org/rtems-release/commit/?id=f48aea09d8d82ab80568ad2edcd02b8a11bea886 -

RE: [PATCH] rtems-examples: Add CoreMark Benchmark

2021-05-04 Thread BAILLIEZ Damien
Hesham* Sorry for the typo ! -Message d'origine- De : BAILLIEZ Damien Envoyé : mardi 4 mai 2021 10:16 À : 'Hesham Almatary' Cc : devel@rtems.org Objet : RE: [PATCH] rtems-examples: Add CoreMark Benchmark Hello Heshman, Yes I only use Make. -Message d'origine- De : H.M.K. Alma

RE: [PATCH] rtems-examples: Add CoreMark Benchmark

2021-05-04 Thread BAILLIEZ Damien
Hello Heshman, Yes I only use Make. -Message d'origine- De : H.M.K. Almatary De la part de Hesham Almatary Envoyé : vendredi 30 avril 2021 19:39 À : BAILLIEZ Damien Cc : devel@rtems.org Objet : Re: [PATCH] rtems-examples: Add CoreMark Benchmark Hello Damien, Glad to know you have an i

Re: [PATCH 2/2] covoar: Store address-to-line info outside of DWARF

2021-05-04 Thread Gedare Bloom
On Fri, Apr 30, 2021 at 2:01 PM Alex White wrote: > > This adds the AddressToLineMapper class and supporting classes to > assume responsibility of tracking address-to-line information. > > This allows the DWARF library to properly cleanup all of its resources > and leads to significant memory savi

Re: [PATCH 1/2] covoar: Store only the file name in ExecutableInfo

2021-05-04 Thread Gedare Bloom
On Fri, Apr 30, 2021 at 2:02 PM Alex White wrote: > > This changes the ExecutableInfo class to only store the executable > file's name rather than an entire instance of rld::files::object. This > allows the rld::files::object to be cleaned up in the ExecutableInfo > constructor. > > Updates #4383

Re: [PATCH rtems-net-legacy] Re-license copyright texts

2021-05-04 Thread Gedare Bloom
ok On Mon, May 3, 2021 at 4:37 PM Vijay Kumar Banerjee wrote: > > --- > bsp_drivers.py | 3 ++- > netlegacy.py| 3 ++- > testsuites/ftp01/wscript| 3 ++- > testsuites/loopback/wscript | 3 ++- > testsuites/networking01/wscript | 3 ++- > testsuite

Re: [PATCH rtems-net-legacy v2] bsp_drivers: Use os.path for compatibility with non Unix host

2021-05-04 Thread Gedare Bloom
looks good to me On Mon, May 3, 2021 at 4:37 PM Vijay Kumar Banerjee wrote: > > Is this Ok to push? > > On Mon, Apr 19, 2021 at 11:32 AM Vijay Kumar Banerjee wrote: > > > > On Mon, Apr 19, 2021 at 11:30 AM Vijay Kumar Banerjee > > wrote: > > > > > > --- > > > bsp_drivers.py | 22 +++--

Re: [PATCH] nfs.c: Change filesystem utime_h handler to utimens_h

2021-05-04 Thread Gedare Bloom
On Mon, May 3, 2021 at 12:34 PM Joel Sherrill wrote: > > Ryan.. these have the same subject/short message and are threading together > as the same patch. > > Resubmit both as v2 with libbsd and net-legacy added to the commit message. > Something like: > > legacy nfs.c: Change filesystem utime_h