bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Warning when compiling GNUstep


From: Chris B. Vetter
Subject: Re: Warning when compiling GNUstep
Date: Mon, 28 Jul 2003 10:55:15 -0700

On Mon, 28 Jul 2003 11:52:42 -0400
"Yen-Ju Chen" <yjchenx@hotmail.com> wrote:
[...]
> I use FreeBSD 4.8, GCC 3.2 with lastest GNUstep CVS (7/28 morning).

Some of these appear on any FreeBSD, regardless of the compiler.

[...]
> Unicode.m: In function `GSToUnicode':
> Unicode.m:1288: warning: passing arg 2 of `iconv' from incompatible
> pointer type
> Unicode.m: In function `GSFromUnicode':
> Unicode.m:1882: warning: passing arg 2 of `iconv' from incompatible
> pointer type

This is due to the fact that Linux has iconv() in libc (AFAIK) and BSD
uses libiconv from ports:

  $ man 3 iconv
  [...]
       size_t iconv (iconv_t cd,
                     const char* * inbuf, size_t * inbytesleft,
                     char* * outbuf, size_t * outbytesleft);
  [...]

libiconv expects a const, the one in libc doesn't.
I notified Alex a while ago on #GNUstep:

  > warning: passing arg 2 of `iconv' from incompatible pointer type
  <alexm_> odd. no warning here
  <alexm_> what's iconv() defined as on your system?
  > alex: it wants 'const char **'
  <alexm_> cbv: glibc doesn't agree
  > alex: man 3 iconv -> size_t iconv (iconv_t cd, const char* * inbuf,
    size_t * inbytesleft, char * * outbuf, size_t * outbytesleft);
  <alexm_> cbv: afaict, the standard is plain "char **"
  <alexm_> cbv:
http://www.opengroup.org/onlinepubs/007904975/functions/iconv.html
  > alex: check the date ... 2001
  <alexm_> new enough for me ;-)
  <alexm_> got a newer version?
  > :0> pkg_info -aR  | grep iconv
  > Information for libiconv-1.8_2:
  >
http://www.gnu.org/software/libiconv/documentation/libiconv/iconv.3.html
  > size_t iconv (iconv_t cd, const char* * inbuf, [...]
  <alexm_> that's libiconv; check glibc
  > there is no glibc on BSD
  <alexm_> everything I found that mentioned const vs. non-const said
           that non-const was correct, but const was still used on many
           systems
  <alexm_> cbv: glibc used to have const, but removed it. afaict,
           non-const is correct, but I'm no t going to spend more time
           trying to figure it out :)
  <alexm_> cbv: I'll assume glibc is correct; get them to change, and
           I'll change too :)

I interpret Alex' answer as

        Because it's in glibc it's therefor 'correct' behaviour....
        (aka: another Linux'ism)

[...]
> Linking tool gpbs ...
> /usr/lib/libc.so.4: WARNING!  setkey(3) not present in the system!
> /usr/lib/libc.so.4: warning: this program uses gets(), which is
> unsafe./usr/lib/libc.so.4: warning: mktemp() possibly used unsafely;
> consider using mkstemp()
> /usr/lib/libc.so.4: WARNING!  des_setkey(3) not present in the system!
> /usr/lib/libc.so.4: WARNING!  encrypt(3) not present in the system!
> /usr/lib/libc.so.4: warning: tmpnam() possibly used unsafely; consider
> using mkstemp()
> /usr/lib/libc.so.4: warning: this program uses f_prealloc(), which is
> not recommended.
> /usr/lib/libc.so.4: WARNING!  des_cipher(3) not present in the system!
> /usr/lib/libc.so.4: warning: tempnam() possibly used unsafely;
> consider using mkstemp()
[...]

The warnings about setkey(3), encrypt(3) and des_cipher(3) are
'inherited'. Simply link -lcrypt and you'll be fine.

mktemp(3) and tmpnam(3) are 'inherited' as well, though I'm not exactly
sure from which linked library, probably libc. These are not related to
GNUstep.

-- 
Chris




reply via email to

[Prev in Thread] Current Thread [Next in Thread]