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

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

Puzzling "implicit declaration" Warning

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

Contents

  Puzzling "implicit declaration" Warning Robbie Hatley <see.my.signature@for.my.contact.info> - 2020-02-06 23:57 -0800
    Re: Puzzling "implicit declaration" Warning Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-07 08:53 +0000
      Re: Puzzling "implicit declaration" Warning Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-07 02:12 -0800
        Re: Puzzling "implicit declaration" Warning Robbie Hatley <see.my.signature@for.my.contact.info> - 2020-02-08 01:53 -0800
          Re: Puzzling "implicit declaration" Warning Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-08 12:59 +0000
            Re: Puzzling "implicit declaration" Warning Manfred <noname@invalid.add> - 2020-02-08 17:21 +0100
              Re: Puzzling "implicit declaration" Warning Manfred <noname@invalid.add> - 2020-02-08 17:34 +0100
              Re: Puzzling "implicit declaration" Warning Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-08 14:37 -0800
          Re: Puzzling "implicit declaration" Warning scott@slp53.sl.home (Scott Lurndal) - 2020-02-08 18:39 +0000
      Re: Puzzling "implicit declaration" Warning Robbie Hatley <see.my.signature@for.my.contact.info> - 2020-02-08 01:15 -0800
        Re: Puzzling "implicit declaration" Warning chad <cdalten@gmail.com> - 2020-02-08 05:05 -0800
        Re: Puzzling "implicit declaration" Warning Bart <bc@freeuk.com> - 2020-02-08 14:05 +0000
        Re: Puzzling "implicit declaration" Warning Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-08 14:35 -0800
          Re: Puzzling "implicit declaration" Warning Bart <bc@freeuk.com> - 2020-02-08 22:39 +0000
            Re: Puzzling "implicit declaration" Warning Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-08 15:30 -0800
            Re: Puzzling "implicit declaration" Warning David Brown <david.brown@hesbynett.no> - 2020-02-09 12:24 +0100
          Re: Puzzling "implicit declaration" Warning Robbie Hatley <see.my.signature@for.my.contact.info> - 2020-02-09 23:42 -0800
            Re: Puzzling "implicit declaration" Warning chad <cdalten@gmail.com> - 2020-02-10 05:34 -0800
            Re: Puzzling "implicit declaration" Warning Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 16:12 +0000
            Re: Puzzling "implicit declaration" Warning Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-10 11:14 -0800
              Re: Puzzling "implicit declaration" Warning Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-11 07:06 +0000
              Re: puzzling enragement by innocuous variable names Robbie Hatley <see.my.signature@for.my.contact.info> - 2020-09-10 19:47 -0700
                Re: puzzling enragement by innocuous variable names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-09-10 20:28 -0700
                Re: puzzling enragement by innocuous variable names Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2020-09-13 14:57 +1000
                  Re: puzzling enragement by innocuous variable names gazelle@shell.xmission.com (Kenny McCormack) - 2020-09-15 17:58 +0000
                Re: puzzling enragement by innocuous variable names Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-09-14 09:38 -0600
            Re: Puzzling "implicit declaration" Warning James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-11 00:21 -0500
    Re: Puzzling "implicit declaration" Warning Les Cargill <lcargill99@comcast.com> - 2020-02-08 17:00 -0600
      Re: Puzzling "implicit declaration" Warning Robbie Hatley <see.my.signature@for.my.contact.info> - 2020-02-09 22:50 -0800
        Re: Puzzling "implicit declaration" Warning Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 16:00 +0000
          Re: Puzzling "implicit declaration" Warning scott@slp53.sl.home (Scott Lurndal) - 2020-02-10 16:28 +0000
            Re: Puzzling "implicit declaration" Warning Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 16:42 +0000

Page 1 of 2  [1] 2  Next page →

#149814 — Puzzling "implicit declaration" Warning

Ahoy, group. I just wrote the following program, and while
it's working, my compiler (gcc) gives a puzzling warning:

/* reverse.c */
#include <stdio.h>
#include <math.h>
#include <stdlib.h>
int main (int Beren, char *Luthien[])
{
   unsigned long  Bob;
   unsigned       Carol;
   unsigned       i;
   unsigned       Digits[25];
   if (2 != Beren) {exit(EXIT_FAILURE);}
   Bob = strtoul(Luthien[1], NULL, 10);
   Carol = 1 + (log10(Bob));
   for ( i = 0 ; i < Carol ; ++i )
   {
      Digits[i] = (Bob/(unsigned long)exp10(i))%10;
   }
   for ( i = 0 ; i < Carol ; ++i )
   {
      printf("%u", Digits[i]);
   }
   exit(EXIT_SUCCESS);
}

And that compiles without error, and it works fine.

BUT, gcc gives the following warnings for the line with "exp10":

