[LTP] [RFC PATCH 1/1] config.mk: Explicitly set used C and C++ standard

[LTP] [RFC PATCH 1/1] config.mk: Explicitly set used C and C++ standard

[Petr Vorel]

Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
IMHO If we really want to require old standard, we should explicitly say which one.
I suppose passing a flag is appropriate way than to use c89 as CC variable.
---
 include/mk/config.mk.default | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/mk/config.mk.default b/include/mk/config.mk.default
index dff3479db..ff67486a1 100644
--- a/include/mk/config.mk.default
+++ b/include/mk/config.mk.default
@@ -54,8 +54,8 @@ bindir			:= ${exec_prefix}/bin
 libdir			:= ${exec_prefix}/lib
 mandir			:= ${datarootdir}/man
 
-CPPFLAGS		:=
-CFLAGS			:= -g -O2
+CPPFLAGS		:= -std=c++98
+CFLAGS			:= -g -O2 -std=gnu89
 LDLIBS			:=
 LDFLAGS			:=
 
-- 
2.11.0

[LTP] [RFC PATCH 1/1] config.mk: Explicitly set used C and C++ standard

[Cyril Hrubis]

Hi!
> IMHO If we really want to require old standard, we should explicitly say which one.
> I suppose passing a flag is appropriate way than to use c89 as CC variable.

Where do we say that we require old standard?

All I can think of is that we should produce portable code, which is
something completely different that sticking to a single C standard
revision...

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] [RFC PATCH 1/1] config.mk: Explicitly set used C and C++ standard

[Petr Vorel]

Hi Cyril,

> > IMHO If we really want to require old standard, we should explicitly say which one.
> > I suppose passing a flag is appropriate way than to use c89 as CC variable.

> Where do we say that we require old standard?
We don't, I just understood it from Alexeys' comments.

[1]:
Please also use checkpatch and fix any errors/warnings reported:
    total: 5 errors, 37 warnings

[2]:
Used default options for gcc in OL6, I guess in my case it has --std=gnu89
by default and you have something different, may be gnu99...

> All I can think of is that we should produce portable code, which is
> something completely different that sticking to a single C standard
> revision...
Make sense :-). Thanks for your comments, please forget on the patch.


Kind regards,
Petr

[1]: http://lists.linux.it/pipermail/ltp/2017-April/004230.html
[2]: http://lists.linux.it/pipermail/ltp/2017-April/004315.html