Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #5300 > unrolled thread

OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc)

Back to article view | Back to comp.lang.c

Contents

  OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) David Mathog <dmathog@gmail.com> - 2011-06-02 13:52 -0700
    Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) Nobody <nobody@nowhere.com> - 2011-06-02 22:16 +0100
    Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) David Mathog <dmathog@gmail.com> - 2011-06-02 14:18 -0700
      Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) David Mathog <dmathog@gmail.com> - 2011-06-02 14:37 -0700
        Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) Ian Collins <ian-news@hotmail.com> - 2011-06-03 09:59 +1200
          Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) David Mathog <dmathog@gmail.com> - 2011-06-02 15:18 -0700
            Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) Ian Collins <ian-news@hotmail.com> - 2011-06-03 10:35 +1200
              Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) David Mathog <dmathog@gmail.com> - 2011-06-02 16:01 -0700
                Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) ImpalerCore <jadill33@gmail.com> - 2011-06-03 06:45 -0700
                  Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) David Mathog <dmathog@gmail.com> - 2011-06-03 12:13 -0700
                    Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) jacob navia <jacob@spamsink.net> - 2011-06-03 21:35 +0200
                    Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) Ian Collins <ian-news@hotmail.com> - 2011-06-04 08:48 +1200
                    Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) Nobody <nobody@nowhere.com> - 2011-06-03 23:28 +0100
                    Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) gordonb.myhxj@burditt.org (Gordon Burditt) - 2011-06-04 00:32 -0500
                      Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) jacob navia <jacob@spamsink.net> - 2011-06-04 08:06 +0200
                        Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) gordonb.c5zg9@burditt.org (Gordon Burditt) - 2011-06-04 22:03 -0500
                        Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) Ian Collins <ian-news@hotmail.com> - 2011-06-05 15:47 +1200
                          Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) jacob navia <jacob@spamsink.net> - 2011-06-05 09:48 +0200
                            Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) Ian Collins <ian-news@hotmail.com> - 2011-06-05 20:22 +1200
                              Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) jacob navia <jacob@spamsink.net> - 2011-06-05 15:59 +0200
                            Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) "Joel C. Salomon" <joelcsalomon@gmail.com> - 2011-06-06 09:09 -0400
                              Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) jacob navia <jacob@spamsink.net> - 2011-06-06 15:24 +0200
                          Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) David Mathog <dmathog@gmail.com> - 2011-06-06 10:17 -0700
                            Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) Ian Collins <ian-news@hotmail.com> - 2011-06-07 07:46 +1200
                              Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) David Mathog <dmathog@gmail.com> - 2011-06-09 09:35 -0700
                                Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) Keith Thompson <kst-u@mib.org> - 2011-06-09 11:18 -0700
                                  Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) David Mathog <dmathog@gmail.com> - 2011-06-09 12:52 -0700
                                Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) Ian Collins <ian-news@hotmail.com> - 2011-06-10 09:14 +1200
              Re: OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc) Keith Thompson <kst-u@mib.org> - 2011-06-02 16:04 -0700

Page 1 of 2  [1] 2  Next page →

#5300 — OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc)

Since this is OT I will keep it very brief.  C code that compiles
cleanly on linux with

  gcc -std=c99 -Wall -pedantic -lm -o test test.c

has problems on Solaris 8 (Sparc) with gcc 4.3.3, where it cannot find
the definitions of NAN, FP_NAN, FP_INFINITE, or the prototypes (and
most likely the functions, if some of this wasn't an error that kept
it from getting that far) for fmax, fmin, isinf, isnormal, and round.

Anybody know why this happens, or better yet, how to work around it?

Thanks,

David Mathog

[toc] | [next] | [standalone]

#5304

On Thu, 02 Jun 2011 13:52:35 -0700, David Mathog wrote:

> Since this is OT I will keep it very brief.  C code that compiles
> cleanly on linux with
> 
>   gcc -std=c99 -Wall -pedantic -lm -o test test.c
> 
> has problems on Solaris 8 (Sparc) with gcc 4.3.3, where it cannot find
> the definitions of NAN, FP_NAN, FP_INFINITE, or the prototypes (and
> most likely the functions, if some of this wasn't an error that kept
> it from getting that far) for fmax, fmin, isinf, isnormal, and round.
> 
> Anybody know why this happens, or better yet, how to work around it?