reverse.c:16:39: warning: implicit declaration of function ‘exp10’
   [-Wimplicit-function-declaration]
   Digits[i] = (Bob/(unsigned long)exp10(i))%10;
                                       ^~~~~
reverse.c:16:39: warning: incompatible implicit declaration of
   built-in function ‘exp10’

Why the "implicit declaration" warning? exp10 appears in math.h
(I double-checked to make sure), and math.h is #include'd; so
I'm not seeing the reason for the "implicit declaration" warning
here. Anyone have an idea of what's going on?

Hmmm... could the fact that exp10 is a Gnu extension be related?
And yet, the program works, so obviously Gnu extensions are being
properly compiled.


-- 
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -E 'say "\154o\156e\167o\154f\100w\145ll\56c\157m";'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley

[toc] | [next] | [standalone]

#149816

On Fri, 2020-02-07, Robbie Hatley wrote:
>
> Ahoy, group. I just wrote the following program, and while
> it's working, my compiler (gcc) gives a puzzling warning:
>
> /* reverse.c */
> #include <stdio.h>
> #include <math.h>
> #include <stdlib.h>
> int main (int Beren, char *Luthien[])
> {
>    unsigned long  Bob;
>    unsigned       Carol;

Your variable names are really confusing!

>    unsigned       i;
>    unsigned       Digits[25];
>    if (2 != Beren) {exit(EXIT_FAILURE);}
>    Bob = strtoul(Luthien[1], NULL, 10);
>    Carol = 1 + (log10(Bob));
>    for ( i = 0 ; i < Carol ; ++i )
>    {
>       Digits[i] = (Bob/(unsigned long)exp10(i))%10;
>    }
>    for ( i = 0 ; i < Carol ; ++i )
>    {
>       printf("%u", Digits[i]);
>    }
>    exit(EXIT_SUCCESS);
> }
>
> And that compiles without error, and it works fine.
>
> BUT, gcc gives the following warnings for the line with "exp10":
>
> reverse.c:16:39: warning: implicit declaration of function ‘exp10’
>    [-Wimplicit-function-declaration]
>    Digits[i] = (Bob/(unsigned long)exp10(i))%10;
>                                        ^~~~~
> reverse.c:16:39: warning: incompatible implicit declaration of
>    built-in function ‘exp10’
>
> Why the "implicit declaration" warning? exp10 appears in math.h
> (I double-checked to make sure), and math.h is #include'd; so
> I'm not seeing the reason for the "implicit declaration" warning
> here. Anyone have an idea of what's going on?
>
> Hmmm... could the fact that exp10 is a Gnu extension be related?

Yes. If you read the exp10(3) man page, it says

   #define _GNU_SOURCE /* See feature_test_macros(7) */

and if you compile as

   gcc -Wall -Wextra -pedantic -O2 -std=gnu99 -D_GNU_SOURCE -c reverse.c

the warning disappears.

> And yet, the program works, so obviously Gnu extensions are being
> properly compiled.

I'm not sure it really works; the warning means the compiler will
assume the prototype is 'int exp10()'.  Then at the linking stage
there is no additional type checking and no protection against GNU
extensions, so it will link ok.

I don't know offhand what happens when you get the prototype wrong,
but it's a bad thing and I make sure it never happens.  (Others will
be able to tell you.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#149818

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Fri, 2020-02-07, Robbie Hatley wrote:
[...]
>> And yet, the program works, so obviously Gnu extensions are being
>> properly compiled.
>
> I'm not sure it really works; the warning means the compiler will
> assume the prototype is 'int exp10()'.  Then at the linking stage
> there is no additional type checking and no protection against GNU
> extensions, so it will link ok.
>
> I don't know offhand what happens when you get the prototype wrong,
> but it's a bad thing and I make sure it never happens.  (Others will
> be able to tell you.)

What happens is undefined behavior.

If you examine your math.h header, I think you'll find that the
declaration of exp10 isn't made visible unless _GNU_SOURCE has been
defined.

Under C90 rules, the behavior would be well defined *if* the function
returned an int result and expected an argument of the type you actually
gave it.  Under C99 and later, calling a function with no visible
declaration is a constraint violation (and if the required diagnostic is
a non-fatal warning, the behavior is undefined).

With a simpler example, compiling with gcc yields (after a couple of
warnings) a program that behaves as if the declaration were visible, but
clang doesn't.  One of the warnings from gcc indicates that it treats
exp10 as a built-in function, so it's not too surprising that it's able
to generate a "correct" call.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#149849

On 2020-02-07 2:12 AM, Keith Thompson wrote:

> If you examine your math.h header, I think you'll find that the
> declaration of exp10 isn't made visible unless _GNU_SOURCE has been
> defined.

I'm using Cygwin's GCC, it's "math.h" (from the "newlib" library)
doesn't mention "_GNU_SOURCE" directly, but it DOES say this:

