bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-wget] Regression since wget 1.10: no_prefix function is *bad*


From: Marlin Frickenschmidt
Subject: [Bug-wget] Regression since wget 1.10: no_prefix function is *bad*
Date: Fri, 10 May 2013 20:27:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130428 Thunderbird/17.0.5

Hello dear wget maintainers,
I want to report a bug of sorts. It is not a direct bug that impedes the
operation of wget to normal users, but one which basically makes it
impossible to add more command-line options to wget without sooner or
later making wget suddenly SIGABRT - without any inclination to show a
proper error whatsover.

The reason for this is the "no_prefix" function, which is supposed to
prepend the string "no-" to a given string (for disabling certain
command line options). The function makes the assumption that the total
length of all command line option names together won't exceed 1024
characters, because the buffer storing the strings for all the
"no-"-prefixed command line options is only chosen that large. And so if
it gets too big, there is just a silent abort(), no error message, no
nothing.

Why don't we use standard functions like asprintf to prepend strings,
and instead build an own, completely broken function for it? Perhaps
there are good reasons for building the string yourself instead of using
the standard library; I don't know. In any case, there is no excuse for
silently abort()ing without an error message. That is the only thing I
am grumpy about, really...

I hope this can be fixed in the next release for the sake of all wget
developers around. I just spent two hours debugging this, and really
couldn't believe my eyes when I found the reason for it. It is hell stupid.

Cheers,
Marlin

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]