These definitions/declarations belong in <math.h>, which is part of the
standard library (libc) rather than gcc. Linux uses GNU libc, Solaris has
its own version (which may or may not support C99; from your report, it
appears not to).

[toc] | [prev] | [next] | [standalone]

#5305

On Jun 2, 1:52 pm, David Mathog <dmat...@gmail.com> wrote:

This may have something to do with it:

**************test.c***************
#include <stdlib.h>
#include <stdio.h>
#include <math.h>

int main(void){
double dv;

  dv=0.0;
  fprintf(stdout,"DEBUG zero %llX\n",dv);
  dv=log(-1);
  fprintf(stdout,"DEBUG nan  %llX\n",dv);
  dv=log(0);
  fprintf(stdout,"DEBUG -inf %llX\n",dv);
  dv=-log(0);
  fprintf(stdout,"DEBUG  inf %llX\n",dv);

  exit(EXIT_SUCCESS);
}
******************************************

Compile with:  gcc -std=c99 -lm -o test test.c

On linux (Opteron machine):

./test
DEBUG zero 0
DEBUG nan  7FF8000000000000
DEBUG -inf FFF0000000000000
DEBUG  inf 7FF0000000000000

and on Solaris (Sparc):

./test
DEBUG zero 0
DEBUG nan  FFF0000000000000
DEBUG -inf FFF0000000000000
DEBUG  inf 7FF0000000000000

So even though they are both IEEE math, there is a difference in the
bits that are set, so that
on the Opteron one can distinguish nan,-inf,and inf from the bit
pattern, but that isn't the case
on the Sparc.  At least with the compiler options I used - for all I
know there may be some switch
that makes NAN on the Sparc (v9 architecture, I think) like it is on
the Opteron.

Regards,

David Mathog

[toc] | [prev] | [next] | [standalone]

#5308

On Jun 2, 2:18 pm, David Mathog <dmat...@gmail.com> wrote:

> and on Solaris (Sparc):
>
> ./test
> DEBUG zero 0
> DEBUG nan  FFF0000000000000
> DEBUG -inf FFF0000000000000
> DEBUG  inf 7FF0000000000000
>

Using Forte 7 compiler (5.4) there is such a flag:

cc -xlibmieee -lm -o test test.c
./test
DEBUG zero 0
DEBUG nan  FFFFFFFFFFFFFFFF
DEBUG -inf FFF0000000000000
DEBUG  inf 7FF0000000000000

Anybody know what the gcc equivalent is?  If I can get the compiler to
generate
code with the right bits, writing isinf etc. becomes a lot easier..

Thanks,

David Mathog

[toc] | [prev] | [next] | [standalone]

#5311

On 06/ 3/11 09:37 AM, David Mathog wrote:
> On Jun 2, 2:18 pm, David Mathog<dmat...@gmail.com>  wrote:
>
>> and on Solaris (Sparc):
>>
>> ./test
>> DEBUG zero 0
>> DEBUG nan  FFF0000000000000
>> DEBUG -inf FFF0000000000000
>> DEBUG  inf 7FF0000000000000
>>
>
> Using Forte 7 compiler (5.4) there is such a flag:

Is there a good reason why you are using an OS and tools that are over a 
decade old?

Both where EOL'd long ago.

With this century's tools, your code compiles fine and gives the same 
result as Linux on amd64.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#5313

On Jun 2, 2:59 pm, Ian Collins <ian-n...@hotmail.com> wrote:

> Is there a good reason why you are using an OS and tools that are over a
> decade old?

There is a reason.  While the OS is that old, gcc 4.3.3 is pretty
recent.  That's why I'm surprised gcc doesn't work here.  Digging
around in the Forte documentation all of these bits and pieces seem to
be there, but in sunmath.h and libsunmath, rather than math.h and
libm, and gcc doesn't seem to work around these missing pieces. Not
even for fmax (and fmin) which only need

  #define fmax(A,B) ( A>=B ? A : B)