...
/* GNU extensions */
#if __GNU_VISIBLE
extern void sincos (double, double *, double *);
extern void sincosf (float, float *, float *);
#ifdef __CYGWIN__
extern void sincosl (long double, long double *, long double *);
#endif /* __CYGWIN__ */
# ifndef exp10
extern double exp10 (double);
# endif
...

BUT, that file #include's "sys/cdefs.h".

And "sys/cdefs.h" #include's "sys/features.h".

And in "sys/features.h" I found this:

#ifdef _GNU_SOURCE
#define	__GNU_VISIBLE		1
#else
#define	__GNU_VISIBLE		0
#endif

So, yes, in order to get any of the Gnu extensions in source code
to work right in Cygwin, apparently one needs to "#define _GNU_SOURCE"
BEFORE #include'ing any headers.

<sarcasm>It sure would have been nice if the Cygwin folks had seen
fit to include this little factoid in their documentation.</sarcasm>


-- 
Cheers,
Robbie Hatley
Midway City, California, USA
perl -E 'say "\154o\156e\167o\154f\100w\145ll\56c\157m";'
https://www.facebook.com/robbie.hatley
https://people.well.com/user/lonewolf/

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

#149850

Robbie Hatley <see.my.signature@for.my.contact.info> writes:
<cut>
> So, yes, in order to get any of the Gnu extensions in source code
> to work right in Cygwin, apparently one needs to "#define _GNU_SOURCE"
> BEFORE #include'ing any headers.
>
> <sarcasm>It sure would have been nice if the Cygwin folks had seen
> fit to include this little factoid in their documentation.</sarcasm>

Have you reported this documentation bug, or better yet, submitted a
patch to the source?

-- 
Ben.

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

#149856

On 2/8/20 1:59 PM, Ben Bacarisse wrote:
> Robbie Hatley <see.my.signature@for.my.contact.info> writes:
> <cut>
>> So, yes, in order to get any of the Gnu extensions in source code
>> to work right in Cygwin, apparently one needs to "#define _GNU_SOURCE"
>> BEFORE #include'ing any headers.
>>
>> <sarcasm>It sure would have been nice if the Cygwin folks had seen
>> fit to include this little factoid in their documentation.</sarcasm>
> 
> Have you reported this documentation bug, or better yet, submitted a
> patch to the source?
> 

 From the cygwin homepage:

<quote>
Cygwin is:

     a large collection of GNU and Open Source tools which provide 
functionality similar to a Linux distribution on Windows.
     ...
</quote>

