[uClibc]Re: annoying warning message

[Manuel Novoa III]

Miles,


On Thu, Feb 21, 2002 at 02:27:25PM +0900, Miles Bader wrote:
> 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').

It might be clearer to you if I said that they may expect that the standard
file functions (fopen(), fseek(), etc) can deal with large files...
an assumption that would be invalid if uClibc was built without largefile
support and hence, in my opinion, worth a warning.

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

You seem to have a problem with the distinction between _LARGEFILE64_SOURCE,
where the *64() funcs are prototyped, and _LARGEFILE_SOURCE, where the
normal-name functions are transparently remapped to work with large files.
_GNU_SOURCE implies _both_.  Also, it seems you haven't thought out the
implications of the new #undef behavior of features.h; more on that below.

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

Many, perhaps most, will work... but any trying to deal with large files
(> 2Gb) on a 32 bit arch will likely fail sometimes.

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

What more can I say about your "category (2)"...

>    [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.

Unfortunately, you can't have it both ways...

Assume uClibc was built without large file support and features.h #undef's
the large-file related marcros.  While a program won't compile if it
explicitly calls one of the *64() funcs, it very well may compile without
a warning if it uses the normal file functions (fopen(), fwrite(), fseek())
but expects them to work for large files.  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...

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.

Now, I grant you, in the majority of cases the warning will be unnecessary
as the files worked on will not be that large.  That's why I said I'd be
open to rephrasing it for clarity.  The fact that I've had to spend as much
time trying to explain to you why the warning is useful in the first place
makes it clear that the wording should be changed.  But that doesn't mean
the warning is completely unnecessary as you assert.

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.

Manuel