in the math.h header file.

Thanks,

David Mathog

[toc] | [prev] | [next] | [standalone]

#5316

On 06/ 3/11 10:18 AM, David Mathog wrote:
> On Jun 2, 2:59 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
>
>> Is there a good reason why you are using an OS and tools that are over a
>> decade old?
>
> There is a reason.  While the OS is that old, gcc 4.3.3 is pretty
> recent.  That's why I'm surprised gcc doesn't work here.

Don't forget the OS pre-dates C99!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#5320

On Jun 2, 3:35 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 06/ 3/11 10:18 AM, David Mathog wrote:
>
> > On Jun 2, 2:59 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
>
> >> Is there a good reason why you are using an OS and tools that are over a
> >> decade old?
>
> > There is a reason.  While the OS is that old, gcc 4.3.3 is pretty
> > recent.  That's why I'm surprised gcc doesn't work here.
>
> Don't forget the OS pre-dates C99!

Right, but the present issues all revolve around IEEE-754 double
support, which dates back to 1985 or so.
I think "nobody" hit it on the head a few posts forward, regarding
libm and math.h.  If the compiler
distribution included Gnu libc then the age of the underlying OS
wouldn't matter.  Unfortunately in this case
the compiler uses libm from the OS, and so no matter how new the
compiler, some parts of it are stuck in the past with the OS.


Regards,

David Mathog

[toc] | [prev] | [next] | [standalone]

#5356

On Jun 2, 7:01 pm, David Mathog <dmat...@gmail.com> wrote:
> On Jun 2, 3:35 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>
> > On 06/ 3/11 10:18 AM, David Mathog wrote:
>
> > > On Jun 2, 2:59 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
>
> > >> Is there a good reason why you are using an OS and tools that are over a
> > >> decade old?
>
> > > There is a reason.  While the OS is that old, gcc 4.3.3 is pretty
> > > recent.  That's why I'm surprised gcc doesn't work here.
>
> > Don't forget the OS pre-dates C99!
>
> Right, but the present issues all revolve around IEEE-754 double
> support, which dates back to 1985 or so.
> I think "nobody" hit it on the head a few posts forward, regarding
> libm and math.h.  If the compiler
> distribution included Gnu libc then the age of the underlying OS
> wouldn't matter.  Unfortunately in this case
> the compiler uses libm from the OS, and so no matter how new the
> compiler, some parts of it are stuck in the past with the OS.

The same issue occurs with the Microsoft C Runtime and C99 printf
support.  You can compile 'printf( "%lu %zu\n", sizeof (int), sizeof
(int) );' with gcc -std=c99 in the MinGW environment, but because it
links in the Microsoft Runtime, the printf statement just generates "4
zu".  Similar problems occur for modifiers 't' and 'll'.

Best regards,
John D.

[toc] | [prev] | [next] | [standalone]

#5376

On Jun 3, 6:45 am, ImpalerCore <jadil...@gmail.com> wrote:

> The same issue occurs with the Microsoft C Runtime and C99 printf
> support.  You can compile 'printf( "%lu %zu\n", sizeof (int), sizeof
> (int) );' with gcc -std=c99 in the MinGW environment, but because it
> links in the Microsoft Runtime, the printf statement just generates "4
> zu".  Similar problems occur for modifiers 't' and 'll'.

Which raises the question - why do we do that?  Is there some reason
why the compilers never seem to supply the equivalent of libc?  Sure,
there are going to be instances where one can get away with using the
native OS libc, but clearly there are lots of other cases where it
doesn't work out so well.  And I would wager it works out less and
less well as the target OS ages.

Here is another test which failed indicating a Solaris vs. Linux
difference:

 36 Fail 0000000.053 22c22
< NaN,Inf,Inf,-Inf,NaN
---
> nan,inf,inf,-inf,nan

Do any of the C standards say what fprintf("%lf\n",dval) is supposed
to emit in each of these cases?  Is it really free to use alternate
capitalization?  I can see the upside in ignoring the punctuation when
reading in these values, but not so much in emitting them.

Regards,

David