I'm no expert with cygwin, but since they say it is a /port/ of GNU 
software for Windows, I believe the GNU (I'd say glibc in this case) 
documentation applies, without the need for them to re-publish it.

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

#149857

On 2/8/20 5:21 PM, Manfred wrote:
> On 2/8/20 1:59 PM, Ben Bacarisse wrote:
>> Robbie Hatley <see.my.signature@for.my.contact.info> writes:
>> <cut>
>>> So, yes, in order to get any of the Gnu extensions in source code
>>> to work right in Cygwin, apparently one needs to "#define _GNU_SOURCE"
>>> BEFORE #include'ing any headers.
>>>
>>> <sarcasm>It sure would have been nice if the Cygwin folks had seen
>>> fit to include this little factoid in their documentation.</sarcasm>
>>
>> Have you reported this documentation bug, or better yet, submitted a
>> patch to the source?
>>
> 
>  From the cygwin homepage:
> 
> <quote>
> Cygwin is:
> 
>      a large collection of GNU and Open Source tools which provide 
> functionality similar to a Linux distribution on Windows.
>      ...
> </quote>
> 
> I'm no expert with cygwin, but since they say it is a /port/ of GNU 
> software for Windows, I believe the GNU (I'd say glibc in this case) 
> documentation applies, without the need for them to re-publish it.

Except, as per other info elsethread, they appear to re-publish it, so 
they should maintain it properly indeed.

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

#149868

Manfred <noname@invalid.add> writes:
[...]
> From the cygwin homepage:
>
> <quote>
> Cygwin is:
>
>     a large collection of GNU and Open Source tools which provide
> functionality similar to a Linux distribution on Windows.
>     ...
> </quote>
>
> I'm no expert with cygwin, but since they say it is a /port/ of GNU
> software for Windows, I believe the GNU (I'd say glibc in this case)
> documentation applies, without the need for them to re-publish it.

Cygwin uses newlib, not glibc.  newlib happens to provide its own
implementations of some (all? I haven't checked) GNU-specific library
functions.

Yes, its documentation should mention -D_GNU_SOURCE.  I've just
suggested that to the Cygwin project.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#149861

Robbie Hatley <see.my.signature@for.my.contact.info> writes:
>
>On 2020-02-07 2:12 AM, Keith Thompson wrote:
>
>> If you examine your math.h header, I think you'll find that the
>> declaration of exp10 isn't made visible unless _GNU_SOURCE has been
>> defined.
>
>I'm using Cygwin's GCC, it's "math.h" (from the "newlib" library)
>doesn't mention "_GNU_SOURCE" directly, but it DOES say this:
>
>...
>/* GNU extensions */
>#if __GNU_VISIBLE
>extern void sincos (double, double *, double *);
>extern void sincosf (float, float *, float *);
>#ifdef __CYGWIN__
>extern void sincosl (long double, long double *, long double *);
>#endif /* __CYGWIN__ */
># ifndef exp10
>extern double exp10 (double);
># endif
>...
>
>BUT, that file #include's "sys/cdefs.h".
>
>And "sys/cdefs.h" #include's "sys/features.h".
>
>And in "sys/features.h" I found this:
>
>#ifdef _GNU_SOURCE
>#define	__GNU_VISIBLE		1
>#else
>#define	__GNU_VISIBLE		0
>#endif
>
>So, yes, in order to get any of the Gnu extensions in source code
>to work right in Cygwin, apparently one needs to "#define _GNU_SOURCE"
>BEFORE #include'ing any headers.
>
><sarcasm>It sure would have been nice if the Cygwin folks had seen
>fit to include this little factoid in their documentation.</sarcasm>

You may find reading the section on namespace pollution illuminating:

https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html

FWIW, Cygwin doesn't have anything to do with GCC or the libraries; they
just compile the open source code for windows.

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

#149847

On 2020-02-07 12:53 AM, Jorgen Grahn wrote:

> Your variable names are really confusing!

Well, since this program is not for corporate masters, I feel free
to be as whimsical as I like. :-)

"Beren" and "Luthien" allude to characters in JRR Tolkien's novel
"The Silmarillion".

"Bob" and "Carol" allude to the 1969 movie "Bob & Carol & Ted & Alice".

> If you read the exp10(3) man page, it says
> 
>    #define _GNU_SOURCE /* See feature_test_macros(7) */

Well, not exactly. I get "No manual page for 'exp10'."
Hmmm. I'm also getting "No manual page for 'exp'."

Ok, turns out, in order to get those manual pages, I had to go into
Cygwin setup and manually install a file called "C Function Documentation".
Seems to me that should be installed automatically with GCC, but oh well.
Now I get:

EXP10(3)                         Mathematical Functions (math.h)                         EXP10(3)

NAME
       exp10, exp10f - exponential, base 10

SYNOPSIS
       #include <math.h>

       double exp10(double x);

       float exp10f(float x);

DESCRIPTION
       exp10 and exp10f calculate 10 ^ x, that is, 10 raised to the power x.

RETURNS
       On success, exp10 and exp10f return the calculated value. If the result underflows, the
       returned value is 0. If the result overflows, the returned value is HUGE_VAL. In either
       case, errno is set to ERANGE.

PORTABILITY
       exp10 and exp10f are GNU extensions.

newlib                                      12/21/2019                                   EXP10(3)


But it doesn't say anything about "#define _GNU_SOURCE".

Neither does "man gcc".

> and if you compile as
> 
>    gcc -Wall -Wextra -pedantic -O2 -std=gnu99 -D_GNU_SOURCE -c reverse.c
> 
> the warning disappears.

OK, I tried that, and yes, that works!

So I modified my file called "maketail", which is #included at the
end of all of my makefiles, to include that macro:

   MACROS := -DPLATFORM_IS_WIN64 -D_GNU_SOURCE

But this is certainly bloody annoying, having to include a macro not
documented on my system. It's a good thing you had mention of it in
the documentation on YOUR system; thanks for the tip! But I have to
wonder why Cygwin's documentation has no mention of it.

But then, Cygwin breaks a number of conventions. GCC is expecting to
see The Gnu Standard C Library. But that's NOT what Cygwin uses!
It uses a (supposedly) equivalent library called "newlib", modified
to behave in a Cygwin + GCC environment AS IF it was "The Gnu C
Standard Library" (which it isn't). So any errors or omissions
in creating the "Gnu-emulating modifed newlib" would result in
puzzling issues. Perhaps this is one of those?

Yes, it is. On doing a NotePad++ "Find In Files" search for
"_GNU_SOURCE" among "*.h" files in "C:\cygwin64", I found the
following cryptic and infuriating comment in file "features.h":

/* Various options should be defined here, but the framework to do this
   is not laid down so far.  Especially notable are the following defines,
   which can be used by the application to switch on or off various
   datatypes and function prototypes:

     _BSD_SOURCE   to include pure BSD functions which are not defined
		   under POSIX.

     _POSIX_SOURCE if the application requests a POSIX compatible system.

     _XOPEN_SOURCE if X/Open functions and datatypes are requested.  This
		   option includes _POSIX_SOURCE.

     _GNU_SOURCE   to turn on GNU extensions which might collide with defines
		   used in application or library headers.  This option
		   includes _BSD_SOURCE, _XOPEN_SOURCE and _POSIX_SOURCE.
*/

And this problem has existed for YEARS, if not DECADES, and yet the Cygwin
team has done NOTHING to fix it. "The framework to do this is not laid down
SO FAR"??? What the devil??? SO FAR??? How many more decades are they going
to wait??? Humankind will likely go extinct before these guys get their act
together. Makes me want to seek a different programming platform. Perhaps
Mingw or something like that.


-- 
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -E 'say "\154o\156e\167o\154f\100w\145ll\56c\157m";'
https://people.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley

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

#149851

On Saturday, February 8, 2020 at 1:16:01 AM UTC-8, Robbie Hatley wrote:
> On 2020-02-07 12:53 AM, Jorgen Grahn wrote:
> 
> > Your variable names are really confusing!
> 
> Well, since this program is not for corporate masters, I feel free
> to be as whimsical as I like. :-)
> 
> "Beren" and "Luthien" allude to characters in JRR Tolkien's novel
> "The Silmarillion".
> 
> "Bob" and "Carol" allude to the 1969 movie "Bob & Carol & Ted & Alice".
> 
> 

All this might good for small programs. But what happens if you write a larger program, put it aside for six months, and then return to work on it? What happens is that it becomes a coding nightmare because the variable names don't give you any kind of insight into your original reasoning.

This in turn makes adding additional functionality and/or fixing new bugs a major pain in the ass.

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

#149852

On 08/02/2020 09:15, Robbie Hatley wrote:
> 
> On 2020-02-07 12:53 AM, Jorgen Grahn wrote:
> 
>> Your variable names are really confusing!
> 
> Well, since this program is not for corporate masters, I feel free
> to be as whimsical as I like. :-)
> 
> "Beren" and "Luthien" allude to characters in JRR Tolkien's novel
> "The Silmarillion".
> 
> "Bob" and "Carol" allude to the 1969 movie "Bob & Carol & Ted & Alice".

I thought it was something to do with RSA encryption. But they 
apparently use "Alice" and "Bob" - from the same movie.

Anyway many use their own alternatives to "foo" and "bar"; mine are 
"fred" and "bill". Pushed for a third, I might use "charlie".

Anything that can't be confused for a possible keyword (like "string" or 
"array" which I always hate in example code).

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

