trivial
#include <stdio.h>
int main(int argc, char *argv[])
{
char b[100];
gets_s(b, sizeof b);
printf("%s\n",b);
return 0;
}
generates
Building main.obj.
[b]C:\Users\User\Documents\Pelles C Projects\mmm\asd\main.c(8): warning #2018: Undeclared function 'gets_s' (did you mean 'gets'?); assuming 'extern' returning 'int'.[/b]
Done.
is it right?
on the other hand
#include <stdio.h>
int main(int argc, char *argv[])
{
char b[100];
gets(b);
printf("%s\n",b);
return 0;
}
That's not a bug!
Please read other reports. To enable safe functions you have to define library extension __STDC_WANT_LIB_EXT1__.
With:
#define __STDC_WANT_LIB_EXT1__ 1
#include <stdio.h>
int main(int argc, char *argv[])
{
char b[100];
gets_s(b, sizeof b);
printf("%s\n",b);
return 0;
}
You will get no more warnings.
gets is deprecated.
Quote from: frankie on March 10, 2015, 06:01:19 PM
That's not a bug!
Please read other reports. To enable safe functions you have to define library extension __STDC_WANT_LIB_EXT1__.
With:
#define __STDC_WANT_LIB_EXT1__ 1
#include <stdio.h>
int main(int argc, char *argv[])
{
char b[100];
gets_s(b, sizeof b);
printf("%s\n",b);
return 0;
}
You will get no more warnings.
gets is deprecated.
No Frankie, sorry
1. I were not sure about gets_s - so ask for possible explanation - thank you for!
2. It was depricated in the c99 standart, but in the c11 standart it was
excluded - so it is the bug, minor one... by the way, with the c99 option the compiler produces "The function gets() is marked as depricated " - and it is true by all means.
yet, gets_s() is recommended for usage instead gets() and it is included in the standart C library, so i can see (at the first sight) no reason to protect it with ugly
__STDC_WANT_LIB_EXT1__ 1
why (to say) Orinius did not put printf() under it...
Quote from: dizergin on March 10, 2015, 06:56:03 PM
yet, gets_s() is recommended for usage instead gets() and it is included in the standart C library, so i can see (at the first sight) no reason to protect it with ugly
__STDC_WANT_LIB_EXT1__ 1
why (to say) Orinius did not put printf() under it...
It is required by standard see (https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=121143577) for compliance tests. The preprocessor predefined macro __STDC_LIB_EXT1__ exists in PellesC.
Quote from: frankie on March 10, 2015, 10:46:33 PM
Quote from: dizergin on March 10, 2015, 06:56:03 PM
yet, gets_s() is recommended for usage instead gets() and it is included in the standart C library, so i can see (at the first sight) no reason to protect it with ugly
__STDC_WANT_LIB_EXT1__ 1
why (to say) Orinius did not put printf() under it...
It is required by standard see (https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=121143577) for compliance tests. The preprocessor predefined macro __STDC_LIB_EXT1__ exists in PellesC.
yes, yet it is end-user optional and it was introduced in c11 (
NOT C99), so C99 user must know nothing about it or not?
Quote from: dizergin on March 11, 2015, 01:55:41 AM
yes, yet it is end-user optional and it was introduced in c11 (NOT C99), so C99 user must know nothing about it or not?
Theoretically should not exist in C99, but why to remove it? It can be helpfull anyway. May we consider it a non standard C99 function? ;)
gets_s() exist in MSVC, so it should be available even before C11.
Quote from: frankie on March 11, 2015, 11:55:37 AM
Quote from: dizergin on March 11, 2015, 01:55:41 AM
yes, yet it is end-user optional and it was introduced in c11 (NOT C99), so C99 user must know nothing about it or not?
Theoretically should not exist in C99, but why to remove it? It can be helpfull anyway. May we consider it a non standard C99 function? ;)
i talk another thing of! - gets_s() is introduced as PART OF STANDART ISO C LIBRARY (since C99). So EVERY program compiled with C99 compliant compiler must proceed through without any warning upon!
Yet gets() was EXCLUDED from STANDART ISO C LIBRARY (since C11) so any C11 compiler must generate ERROR upon (also C99 compiler must warn upon)!
Of course gets() may exist for backward compatibility (in C11 mode).. or as peculiar Pelles C feature in this case it is matter of extenstion compiler option, extra library header, or protective macro definition ( just as _USE_MATH_DEFINES for M_PI.... GNU C extension)
Quote from: TimoVJL on March 11, 2015, 12:37:26 PM
gets_s() exist in MSVC, so it should be available even before C11.
I think It should for it is integral part ISO standart library since C99 and Pelles C claims itself to be ISO compliant. MS so far as I know has never been bothering itself about any compatibility with ISO... Yet in the last VS2013 they are almost wipe out C from regular projects...
gets_s is not in WG14/N1124 document ?
What document you refer ?
Quote from: TimoVJL on March 11, 2015, 03:27:35 PM
gets_s is not in WG14/N1124 document ?
What document you refer ?
I just browse through a bunch documents with gets_s() - they are :( drafts. So as say Frankie "technically" - pure C99 compiler must warn on gets() (and Pelles C does) C11 must prohibit compiliation (Pelles C just warns). Concerning gets_s() both C99 and C11 compliants must prohibit compiliation (Pelles C passes with warning) like
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("%f",sqrt(2.0));
return 0;
}
with the same message... and that is bug
Just a moment you are missing something.
The warning/deprecation mechanism pass through the preprocessor and ISO headers, and an hedaer cannot block the compiler itself. This is correct because, while the standard library function gets() could be deprecated by ISO, no parts of the standard exclude taht you can create your own routine called gets() or any other function.
Moreover you can exclude standard libraries and header and compile something in native mode or whatever (I wrote a sample OS using PellesC that way, it is in contrubutions).
Quote from: frankie on March 11, 2015, 05:09:15 PM
Just a moment you are missing something.
The warning/deprecation mechanism pass through the preprocessor and ISO headers, and an hedaer cannot block the compiler itself. This is correct because, while the standard library function gets() could be deprecated by ISO, no parts of the standard exclude taht you can create your own routine called gets() or any other function.
Moreover you can exclude standard libraries and header and compile something in native mode or whatever (I wrote a sample OS using PellesC that way, it is in contrubutions).
I am aware of, but I talk about safety of the standart library level - just look upon sqrt() example - it is just passed by with no any math.h header declaration, on the other hand you can not reach out M_PI without redefinition or _USE_MATH_DEFINES (defined within the same math.h header). Yet I were quite assured that it is safe to make C program on std lib level...
I see :)
But C is not a strong checking language... :)