Character arrays

[Michael Mair]

Right. I thought that 0x.. constants were unsigned, I must
have been confusing that with some other situation
(although I can't think what).

Probably you thought of the printf/scanf format %x which
expects unsigned integers.

Cheers
Michael

 

[Dan Pop]

Assuming we want to use C99:
Which compiler/library combination conforming to the C99
standard would you suggest, then?

Any that claims C99 conformance. I haven't used any, so I can't have any
preferences.

Also note that gcc -std=c99 doesn't solve the C99 library conformance
issue by magic.

I fear so, too. I still hope that it's only a hen-egg problem: If one of
the widely used compilers would give us C99, it would start being used
and demanded in other compilers too.
As the gcc people still claim to aim for C99, I keep my hopes up.

I haven't noticed gcc making any progress since 2001. There is precious
little evidence that things are going to change any time soon and this
is not going to solve the library problem, anyway.

Yep. So I teach both, hoping for the best... :-/

IMHO, the resources spent on taching C99 would be better used on
clarifying the darker aspects of C89. If C99 ever catches on, the
transition would be trivial for any experienced C89 programmer. I already
went through the transition from K&R C (the language I've actually learned
from K&R1) to ANSI C and it was a piece of cake. C89 to C99 should be
even easier.

Granted. But _Bool is really not my reason for using C99; I am
not sure what the latter part of your sentence refers to.

The bulk of the new features in C99 (language and library) address
numerical analysis applications.

Yes. I also would like to have the types from <stdint.h>

To me, they look like a cure that is worse than the disease.

You can have (most of them, anyway) now, there are publicly available
implementations for C89 (e.g. http://www.lysator.liu.se/c/q8/index.html).

and designated initializers.

They look cute, but I've never had any real need for them. I'd rather
have compound literals instead, but I can happily live without them, too.

I find it more worrying that things like typeof have been kept
from us

Since no committee member had GNU C on his agenda, there was no real
attempt to give a serious look at the *many* very useful extensions
provided by GNU C, although they're nicely documented in a special
section of the gcc documentation. Apart from being good ideas, there
was also plenty of existing practice, as gcc is, by far, one of the most
popular implementations.

and that certain things are (still) so weak that they are
next to useless (e.g. volatile or bit fields).

volatile has its uses even in portable code (signal handlers) and bit
fields have never been meant to be used in portable code. Whether we
like to admit it here or not, C is still the language of choice for
low level (close to the hardware) programming where most of the things
cannot be done portably, anyway. So, the fact that your bit fields will
stop working when using a compiler for a different embedded control CPU
is not going to be much of a problem.

Apart from that and even though I am aware that this is a
_very_ controversial issue, I would have liked to see in addition
to the standard library sort of extended libraries covering
stuff which should not demanded for portable applications but
is more or less the object of reinventing the wheel for most
C programmers. These should really be kept apart from C as
such but could ease the way for "compatibility" between compilers
on mainstream systems. Could also be an additional standard.

The best you can find in this direction is POSIX and BSD socket support.
The latter seems to be "universally" available these days and the POSIX
curses library is supported on almost any platform where it makes sense.

There are also widely supported GUI libraries, but they are largely
ignored because they don't provide as much functionality/convenience as
the natively supported ones.

It would be nice to have all these things covered by platform neutral
standards, but the lack of such standards doesn't make the available tools
any less useful.

Dan

 

[Charlie Gordon]

Probably you thought of the printf/scanf format %x which
expects unsigned integers.

Or maybe that some of them are and some aint :

0x1 is signed or unsigned depending on context
0x80000000 is unsigned on architectures with 32 bit ints.
and so is 0xffffffff.

Chqrlie.

 

[Dan Pop]

0x1 is signed or unsigned depending on context

Could you point out a context where 0x1 doesn't have the type signed int?

0x80000000 is unsigned on architectures with 32 bit ints.
and so is 0xffffffff.

OTOH, the type signed int can represent the value of 0x1 on *any*
architecture.

The actual rules are a monument of inconsistency, so it's better to use
all the suffixes needed to get the desired type and make your intentions
perfectly clear to anyone who might be reading your code.

5 The type of an integer constant is the first of the corresponding
list in which its value can be represented.

|| |
|| | Octal or Hexadecimal
Suffix || Decimal Constant | Constant
-------------++-----------------------+------------------------
none ||int | int
||long int | unsigned int
||long long int | long int
|| | unsigned long int
|| | long long int
|| | unsigned long long int
-------------++-----------------------+------------------------
u or U ||unsigned int | unsigned int
||unsigned long int | unsigned long int
||unsigned long long int | unsigned long long int
-------------++-----------------------+------------------------
l or L ||long int | long int
||long long int | unsigned long int
|| | long long int
|| | unsigned long long int
-------------++-----------------------+------------------------
Both u or U ||unsigned long int | unsigned long int
and l or L ||unsigned long long int | unsigned long long int
-------------++-----------------------+------------------------
ll or LL ||long long int | long long int
|| | unsigned long long int
-------------++-----------------------+------------------------
Both u or U ||unsigned long long int | unsigned long long int
and ll or LL || |

If an integer constant cannot be represented by any type in
its list, it may have an extended integer type, if the extended
integer type can represent its value. If all of the types in the
list for the constant are signed, the extended integer type shall
be signed. If all of the types in the list for the constant are
unsigned, the extended integer type shall be unsigned. If the
list contains both signed and unsigned types, the extended
integer type may be signed or unsigned.

Note that this is inconsistent with the C89 rules, too, where an
unsuffixed decimal constant has type unsigned long if it cannot be
represented by the type long, while unsigned long long is not an
option in C99.

Dan

 

[pete]

0x1 is signed or unsigned depending on context

No. 0x1 is an expression of type int in any context.