#149867

Robbie Hatley <see.my.signature@for.my.contact.info> writes:
> On 2020-02-07 12:53 AM, Jorgen Grahn wrote:
>> Your variable names are really confusing!
>
> Well, since this program is not for corporate masters, I feel free
> to be as whimsical as I like. :-)

No, it's not for "corporate masters", it's for a bunch of C experts
you're asking for help.  Using obscure names like Beren and Luthien
rather than argc and argv doesn't help anyone.  Please write clear code.

[...]

>> If you read the exp10(3) man page, it says
>> 
>>    #define _GNU_SOURCE /* See feature_test_macros(7) */
>
> Well, not exactly. I get "No manual page for 'exp10'."
> Hmmm. I'm also getting "No manual page for 'exp'."
>
> Ok, turns out, in order to get those manual pages, I had to go into
> Cygwin setup and manually install a file called "C Function Documentation".

The package that provides the library man pages is called "cygwin-doc".
I suspect it's not installed by default out of concern for saving space.

> Seems to me that should be installed automatically with GCC, but oh well.
> Now I get:
>
> EXP10(3)                         Mathematical Functions (math.h)                         EXP10(3)
>
> NAME
>        exp10, exp10f - exponential, base 10
[...]
> PORTABILITY
>        exp10 and exp10f are GNU extensions.
>
> newlib                                      12/21/2019                                   EXP10(3)
>
>
> But it doesn't say anything about "#define _GNU_SOURCE".

I agree that it should.  I've sent email to the Cygwin mailing list
suggesting it.

https://cygwin.com/ml/cygwin/2020-02/msg00069.html

> Neither does "man gcc".

gcc is the compiler.  The compiler and library are separate components.
I wouldn't expect a compiler's documentation to discuss library
functions.

[...]

> But then, Cygwin breaks a number of conventions. GCC is expecting to
> see The Gnu Standard C Library. But that's NOT what Cygwin uses!
> It uses a (supposedly) equivalent library called "newlib", modified
> to behave in a Cygwin + GCC environment AS IF it was "The Gnu C
> Standard Library" (which it isn't). So any errors or omissions
> in creating the "Gnu-emulating modifed newlib" would result in
> puzzling issues. Perhaps this is one of those?

No, gcc (the GNU compiler collection) doesn't require glibc (the GNU C
library).  It can work with any conforming library implementation.  Some
implementations use Microsoft's C library.  Back when I used Solaris, it
worked with Sun's C library.

