Syntax for union parameter

[Ben Bacarisse]

The #define _TEST_ME line is commented out.

Ah, I see. Your "must be uncommented" confused me. There is no need to
un-comment that line to define _TEST_ME.

Yes. It's not C. The extension on sha1.cpp is .cpp.

Sure. I thought you'd want to call it C since you've been talking about
C all this time. Anyway, just replace C with C++:

Does that make it not C++ anymore? I.e. is there some stuff related to
VS that makes it compile there when it won't just by giving the file to
a compiler?

You've answered this elsewhere. For some odd reason, this code in not
intended to be compiler like any other translation unit, but it is to be
#included. Obviously that can provide the code with almost any possible
environment, so the fact that is does not compile directly is
irrelevant. I won't comment on the merits of this, I'm sure it's right
for you.

<snip>

 

[glen herrmannsfeldt]

(snip, someone wrote)

For some reason I was thinking that twos complement didn't allow trap
representations. Silly me.

Even without it, programs have to be careful with that value.
Among others, -x or abs(x) gives a negative result.

Although the test actually works for what most people are probably
assuming when they specify twos complement. In the case of ones
complement or sign/mag, the trap value doesn't reduce the range (it
just replaces the negative zero).

The possibility of trap representations and negative zero are
good reasons to avoid signed types for bit manipulation.

Maybe someone should start building more such machines to
force C programmers to shape up and code right.

-- glen

 

[James Kuyper]

What's the problem with testing -1 & 3? You get 3, 2 or 1 depending on
whether ints are represented using 2's complement, 1's complement or
sign-magnitude.

No, you get 3, 2, or 1 depending upon whether intmax_t is 2's
complement, 1's complement, or sign-magnitude. In principle, 'int' can
be different. The only types who's properties can be tested directly in
the preprocessor are intmax_t and uintmax_t.

It's not a big issue in real life, of course. Anything other than 2's
complement is very rare these days, and systems where two signed types
are supported that handle negative values differently are even rarer.

 

[Ben Bacarisse]

No, you get 3, 2, or 1 depending upon whether intmax_t is 2's
complement, 1's complement, or sign-magnitude. In principle, 'int' can
be different. The only types who's properties can be tested directly in
the preprocessor are intmax_t and uintmax_t.

Ah yes, of course. Curiously I checked that with the other posted
solutions and the forgot for my own suggestion!

It's not a big issue in real life, of course. Anything other than 2's
complement is very rare these days, and systems where two signed types
are supported that handle negative values differently are even rarer.

Non 2's complement implementations are peculiar enough and rare enough
that that I think one should be prepared for the worst. For example, a
32 bit 1's complement machine has not 64 bit ints and to satisfy C99 the
implementation just uses a simple software implementation using 32 bit
unsigned ints. If it were mine to write, I'd implement 2's complement
arithmetic.

 

[Ike Naar]

Even without it, programs have to be careful with that value.
Among others, -x or abs(x) gives a negative result.

The behaviour of abs(x) is undefined for that value:

7.22.6.1 The abs, labs and llabs functions
[...]
Description
2 The abs, labs, and llabs functions compute the absolute value of an
integer j. If the result cannot be represented, the behavior is
undefined. 304)
[...]
304) The absolute value of the most negative number cannot be
represented in two's complement.

 

[glen herrmannsfeldt]

(snip, I wrote)

The behaviour of abs(x) is undefined for that value:

7.22.6.1 The abs, labs and llabs functions
[...]
Description
2 The abs, labs, and llabs functions compute the absolute value of an
integer j. If the result cannot be represented, the behavior is
undefined. 304)
[...]
304) The absolute value of the most negative number cannot be
represented in two's complement.

OK, but yes, the most natural value (complement all bits and add
one) you get the original value back, and you also get overflow.

As well as I remember, the effects of overflow are always
undefined.

In any case, and especially in the case of UB, you might
get a negative value from abs(x).

-- glen

-- glen

 

[David Brown]

One feature I would love to see in the standards - which would require
more work from the compiler and not just a typedef - is to have defined
integer types that specify explicitly big-endian or little-endian
layout. Non-two's-complement systems are rare enough to be relegated to
history, but there are lots of big-endian and little-endian systems, and
lots of data formats with each type of layout. I have used a compiler
with this as an extension feature, and it was very useful.