[toc] | [prev] | [next] | [standalone]

#5379

Le 03/06/11 21:13, David Mathog a écrit :
> On Jun 3, 6:45 am, ImpalerCore<jadil...@gmail.com>  wrote:
>
>> The same issue occurs with the Microsoft C Runtime and C99 printf
>> support.  You can compile 'printf( "%lu %zu\n", sizeof (int), sizeof
>> (int) );' with gcc -std=c99 in the MinGW environment, but because it
>> links in the Microsoft Runtime, the printf statement just generates "4
>> zu".  Similar problems occur for modifiers 't' and 'll'.
>
> Which raises the question - why do we do that?  Is there some reason
> why the compilers never seem to supply the equivalent of libc?

Not all compilers do this.

The lcc-win compiler has its own basic library in 32 and 64 bits since
one of the goals was to support C99. It is the only compiler under
windows to support C99.

And this was done by a single individual working for years like a fool.

gcc never did it for windows and, apparently, for Solaris either.

[toc] | [prev] | [next] | [standalone]

#5383

On 06/ 4/11 07:13 AM, David Mathog wrote:
> On Jun 3, 6:45 am, ImpalerCore<jadil...@gmail.com>  wrote:
>
>> The same issue occurs with the Microsoft C Runtime and C99 printf
>> support.  You can compile 'printf( "%lu %zu\n", sizeof (int), sizeof
>> (int) );' with gcc -std=c99 in the MinGW environment, but because it
>> links in the Microsoft Runtime, the printf statement just generates "4
>> zu".  Similar problems occur for modifiers 't' and 'll'.
>
> Which raises the question - why do we do that?  Is there some reason
> why the compilers never seem to supply the equivalent of libc?

Probably to avoid chaos when the OS and application are linked to 
different version of libc!

> Sure,
> there are going to be instances where one can get away with using the
> native OS libc, but clearly there are lots of other cases where it
> doesn't work out so well.  And I would wager it works out less and
> less well as the target OS ages.

Quite.  That's why you run old code with old compilers on old OSs.  If 
you want newer language features, use a newer OS.  Whinging that an OS 
and compiler that are sufficiently old to be no longer supported don't 
do what you want is pointless.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#5393

On Fri, 03 Jun 2011 12:13:09 -0700, David Mathog wrote:

> Which raises the question - why do we do that?  Is there some reason
> why the compilers never seem to supply the equivalent of libc?  Sure,
> there are going to be instances where one can get away with using the
> native OS libc, but clearly there are lots of other cases where it
> doesn't work out so well.

It typically works out better than trying to use a compiler-specific libc,
which tends to fall down the moment you need to use the OS and thus use
the OS' DLLs which are linked against the OS' libc.

A compiler-specific libc would work better on Windows than on most Unices
due to the different dynamic linking models. On Windows, imported symbols
are tied to a specific DLL, so you can have multiple versions of MSVCRT
co-exist within a single process. On most Unices, you end up with symbol
conflicts. OTOH, with Windows' model you can run into problems if a
library function expects the caller to provide a FILE*, a pointer obtained
from malloc(), etc.

[toc] | [prev] | [next] | [standalone]

#5415

>> The same issue occurs with the Microsoft C Runtime and C99 printf
>> support. You can compile 'printf( "%lu %zu\n", sizeof (int), sizeof
>> (int) );' with gcc -std=c99 in the MinGW environment, but because it
>> links in the Microsoft Runtime, the printf statement just generates "4
>> zu". Similar problems occur for modifiers 't' and 'll'.
> 
> Which raises the question - why do we do that?  Is there some reason
> why the compilers never seem to supply the equivalent of libc?  Sure,

The interfaces between libc and the rest of the OS (not the interface
between libc and the user program) may not be documented and changes
may not be announced.  (I'm thinking especially of the syscall
interface to the kernel).  This isn't too bad if the OS version of
libc is open-source, but the compiler vendor needs to track OS
changes.  Someone who tries to duplicate that may be operating in
constant catch-up mode to keep up with the changes.  The OS developers
figure that THEY are in charge of libc and if they make a change
that stays compatible (e.g. a matching libc/kernel change that won't
affect dynamic-linked programs, which works great unless you try
to use an OLD libc on a NEW kernel or vice-versa) they aren't going
to worry about that other libc some compiler vendor added.