Typically gcc works with the "native" library for the platform.  There's
no particular reason that has to be glibc.  The folks who built Cygwin
made the perfectly valid decision to use newlib rather than glibc.

[...]

> And this problem has existed for YEARS, if not DECADES, and yet the Cygwin
> team has done NOTHING to fix it. "The framework to do this is not laid down
> SO FAR"??? What the devil??? SO FAR??? How many more decades are they going
> to wait??? Humankind will likely go extinct before these guys get their act
> together. Makes me want to seek a different programming platform. Perhaps
> Mingw or something like that.

Maybe you should ask for your money back.  Oh, wait ...

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#149869

On 08/02/2020 22:35, Keith Thompson wrote:
> Robbie Hatley <see.my.signature@for.my.contact.info> writes:

> 
>> And this problem has existed for YEARS, if not DECADES, and yet the Cygwin
>> team has done NOTHING to fix it. "The framework to do this is not laid down
>> SO FAR"??? What the devil??? SO FAR??? How many more decades are they going
>> to wait??? Humankind will likely go extinct before these guys get their act
>> together. Makes me want to seek a different programming platform. Perhaps
>> Mingw or something like that.
> 
> Maybe you should ask for your money back.  Oh, wait ...

That's a little unfair.

The availabilty of free compilers such as gcc means there is less of a 
market for commercial versions, at least for individuals or small 
businesses.

But does that mean that if something is wrong with a free one that has 
eliminated paid-for competition, you're not allowed to complain about it?

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

#149873

Bart <bc@freeuk.com> writes:
> On 08/02/2020 22:35, Keith Thompson wrote:
>> Robbie Hatley <see.my.signature@for.my.contact.info> writes:
>>> And this problem has existed for YEARS, if not DECADES, and yet the Cygwin
>>> team has done NOTHING to fix it. "The framework to do this is not laid down
>>> SO FAR"??? What the devil??? SO FAR??? How many more decades are they going
>>> to wait??? Humankind will likely go extinct before these guys get their act
>>> together. Makes me want to seek a different programming platform. Perhaps
>>> Mingw or something like that.
>>
>> Maybe you should ask for your money back.  Oh, wait ...
>
> That's a little unfair.

Perhaps.

> The availabilty of free compilers such as gcc means there is less of a
> market for commercial versions, at least for individuals or small
> businesses.
>
> But does that mean that if something is wrong with a free one that has
> eliminated paid-for competition, you're not allowed to complain about
> it?

The failure to document -D_GNU_SOURCE is certainly worth complaining
about.  My point (which I may not have made very clearly) is that it's
not worth ranting about.

BTW, if anyone wants to submit a patch, it appears that the newlib
exp10(3) man page is extracted from comments in
    newlib/libm/common/s_exp10.c
in
    git://sourceware.org/git/newlib-cygwin.git
Be sure to look for other GNU extensions as well.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#149877

On 08/02/2020 23:39, Bart wrote:
> On 08/02/2020 22:35, Keith Thompson wrote:
>> Robbie Hatley <see.my.signature@for.my.contact.info> writes:
> 
>>
>>> And this problem has existed for YEARS, if not DECADES, and yet the 
>>> Cygwin
>>> team has done NOTHING to fix it. "The framework to do this is not 
>>> laid down
>>> SO FAR"??? What the devil??? SO FAR??? How many more decades are they 
>>> going
>>> to wait??? Humankind will likely go extinct before these guys get 
>>> their act
>>> together. Makes me want to seek a different programming platform. 
>>> Perhaps
>>> Mingw or something like that.
>>
>> Maybe you should ask for your money back.  Oh, wait ...
> 
> That's a little unfair.
> 
> The availabilty of free compilers such as gcc means there is less of a 
> market for commercial versions, at least for individuals or small 
> businesses.
> 

Note that you can get paid support for gcc from various sources.  If you 
want a commercial version of Cygwin, Redhat will happily sell you it, 
with different prices for different support models.

> But does that mean that if something is wrong with a free one that has 
> eliminated paid-for competition, you're not allowed to complain about it?

Of course you are allowed to complain about problems in software, even 
when it is free.  You can't /demand/ a fix, and you can't expect someone 
to listen if you want to yell at them, but you certainly have the right 
to complain about problems.  Most free software projects want to hear 
about bugs or suggestions.  But you will get on a lot better by 
reporting the issues politely, in a manner that aids fixing it (such as 
with simple test cases), and in the right place (the cygwin forums or 
mailing lists, rather than a C newsgroup).

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

#149908

On 2020-02-08 2:35 PM, Keith Thompson wrote:

> ... Using obscure names like Beren and Luthien
> rather than argc and argv  doesn't help anyone.
> Please write clear code....

If you find the names "Beren" and "Luthien" to be "obscure",
you need to read The Silmarillion. :-)