[...]

Implementing arithmetic on foreign-endian integers strikes me as
a waste of time. If I need to read and write big-endian integers
on a little-endian machine (a common requirement, since network
protocols typically often big-endian), I can just convert big-
to little-endian on input and little- to big-endian on output.

And POSIX provides htonl, htons, ntohl, and ntohs for exactly that
purpose ("h" for host, "n" for network).

There are no such functions that will convert between big-endian
and little-endian on a big-endian system, but such conversions are
rarely needed (and it's easy enough to roll your own if necessary).

https://en.wikipedia.org/wiki/Endianness

It might be a waste of time for /your/ sort of programming, but it is
not a waste of time in embedded systems. I don't often need to convert
endianness, but it certainly happens on occasion - and compilers that
have extensions allowing data to be declared in a particular format make
it easier to write clearer code in such cases. It means the format
choice is made at the declaration of the data (or data types), avoiding
extra function call syntax when the data is used, and avoiding the
possibility that the function call syntax is forgotten. It also means
that you write more portable code, because it is easy and cheap to
declare the endianness of transferred data even if you know it is the
same as your current target.

Posix functions don't help here - we are a /long/ way from posix on such
systems. And the necessity of specifying the sizes in the posix
functions is an extra layer of complication on embedded systems, where
such transferred data often has varying data sizes. And of course,
there are plenty of times when you might want to access little-endian on
big-endian architectures, for which Posix does not help.

Different types of programming needs (or wants) different features - a
standards defined way of declaring the endianness of data and types
would be a useful feature for many people, and save a lot of
roll-your-own solutions.

 

[Jorgen Grahn]

I've just completed my first project in C, very simple, very basic first
year computer science stuff, A 'Bounded Array' component and an
encapsulated Linked List and a Stack and FIFO Queue that 'extended' the
List by using only selected functions that 'make sense' in terms of
those latter two structures. Everything is done with pointers for
maximum flexibility, no assumption is made about the 'type' of data
stored and there are no hard coded 'magic numbers'

I spent 10% of the time figuring out the logic and writing code and 90%
of the time fretting about whether there was some arcane rule that I had
violated that meant that although the thing worked as far as I could
tell there was no way of actually knowing because unless I read and
inwardly digested the entire language spec something may be 'undefined' ...

This is my particular problem at the moment, something can appear to
work no matter how hard I test it yet still be 'undefined' in terms of
the language spec ... it just makes me feel uneasy.

Oh yes, and apart from never wearing brown shoes I don't 'do fashion'

But I'm thinking to myself: "well, maybe he was damaged by the
'undefined' scare people without actually being one of them ..."

I don't know ... I think worrying about it (especially when security
is involved) is a honorable thing to do. And painful.

I don't worry too much, but I don't know if it's because I've amassed
20 years of experience so I'm now a C demi-god, or if I'm simply a bit
more sloppy than you.

If
- my code compiles without warnings with 'gcc -W -Wall -pedantic
-std=c99'
- I've reviewed all casts and uses of void*
- I'm happy with it in general
- it runs well in practice and produces no Valgrind warnings

then I'm happy with it. As an extra bonus I can run it on both
AMD64 and PowerPC.

And in the end, code doesn't usually have to be free from bugs.
You can almost always apologize, and fix them.

And how long do you think this can go on for? Will 'the committee' still
be determined to support a Babbage difference engine in 100 years time.

*shrug* That's their problem -- and unrelated to what we're discussing
here, I think. I was merely trying to explain what kind of
environment C grew up in.

How can something progress and improve when it has to support everything
that ever existed?

Replacement is the best solution, I think. But it will not happen
anytime soon.

/Jorgen

 

[James Kuyper]

On 02/09/2014 11:51 AM, Robbie Brown wrote:
....

And how long do you think this can go on for? Will 'the committee' still
be determined to support a Babbage difference engine in 100 years time.

I don't think so - I doubt that it's supported now. You might be
thinking of his Analytical Engine? It's Turing complete, so it might be
possible, but there's probably some requirement of the C standard it
would have difficulty meeting.