[308] in netbsd-help mailing list archive

home help back first fref pref prev next nref lref last post

Re: gcc on NetBSD..

daemon@ATHENA.MIT.EDU (John Hawkinson)
Fri Sep 1 11:45:49 1995

Date: Fri, 1 Sep 1995 11:45:01 -0400
To: I-Lin Wang <ilin@MIT.EDU>
Cc: netbsd-help@MIT.EDU
In-Reply-To: "[307] in netbsd-help mailing list archive"
From: John Hawkinson <jhawk@MIT.EDU>

> 	  When I compiled my .c code, this gcc is from my machine, not from
> /mit/cygnus, right?

Correct. Note that if you want to, you can use gcc from the gnu locker.

> I found it will always has the warning message:
> 	  
> /usr/include/machine/types.h:67: warning: ANSI C does not support `long long'
> 	  
> 	  Although my code was still compiled, I am afraid this warning my
> produce some troulbes in the future.

The warning means what it says. NetBSD and other 44BSD-based operating
systems use a 64-bit value for a number of their system function
calls (off_t is a 64-bit number, for intance). This is a gcc extension,
and is not necessarily supported by ANSI C. This should not be
a portability issue, since your programs should not make explicit
assumptions about the lengths of various system data types, nor should
they prototype system library functions (because such functions should
be prototyped in system include files). If you tried to use a non-GNU
strict ANSI compiler under NetBSD you might have some problems, but
no such compilers exist.

I've attached the gcc documentation on "long long" for your reference.

> When I compiled this code in Athena workstation, there is no such
> message.

Normally you shouldn't see that error unless you compile with

	gcc -pedantic

or

	gcc -ansi -pedantic

Errors generated from -pedantic are not necessarily errors. ``webster'
defines pedantic as:

	one who is unimaginative or who unduly emphasizes minutiae in the 
	presentation or use of knowledge

In particular, the gcc manual notes ```-pedantic' causes warnings for
many GNU C extensions.'' It further states:

     This option is not intended to be useful; it exists only to satisfy
     pedants who would otherwise claim that GNU CC fails to support the
     ANSI standard.

> Could anyone tell me what's going on? Is the gcc here in NetBSD
> really reliable enough??

As above, it's not a reliability issue. It's what is supposed to
happen.


--jhawk


Extensions to the C Language Family
***********************************

   GNU C provides several language features not found in ANSI standard
C.  (The `-pedantic' option directs GNU CC to print a warning message if
any of these features is used.)  To test for the availability of these
features in conditional compilation, check for a predefined macro
`__GNUC__', which is always defined under GNU CC.

   These extensions are available in C and Objective C.  Most of them
are also available in C++.  *Note Extensions to the C++ Language: C++
Extensions, for extensions that apply *only* to C++.

Double-Word Integers
====================

   GNU C supports data types for integers that are twice as long as
`long int'.  Simply write `long long int' for a signed integer, or
`unsigned long long int' for an unsigned integer.  To make an integer
constant of type `long long int', add the suffix `LL' to the integer.
To make an integer constant of type `unsigned long long int', add the
suffix `ULL' to the integer.

   You can use these types in arithmetic like any other integer types.
Addition, subtraction, and bitwise boolean operations on these types
are open-coded on all types of machines.  Multiplication is open-coded
if the machine supports fullword-to-doubleword a widening multiply
instruction.  Division and shifts are open-coded only on machines that
provide special support.  The operations that are not open-coded use
special library routines that come with GNU CC.

   There may be pitfalls when you use `long long' types for function
arguments, unless you declare function prototypes.  If a function
expects type `int' for its argument, and you pass a value of type `long
long int', confusion will result because the caller and the subroutine
will disagree about the number of bytes for the argument.  Likewise, if
the function expects `long long int' and you pass `int'.  The best way
to avoid such problems is to use prototypes.

home help back first fref pref prev next nref lref last post