This is less of an issue with math functions, *printf, and the
string library and such since they usually don't have much of an
interface with the kernel in areas where changes occur.

However, it's a problem trying to replace *PART* of libc.
Things also tend to go very badly if you try to link to multiple
versions of the same library.


> there are going to be instances where one can get away with using the
> native OS libc, but clearly there are lots of other cases where it
> doesn't work out so well.  And I would wager it works out less and
> less well as the target OS ages.

I can see problems where the OS (and its version of libc) is young
enough to be under active development.

> Here is another test which failed indicating a Solaris vs. Linux
> difference:
> 
> 36 Fail 0000000.053 22c22
> < NaN,Inf,Inf,-Inf,NaN
> ---
>> nan,inf,inf,-inf,nan
> 
> Do any of the C standards say what fprintf("%lf\n",dval) is supposed
> to emit in each of these cases?  

C90 didn't require that there BE any such thing as an Inf or NaN and
I'm fairly sure that output capitalization is not specified.

> Is it really free to use alternate
> capitalization?  I can see the upside in ignoring the punctuation when
> reading in these values, but not so much in emitting them.

Interesting.  I recall a very, very old compiler (pre-C90) that
infinite looped in printf() if you passed it an Inf or Nan (essentially,
printf() knew nothing about such things.  It kept trying to divide
by 10 until the number got small, which it never did.

[toc] | [prev] | [next] | [standalone]

#5416

Le 04/06/11 07:32, Gordon Burditt a écrit :
>>> The same issue occurs with the Microsoft C Runtime and C99 printf
>>> support. You can compile 'printf( "%lu %zu\n", sizeof (int), sizeof
>>> (int) );' with gcc -std=c99 in the MinGW environment, but because it
>>> links in the Microsoft Runtime, the printf statement just generates "4
>>> zu". Similar problems occur for modifiers 't' and 'll'.
>>
>> Which raises the question - why do we do that?  Is there some reason
>> why the compilers never seem to supply the equivalent of libc?  Sure,
>
> The interfaces between libc and the rest of the OS (not the interface
> between libc and the user program) may not be documented and changes
> may not be announced.  (I'm thinking especially of the syscall
> interface to the kernel).  This isn't too bad if the OS version of
> libc is open-source, but the compiler vendor needs to track OS
> changes.  Someone who tries to duplicate that may be operating in
> constant catch-up mode to keep up with the changes.  The OS developers
> figure that THEY are in charge of libc and if they make a change
> that stays compatible (e.g. a matching libc/kernel change that won't
> affect dynamic-linked programs, which works great unless you try
> to use an OLD libc on a NEW kernel or vice-versa) they aren't going
> to worry about that other libc some compiler vendor added.
>
> This is less of an issue with math functions, *printf, and the
> string library and such since they usually don't have much of an
> interface with the kernel in areas where changes occur.
>

Exactly, and those functions should be provided by the compiler,
not the OS.

> However, it's a problem trying to replace *PART* of libc.
> Things also tend to go very badly if you try to link to multiple
> versions of the same library.
>

This is absolutely no problem if the linker links to a compiler
version of the libc that THEN calls the OS libc if necessary.
>
>> there are going to be instances where one can get away with using the
>> native OS libc, but clearly there are lots of other cases where it
>> doesn't work out so well.  And I would wager it works out less and
>> less well as the target OS ages.
>
> I can see problems where the OS (and its version of libc) is young
> enough to be under active development.
>

Bogus, since the libc interfaces didn't change since C89 in most
cases.

[toc] | [prev] | [next] | [standalone]

#5466

>> This is less of an issue with math functions, *printf, and the
>> string library and such since they usually don't have much of an
>> interface with the kernel in areas where changes occur.
>>
> 
> Exactly, and those functions should be provided by the compiler,
> not the OS.

