Re: lseek: Value too large for defined data type

On Jul 26, 5:54 am, phil-news-nos...@xxxxxxxx wrote:

These two things are not analogous. In the case of file offset, there is
virtually no need for any application to not be using 64 bit offsets. It
should be the default. Cases where a program needs to _not_ use them would
be very small embedded code and such. But we still have plenty of need for
non-pthreads code that making pthreads the default does not make sense.

Actually, I disagree on both counts. With respect to the first claim,
there *is* code that uses 32 bit offsets internally. It will not work
properly with 64 bit offsets to the OS. There is a need for these
applications to not be using 64 bit offsets. With respect to the
second claim, even non-pthreads code has to use libraries, and those
libraries are almost always also used by pthreads code.

DS

.

Relevant Pages

  • Re: How does an executable know that it needs a specific *.dll or *.so to be able to run?
    ... compare with a Linux ?shared object? ... shared objects/shared libraries in Unix are always linked ... using the name of the functions, not using offsets. ... to opinions held by my employer, Sun Microsystems. ...
    (comp.unix.programmer)
  • Re: shared vs static library
    ... I sort of got the impression that libraries are shared, ... change and the application needs to be recompiled with the new offsets, ... so upgrading a library file is not the same as upgrading a DLL file on ... Shared libraries are always dynamically linked (although ...
    (comp.unix.programmer)
  • Re: F95 I/O filesize problems
    ... the runtime libraries that have byte offsets in bytes (in many implementations). ... and some libraries protect against file write wraparound by not allowing more than 2G-1 unless the executable has a special LARGEFILE attribute. ...
    (comp.lang.fortran)