[uClibc]Re: annoying warning message

[Miles Bader]

mjn3 at codepoet.org (Manuel Novoa III) writes:
> No, this is good... and I assure you that it isn't there just to annoy.
> Since _LARGEFILE_SOURCE is implied by _GNU_SOURCE and someone building
> an application with _GNU_SOURCE defined is _expecting_ that, for instance,
> fseek() has been remapped to fseek64(),

There are two types of programs that define _GNU_SOURCE:

  (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').

      This is most programs.

      There will now be annoying warning messages emitted for every file
      compiled in this category.

  (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).

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.

   [Programs that don't use _GNU_SOURCE, of course, won't be affected]

So -- a benefit in the common-case (1), and no real drawbacks.  Sounds
like a good change to me!

> Also please note that after emitting the warning, all large-file related
> defines are #undef'd.  This should address a problem that _you_ pointed
> out last month...

The _other_ behavior (the #undefing) of the new code is good -- it
prevents libc from pretending to have largefile support when it doesn't.
However, the warning is completely unnecessary.  And annoying.

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'