Re: [bug #63307] make 4.4 passes ignored SIGPIPE on to children

[Alejandro Colomar]

On 11/9/22 21:36, Paul D. Smith wrote:

Follow-up Comment #18, bug #63307 (project make):

I can see an argument for both sides ("give up immediately" and "run to
completion").  Most likely it's one of those things where different people
legitimately want different behaviors.

But I think that since all previous versions of GNU Make used the "give up
immediately" model, and it wasn't our intention to specifically change that,
we should preserve that behavior until/unless someone wants the opposite
behavior.

If we have "give up immediately" and you want to guard against that, you can
do so (say, redirecting output to /dev/null or whatever).  If we have "run to
completion" and that's not what you want, you don't have any way to get "give
up immediately" (unless we introduce an option which I don't want to do).

Not to mention the advantage that it's a much simpler (trivial) change to go
back to "give up immediately" :).


Not that I care about the behavior in this corner case, but was reading the list 
and thought of this:


You can actually get a rough guess of the intention of the user:

If -i or -k was used, "run to completion" is probably wanted; otherwise, "give 
up immediately" makes sense as a default.


No need for new flags.  Yes, this is reinterpreting the options for more than 
they were originally purposed, but in my head it makes sense. :)


Cheers,

Alex
--



OpenPGP_signature
Description: OpenPGP digital signature

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

[Paul D. Smith]

Follow-up Comment #18, bug #63307 (project make):

I can see an argument for both sides ("give up immediately" and "run to
completion").  Most likely it's one of those things where different people
legitimately want different behaviors.

But I think that since all previous versions of GNU Make used the "give up
immediately" model, and it wasn't our intention to specifically change that,
we should preserve that behavior until/unless someone wants the opposite
behavior.

If we have "give up immediately" and you want to guard against that, you can
do so (say, redirecting output to /dev/null or whatever).  If we have "run to
completion" and that's not what you want, you don't have any way to get "give
up immediately" (unless we introduce an option which I don't want to do).

Not to mention the advantage that it's a much simpler (trivial) change to go
back to "give up immediately" :).


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: GNU make for x86_64-pc-linux-gnu

[Paul Smith]

On Wed, 2022-11-09 at 14:58 +, Dadzio, Joerg wrote: 
> I want to inspect the preprocessor output of  ‘make’ for .c projects
> in order to make sure my set of ‘#define …’ instructions does work
> fine.

Note, there is no such thing as "preprocessor output of make". 
Makefiles are not C/C++ code, and the preprocessor runs on C/C++ code.

Make can invoke the preprocessor on your C/C++ code, if you write a
recipe that tells make how to do that.

> However, I can’t find the option to get it, and ‘-E’ did not work.
> Can you help me – or notify this note as a request, please?

When asking for help please include the EXACT command you typed (cut
and pasted from your terminal) and the EXACT output you got (again, cut
and pasted), plus information on what was wrong.

If you mean you invoked "make -E", then no, that will not work because
"-E" is an option to the C/C++ compiler, and make is not a C/C++
compiler: it can *RUN* a C/C++ compiler, but it is not itself a
compiler (see above).

If you mean you invoked some recipe in your makefile that ran the
compiler with the -E option, then please show what happened: "did not
work" is not a problem description we can help you with.


Just FWIW, here is a sample rule that could appear in your makefile to
invoke the preprocessor only (assuming your source files use ".c"
extensions):

%.i : %.c
$(CC) $(CPPFLAGS) -E -o $@ $<

Now if you run "make foo.i" then make will run the preprocessor on the
file "foo.c" and put the results in a file "foo.i".

GNU make for x86_64-pc-linux-gnu

[Dadzio, Joerg]

Hello dear GNU Org,

I want to inspect the preprocessor output of  'make' for .c projects in order 
to make sure my set of '#define ...' instructions does work fine.
However, I can't find the option to get it, and '-E' did not work.
Can you help me - or notify this note as a request, please?


