Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Who owns the variable in my header file ?

Reply
Thread Tools

Re: Who owns the variable in my header file ?

 
 
Keith Thompson
Guest
Posts: n/a
 
      10-04-2012
lipska the kat <(E-Mail Removed)> writes:
[...]
> According to man gcc on my Ubuntu Linux 12.04 64 bit machine
> 89,90 are fully supported whereas support for 99 onwards is 'limited'
> Compiling with the -ansi switch compiles to the 89/90 spec which
> reinforces my opinion that 90 is the one for me.


C89 and C90 are exactly the same language. The history is that
ANSI (the US standards body) issued the first C standard in 1989.
In 1990, ISO (the international standards body) issued its version of
the C standard; it added some introductory material and renumbered
the sections, but made no other changes. ANSI then officially
adopted the ISO standard. This is the version of the language
that's commonly referred to as "ANSI C", though ANSI itself no
longer recognizes it. It's also the version described in the second
(and final) edition of K&R (The C Programming Language, by Kernighan
& Ritchie).

There was an amendment in 1995.

ISO issued a new standard in 1999, and another in 2011; these
are referred to as C99 and C11, respectively. Both of these were
originally issued by ISO, not ANSI, and ANSI officially adopted
both as-is after ISO issued them.

gcc has excellent support for C90, very good support for C99
(see <http://gcc.gnu.org/c99status.html>), and is working on C11
support. The library (most of it) is a separate project from gcc
(the compiler), and implementations generally use different libraries
on different systems. Linux systems use the GNU libc (glibc).

At this point, the only real reason to avoid C99-specific features
is if you need your code to compile with Microsoft's C compiler;
Microsoft has stated that they don't intend to support C past the
C90 standard.

> There are also a whole bunch of gnu dialects
> but my brain imploded at this point so I went to the pub


Yes, gcc implements a number of its own extensions to the
language (as the standard permits). Use "-std=c99 -pedantic", or
"-std=c11 -pedantic" if you're brave, if you want warnings about
non-portable code. Use "-ansi -pedantic" for maximum portability --
but then you're cutting yourself off from newer language features.
Use "-std=gnuxx", where "xx" is a year number, if you want to use
gcc-specific extensions -- but then you're cutting yourself off from
portability to other compilers (except for some that implement the
GNU extensions).

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      10-05-2012
lipska the kat <(E-Mail Removed)> writes:
> On 05/10/12 00:08, Keith Thompson wrote:
>> lipska the kat<(E-Mail Removed)> writes:

>
> [snip]
>
>> At this point, the only real reason to avoid C99-specific features
>> is if you need your code to compile with Microsoft's C compiler;
>> Microsoft has stated that they don't intend to support C past the
>> C90 standard.

>
> It seems to me that the C specification plays a far more important role
> in the life of a C developer than the specifications of other languages
> play in the lives of developers in those languages. I'm afraid I have to
> admit that in the past I have been guilty of using a
> (particular)language without understanding it's specification, not sure
> I can be so careless with C.


I'm not at all sure that it does so for *most* C developers.
(It's been observed that the Ada programming community is unusual in
that most developers have, and actually use, a copy of the language
reference manual.)

One of C's strongest features (and greatest potential pitfalls)
is that it permits you write blatantly *non-portable* code when
you need to. That often means having to be familiar with whatever
extensions your compiler provides. It's often necessary if you
want to get "close to the metal" (or silicon, or whatever).

Not all code needs to be, or even can be, portable.
My own preference (and recommendation) is to write portable
standard-conforming code unless there's a good reason not to,
and if you need to write non-portable code, to be *aware* of it.

[...]

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Angel
Guest
Posts: n/a
 
      10-05-2012
On 2012-10-05, lipska the kat <(E-Mail Removed)> wrote:
> On 05/10/12 00:08, Keith Thompson wrote:
>> lipska the kat<(E-Mail Removed)> writes:

>
> [snip]
>
>> At this point, the only real reason to avoid C99-specific features
>> is if you need your code to compile with Microsoft's C compiler;
>> Microsoft has stated that they don't intend to support C past the
>> C90 standard.

>
> It seems to me that the C specification plays a far more important role
> in the life of a C developer than the specifications of other languages
> play in the lives of developers in those languages. I'm afraid I have to
> admit that in the past I have been guilty of using a
> (particular)language without understanding it's specification, not sure
> I can be so careless with C.


You're far from alone there. You wouldn't believe the amount of C code
that works fine on x86, but breaks on sparc, powerpc or even x86_64, all
because the programmer is making assumptions that may be true for x86
but are not guaranteed by any standard.

The size of an int is a common one, or the order of bytes. If you write
your code assuming that an int is 4 bytes stored little-endian, your code
will probably work on x86 but fail on the other architectures I mentioned.
(sparc and powerpc are big-endian, and the size of an int on x86_64 is
likely to be 8 bytes)

Writing a non-trivial program portably is no small task, but saves a lot
of headaches when you want to port it to a different architecture.
Understanding what the C standard (or other standards like POSIX)
guarantee and what they don't is a key part of writing portable code.


--
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c
 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      10-05-2012
On Fri, 05 Oct 2012 11:38:22 +0000, Angel wrote:

> The size of an int is a common one, or the order of bytes. If you write
> your code assuming that an int is 4 bytes stored little-endian, your code
> will probably work on x86 but fail on the other architectures I mentioned.
> (sparc and powerpc are big-endian, and the size of an int on x86_64 is
> likely to be 8 bytes)


No it isn't. The common x86_64 platforms (Windows, Linux, OSX) all have a
32-bit int. Windows 64-bit also has a 32-bit long (Linux and OSX have a
64-bit long).

64-bit int is uncommon, partly because it means that you have two
standard 64-bit types (int and long) but either no standard 32-bit type
(if short is 16-bit) or no standard 16-bit type (if short is 32-bit).

And even if you have an int32_t type, types smaller than int get
promoted to int at the drop of a hat.

So a platform with a 64-bit int type ends up not being able to run code
which works fine on just about every other 32-bit and 64-bit platform,
effectively being a great "unportability detector" but annoying to
actually port code to.

 
Reply With Quote
 
Angel
Guest
Posts: n/a
 
      10-05-2012
On 2012-10-05, Nobody <(E-Mail Removed)> wrote:
> On Fri, 05 Oct 2012 11:38:22 +0000, Angel wrote:
>
>> The size of an int is a common one, or the order of bytes. If you write
>> your code assuming that an int is 4 bytes stored little-endian, your code
>> will probably work on x86 but fail on the other architectures I mentioned.
>> (sparc and powerpc are big-endian, and the size of an int on x86_64 is
>> likely to be 8 bytes)

>
> No it isn't. The common x86_64 platforms (Windows, Linux, OSX) all have a
> 32-bit int. Windows 64-bit also has a 32-bit long (Linux and OSX have a
> 64-bit long).


Point taken, I should have written "might be" instead of "is likely to
be", but that doesn't invalidate the point that it's wrong to assume
that sizeof (int) == 4.

Replace int with size_t, then. On every 64-bit OS I have tested, sizeof
(size_t) == 8 (and indeed sizeof (int) == 4), but I have seen many a
program where the programmer assumed that int will do in places where
size_t should be used...

[...]


--
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Who owns the variable in my header file ? Eric Sosman C Programming 46 12-19-2012 07:01 PM
Re: Who owns the variable in my header file ? Edward A. Falk C Programming 5 10-11-2012 08:30 PM
Re: Who owns the variable in my header file ? James Kuyper C Programming 0 10-04-2012 12:43 PM
Re: Who owns the variable in my header file ? Ike Naar C Programming 0 10-03-2012 07:52 PM
Re: Who owns the variable in my header file ? Kaz Kylheku C Programming 0 10-03-2012 07:40 PM



Advertisments