As for that "not helping", "not helping" who with what?
My goal there was not to help C programmers understand
code better. But then, that was CLEARLY never my goal,
so why are we even talking about it as if it was?

As for the ACTUAL goal, I'd have to say it's love and
remembrance, things which even the least-emotional
C programmers should understand, even though it has nothing
to do with C, programming, computers, or technology.

As for "argc" and "argv", I find those stultifying, and
indeed they are unnecessary, as C compilers just look for
"left argument of main" and "right argument of main", and
don't care about the NAMES at all. So I always use Beren
and Luthien instead, because I program computers, computers
don't program me.

Now, the variables "Bob" and "Carol" in my little program,
I admit were unnecessarily nondescriptive, so I changed
them to "number" and "digits".

> The package that provides the library man pages is called "cygwin-doc".
> I suspect it's not installed by default out of concern for saving space.

Thanks for clarifying that. I Installed a bunch of likely-seeming doc files
last night in hope that one of them would have the man pages for C std lib
functions, and clearly one did, but it seems I was mistaken on which one
it was.

The description for "cygwin-doc" didn't help much, saying "Cygwin-specific
documentation including man pages". But I don't see The C Programming
Language or GCC or newlib as being "Cygwin-Specific", so it's rather like
hiding "Hamilton-Beach Blender Manual" inside "Ford-Taurus-specific
documentation" because the car happens to have a blender sitting in its
trunk. :-/

> > But it doesn't say anything about "#define _GNU_SOURCE".
>
> I agree that it should.  I've sent email to the Cygwin mailing list
> suggesting it.
>
> https://cygwin.com/ml/cygwin/2020-02/msg00069.html

Thanks. I didn't even know how to go about doing that.

> ...Typically gcc works with the "native" library for the platform.
> There's no particular reason that has to be glibc...

Ok. That does raise all sorts of possibilities both for errors
and maybe for abuse, though. I could implement "hatleylib" in
such a way that whenever someone calls the "asinh()" function
in a program, it does a destructive reformat of drive C: or
some other unpleasant thing.

> Maybe you should ask for your money back.  Oh, wait ...

Non-free software costs dollars. Free software costs hours.
Which is part of why I often roll my own, instead of wasting
$500 buying software, or 500 hours trying to understand and
troubleshoot software. At least that way, any bugs are my
own responsibility, and I'm the one person most qualified
to fix them.


-- 
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -E 'say "\154o\156e\167o\154f\100w\145ll\56c\157m";'
https://www.facebook.com/robbie.hatley
https://people.well.com/user/lonewolf/

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

#149915

On Sunday, February 9, 2020 at 11:43:01 PM UTC-8, Robbie Hatley wrote:
> On 2020-02-08 2:35 PM, Keith Thompson wrote:
> 
> > ... Using obscure names like Beren and Luthien
> > rather than argc and argv  doesn't help anyone.
> > Please write clear code....
> 
> If you find the names "Beren" and "Luthien" to be "obscure",
> you need to read The Silmarillion. :-)
> 
> As for that "not helping", "not helping" who with what?
> My goal there was not to help C programmers understand
> code better. But then, that was CLEARLY never my goal,
> so why are we even talking about it as if it was?
> 
> As for the ACTUAL goal, I'd have to say it's love and
> remembrance, things which even the least-emotional
> C programmers should understand, even though it has nothing
> to do with C, programming, computers, or technology.
> 
> As for "argc" and "argv", I find those stultifying, and
> indeed they are unnecessary, as C compilers just look for
> "left argument of main" and "right argument of main", and
> don't care about the NAMES at all. So I always use Beren
> and Luthien instead, because I program computers, computers
> don't program me.
> 
> Now, the variables "Bob" and "Carol" in my little program,
> I admit were unnecessarily nondescriptive, so I changed
> them to "number" and "digits".
> 
> > The package that provides the library man pages is called "cygwin-doc".
> > I suspect it's not installed by default out of concern for saving space.
> 
> Thanks for clarifying that. I Installed a bunch of likely-seeming doc files
> last night in hope that one of them would have the man pages for C std lib
> functions, and clearly one did, but it seems I was mistaken on which one
> it was.
> 
> The description for "cygwin-doc" didn't help much, saying "Cygwin-specific
> documentation including man pages". But I don't see The C Programming
> Language or GCC or newlib as being "Cygwin-Specific", so it's rather like
> hiding "Hamilton-Beach Blender Manual" inside "Ford-Taurus-specific
> documentation" because the car happens to have a blender sitting in its
> trunk. :-/
> 
> > > But it doesn't say anything about "#define _GNU_SOURCE".
> >
> > I agree that it should.  I've sent email to the Cygwin mailing list
> > suggesting it.
> >
> > https://cygwin.com/ml/cygwin/2020-02/msg00069.html
> 
> Thanks. I didn't even know how to go about doing that.
> 
> > ...Typically gcc works with the "native" library for the platform.
> > There's no particular reason that has to be glibc...
> 
> Ok. That does raise all sorts of possibilities both for errors
> and maybe for abuse, though. I could implement "hatleylib" in
> such a way that whenever someone calls the "asinh()" function
> in a program, it does a destructive reformat of drive C: or
> some other unpleasant thing.
> 
> > Maybe you should ask for your money back.  Oh, wait ...
> 
> Non-free software costs dollars. Free software costs hours.
> Which is part of why I often roll my own, instead of wasting
> $500 buying software, or 500 hours trying to understand and
> troubleshoot software. At least that way, any bugs are my
> own responsibility, and I'm the one person most qualified
> to fix them.
> 
> 
> -- 

