Re: git on HP NonStop
On 08/22/2012 06:38 PM, Joachim Schmitz wrote: -Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Tuesday, August 21, 2012 4:06 AM To: Joachim Schmitz Cc: 'Johannes Sixt'; 'Jan Engelhardt'; git@vger.kernel.org Subject: Re: git on HP NonStop Joachim Schmitz j...@schmitz-digital.de writes: OK, so let's have a look at code, current git, builtin/cat-file.c, line 196: void *contents = contents; This variable is set later in an if branch (if (print_contents == BATCH), but not in the else branch. It is later used always under the same condition as the one under which it is set. Apparently is is malloc_d storage (there a free(content);), so there's no harm al all in initializing it with NULL, even if it only appeases a stupid compiler. It actually is harmful. See below. Harmful to initialize with NULL or to use that undefined behavoir? I checked what our compiler does here: after having warned about vlues us used before it is set: it actually dies seem to have initializes the value to 0 resp. NULL. So here there's no harm done in avoiding undefined behavior and set it to 0 resp NULL in the first place. There is harm in tricking future programmers into thinking that the initialization actually means something, which some of them do. It's unlikely that you're the one to maintain that code forever, and the var = var idiom is used widely within git with a clear meaning as a hint to programmers who read a bit of git code. If they aren't used to that idiom, they usually investigate it in the code and pretty quickly realize that what it means. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git on HP NonStop
From: Andreas Ericsson [mailto:a...@op5.se] Sent: Thursday, August 23, 2012 10:24 AM To: Joachim Schmitz Cc: 'Junio C Hamano'; 'Johannes Sixt'; 'Jan Engelhardt'; git@vger.kernel.org Subject: Re: git on HP NonStop On 08/22/2012 06:38 PM, Joachim Schmitz wrote: -Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Tuesday, August 21, 2012 4:06 AM To: Joachim Schmitz Cc: 'Johannes Sixt'; 'Jan Engelhardt'; git@vger.kernel.org Subject: Re: git on HP NonStop Joachim Schmitz j...@schmitz-digital.de writes: OK, so let's have a look at code, current git, builtin/cat-file.c, line 196: void *contents = contents; This variable is set later in an if branch (if (print_contents == BATCH), but not in the else branch. It is later used always under the same condition as the one under which it is set. Apparently is is malloc_d storage (there a free(content);), so there's no harm al all in initializing it with NULL, even if it only appeases a stupid compiler. It actually is harmful. See below. Harmful to initialize with NULL or to use that undefined behavoir? I checked what our compiler does here: after having warned about vlues us used before it is set: it actually dies seem to have initializes the value to 0 resp. NULL. So here there's no harm done in avoiding undefined behavior and set it to 0 resp NULL in the first place. There is harm in tricking future programmers into thinking that the initialization actually means something, which some of them do. Hmm, OK, I can agree to that. It's unlikely that you're the one to maintain that code forever, It is unlike for me to ever have to maintain this code. Currently that's Junio's job and I won't apply for in ;-) and the var = var idiom is used widely within git This is overstating it a bit. I went thru the entire code and reported all places I could find in an earlier email. I went back and counted: It is used in 11 files, at 15 places, for 21 variables. OK, I may have missed a few more that were in code paths my compiler didn't see, but still some 21+ isn't really much. with a clear meaning Only if you call undefined behavior a 'clear meaning! as a hint to programmers who read a bit of git code. If they aren't used to that idiom, they usually investigate it in the code and pretty quickly realize that what it means. Whether I realize what it means, is irrelevant, my compiler does not and warns about it, and as per the ANSI/ICO C standard it invokes undefined behavior. If a proper initialization is meaningless for these cases, don't do them at all, let the stupid compiler complain about it and the clever programmer check whether the warning is useful, but don't avoid a compiler warning on one compiler by introducing undefined behavior and provoke a compiler warning on another. Bye, Jojo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git on HP NonStop
-Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Tuesday, August 21, 2012 4:06 AM To: Joachim Schmitz Cc: 'Johannes Sixt'; 'Jan Engelhardt'; git@vger.kernel.org Subject: Re: git on HP NonStop Joachim Schmitz j...@schmitz-digital.de writes: OK, so let's have a look at code, current git, builtin/cat-file.c, line 196: void *contents = contents; This variable is set later in an if branch (if (print_contents == BATCH), but not in the else branch. It is later used always under the same condition as the one under which it is set. Apparently is is malloc_d storage (there a free(content);), so there's no harm al all in initializing it with NULL, even if it only appeases a stupid compiler. It actually is harmful. See below. Harmful to initialize with NULL or to use that undefined behavoir? I checked what our compiler does here: after having warned about vlues us used before it is set: it actually dies seem to have initializes the value to 0 resp. NULL. So here there's no harm done in avoiding undefined behavior and set it to 0 resp NULL in the first place. The next one, builtin/fast-export.c, line 486: struct commit *commit = commit; it is set in a switch statement, but not in every case, as far as I can see. Hmm, maybe it is, and I just get lost in the code And it is used directly after the switch, hopefully set to something reasonable. Why take the risk and not set it to NULL? Ditto. Next one, builtin/rev-list.c, line 390: int reaches = reaches, all = all; revs.commits = find_bisection(revs.commits, reaches, all, bisect_find_all); Seem pretty pointless to initialize them, provided find_bisection doesn't read them. Does it? That is why they are not initializations but marks to the compiler to signal you may be stupid enough to think they are used before initialized or assigned, but that is not the case. Initializing them would be pointless. Next one, fast-import.c, line 2268: struct object_entry *oe = oe; os gets set in en if and an else branch, but not in then intermediate else if branch! Look again. If the recent code is too complex for you to understand, go back to 10e8d68 (Correct compiler warnings in fast-import., 2007-02-06) and read the function. The control flow of the early part of that function dictates that either oe is assigned *or* inline_data is set to 1. When inline_data is false, oe is always set. The compiler was too stupid to read that, and that is why the (confusing) idiom to mark it for the stupid compiler was used. There are a few reasons why I do not think this self-assignment idiom or initializing the variable to an innocuous-looking random value is a particularly good thing to do when you see compiler warnings. If the compiler suspects the variable might be unused, you should always look at it and follow the flow yourself. Once you know it is a false alarm, you can use the idiom to squelch the warning, and it at the same serves as a note to others that you verified the flow and made sure it is a false warning. When the next person wants to touch the code, if the person knows the use of the idiom, it only serves as a warning to be extra careful not to introduce a new codepath that reads the variable without setting, as the compiler no longer helps him. If the person who touches the code is as clueless as the compiler and cannot follow the codepath to see the variable is never used uninitialized, the result will be a lot worse. That is the reason why I do not think the idiom to squelch the compiler is such a good thing. Careless people touch the code, so oe = oe initialization carefully placed in the original version does not necessarily stay as a useful documentation. But if you use oe = NULL as a way to squelch the warning in the first place, it is no better than oe = oe. In a sense, it is even worse, as it just looks like any other initialization and gives a false impression that the remainder of the code is written in such a way that it tolerates oe being NULL in any codepath, or there is some assignment before that before the code reaches places where oe cannot be NULL. That is different from what oe = oe initializaion documents-- -in the codepath protected by if (inline_data), it isn't just oe can safely be NULL there; instead it is oe can safely be *any* value there, because we don't use it. Of course, if you explicitly initialized oe to NULL, even if you introduce a codepath where oe cannot be NULL later, you won't get a warning from the compiler, so it is no better than oe = oe. And that is the reason why I do not think initialization to an innocuous-looking random value (e.g. NULL) is a good answer, either. When both are not good, replacing oe = oe with oe = NULL didn't make much sense
RE: git on HP NonStop
From: Jan Engelhardt [mailto:jeng...@inai.de] Sent: Sunday, August 19, 2012 6:26 PM To: Joachim Schmitz Cc: 'Junio C Hamano'; git@vger.kernel.org Subject: RE: git on HP NonStop On Tuesday 2012-08-14 17:52, Joachim Schmitz wrote: @@ -98,6 +99,11 @@ #include stdlib.h #include stdarg.h #include string.h +#ifdef __TANDEM +# include strings.h /* for strcasecmp() */ + typedef int intptr_t; /* not int * ?!? */ + typedef unsigned int uintptr_t; /* not unsigned int * ?!? */ Of course not. intptr_t is an integral value capable of holding a pointer; it is not a pointer to int (because that would really be redundant to int*.) OK, thanks for the clarification. Another issue I stumbled across: There are numerous places (well, some 10) were something like the following is done int var = var; char *othervar = othervar; Here this leads to Compiler warnings 'variable var is used before its value is set' on NonStop. This self-initialization seems to be a GCC extension (?), but even gcc has a -Winit-self option to warn about this. Shouldn't that better be like the following? int var = 0; char *othervar = NULL; What is the reason for using that self-init stuff? I don't think it is really portable, is it? Bye, Jojo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git on HP NonStop
Am 8/20/2012 12:36, schrieb Joachim Schmitz: int var = var; char *othervar = othervar; ... What is the reason for using that self-init stuff? I don't think it is really portable, is it? It is used to avoid var may be used uninitialized warnings for some compilers. Officially (according to the C standard), it is undefined behavior. But I've observed considerable resistance by Junio to fix this properly. Therefore, unless you can show that your compiler generates unusable code you better live with the self-initialization warnings. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git on HP NonStop
From: Johannes Sixt [mailto:j.s...@viscovery.net] Sent: Monday, August 20, 2012 12:57 PM To: Joachim Schmitz Cc: 'Jan Engelhardt'; 'Junio C Hamano'; git@vger.kernel.org Subject: Re: git on HP NonStop Am 8/20/2012 12:36, schrieb Joachim Schmitz: int var = var; char *othervar = othervar; ... What is the reason for using that self-init stuff? I don't think it is really portable, is it? It is used to avoid var may be used uninitialized warnings for some compilers. Well, it results in a similar warning on NonStop. var is used before it is set and I think this is equally bad. In either case we don't know what the content of that var is. E.g. in wt_status.c the variable 'status' is set at only one place, but later it is switched on. If lucky we get to the default case and die. So why not just int status = 0; Officially (according to the C standard), it is undefined behavior. Yes, I had that suspicion. Not good to rely in this... But I've observed considerable resistance by Junio to fix this properly. What's the reason behind that? Therefore, unless you can show that your compiler generates unusable code you better live with the self-initialization warnings. So far I can't, so I guess I'll have to live with the warnings, but don't quite like it. -- Hannes Bye, Jojo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git on HP NonStop
Johannes Sixt j.s...@viscovery.net writes: Am 8/20/2012 12:36, schrieb Joachim Schmitz: int var = var; char *othervar = othervar; ... What is the reason for using that self-init stuff? I don't think it is really portable, is it? It is used to avoid var may be used uninitialized warnings for some compilers. Officially (according to the C standard), it is undefined behavior. But I've observed considerable resistance by Junio to fix this properly. I had resisted - int foo = foo; + int foo = 0; in the past. If some compiler is not seeing that foo is never used uninitialized, such a compiler will generate an unnecessary initialization, so it is not a _proper_ fix anyway (in fact, I do not think a proper fix exists, short of simplifying the code so that less sophisticated compilers can see that foo is never used uninitialized). So, no, I never resisted a proper fix. I resisted swapping an unsatisfactory workaround with another. Between the two unsatisfactory workarounds, the latter (explicit and unnecessary assignment to an innocuous value) is lessor of two evils, so I do not particularly mind it, though. Indeed, I think more recent history shows that we have such changes. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git on HP NonStop
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Monday, August 20, 2012 6:30 PM
To: Johannes Sixt
Cc: Joachim Schmitz; 'Jan Engelhardt'; git@vger.kernel.org
Subject: Re: git on HP NonStop
Johannes Sixt j.s...@viscovery.net writes:
Am 8/20/2012 12:36, schrieb Joachim Schmitz:
int var = var;
char *othervar = othervar;
...
What is the reason for using that self-init stuff? I don't think it
is really portable, is it?
It is used to avoid var may be used uninitialized warnings for some
compilers. Officially (according to the C standard), it is undefined
behavior. But I've observed considerable resistance by Junio to fix
this properly.
I had resisted
- int foo = foo;
+ int foo = 0;
in the past. If some compiler is not seeing that foo is never used
uninitialized,
such a compiler will generate an unnecessary initialization, so it is not
a
_proper_ fix anyway (in fact, I do not think a proper fix exists, short of
simplifying the code so that less sophisticated compilers can see that
foo is
never used uninitialized).
So, no, I never resisted a proper fix. I resisted swapping an
unsatisfactory
workaround with another.
Between the two unsatisfactory workarounds, the latter (explicit and
unnecessary assignment to an innocuous value) is lessor of two evils, so I
do not
particularly mind it, though. Indeed, I think more recent history shows
that we
have such changes.
OK, so let's have a look at code, current git,
builtin/cat-file.c, line 196:
void *contents = contents;
This variable is set later in an if branch (if (print_contents == BATCH),
but not in the else branch. It is later used always under the same condition
as the one under which it is set.
Apparently is is malloc_d storage (there a free(content);), so there's no
harm al all in initializing it with NULL, even if it only appeases a stupid
compiler.
The next one, builtin/fast-export.c, line 486:
struct commit *commit = commit;
it is set in a switch statement, but not in every case, as far as I can see.
Hmm, maybe it is, and I just get lost in the code
And it is used directly after the switch, hopefully set to something
reasonable.
Why take the risk and not set it to NULL?
Next one, builtin/rev-list.c, line 390:
int reaches = reaches, all = all;
revs.commits = find_bisection(revs.commits, reaches, all,
bisect_find_all);
Seem pretty pointless to initialize them, provided find_bisection doesn't
read them. Does it?
I'm too Next one, lazy to check... I'd just set them to 0 and stop worrying.
Next one, fast-import.c, line 2268:
struct object_entry *oe = oe;
os gets set in en if and an else branch, but not in then intermediate else
if branch!
It is checked for !NULL later, so it should really get initialized to NULL
in the first place!
Same file, line 2437, same variable name, same story!
Same file, line 2616, variable e, it is used in an if branch but set after
that!
Same file again, line 2917, variable oe again. Same story as above.
Next file, ll-merge.c, line
static const struct ll_merge_options default_opts;
Somewhat different story here, compiler warning claims const variable
default_opts requires an initializer
Possible fix:
static const struct ll_merge_options default_opts = {0};
next file, match-trees.c, line 75ff:
const unsigned char *elem1 = elem1;
const unsigned char *elem2 = elem2;
const char *path1 = path1;
const char *path2 = path2;
unsigned mode1 = mode1;
unsigned mode2 = mode2;
Some get set, some not, depending on code path, but all get used, with
possibly bogus content.
Next file, merge-recursive.c, line 1903:
struct tree *mrtree = mrtree;
passed on my address to another function, which hopefully knows how to treat
it. It woult be learer and simpler to just have
struct tree *mrtree = NULL;
wouldn't it?
Next file, run-command.c, line 272:
int failed_errno = failed_errno;
Set deeply nested in some cases. Seems to be used reasonably, but again, why
take chanses= 0 is a goot errno ;-)
Next file, submodule.c, line 265:
struct commit *left = left, *right = right;
As far as I can see it is not set properly before it gets used in some
cases.
Next filen, transport.c, line 106:
int cmp = cmp, len;
I seem to see code paths whet it is used without being set properly
Next file, vcs-svn/svndiff.c, line 299 oh, that one has been fixed and
initialized to -1.
Next (and last) file, wt-status.c, line 267:
int status = status;
It apparently does get set properly before use. So here it once may once
again just make a compiler happy to set it to 0.
Bye, Jojo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
Re: git on HP NonStop
Joachim Schmitz j...@schmitz-digital.de writes: OK, so let's have a look at code, current git, builtin/cat-file.c, line 196: void *contents = contents; This variable is set later in an if branch (if (print_contents == BATCH), but not in the else branch. It is later used always under the same condition as the one under which it is set. Apparently is is malloc_d storage (there a free(content);), so there's no harm al all in initializing it with NULL, even if it only appeases a stupid compiler. It actually is harmful. See below. The next one, builtin/fast-export.c, line 486: struct commit *commit = commit; it is set in a switch statement, but not in every case, as far as I can see. Hmm, maybe it is, and I just get lost in the code And it is used directly after the switch, hopefully set to something reasonable. Why take the risk and not set it to NULL? Ditto. Next one, builtin/rev-list.c, line 390: int reaches = reaches, all = all; revs.commits = find_bisection(revs.commits, reaches, all, bisect_find_all); Seem pretty pointless to initialize them, provided find_bisection doesn't read them. Does it? That is why they are not initializations but marks to the compiler to signal you may be stupid enough to think they are used before initialized or assigned, but that is not the case. Initializing them would be pointless. Next one, fast-import.c, line 2268: struct object_entry *oe = oe; os gets set in en if and an else branch, but not in then intermediate else if branch! Look again. If the recent code is too complex for you to understand, go back to 10e8d68 (Correct compiler warnings in fast-import., 2007-02-06) and read the function. The control flow of the early part of that function dictates that either oe is assigned *or* inline_data is set to 1. When inline_data is false, oe is always set. The compiler was too stupid to read that, and that is why the (confusing) idiom to mark it for the stupid compiler was used. There are a few reasons why I do not think this self-assignment idiom or initializing the variable to an innocuous-looking random value is a particularly good thing to do when you see compiler warnings. If the compiler suspects the variable might be unused, you should always look at it and follow the flow yourself. Once you know it is a false alarm, you can use the idiom to squelch the warning, and it at the same serves as a note to others that you verified the flow and made sure it is a false warning. When the next person wants to touch the code, if the person knows the use of the idiom, it only serves as a warning to be extra careful not to introduce a new codepath that reads the variable without setting, as the compiler no longer helps him. If the person who touches the code is as clueless as the compiler and cannot follow the codepath to see the variable is never used uninitialized, the result will be a lot worse. That is the reason why I do not think the idiom to squelch the compiler is such a good thing. Careless people touch the code, so oe = oe initialization carefully placed in the original version does not necessarily stay as a useful documentation. But if you use oe = NULL as a way to squelch the warning in the first place, it is no better than oe = oe. In a sense, it is even worse, as it just looks like any other initialization and gives a false impression that the remainder of the code is written in such a way that it tolerates oe being NULL in any codepath, or there is some assignment before that before the code reaches places where oe cannot be NULL. That is different from what oe = oe initializaion documents---in the codepath protected by if (inline_data), it isn't just oe can safely be NULL there; instead it is oe can safely be *any* value there, because we don't use it. Of course, if you explicitly initialized oe to NULL, even if you introduce a codepath where oe cannot be NULL later, you won't get a warning from the compiler, so it is no better than oe = oe. And that is the reason why I do not think initialization to an innocuous-looking random value (e.g. NULL) is a good answer, either. When both are not good, replacing oe = oe with oe = NULL didn't make much sense, especially when the former _could_ be used better by more careful people. And that is the resistance J6t remembers. But when recent compilers started to warn oe = oe that itself is undefined, the equation changed. The idiom ceased to be a way to squelch the incorrect compiler warning (which was the primary point of its use---the documentation value is secondary, as what we document is we are squelching a false alarm, but we no longer are squelching anything). See 4a5de8d (vcs-svn: avoid self-assignment in dummy initialization of pre_off, 2012-06-01), and 58ebd98 (vcs-svn/svndiff.c: squelch false unused warning from gcc, 2012-01-27) that it updated, for
RE: git on HP NonStop
On Tuesday 2012-08-14 17:52, Joachim Schmitz wrote: @@ -98,6 +99,11 @@ #include stdlib.h #include stdarg.h #include string.h +#ifdef __TANDEM +# include strings.h /* for strcasecmp() */ + typedef int intptr_t; /* not int * ?!? */ + typedef unsigned int uintptr_t; /* not unsigned int * ?!? */ Of course not. intptr_t is an integral value capable of holding a pointer; it is not a pointer to int (because that would really be redundant to int*.) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git on HP NonStop
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Tuesday, August 14, 2012 4:44 PM
To: Joachim Schmitz
Subject: Re: git on HP NonStop
Joachim Schmitz j...@schmitz-digital.de writes:
Interesting, I never mentioned Tandem did I, But still you recognized
HP NonStop as that.
No, *you* did in your patch #ifdef.
Ah, I see.
Well, I do care about that platform, but if you don't, there's not
much point in me trying to get Tandem specific patches applied, is it?
As long as the change is isolated (i.e. compilation without #define
TANDEM
__TANDEM actually
for other people will produce byte-for-byte identical result as before),
and
cleanly made (i.e. the resulting source code is not littered with #ifdef
TANDEM in many places), I do not think there is a reason not to have such
a
patchset.
It isn't in many places, only 2 places in git-compat-util.h so far:
/usr/local/bin/diff -EBbu ./git-compat-util.h.orig ./git-compat-util.h
--- ./git-compat-util.h.orig2012-07-30 15:50:38 -0500
+++ ./git-compat-util.h 2012-08-12 11:26:46 -0500
@@ -74,7 +74,8 @@
# define _XOPEN_SOURCE 500
# endif
#elif !defined(__APPLE__) !defined(__FreeBSD__) !defined(__USLC__)
\
- !defined(_M_UNIX) !defined(__sgi) !defined(__DragonFly__)
+ !defined(_M_UNIX) !defined(__sgi) !defined(__DragonFly__) \
+ !defined(__TANDEM)
#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs
600 for S_ISLNK() */
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#endif
@@ -98,6 +99,11 @@
#include stdlib.h
#include stdarg.h
#include string.h
+#ifdef __TANDEM
+# include strings.h /* for strcasecmp() */
+ typedef int intptr_t; /* not int * ?!? */
+ typedef unsigned int uintptr_t; /* not unsigned int * ?!? */
+#endif
#include errno.h
#include limits.h
#include sys/param.h
Too much? The 2nd part is not necessary NonStop specific, any idea for a
better way?
There there's Makefile:
/usr/local/bin/diff -EBbu ./Makefile.orig ./Makefile
--- ./Makefile.orig 2012-07-30 15:50:38 -0500
+++ ./Makefile 2012-08-14 06:07:16 -0500
@@ -1297,6 +1297,45 @@
NO_CURL =
NO_EXPAT =
endif
+ifeq ($(uname_S),NONSTOP_KERNEL)
+ CC = cc -c99 # needs some C99 features, inline is just one of them
+ CFLAGS= -g -O
+ prefix = /usr/local
+
+ # as detected by './configure'
+ #NO_CURL = YesPlease # missdetected, disabled, see below
+ NEEDS_SSL_WITH_CURL = YesPlease # added manually, see above
+ HAVE_LIBCHARSET_H=YesPlease
+ NEEDS_LIBICONV = YesPlease # needs libiconv first, changed further
down
+ NO_SYS_SELECT_H=UnfortunatelyYes
+ NO_D_TYPE_IN_DIRENT = YesPlease
+ NO_HSTRERROR=YesPlease
+ NO_STRCASESTR=YesPlease
+ NO_FNMATCH_CASEFOLD = YesPlease
+ NO_MEMMEM = YesPlease
+ NO_STRLCPY = YesPlease
+ NO_SETENV = YesPlease
+ NO_UNSETENV = YesPlease
+ NO_MKDTEMP = YesPlease
+ NO_MKSTEMPS = YesPlease
+ OLD_ICONV=UnfortunatelyYes # currently libiconv-1.9.1
+ NO_REGEX=YesPlease # Why? ToDo?
+ NO_PTHREADS=UnfortunatelyYes # ToDo? Using PUT, maybe?
+
+ # our's are in ${prefix}/bin
+ PERL_PATH = ${prefix}/bin/perl
+ PYTHON_PATH = ${prefix}/bin/python
+
+ # not detected (nor checked for) by './configure'
+ COMPAT_CFLAGS += -DSA_RESTART=0 # we don't have SA_RESTART on
NonStop
+ COMPAT_CFLAGS += -DHAVE_STRING_H=1 # needed in
compat/fnmatch/fnmatch.c
+ NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease # we don't have that on
NonStop
+ NO_NSEC = YesPlease # we don't have that on NonStop
+ NO_PREAD = YesPlease # we could use floss_pread though?
+ NO_MMAP = YesPlease # we could use floss_mmap though?
+ # newly implemented further down
+ NO_POLL = YesPlease # we could use floss_poll though?
+endif
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
NO_PREAD = YesPlease
@@ -1526,6 +1565,11 @@
LIB_4_CRYPTO = $(OPENSSL_LINK) -lcrypto
endif
endif
+ifndef NO_GETTEXT
+ifndef LIBC_CONTAINS_LIBINTL
+ EXTLIBS += -lintl
+endif
+endif
ifdef NEEDS_LIBICONV
ifdef ICONVDIR
BASIC_CFLAGS += -I$(ICONVDIR)/include
@@ -1538,11 +1582,6 @@
ifdef NEEDS_LIBGEN
EXTLIBS += -lgen
Endif
-ifndef NO_GETTEXT
-ifndef LIBC_CONTAINS_LIBINTL
- EXTLIBS += -lintl
-endif
-endif
ifdef NEEDS_SOCKET
EXTLIBS += -lsocket
endif
@@ -1591,6 +1630,11 @@
BASIC_CFLAGS += -DNO_GETTEXT
USE_GETTEXT_SCHEME ?= fallthrough
endif
+ifdef NO_POLL
+ NO_SYS_POLL_H = YesPlease
+ COMPAT_CFLAGS += -DNO_POLL -Icompat/win32 # so it finds poll.h
+ COMPAT_OBJS += compat/win32/poll.o
+endif
ifdef NO_STRCASESTR
COMPAT_CFLAGS += -DNO_STRCASESTR
COMPAT_OBJS += compat/strcasestr.o
How das that look to you?
Finally, I would prefer to see any message that is addressed to me as
the project maintainer to be Cc'ed to the list. I feel 80% of my
