Re: lseek: Value too large for defined data type

On Sat, 21 Jul 2007 01:06:34 -0700 David Schwartz <davids@xxxxxxxxxxxxx> wrote:
| On Jul 20, 7:49 pm, phil-news-nos...@xxxxxxxx wrote:
|
|> One of these days we need to fix all this ... basically migrate to purely
|> 64-bit file offset platforms. It should "just work" without any changes
|> needed at that point, if they do it right (which is not a given). If old
|> programs compiled on legacy 32-bit file offset platforms break, so be it.
|
| It is all fixed. It does just work. No changes are needed.
|
| All that is needed is '-D_FILE_OFFSET_BITS=64' and complaining about
| that is like arguing that PTHREADS support doesn't "just work" because
| you have to specify '-pthread' on the command line when you compile/
| link.

"No changes are needed." and "All that is needed is ..." are contrary.
Adding the '-D_FILE_OFFSET_BITS=64' is a change.

If the nature of pthreads requires the compiler to generate different code,
then sure, pthreads usage needs to be specified. If there was a reason to
never use anything but pthreads, then I'd say the compiler should default
to doing what pthreads needs.

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.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-07-26-0748@xxxxxxxx |
|------------------------------------/-------------------------------------|
.

Relevant Pages

  • Re: Problem with the lambda form
    ... foreign-function interface and pthreads. ... What about lower level stuff such as, oh, a thread-safe evaluator, thread-aware ... The bare minimum needed would be for the thread creation primitive you added to create some thread-local structures, and for there to be a way to get a globally-unique identifier for the current thread. ... It is a weakness of CL that whereas there's a macro system to provide hooks into the compiler there's nothing analogous to provide hooks into the GC. ...
    (comp.lang.lisp)
  • Re: threading in g++
    ... but there are also human questions and answers. ... >> I assume pthreads library is compiled with gcc, ... > It could have been compiled with Intel 'icc', or any other compiler. ... >> standards but is reported to allow atomic operations depending on the ...
    (comp.unix.programmer)
  • Re: Access Thread Local - performance - ?
    ... __thread specifier which doesn't require pthreads or syscalls to access.. ... Few people have the luxury of using a C99 compiler, ...
    (comp.programming.threads)
  • C++, Pthreads & other threading technologies
    ... I've written a few programs in C++ that use Pthreads. ... In Linux and the g++ compiler we have to use the ``-pthread'' option - *not only* to link the threading library, but to do other changes to some underlying tools. ... For example - which variant of the errno variable is used in programs using Boost or TBB - the one usied in POSIX threads or the ``ordinary'' one? ... In particular, it seems that in the degenerate case of using only one thread, Boost threads are slightly faster than Pthreads - linking Boost libraries does not prevent aggressive optimizations when compiling, while using ``-pthread'' does. ...
    (comp.programming.threads)