20 Dec
2023
20 Dec
'23
1:39 p.m.
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.melzer(a)kernkonzept.com
Kernkonzept GmbH, Dresden, Germany, HRB 31129, CEO Dr.-Ing. Michael Hohmuth
21 Dec
21 Dec
6:38 a.m.
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.melzer(a)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.melzer(a)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.melzer(a)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(a)uclibc-ng.org
To unsubscribe send an email to devel-leave(a)uclibc-ng.org
11:09 a.m.
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,
--
Kernkonzept GmbH
Sitz: Dresden
HRB 31129
Geschäftsführer: Dr.-Ing. Michael Hohmuth
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.melzer(a)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.melzer(a)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.melzer(a)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(a)uclibc-ng.org
To unsubscribe send an email to devel-leave(a)uclibc-ng.org
_______________________________________________
devel mailing list -- devel(a)uclibc-ng.org
To unsubscribe send an email to devel-leave(a)uclibc-ng.org
4 Jan
4 Jan
3:27 p.m.
Hi Marius,
both patches pushed. Thanks.
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.melzer(a)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.melzer(a)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.melzer(a)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(a)uclibc-ng.org
To unsubscribe send an email to devel-leave(a)uclibc-ng.org
137
days inactive
152
days old
3 comments
3 participants
participants (3)
-
Marcus Hähnel -
Marius Melzer -
Waldemar Brodkorb