> On Apr 24, 2024, at 11:44, Linus Torvalds <[email protected]>
> wrote:
>
> On Wed, 24 Apr 2024 at 11:13, Dirk Hohndel via subsurface
> <[email protected]> wrote:
>>
>> Those with better skills in interpreting error messages... what am I missing?
>
> I think the line numbers are wrong, probably because of inlining etc.
>
> The real issue is _probably_ on line 525:
I don't think you are correct... I got fooled by the weird error output.
The real error is in line 290:
/<<PKGBUILDDIR>>/core/uemis-downloader.cpp:290:32: error: ‘%s’ directive output
between 0 and 12 bytes may cause result to exceed ‘INT_MAX’
[-Werror=format-truncation=]
290 | snprintf(buf, len, "%s/%s", path, name);
| ^~
Reading through the logic behind the warning it is... questionable. And turning
the
warning into an error of course makes this all even more annoying.
https://stackoverflow.com/questions/51534284/how-to-circumvent-format-truncation-warning-in-gcc
I think this will make the compiler shut up and the build not fail. It's...
demented,
MHO, but what can I say...
diff --git a/core/uemis-downloader.cpp b/core/uemis-downloader.cpp
index 37bdfce23..ff64f39ba 100644
--- a/core/uemis-downloader.cpp
+++ b/core/uemis-downloader.cpp
@@ -285,10 +285,12 @@ static char *build_filename(const char *path, const char
*name)
int len = strlen(path) + strlen(name) + 2;
char *buf = (char *)malloc(len);
#if WIN32
- snprintf(buf, len, "%s\\%s", path, name);
+ l = snprintf(buf, len, "%s\\%s", path, name);
#else
- snprintf(buf, len, "%s/%s", path, name);
+ l = snprintf(buf, len, "%s/%s", path, name);
#endif
+ if(l < 0 or l > len)
+ printf("this compiler is broken -- snprintf returned %d\n", l);
return buf;
}
Now, separately, the below code also could create stupid warnings. So I elected
to
create even more silly code to fix that as well.
>
> snprintf(fl, 13, "ANS%d.TXT", filenumber);
>
> where the compiler things that the 13 byte buffer is not enough for
> some integers (ie "%d" could be "-2147483648", which is 11 characters
> just there). Thus the "0..12" thing.
>
> And yes, we do that clamping to 0..9999, but I suspect the compiler
> can't quite follow it, and doesn't quite figure out that the max is
> 3+4+4+1.
>
> And it probably all depends on compiler version and just random
> phase-of-the-moon things.
>
> But my guess is that you should change the magic "13" to be something
> bigger, preferably something that is safe for any integer so that the
> compiler doesn't have to understand the clamping logic.
>
> Alternatively, make it easier for the compiler to understand the
> clamping: maybe make 'filenumber' be unsigned (and make the "%d" be
> "%u), and then just do
>
> if (filenumber > UEMIS_MAX_FILES)
> filenumber = 0;
>
> which is a *lot* easier for a compiler to understand than the
> currently "conditional signed modulus" operation it does.
@@ -517,14 +519,10 @@ static void uemis_increased_timeout(int *timeout)
static char *build_ans_path(const char *path, int filenumber)
{
- char *intermediate, *ans_path, fl[13];
+ char *intermediate, *ans_path, fl[15];
- /* Clamp filenumber into the 0..9999 range. This is never necessary,
- * as filenumber can never go above UEMIS_MAX_FILES, but gcc doesn't
- * recognize that and produces very noisy warnings. */
- filenumber = filenumber < 0 ? 0 : filenumber % 10000;
-
- snprintf(fl, 13, "ANS%d.TXT", filenumber);
+ uint16_t fn = (filenumber < 0 || filenumber > UEMIS_MAX_FILES) ? 0 :
filenumber;
+ snprintf(fl, 13, "ANS%u.TXT", fn);
intermediate = build_filename(path, "ANS");
ans_path = build_filename(intermediate, fl);
free(intermediate);
This feels equally demented, but at least stops the warning 🤦🏻♂️
/D_______________________________________________
subsurface mailing list -- [email protected]
To unsubscribe send an email to [email protected]