With best regards,

Joerg Dadzio



Siemens AG

Digital Industries

Factory Automation

Product Creator 3

DI FA CTR ICO PRC3

Werner-von-Siemens-Str. 50

92224 Amberg, Germany

Tel.: +49 9621 963-3141

Fax: +49 9621 80-5167

mailto:joerg.dad...@siemens.com



www.siemens.com



Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive 
Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; 
Registered offices: Berlin and Munich, Germany; Commercial registries: 
Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

[PATCH 1/2] Fix duplicated __strchrnul() declaration error on OS/2 kLIBC

[KO Myung-Hun]

OS/2 kLIBC has __strchrnul(). But HAVE___STRCHRNUL is undefined.
'static' declarion of __strchrnul() causes an error with gcc4 because
OS/2 kLIBC declares __strchrnul() as public.

-
gcc -DHAVE_CONFIG_H -I. -I../src   -D__ST_MT_ERRNO__  -Wno-cast-qual 
-Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef 
-Wno-unused-function -Wno-unused-parameter -Wno-float-conversion 
-Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits 
-Wno-unsuffixed-float-constants -O2 -Zomf -Zmt -MT libgnu_a-fnmatch.o -MD -MP 
-MF .deps/libgnu_a-fnmatch.Tpo -c -o libgnu_a-fnmatch.o `test -f 'fnmatch.c' || 
echo './'`fnmatch.c
fnmatch.c:135:1: error: static declaration of '__strchrnul' follows non-static 
declaration
  135 | __strchrnul (s, c)
  | ^~~
In file included from fnmatch.c:34:
f:/lang/gcc/usr/include/string.h:198:10: note: previous declaration of 
'__strchrnul' was here
  198 | char*__strchrnul(const char *, int);
  |  ^~~
-
---
 lib/fnmatch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/fnmatch.c b/lib/fnmatch.c
index 4da8c5f..decfe7a 100644
--- a/lib/fnmatch.c
+++ b/lib/fnmatch.c
@@ -130,7 +130,7 @@ extern int errno;
 
 /* This function doesn't exist on most systems.  */
 
-# if !defined HAVE___STRCHRNUL && !defined _LIBC
+# if !defined HAVE___STRCHRNUL && !defined _LIBC && !defined __KLIBC__
 static char *
 __strchrnul (s, c)
  const char *s;
-- 
2.30.0

[PATCH 2/2] Fix assignment of read-only location error OS/2

[KO Myung-Hun]

-
gcc -DHAVE_CONFIG_H   -Isrc -I./src -Ilib -I./lib 
-DLIBDIR=\"/usr/local/lib\" -DLOCALEDIR=\"/usr/local/share/locale\"   
-D__ST_MT_ERRNO__  -O2 -Zomf -Zmt -MT src/job.o -MD -MP -MF $depbase.Tpo -c -o 
src/job.o src/job.c &&\
mv -f $depbase.Tpo $depbase.Po
src/job.c: In function 'construct_command_argv_internal':
src/job.c:3229:21: error: assignment of read-only location '*shellflags'
 3229 |   shellflags[0] = '/'; /* "/c" */
  | ^
-
---
 src/job.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/job.c b/src/job.c
index b78f279..22b4a82 100644
--- a/src/job.c
+++ b/src/job.c
@@ -3226,7 +3226,13 @@ construct_command_argv_internal (char *line, char 
**restp, const char *shell,
 
 # ifdef __EMX__ /* is this necessary? */
 if (!unixy_shell && shellflags)
-  shellflags[0] = '/'; /* "/c" */
+  {
+int n = strlen (shellflags) + 1;
+char *flags = alloca (n);
+memcpy (flags, shellflags, n);
+flags[0] = '/'; /* "/c" */
+shellflags = flags;
+  }
 # endif
 
 /* In .ONESHELL mode we are allowed to throw the entire current
-- 
2.30.0