Well, if the functions are provided by the compiler *AND* the OS,
you've got potential problems, which the C standard covers by saying
that trying to redefine library routines leads to undefined behavior.
If the functions are provided by the compiler *AND NOT* the OS,
then what do the OS-supplied programs use to call the kernel?  Are
they all written in Perl?  Most of these problems are related to
how the *OS* libc is laid out.  If it's available as one monolithic
chunk, all-or-nothing, then there's a good chance what you can
replace is everything or nothing, with no options for anything in
between.

>> However, it's a problem trying to replace *PART* of libc.
>> Things also tend to go very badly if you try to link to multiple
>> versions of the same library.
>>
> 
> This is absolutely no problem if the linker links to a compiler
> version of the libc that THEN calls the OS libc if necessary.

This is true if you are simply adding missing routines that the
OS libc does not supply that can be written in Standard C.
Unfortunately, things like printf conversions don't qualify, and
they are also common C99 deficiencies in an old OS libc.

There can be problems trying to replace printf().  The compiler
libc defines its own printf(), which calls some of the stdio routines,
which call malloc(), which is in the OS libc.  (If you also replace
malloc(), then you have to interface to sbrk() or mmap(), or whatever
malloc() uses to get memory from the OS.)  The OS libc also includes
its own (ancient) version of printf() which doesn't support a lot
of the new C99 conversions.  Now you've got two printf()s in the
same program.  This is not guaranteed to work.  It's not guaranteed
to break, either, but it's possible to have it fail, for example,
with duplicate symbol errors on printf().  I've worked with a real
system where this was an issue.  Getting around it by carefully
crafting the *compiler* libc only didn't work.


>>> there are going to be instances where one can get away with using the
>>> native OS libc, but clearly there are lots of other cases where it
>>> doesn't work out so well.  And I would wager it works out less and
>>> less well as the target OS ages.
>>
>> I can see problems where the OS (and its version of libc) is young
>> enough to be under active development.
>>
> 
> Bogus, since the libc interfaces didn't change since C89 in most
> cases.

Prove to me by quoting the C standard that the size of an fpos_t
did not change from 32 to 64 bits on a particular implementation
from one version to the next.  (Yet I think all OSs over the last
30 years had to deal with a 32-bit max file size being insufficient:
Windows, Linux, UNIX of all variations, etc.  Not sure about VMS.)
Prove to me by quoting the C standard that sizeof(FILE) does not
change on a particular implementation from one version to the next.
Prove to me by quoting the C standard that a time_t did not change
from 32 to 64 or 256 bits on a particular implementation from one
version to the next.

The libc interface *TO THE KERNEL* is not specified in C89, and on
a particular implementation, you don't know whether it changed or
not without close examination.  (On x86, the instruction to transition
to kernel mode might be an "int" instruction, or a call to a trap
gate, or something else.  If you put that instruction, whatever it
is, in the compiler libc, be prepared to have to change it.  Someone
will find a code sequence that takes a few machine cycles less for
a system call.  I believe over the history of FreeBSD, that instruction
and the linkage between libc and the kernel has changed.  It's
nicely transparent if nobody is copying parts of that code into the
compiler libc.)

You could get away with this if the routines you are replacing use
only C-documented interfaces to libc.  Or POSIX-documented interfaces,
which are also unlikely to change much.  You can't: it's not
guaranteed that there isn't any unwarranted chuminess between
routines that you are replacing and routines you are NOT replacing,
such as printf and stdio, or stdio and malloc/free, or malloc and
sbrk.  The layout of things like FILE also isn't guaranteed to be
unchangeable, either (and I believe over the history of FreeBSD,
it has changed in an incompatible way, incompatible if you insist
on linking with an old (compiler) libc on a system with a new kernel.
But old executables worked (the old way), and newly-linked code
worked (the new way)).  The same sort of changes were used in
enlarging off_t.

There isn't a nice, clean break where you could replace one piece
and not another.  You might get away with it replacing all the trig
functions, but when you need to start replacing printf(), trouble
starts.

[toc] | [prev] | [next] | [standalone]

#5467

