strnlen() warning

[Mat]

Hi all.
This function is a GNU extension ok... so pls dont start with "this is
not standard C", "go to comp.*.unix"... here I have more probability to
get a good reply.
BTW, when I compile my app I get:

warning: implicit declaration of function `strnlen'

And I hate this :)
Ok, it's only a stupid warning in this case but I would like to know
the right define that allow me to include the standard prototype of the
function.

>From string.h :

#ifdef __USE_GNU
extern size_t strnlen (__const char *__string, size_t __maxlen)
__THROW __attribute_pure__;
#endif

But if I try to compile with -D__USE_GNU the warning remains...
Someone can help me?

Bye,
-Mat-

P.S.
I have the same problem with crypt() ...

[Clever Monkey]

Mat wrote:

This function is a GNU extension ok... so pls dont start with "this is
not standard C", "go to comp.*.unix"... here I have more probability to
get a good reply.
BTW, when I compile my app I get:

warning: implicit declaration of function `strnlen'

And I hate this :)
Ok, it's only a stupid warning in this case but I would like to know
the right define that allow me to include the standard prototype of the
function.

>>From string.h :

#ifdef __USE_GNU
extern size_t strnlen (__const char *__string, size_t __maxlen)
__THROW __attribute_pure__;
#endif

But if I try to compile with -D__USE_GNU the warning remains...
Someone can help me?

Sounds like your include paths are messed up. Are you sure you are
getting the string.h that corresponds to the GNU extensions? One trick
is to have the compiler leave the interim files around so you can see
what the source-and-headers expand to during the pre-processor phase.

And, yes, this is surely off-topic here. I'm sure one of the GNU
newsgroups can help you. Follow-ups set.

[Mike Wahler]

"Mat" <he***********@gmail.comwrote in message
news:11**********************@75g2000cwc.googlegro ups.com...

Hi all.
This function is a GNU extension ok... so pls dont start with "this is
not standard C", "go to comp.*.unix"... here I have more probability to
get a good reply.

This newsgroup is about ISO standard C. So why would
you expect more probability of a good reply here rather
than in a topical group?

BTW, when I compile my app I get:

warning: implicit declaration of function `strnlen'

This means you've called the function 'strnlen()' with
no prototype in scope.

>
And I hate this :)

So provide a prototype. If this function is provided by
your implementation, I'd expect it would also provide a
header which declares it. Failing that, find out its
signature and declare it yourself.

Ok, it's only a stupid warning in this case

Warnings are there for a reason. Don't disregard them
or consider them 'stupid'.

>but I would like to know
the right define that allow me to include the standard prototype of the
function.

There is not function 'strnlen()' in standard C. So of course
it cannot have a 'standard prototype'.

>

>>From string.h :

#ifdef __USE_GNU
extern size_t strnlen (__const char *__string, size_t __maxlen)
__THROW __attribute_pure__;
#endif

OK there's the prototype (looks like it uses some nonstandard
keywords too).

>
But if I try to compile with -D__USE_GNU the warning remains...
Someone can help me?

You're seeing an issue with your compiler. It's not a language
problem. You can get the best help with this on a GNU newsgroup,
mailing list or web site.

Bye,
-Mat-

P.S.
I have the same problem with crypt() ...

Neither is 'crypt()' part of standard C.

-Mike

[Thomas J. Gritzan]

Mat schrieb:

Hi all.
This function is a GNU extension ok... so pls dont start with "this is
not standard C", "go to comp.*.unix"... here I have more probability to
get a good reply.
BTW, when I compile my app I get:

warning: implicit declaration of function `strnlen'

And I hate this :)
Ok, it's only a stupid warning in this case but I would like to know
the right define that allow me to include the standard prototype of the
function.

>>From string.h :

#ifdef __USE_GNU
extern size_t strnlen (__const char *__string, size_t __maxlen)
__THROW __attribute_pure__;
#endif

But if I try to compile with -D__USE_GNU the warning remains...
Someone can help me?

It definitly is offtopic here, you had better asked in a GNU/gcc newgroups.

By short googling I found out that you have to use -D_GNU_SOURCE.

--
Thomas

[Mat]

Thomas J. Gritzan wrote:

By short googling I found out that you have to use -D_GNU_SOURCE.

Perfect, thanks Thomas.
I googled before but I didnt find this.

[Mat]

Mike Wahler wrote:

This newsgroup is about ISO standard C. So why would
you expect more probability of a good reply here rather
than in a topical group?

Because most of the "topical groups" are almost abandoned.
Look, got 3 replies in less then 10 mins and the solution.

warning: implicit declaration of function `strnlen'

This means you've called the function 'strnlen()' with no prototype in scope.

Hehe, yes :)
This is why I wrote the first post.

Ok, it's only a stupid warning in this case

Warnings are there for a reason. Don't disregard them
or consider them 'stupid'.

Sure, that's why I wrote "in this case".
I didn't posted the test up but it's a trivial code sample for strnlen.

There is not function 'strnlen()' in standard C. So of course
it cannot have a 'standard prototype'.

There is more then one standard, as I wrote before this is a GNU
extension.
Dont repeat again it's OT, I know it.

Neither is 'crypt()' part of standard C.

Yes, it's not part of standard C :)

[Flash Gordon]

Mat wrote:

Hi all.
This function is a GNU extension ok... so pls dont start with "this is
not standard C", "go to comp.*.unix"... here I have more probability to
get a good reply.

Go to a GNU group then.

BTW, when I compile my app I get:

warning: implicit declaration of function `strnlen'

And I hate this :)
Ok, it's only a stupid warning in this case but I would like to know
the right define that allow me to include the standard prototype of the
function.

No, the warning is not stupid. It shows a serious defect.

>>From string.h :

#ifdef __USE_GNU
extern size_t strnlen (__const char *__string, size_t __maxlen)
__THROW __attribute_pure__;
#endif

But if I try to compile with -D__USE_GNU the warning remains...
Someone can help me?

If defining __USE_GNU does not help then ask in a GNU group.

Bye,
-Mat-

P.S.
I have the same problem with crypt() ...

So ask somewhere that crypt is topical.

Why should anyone help since you know this is the wrong place?
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Keith Thompson]

"Mat" <he***********@gmail.comwrites:

This function is a GNU extension ok... so pls dont start with "this is
not standard C", "go to comp.*.unix"... here I have more probability to
get a good reply.

This is not standard C. Try gnu.gcc.help.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[William Ahern]

On Thu, 27 Jul 2006 08:33:43 -0700, Mat wrote:

>
Thomas J. Gritzan wrote:

>By short googling I found out that you have to use -D_GNU_SOURCE.

Perfect, thanks Thomas.
I googled before but I didnt find this.

You didn't need google. If you had traced the origins of __USE_GNU you
would have found it, as well as _GNU_SOURCE, in /usr/include/features.h.
That's an informative header for understanding Unix and Linux standard
support. In particular, _FOO_SOURCE is the typical way to expose
standard library functions in Unix environments.

In any event, this group was certainly the wrong place to come to. You
would most certainly have gotten a correct and far more helpful answer in
either comp.unix.programmer or comp.os.linux.development.apps. In the
future, know that comp.unix.programmer is extremely helpful and just as
prompt as comp.lang.c. Also, that group is also far more flexible w.r.t
topicality, maybe because "Unix" is a far more fuzzy topic.

Your post generated 5 responses w/o an answer or possibly w/ misleading
information (at least, misleading to your efforts and edification), and a
single one w/ the answer. You didn't take _our_ needs and wants into
account when deciding which group to post your question in. And maybe
that's the most important point.