[uClibc]Re: annoying warning message

[Manuel Novoa III]

Miles,

On Thu, Feb 21, 2002 at 06:01:27PM +0900, Miles Bader wrote:
> mjn3 at codepoet.org (Manuel Novoa III) writes:
> > That's because the remapping to a nonexistent *64() function, which
> > you were counting on to generate an error, _no_longer_takes_place_!
> > So the program will fail mysteriously when trying to handle a file
> > larger than 2GB...
> 
> Look, I know all that.
> 
> > The whole point of the warning generated was to let the user know that
> > large files weren't supported.  That doesn't just mean that the *64()
> > funcs aren't supported... which you apparently mistakenly believe.
> 
> No, I don't `mistakenly believe' that (I don't believe that at all).

Given that I don't know anything about you, and can only go by what you
wrote, that certainly wasn't evident from your last message.  You broke down
programs into two types:

   (1) Programs that define _GNU_SOURCE to get all the various
       convenience functions it has traditionally enabled, and which
       don't give a rats ass about large-file support.  Of course they'll
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       happily _use_ it if it's enabled by _GNU_SOURCE, since it's
       basically transparent, but they don't really care, because they
       don't use the `64-bit' specific interfaces (in particular, they
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
       don't care at all whether `fseek has been remapped to fseek64').

and

   (2) Programs that define _GNU_SOURCE expecting to get large-file only
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       functions (e.g., fseek64) and will break horribly if they're not
       ^^^^^^^^^^^^^^^^^^^^^^^^^
       present.
 
       [Are there any in this category at all?]
 
       The warning messages in this case could be helpful, but are not
       really necessary, because the compile will barf on the actual uses
       of the large-file-only functions (e.g. fseek64).

You completlely ingored the category of programs that defined _GNU_SOURCE
but did care about large file support accessed through the normal non *64
function names.  In fact, you seemed to be implying that programs needing
large file functionality would _only_ access it through the *64 functions,
as you went on to write:

       Now, consider, if "features.h" were to keep its current behavior of
       #undefing unavailable large-file support, but _not_ emit the annoying
       warning message; what will happen?
 
       Programs in category (1) will continue to work, and as a bonus won't
       annoy people.

       Programs in category (2) will continue to fail to compile, because the
       64-bit specific interfaces aren't there.

Again, no mention of the third category of programs that I mentioned above.
And in fact, as I pointed out in my reply, not all programs in your category (1)
_would_ work as intended.  As I said, I don't know anything about you and,
going by what you wrote, you didn't seem to have a clear understanding of the
large file issues.

> _GNU_SOURCE's main purpose is to enable _interface changes_ that wouldn't
> otherwise be enabled because of incompatibilities with standards, then
> _interface differences_ are the most important thing.  This is why I
> consider the non-definition of the xxx64 interfaces the most serious
> repercussion of _GNU_SOURCE mixed with DO_LFS=false.
> 
> It's quite reasonable for macros with a _specific_ meaning
> (e.g. _LARGEFILE_SOURCE) to emit a warning/error if something is broken,
> but the situation is a lot different for _GNU_SOURCE, because it's a
> `catch-all' macro, that defines the kitchen sink.  People turn it on for
> all sorts of reasons, and you have to be practical about how you interpret
> it.
> 
> The bottom line is that your change is going to result in tons of warning
> messages for _lots_ of programs, which are completely pointless 99.999% of
> the time, and which have no way of being turned off.  It may strike you as
> being a great and useful thing, but it's going to simply annoy most
> people.

Ahh... is that the issue?  Why on earth didn't you say so in the first place?
At no time before this message did you mention that the _quantity_ of warnings
was an issue.  I must confess that I had overlooked that aspect, as I've been
working exclusively over the past several months on the new stdio
implementation, and haven't been building applications other than test programs.

Ok, let's address the problem of how to turn them off.  One possibility, other
than grep -v  ;-), would be that an error be generated instead of a warning...
something like
  
  You are compiling with an option (_GNU_SOURCE or _XOPEN_SOURCE perhaps)
  which implies some form of large file support.  However, uClibc was
  configured without large file support enabled and you may be limited
  to files < 2GB.  If this is ok, add -DNO_LFS_OK to your compiler options.

Then a build would stop on the first file, the user would be advised of the
situation, and could take the appropriate action.  In fact, it wouldn't be
difficult at all to simply have the gcc wrapper test for an environment variable
to disable the warning so that you wouldn't have to modify your configuration/
makefiles at all.

Other suggestions welcome.

> > Finally, if you want to continue this thread, please read and _understand_
> > what is going on in features.h and stdio.h before you reply.  That would
> > save _me_ some time... and annoyance.
> 
> Oh, please quit with the stupid petty insults; I understand very clearly
> what's going on.

I'm sorry you feel insulted... but just so you know, I spent over an hour and
a half working on that reply.  I've spent almost as much time composing this
one.  I let _my_ irritation at the amount of time spent come through in my
reply and I apologize.  But please know that I carefully went over what you
wrote, and the fact that you "know what's going on" was not clear at all.
In fact, as I've tried to explain in this message,  I was quite convinced
that you _didn't_, and that you needed an explanation of the reason for the
warning.

Manuel