Hi Waldemar, uclibc(-ng) works very well with clang for us. We test clang 15, 16 and 17. It is, next to gcc (from 9) our go-to compiler. Clang builds are used on an arm64 hardware target as well as on QEMU and work just as well as their gcc counterparts.
Kernkonzept develops the Open Source L4Re microkernel operating system and hypervisor for the high assurance, security and safety markets (l4re.org / github.com/Kernkonzept). Uclibc-ng is the C-library for our userland implementation. The system (originally developed at TU Dresden) has used a large subset of uclibc since the early 2000s for the userland. We have, from time to time, picked uclibc-ng changes and fixes that were relevant to us after the original uclibc was "abandoned". We use uclibc also as a basis for libstdc++ (from gcc) and C++ is our primary programming language. Accordingly many uclibc files are used in a C++ context. Currently, our primary architectures are amd64, arm, arm64, risc-v and mips. But we also have (non-working) SPARC and PPC32 ports. Our main focus are MMU-based systems but lately we also ventured into MPU systems (Cortex-R52/82) as well. In the last months we made a concerted effort to sync the whole library to the uclibc-ng upstream and contribute what fixes we have that might benefit you. We are half-way through with this task, so there might be more patches in the coming weeks. Due to the markets we address we have extensive tests for all the functionality from uclibc(-ng) that is used in safety or security critical components. We also check for a comprehensive set of warnings as well as perform static analysis on all code that goes into safety- /security-critical applications. That is where these patches from our team come from that you saw in the last weeks. We would be very happy if you find value in them and want to have them upstream. Best regards, - Marcus On Thu, 2023-12-21 at 07:38 +0100, Waldemar Brodkorb wrote: > Hi, > > sure. Is uclibc-ng fully compilable with clang and the result is > working on a target? What architectures you use? > For what project you use uclibc-ng @ kernkonzept.com? > > best regards > Waldemar > > Marius Melzer wrote, > > > Hi, > > > > I fixed two kinds of Clang warnings in uclibc-ng (see patches > > attached). Is > > that something you would be willing to include? > > > > Best regards, > > Marius > > > > -- > > Marius Melzer, marius.mel...@kernkonzept.com > > > > Kernkonzept GmbH, Dresden, Germany, HRB 31129, CEO Dr.-Ing. Michael > > Hohmuth > > > From b251126f8d718ba4035140223518ba91a3434b2a Mon Sep 17 00:00:00 > > 2001 > > From: Marius Melzer <marius.mel...@kernkonzept.com> > > Date: Wed, 20 Dec 2023 13:36:18 +0100 > > Subject: [PATCH 2/2] Fix -Wnon-literal-null-conversion clang > > warning > > > > Clang warns that the NULL character literal '\0' is used as a > > pointer > > value. Change this to 0 in order to avoid the warning. > > --- > > libc/inet/resolv.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libc/inet/resolv.c b/libc/inet/resolv.c > > index cda3b399a..2f627ca08 100644 > > --- a/libc/inet/resolv.c > > +++ b/libc/inet/resolv.c > > @@ -1778,7 +1778,7 @@ int __read_etc_hosts_r( > > found: > > result_buf->h_name = *(result_buf->h_aliases++); > > result_buf->h_addr_list = (char**)(buf + > > HALISTOFF); > > - *(result_buf->h_addr_list + 1) = '\0'; > > + *(result_buf->h_addr_list + 1) = 0; > > h_addr0 = (struct in_addr*)(buf + INADDROFF); > > result_buf->h_addr = (char*)h_addr0; > > if (0) /* nothing */; > > -- > > 2.43.0 > > > > > From 31f2f58ed426e9f76f745f1d0656b65662025d0c Mon Sep 17 00:00:00 > > 2001 > > From: Marius Melzer <marius.mel...@kernkonzept.com> > > Date: Wed, 20 Dec 2023 13:31:47 +0100 > > Subject: [PATCH 1/2] Fix -Wgnu-designator clang warnings > > > > Clang warns about the use of old GNU-style designators. To avoid > > this, > > use the C99 designators instead. > > --- > > libc/stdlib/random.c | 14 +++++++------- > > 1 file changed, 7 insertions(+), 7 deletions(-) > > > > diff --git a/libc/stdlib/random.c b/libc/stdlib/random.c > > index b009c4310..05ce3fe84 100644 > > --- a/libc/stdlib/random.c > > +++ b/libc/stdlib/random.c > > @@ -139,8 +139,8 @@ static struct random_data unsafe_state = > > in the initialization of randtbl) because the state table > > pointer is set > > to point to randtbl[1] (as explained below).) */ > > > > - fptr : &randtbl[SEP_3 + 1], > > - rptr : &randtbl[1], > > + .fptr = &randtbl[SEP_3 + 1], > > + .rptr = &randtbl[1], > > > > /* The following things are the pointer to the state > > information table, > > the type of the current generator, the degree of the > > current polynomial > > @@ -152,13 +152,13 @@ static struct random_data unsafe_state = > > indexing every time to find the address of the last element > > to see if > > the front and rear pointers have wrapped. */ > > > > - state : &randtbl[1], > > + .state = &randtbl[1], > > > > - rand_type : TYPE_3, > > - rand_deg : DEG_3, > > - rand_sep : SEP_3, > > + .rand_type = TYPE_3, > > + .rand_deg = DEG_3, > > + .rand_sep = SEP_3, > > > > - end_ptr : &randtbl[sizeof (randtbl) / sizeof (randtbl[0])] > > + .end_ptr = &randtbl[sizeof (randtbl) / sizeof (randtbl[0])] > > }; > > > > > > -- > > 2.43.0 > > > > > _______________________________________________ > > devel mailing list -- devel@uclibc-ng.org > > To unsubscribe send an email to devel-le...@uclibc-ng.org > > _______________________________________________ > devel mailing list -- devel@uclibc-ng.org > To unsubscribe send an email to devel-le...@uclibc-ng.org -- Kernkonzept GmbH Sitz: Dresden HRB 31129 Geschäftsführer: Dr.-Ing. Michael Hohmuth
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-le...@uclibc-ng.org
