Testing file offset bits?

[Stephen Kelly]

On 04/22/2013 08:46 PM, Alexander Neundorf wrote:
> On Monday 22 April 2013, Stephen Kelly wrote:
>> Users of kdelibs will be using either Qt file APIs or something from
>> kde_file.h, which will still use the definition.
>>
>> If we use our imagination, we could say that potentially someone could
>> be using open directly and relying on the definition having been set
>> elsewhere. That would not be smart on their part, is vanishingly rare
>> (because obviously they'd use Qt APIs instead), and I don't think we
>> should care.
> We are not talking about building kdelibs or even KDE SC here, we are talking
> about everything out there building against kdelibs.

Yes, exactly. My comment above should be read with that in mind.

> They all get those 64-bit-related definitions with KDE4, and I think they also
> got them with KDE3 and maybe also KDE2.

Even if it has been there for a long time, that doesn't make it a good idea.

Anyway, any 3rd party code which uses kde_file.h will still get the 
definition, even if they don't use KDE_open, and use open directly instead.

> Nobody is forced to use KDECompilerSettings.cmake anymore with KDE frameworks.
> This file contains optional compiler settings, which are considered useful. If
> a developer wants to take care of this himself, he simply does not have to use
> that file.

Right. However, note that my solution of putting the define in the 
INTERFACE_COMPILE_DEFINITIONS of kdecore (or whatever target kde_file.h 
ends up in) takes the choice out of the 3rd parties hands. Even if they 
don't use KDECompilerSettings.cmake, they still get the define, so my 
solution is probably 'more safe' from that point of view.

> Why break apps which may rely on those flags being present and force them to
> take care of this themselves, probably only after some user reported breakage
> on large files after upgrading ?

That would be the case if KDECompilerSettings.cmake is not used, and it 
would be the case if kdecore is not used.

I don't think it is a general responsibility of KDE to provide compiler 
flags to projects which are unaware of them anyway, and are doing their 
own thing anyway (by using posix open directly, going against the 
documentation of both QFile and kde_file.h).

Particularly as we're creating a 'breaking release' (KF5), and generally 
making our code more appropriate for ourselves, I don't think we need to 
be concerned with non-conformant use of KDE4 libs and I don't think we 
need to be concerned with imagined expectations for compiler flags an 
imagined 3rd party relies on.

> You may say that direct usage of open() etc. is considered bad in kdelibs or
> KDE SC, but it is valid POSIX API, and any 3rd party developer is free to use
> it and I'm far from saying that it is per se a bad thing.

kde_file.h says that its open() is a replacement, so it should be used 
instead of the direct open().

My opinion is that we should confine defines to where we know they are 
required (as I did in my commit), and note such changes in 
http://techbase.kde.org/Development/ECM_SourceIncompatChanges or 
similar. I can't speak for anyone elses opinion on it.

Thanks,

Steve.