On 06/ 4/11 06:06 PM, jacob navia wrote:
> Le 04/06/11 07:32, Gordon Burditt a écrit :
>>
>> This is less of an issue with math functions, *printf, and the
>> string library and such since they usually don't have much of an
>> interface with the kernel in areas where changes occur.
>>
>
> Exactly, and those functions should be provided by the compiler,
> not the OS.

If so, how do you cope with the other dependencies?  Not just technical, 
but documentation.  Do you provide replacement man pages?  How about 
linking to libraries built with the system libc?

I can see this getting very messy, very fast.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#5469

Le 05/06/11 05:47, Ian Collins a écrit :
> On 06/ 4/11 06:06 PM, jacob navia wrote:
>> Le 04/06/11 07:32, Gordon Burditt a écrit :
>>>
>>> This is less of an issue with math functions, *printf, and the
>>> string library and such since they usually don't have much of an
>>> interface with the kernel in areas where changes occur.
>>>
>>
>> Exactly, and those functions should be provided by the compiler,
>> not the OS.
>
> If so, how do you cope with the other dependencies? Not just technical,
> but documentation. Do you provide replacement man pages?

Yes, and lcc-win provides its own documentation since
there are sizable differences between the C99 printf
that I provide, and the system printf that is C89.

> How about
> linking to libraries built with the system libc?
>

lcc-win doesn't accept static library linking with
other compiler's libraries. I would have to
replicate Microsoft object code format (that is not
documented) and I would have to replicate the Microsoft
linker behavior, that is not documented either.

That is why lcc-win  provides its own linker.

> I can see this getting very messy, very fast.
>

Of course much less messy is to fail to provide
a C99 library when the system is not C99 like
mingw under windows (gcc doesn't run under windows).

I have demonstrated that if you want to do it you can
do it. But I am always wrong in this group, even if I
provide a full C99 implementation under windows.

[toc] | [prev] | [next] | [standalone]

#5470

On 06/ 5/11 07:48 PM, jacob navia wrote:
> Le 05/06/11 05:47, Ian Collins a écrit :
>> On 06/ 4/11 06:06 PM, jacob navia wrote:
>>> Le 04/06/11 07:32, Gordon Burditt a écrit :
>>>>
>>>> This is less of an issue with math functions, *printf, and the
>>>> string library and such since they usually don't have much of an
>>>> interface with the kernel in areas where changes occur.
>>>>
>>>
>>> Exactly, and those functions should be provided by the compiler,
>>> not the OS.
>>
>> If so, how do you cope with the other dependencies? Not just technical,
>> but documentation. Do you provide replacement man pages?
>
> Yes, and lcc-win provides its own documentation since
> there are sizable differences between the C99 printf
> that I provide, and the system printf that is C89.

OK.

>> How about
>> linking to libraries built with the system libc?
>
> lcc-win doesn't accept static library linking with
> other compiler's libraries. I would have to
> replicate Microsoft object code format (that is not
> documented) and I would have to replicate the Microsoft
> linker behavior, that is not documented either.
>
> That is why lcc-win  provides its own linker.

Ah, I see.  I'm not used to the windows way of doing things.  Do you 
have problems with system libraries?  I'm used to the Unix way where all 
C compilers coexist by using the system ABI and libraries.

>> I can see this getting very messy, very fast.
>
> Of course much less messy is to fail to provide
> a C99 library when the system is not C99 like
> mingw under windows (gcc doesn't run under windows).

Now I'm really glad I don't have to use windows!

> I have demonstrated that if you want to do it you can
> do it. But I am always wrong in this group, even if I
> provide a full C99 implementation under windows.

Why oh why do you have to take every comment as a personal insult?  I'd 
have thought you've been around Usenet long enough to how it works.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#5493

Le 05/06/11 10:22, Ian Collins a écrit :
> On 06/ 5/11 07:48 PM, jacob navia wrote:
>> I have demonstrated that if you want to do it you can
>> do it. But I am always wrong in this group, even if I
>> provide a full C99 implementation under windows.
>
> Why oh why do you have to take every comment as a personal insult? I'd
> have thought you've been around Usenet long enough to how it works.
>

Sorry I am getting paranoiac...

:-)

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web