[PATCH] Pacify Oracle Studio c99

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] Pacify Oracle Studio c99

Paul Eggert
* src/dep.h (DEP):
* src/function.c (struct function_table_entry):
Use unsigned int, not unsigned short.  Without this patch, c99
complains ‘warning: nonportable bit-field type’.
---
 src/dep.h      | 10 +++++-----
 src/function.c |  4 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/dep.h b/src/dep.h
index baa64df..d44a507 100644
--- a/src/dep.h
+++ b/src/dep.h
@@ -44,11 +44,11 @@ struct nameseq
     NAMESEQ (_t);                               \
     struct file *file;                          \
     const char *stem;                           \
-    unsigned short flags : 8;                   \
-    unsigned short changed : 1;                 \
-    unsigned short ignore_mtime : 1;            \
-    unsigned short staticpattern : 1;           \
-    unsigned short need_2nd_expansion : 1
+    unsigned int flags : 8;                     \
+    unsigned int changed : 1;                   \
+    unsigned int ignore_mtime : 1;              \
+    unsigned int staticpattern : 1;             \
+    unsigned int need_2nd_expansion : 1
 
 struct dep
   {
diff --git a/src/function.c b/src/function.c
index 715326d..b709754 100644
--- a/src/function.c
+++ b/src/function.c
@@ -38,8 +38,8 @@ struct function_table_entry
     unsigned char len;
     unsigned char minimum_args;
     unsigned char maximum_args;
-    unsigned char expand_args:1;
-    unsigned char alloc_fn:1;
+    unsigned int expand_args:1;
+    unsigned int alloc_fn:1;
   };
 
 static unsigned long
--
2.21.0


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Pacify Oracle Studio c99

Paul Smith-20
On Tue, 2019-08-27 at 12:32 -0700, Paul Eggert wrote:
> Use unsigned int, not unsigned short.  Without this patch, c99
> complains ‘warning: nonportable bit-field type’.

I saw this warning on Windows as well.  I seem to recall that this was
done on purpose to pack data structures more tightly, which can save a
lot of memory on large build systems.

However looking at it now I don't think it will actually end up saving
any space.  It ostensibly saves two bytes per struct dep but they
cannot be obtained in any way that lets us actually avoid the extra 2
bytes of dead space, at least not on any common architecture today.


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Pacify Oracle Studio c99

Paul Eggert
Paul Smith wrote:
> I saw this warning on Windows as well.  I seem to recall that this was
> done on purpose to pack data structures more tightly, which can save a
> lot of memory on large build systems.
>
> However looking at it now I don't think it will actually end up saving
> any space.

I don't either. In a struct, 'unsigned int foo : 8;' should behave like
'unsigned short foo : 8;', and similarly if you change 'short' to 'char', or
change '8' to '1'. At least, that should be true for typical compilers (the C
standard doesn't say exactly what should happen).

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Pacify Oracle Studio c99

Dennis Clarke
On 8/27/19 4:23 PM, Paul Eggert wrote:

> Paul Smith wrote:
>> I saw this warning on Windows as well.  I seem to recall that this was
>> done on purpose to pack data structures more tightly, which can save a
>> lot of memory on large build systems.
>>
>> However looking at it now I don't think it will actually end up saving
>> any space.
>
> I don't either. In a struct, 'unsigned int foo : 8;' should behave like
> 'unsigned short foo : 8;', and similarly if you change 'short' to
> 'char', or change '8' to '1'. At least, that should be true for typical
> compilers (the C standard doesn't say exactly what should happen).
>

Could this be a good time to point to stdint.h and uintX_t for X bits?
May clarify matters.  However that leads to another funny question.
I have been running configure over and over on various machines with c99
type CFLAGS and also without them. One thing I do see is configure seems
to be happy about "checking for good max_align_t" where we get a no for
C99 and a yes if I specify no language standard at all. Well max_align_t
is a C11 type of concept and seems to have no bearing on the build or
tests running regardless.

So I have to ask is GNU Make shooting for C89 or C99 type dialect ?


Dennis

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make