It pains me to say this, but after reading this, I've come to the conclusion that you're an idiot and that you should never be let out of tech support.

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

#149922

Robbie Hatley <see.my.signature@for.my.contact.info> writes:
<cut>
> As for "argc" and "argv", I find those stultifying, and
> indeed they are unnecessary, as C compilers just look for
> "left argument of main" and "right argument of main", and
> don't care about the NAMES at all. So I always use Beren
> and Luthien instead, because I program computers, computers
> don't program me.

You don't work in a team, do you?  In a team, you are programming for
people and the team /should/ program you.  Even if you hate the
prevailing style, you won't do well using, say, single letter names for
everything (I once worked in the same lab as, but fortunately not the
same team as, someone who did that).

When you post code asking for advice, your own private obsessions start
to rub up against public expectations.  Not quite like being in a team,
but you could choose to smooth your path though the world by picking
which obsessions you insist on presenting in public.

[Aside.  Some languages have a word or two that one just can't do
without.  I would, if I could, I'd use the Spanish "manía" rather than
obsession.  It's milder.]

<cut>
-- 
Ben.

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

#149927

Robbie Hatley <see.my.signature@for.my.contact.info> writes:
> On 2020-02-08 2:35 PM, Keith Thompson wrote:
>> ... Using obscure names like Beren and Luthien
>> rather than argc and argv  doesn't help anyone.
>> Please write clear code....
>
> If you find the names "Beren" and "Luthien" to be "obscure",
> you need to read The Silmarillion. :-)
>
> As for that "not helping", "not helping" who with what?

Communication.

> My goal there was not to help C programmers understand
> code better. But then, that was CLEARLY never my goal,
> so why are we even talking about it as if it was?

You posted to a forum full of C programmers.  You posted C code.
Did you not want those C programmers to understand your code?

By using silly names, you made that more difficult.  If you do that
deliberately, many of us will be less inclined to help you.

> As for the ACTUAL goal, I'd have to say it's love and
> remembrance, things which even the least-emotional
> C programmers should understand, even though it has nothing
> to do with C, programming, computers, or technology.

You like Tolkein.  Good for you.  You can put any irrelevancies
you like in your signature (at the end of the article, following
a line consisting of "-- ").

Or you can write anything you like if your goal is to annoy people.

> As for "argc" and "argv", I find those stultifying, and
> indeed they are unnecessary, as C compilers just look for
> "left argument of main" and "right argument of main", and
> don't care about the NAMES at all. So I always use Beren
> and Luthien instead, because I program computers, computers
> don't program me.

Do you object to the words "left" and "right" in English?  Do you
find them "stultifying?

You're absolutely right that the compiler doesn't care what you
call the parameters of main.  Human readers do.

> Now, the variables "Bob" and "Carol" in my little program,
> I admit were unnecessarily nondescriptive, so I changed
> them to "number" and "digits".

You understand why "Bob" and "Carol" were poor choices.  "Beren"
and "Luthien" are just as bad, perhaps worse, for exactly the same
reason.  ("Bob" and "Carol" are not uncommonly used as generic
names like "foo" and "bar".  "Beren" and "Luthien" are not, and
are more distracting.)

[...]

>> ...Typically gcc works with the "native" library for the platform.
>> There's no particular reason that has to be glibc...
>
> Ok. That does raise all sorts of possibilities both for errors
> and maybe for abuse, though. I could implement "hatleylib" in
> such a way that whenever someone calls the "asinh()" function
> in a program, it does a destructive reformat of drive C: or
> some other unpleasant thing.

Of course, you could implement a C library that doesn't work
correctly.  The easiest way to do that would be to take an existing
open source library and break it in some way.  You could implement
a non-working compiler in the same way.

A C implementation includes a number of components, including a
compiler and a run-time library.  Some are tightly integrated,
but gcc is specifically designed to work with a variety of
runtime libraries.  (In fact gcc appears to be about a year older
than glibc.)  Ensuring that the components work together is the
responsibility of whoever puts them together into an implementation.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web