public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* (1) C and C++ (2) gets() and fgets()
@ 2011-12-26 20:22 Matthew D. Gutchess
  2011-12-26 21:42 ` Sam Varshavchik
  0 siblings, 1 reply; 2+ messages in thread
From: Matthew D. Gutchess @ 2011-12-26 20:22 UTC (permalink / raw)
  To: gcc-help

Hi, 
    My goal is to learn how to write windows-type programs in C++, so to update my programming skills, I am compiling and running sample C and C++ programs.  

    (1) C versus C++.  The ".h" is not used in C++ include files, correct?  I assume that C and C++ object files can be linked into an executable, but are C and C++ incompatible with each other?  Should one use C or C++ or are the two dialects compatible?  What can one accomplish in C++ that cannot be accomplished in C?  

    (2) Man pages state that gets() is "dangerous" because it can be used to purposely cause buffer overflows and recommend using fgets().  gets() accepts input from stdin, but fgets() accepts input from stream.  

For example, how would the program below be modified to use fgets() instead of gets()?:
/*

 * L I S T _ 3

 *

 * Display the contents of an ASCII text file

 * file on the user's screen.

 *

 */



#include <stdio.h>



#define MAXPATH 64

#define MAXLINE 256



int

main(void)

{

	int ch;                 /* input character */

	FILE *fp;               /* file pointer */

	char pathname[MAXPATH]; /* filename buffer */

	char line[MAXLINE];     /* line buffer for fgets() */



	/*

	 * Prompt the user for a filename and read it.

	 */

	printf("Filename: ");

	gets(pathname);

	if (*pathname == '\0')

           {

                printf("\n\n File not found. \n");

		return (0);

           }

        else

           {

  	    /*

	     * Open the named file for reading.

	     */

	    fp = fopen(pathname, "r");



	    /*

	     * Read the contents of the file and display it

	     * a line at a time as it is read.

	     */

	    while (fgets(line, MAXLINE, fp) != NULL)

		fputs(line, stdout);



	    /*

	     * Close the file.

	     */

	    fclose(fp);

            }

        

	return (0);

}

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: (1) C and C++ (2) gets() and fgets()
  2011-12-26 20:22 (1) C and C++ (2) gets() and fgets() Matthew D. Gutchess
@ 2011-12-26 21:42 ` Sam Varshavchik
  0 siblings, 0 replies; 2+ messages in thread
From: Sam Varshavchik @ 2011-12-26 21:42 UTC (permalink / raw)
  To: gcc-help

[-- Attachment #1: Type: text/plain, Size: 3092 bytes --]

Matthew D. Gutchess writes:

>     (1) C versus C++.  The ".h" is not used in C++ include files, correct?

Not really. There's nothing wrong with including a .h from a C++ include  
file. The only thing to watch out for is that the C include should be "C++  
aware", that is, if processed as C++ source, it conditionally wraps all  
declaration into extern "C" linkage. This is most certainly the case with  
your system headers.
 
> I assume that C and C++ object files can be linked into an executable, but  
> are C and C++ incompatible with each other?

C++ translation units can certainly be linked with, and C++ code, can call C  
code, if functions C functions are declared with "C" linkage:

extern int foo();

Compiled as C, this declares a C function foo(). Compiled as C++, the code  
would expect to call a C++ function foo(), which is not the same. For C++,  
if it's declared as

extern "C" int foo();

Then the C++ translation unit will use C linkage, and be able to call the C  
function foo(). Conversely, a C++ function can also be, carefully, declared  
with C linkage, allowing it to be called from. But just because it can, is  
obviously not the whole story. C, for example, doesn't know anything about  
C++ exceptions, and may not have any idea what to do with a thrown  
exception, if some C function is in the call stack.

If you carefully unwrap your system header files, stdio.h would be a good  
example, and trace all the preprocessor stuff in there, somewhere you'll  
find in there something along the lines

#if defined(__cplusplus)
extern "C" {
#endif

…

#if defined(__cplusplus)
};
#endif

This may not exactly match what you see on your platform, but you'll have  
something very similar. All the meat in stdio.h gets shoved in the middle.  
When processed as C, all the declarations are visible directly. When  
processed as C++, the predefined "__cplusplus" preprocessor symbol makes  
everything declared inside extern "C" linkage, making all C library  
functions from stdio.h callable from C++ translation units. The same goes  
for all other system header files.

>                                             Should one use C or C++ or are  
> the two dialects compatible?  What can one accomplish in C++ that cannot be  
> accomplished in C?

Well, exceptions for once. Templates, for another. There's no real  
equivalent to templates, in C. Then this whole object-oriented thing…

>     (2) Man pages state that gets() is "dangerous" because it can be used to  
> purposely cause buffer overflows and recommend using fgets().  gets()  
> accepts input from stdin, but fgets() accepts input from stream.

stdin is an ordinary stream.

> For example, how would the program below be modified to use fgets() instead  
> of gets()?:

> 	printf("Filename: ");
>
> 	gets(pathname);

fgets(pathname, sizeof(pathname), stdin);

Plus some error checking would be nice here, too.

But, this is really C, not C++. With C++, you would use std::cin, and  
std::getline().



[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2011-12-26 20:22 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-26 20:22 (1) C and C++ (2) gets() and fgets() Matthew D. Gutchess
2011-12-26 21:42 ` Sam Varshavchik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).